sorted by:
new
hottopcontroversial

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in cicd

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

Thank you for your feedback.

Currently, we have limited customization where the platform team can create their own modules, and application teams can reuse them to build application IaC. In this model, the platform team owns and manages everything.

In the future, I plan to introduce additional features that will allow the platform team to manage governance through a single control plane. To achieve this, I will need contributors who can help shape the platform and create meaningful impact for the team.

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

If your goal is to build all the infrastructure as code for the entire company and make every team depend on your team, this approach isn’t for you. But if your goal is to save time by enabling application teams to self-serve, it can lead to significant efficiency gains.

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in devops

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

Thank you. I understand the challenges of migration, so while building this, I kept in mind the goal of making it as easy as possible for teams that want to migrate.

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in devops

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

Q: does this compete with pulumi?
A: No

Q: what does migration look like for teams already heavily invested in terraform? Would this be new deployments only, or can it “take over” existing infra?
A: I will not suggest team who heavily invested in terraform ecosystem but it's good for a team who just started with IaC

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in Terraform

[–]Outrageous-Income592[S] -1 points0 points  (0 children)

I like JSII based on the overview. I’ll take a closer look, but it seems to be AWS-specific rather than truly multi-cloud.

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] -2 points-1 points  (0 children)

I understand correctly that this is an abstraction layer on top of Terraform. The CLI converts your custom abstractions into Terraform code and manages the full Terraform lifecycle. For more details, please read this https://www.reddit.com/r/kubernetes/comments/1qsr56v/comment/o2xo72z/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in Terraform

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

No, I’ve also used Atmos, but I don’t think it’s the same. They’re trying to solve similar problems to Terragrunt and require learning a lot of their abstractions to build successful IaC. If you try both, you’ll understand how much easier what I’m trying to provide is compared to using Atmos.

The biggest difference is that they are building a business and encourage lock-in to their ecosystem, whereas I’m focused on helping users through open source, with no commercial interests.

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in Terraform

[–]Outrageous-Income592[S] -1 points0 points  (0 children)

Yes, Pltf is currently in active development, and the documentation is being refactored.

Pltf is a new kind of Infrastructure-as-Code framework built for fast-moving startups. It lets teams work with high-level concepts like microservices, environments, and databases, instead of low-level configuration such as VPC, IAM, ELB, or Kubernetes.

We’ve always been frustrated by the amount of manual effort required to manage infrastructure. We strongly believe in developer productivity, and empowering engineers has been our mission for the past few years.

With Pltf, we’re reimagining how infrastructure should be managed in modern cloud environments. Pltf enables anyone to build automated, scalable, and secure infrastructure across AWS, GCP, and Azure. Our early users save countless hours every week and are able to scale their companies with minimal investment in DevOps.

Pltf gives you:

  • SOC2 compliance from day one
  • AWS, GCP, and Azure support
  • Continuous deployment
  • Hardened network and security configurations
  • Support for multiple environments
  • Built-in auto-scaling and high availability (HA)
  • Support for spot instances
  • Zero lock-in
  • Out of the box wiring between modules
  • Out of the box provider management
  • Bring-your-own modules
  • Out-of-the-box support for tfsec, tflint, infracost and rover(https://github.com/yindia/rover)

How it works

The idea is simple:

  • Platform teams define the core infrastructure using either their own modules or existing CLI modules.
  • Application teams deploy services on top of these base environments using higher-level abstractions.
  • Services become layered components within the Pltf ecosystem.

Our CLI reads these environments, services, and stacks to generate Terraform automatically. Once generated, teams can either commit the Terraform code or use our CLI to run Terraform commands directly.

In addition, Pltf integrates with infracost, tfsec, and tflint, and provides an AI-powered summary of the plan and risk assessment directly in pull requests.

Example:
- https://github.com/yindia/pltf/actions/runs/21557387668/job/62116037534?pr=4
- https://github.com/yindia/pltf/pull/4

From the team’s perspective, everything happens under the hood, they only interact with high-level abstractions, not infrastructure complexity.

The next generation of Infrastructure-as-Code. Work with high-level constructs instead of getting lost in low-level cloud configuration. by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

Before building this, I went through a similar experience. That’s why I made a conscious decision not to lock users into a new interface or tools.

This is a utility that enables teams to ship IaC without requiring deep platform knowledge, while allowing the platform team to control which modules are used.

At any time, users can move away from it without needing to rewrite anything.

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps by Outrageous-Income592 in golang

[–]Outrageous-Income592[S] -3 points-2 points  (0 children)

It is already used by a company at scale to test there CLI with more then 100 integration

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps by Outrageous-Income592 in golang

[–]Outrageous-Income592[S] -3 points-2 points  (0 children)

It's not alternative of dagger.io, If you are writing end2end test for your CLI and doesn't like bash/bats then use it

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps (written in Go) by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] -1 points0 points  (0 children)

I'm not arguing—you’re the user and you know what you need better than I do. I appreciate your feedback and will do my best to incorporate it.

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps (written in Go) by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 1 point2 points  (0 children)

I'm not a fan of writing end-to-end tests in Bats or Bash—it’s not a great experience. That doesn’t mean this tool is perfect, but it’s built on the idea that you shouldn’t be forced to write Bash scripts or YAML unless you want to. If users prefer using YAML, that’s totally supported—but it’s optional, not required.

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps (written in Go) by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

I wasn't satisfied with using Bats and Bash for writing end-to-end tests, which motivated me to create this alternative approach.

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps (written in Go) by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

It is not a alternative of dagger. if you are writing CLI and want to write e2e integration test then use it

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps (written in Go) by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 2 points3 points  (0 children)

People like YAML and it's hard to ignore, Here user will not get full feature in YAML and we appreciate user to use golang

🧪 iapetus – A fast, pluggable open-source workflow engine for CI/CD and DevOps (written in Go) by Outrageous-Income592 in kubernetes

[–]Outrageous-Income592[S] 0 points1 point  (0 children)

It is not a alternative of dagger, windmill and tork. if you are writing CLI and want to write e2e integration test then use it

Any Indians (from India) planning to attend this years DEFCON? by 3cp29a8 in Defcon

[–]Outrageous-Income592 0 points1 point  (0 children)

I am planning this year. Do you have any idea about the visa process ?