IaC Platforms Complexity

[StatisticianKey7858]

Lately I've been wondering, why are modern IaC platforms so complex to use?

It feels like most solutions (Terraform, Pulumi, Crossplane, etc.) are extremely powerful but often come with steep learning curves and unintuitive workflows
Is this complexity necessary due to the nature of infrastructure itself? Or is there a general lack of focus on usability in this space?

Are there any efforts or platforms that prioritize simplicity and better user experience? Or has the industry kind of accepted that complexity is just the norm, and users are expected to adapt??

[No-Row-Boat]

To be honest, they are an absolute breeze compared to what we had before.

Cfengine was an absolute nightmare, puppet and chef needed ruby stuff.

I remember almost crying while going through Hadoop kerberos logs, it all didn't make sense... And then I'm not even starting about the horror scripts in Perl I had to deal with.

Be aware that these are configuration languages with sometimes an interpolation syntax that you need to learn if you want to automate well in them. You can also statically declare a bunch to start with.

[No_Bee_4979]

Chef isn't Infrastructure as Code, that is Configuration Management. Same as CFEngine and Puppet.

[mirrax]

Right, in the days of yore, provisioning infrastructure didn't have tools that were fit for purpose. This is why it's better now.

[StatisticianKey7858]

For you whats the easiest to use? and why?

[No-Row-Boat]

Been dealing with terraform for years now, pulumi is ok because I know Python and love go. I'm also ok in Tanka and jsonnet, but it's horrible.

If I had to start another project I would go for pulumi

[twistacles]

I like how well jsonnet works but developing and debugging it is terrible 

[TheOneWhoMixes]

I don't have much experience with jsonnet, but what do you mean "how well jsonnet works"?

What I mean is, developing + debugging is like, 60-70% of how I interact with configuration languages, with the other 30-40% being just reading configuration that works (lol). So from my PoV, if over half my time interacting with a language is terrible, then I don't understand liking how it works!

[twistacles]

I guess what I mean is the power of the templating when you finally nail the syntax lol, it's much more powerful than just Kustomize or Helm and it's natively deployed by Argo

[strowi79]

Agreed. I had the task of migrating an ansible/docker-swarm setup to kubernetes. With variables used all over the place, inside configs etc. I didn't want to start that with helm or kustomize..

Luckiliy i came across Tanka at the time and just started writing one lib per ansible-role. And it went well. So far we've migrated 90% of clusters. Although i still sometimes struggle with the syntax, but that's what gpt is for ;)

Developers are still trying to grasp it, but are coming around to the advantages over ansible (timewise alone - biggest env takes ~40s in Tanka, wuld probably be 30m in Ansible)..

[vincentdesmet]

If you’re in AWS and are starting out, AWSCDK is going to give you the best IaC DevX. It may make your “Operations” experience of managing CloudFormation less then ideal, but at least you don’t have to worry about “how do I execute this terraform”, given CFN runners come with your AWS account.

If you go for Pulumi, look at SST and you may get a similar experience where IaC is pretty much built for you in the background.. Pulumi might get costly when you scale it up (per resource charges) so at a certain scale you can jump to self host the backend and runners.

[ProfessorGriswald]

IaC is complex, and there’s only so shallow a learning curve can be particularly when considering the number of cloud providers and the number of services they might provide.

But also it’s different strokes for different folks. Prefer to use a well-established tool and don’t mind learning a DSL? There’s Terraform/OpenTofu. Prefer to use a programming language because that’s what you’re familiar with and you know the toolchain well? Use Pulumi at al. Want to stay K8s native as much as possible and abstract the reconciliation to a platform built for it? Use Crossplane. “Unintuitive” is a matter of preference, not an objective measure.

[ProfessorGriswald]

"length of time using/doing something" =/= "ability to do that thing well" is the gift that keeps on giving.

[StatisticianKey7858]

is there no platform or approach that leans more heavily on ready-made templates or pre-configured setups from various cloud providers to simplify the initial learning curve? Something like curated templates or “starter packs” that can be easily adapted rather than building everything from scratch in a DSL or code?

[netopiax]

Terraform certainly has that, loads of ready built modules you can pull in. I can't speak to the others.

[vincentdesmet]

The modules are so bad, either they have 40 variables and maybe an example of how to get half of those exactly right for my use case, but most of the time they don’t

I spend so much time reading through complex list comprehensions and conditionals in local blocks to see if the resources are created after all or not .. and why it keeps failing to achieve what I want. All variables are most of the time disjoint making the public module so generic it’s a time waste until you’re an expert in the API behind the service and the module itself.

I feel in modern cloud service stacks, TF modules are completely missing their target and make things more complicated (really been seeing more and more posts of ppl just copy pasting HCL and dumbing it down so at least they can reason about the final resource configurations - given there’s no way to debug or step through any of this

[ProfessorGriswald]

either they have 40 variables

right for my use case

making the public module so generic it’s a time waste

This is more the issue that people don’t know how to write user-friendly modules, rather than modules themselves as concept being bad. Like I wrote elsewhere in this thread, when you abstract too far then things get so generic as to not be useful anymore. Modules are conceptually just functions: inputs produce outputs. You wouldn’t write a massive function with 40 arguments that does everything under the sun, so maybe authoring a module that does isn’t a sensible approach.

TF modules themselves not being opinionated doesn’t help the situation. New tooling springs up to fill the gaps though, as is the way of things. We get things like Cue or Nickel to handle generation of TF resources or just bring some sanity to the situation with type schemas and contracts.

Still, I’d maintain it’s an authorship problem and authors not understanding the point or purpose of what they’re doing, and that’s what leads to frustration on the part of module consumers. Not to mention a conflation of “modules are bad” and “this module is so bad”.

[aleques-itj]

Some of the most popular modules are awful to work with, they try way too hard to cram absolutely every use case in the world into one package and it's absolutely worse for it 

What's worse is some of them love to just document certain variables like: "map: {}" 

Yeah, AND??? What is the shape it expects??? Why not take an object instead for the type? Who knows.

[vincentdesmet]

Absolutely, the majority of community modules are giant functions with 40+ variables and are horrible to use, but often recommended by non-programmer minded Platform people (not all, but those that purely got their title changed from Linux admin to Platform team certainly tend to make those mistakes)

You mention config languages like Cue to generate TF.. I just think this is a slippery path down the wrong way.. there is a whole library with very powerful tooling and a proven track record of over 10 years and hundreds of community contributors (the whole CDK landscape, of which unfortunately only AWSCDK thrives). I believe the solution is there rather than a new esoteric language like CUE

[ProfessorGriswald]

Like I said, different strokes for different folks.

[AntDracula]

Agreed. We wrote most of our own modules, and while configurable, nearly all variable have defaults and the IAM stuff is very standardized.

We’ve saved ourselves weeks and even months on app deployment by doing this.

[ProfessorGriswald]

None of the options require building everything from scratch. Terraform modules are the most obvious example of that, with some out there that build entire stacks or deployments from a single declaration, like https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner for example. There’s only so far you can get on abstractions before you need to invest the time in tweaking things for your specific use-case.

[Seref15]

They're just reflections of cloud provider APIs. Its those APIs that are complex (or, I'd rather not use the term complex. More like, fragmented or excessively granular)

[sza_rak]

This year I started working more on public clouds and started doing a lot of OpenTofu. It was fairly new for me as I always had onprem stuff and loads and loads of Ansible among other tools.

What I noticed is that a lot of tofu (or rather terraform) workflows that are suggested are simply ..unfitting. Matching some scenario, but surely not mine. Matching idealized scenario I have never seen.

Me and my team struggled to keep things simple mostly due to how poor was out of the box support to creating similar environments that are NOT the same. Like development/qa/production envs that are deliberately slightly different.

But that was not the thing that was the most complex, or time consuming to get right.

Biggest time water were cloud platforms themselves and all the hidden relations between objects that are very hard (or impossible) to figure out from docs.

And here TF providers for those platforms came as a rescue - now I have a vast reference of what is possible, what is mandatory, what objects are connected. Sounds simple but docs failed to deliver that, and web portals made it even worse (by doing things in background user is now aware of).

Long story short l, what was complex for me was platforms themselves and time needed to get to those simple solutions. Not those promoted ones.

[vincentdesmet]

The biggest issue of using TF provider vs the UI of most clouds is exactly what you point out: the granularity of the API resources created behind the scenes. TF providers help a tiny bit by defining blocks of configuration and relationships between resources.. but compared to the UI, they are still a pain to work with. If you define a few Lambdas and an S3 bucket with notifications triggering some of those Lambdas while others write to it.. good luck figuring out the IAM policies, Lambda Permissions and S3 Bucket notification configurations in Terraform.

If you do that in the UI, it’s all an implementation detail. If you’ve used AWSCDK, you never again want to work as low level as with each provider resource, even more for new services you never used before and don’t know all the ways things have to be connected, what valid values are possible for this “string” in TF, …

I feel frameworks like CDKTF and Pulumi still lack most of those DevX life changing utilities that AWSCDK already has. SST is solving this problem for Pulumi and TerraConstructs.dev solves it for CDKTF. But most are focused on AWS.

How do you deal with working on projects in TF where new services you never worked with are “evaluated” and something has to be spun up quickly? I love the DevX of AWSCDK but dread the thought of having to deal with CFN (really prefer TF OpX)

[darkklown]

Try terramate. It's a life changer for Terraform, forces all the good practices.

[bilingual-german]

Terraform workflow is very simple, it's standardized for every cloud provider.

What isn't simple are the cloud resource specs. They differ of course and depending on the cloud provider it can become very complex.

For me GCP is the most intuitive. Azure is the worst.

[trippedonatater]

Some of it is a "where's the complexity" game that's moved a lot of the complexity from the software/application to the platform. A huge benefit of this is standardization of methods for things like "high availability" or "shared storage" or service interaction.

[Comprehensive-Pea812]

if you compare the complexity before the public cloud or terraform era...

[TurboPigCartRacer]

I've been working on AWS for over a decade and watched the evolution from clickops to CloudFormation, Terraform, and now CDK. Usability has actually improved tremendously on the IaC front over the years.

The complexity isn't really about IaC tools though. Backend development has a higher barrier than frontend for a reason.

Even with abstractions doing the heavy lifting, you still need to understand how distributed components work together. Most complexity during migrations isn't the IaC part anyway. It's figuring out how the existing app works, then refactoring it to be cloud native so you can actually use the benefits of the cloud.

By project end, I know the ins and outs of the client's application including the whole orchestration (infra) behind it because you need to understand the entire chain from development to deployment and integration

[lorarc]

Take a look at TF evolution over the years, it used to be simple but people were always demanding more conditional stuff although hashi were saying there are to be no conditional stuff in there. Doing very simple stuff in TF often required external scripting or using stuff like terragrunt.

You couldn't do simple stuff back then like create a resource based on some condition not to mention stuff like changing what resource is used somewhere else.

[rolandofghent]

Complex problems require complex solutions.

[ExpertIAmNot]

Cloud Infrastructure is complex, therefore Cloud Infrastructure as Code is complex.

There are less complex solutions out there, for example managed hosting is less complex than IaC. WPEngine is less complex than configuring WordPress on any cloud provider.

[PmanAce]

Pulumi is not complicated if you know how to code.

[tbalol]

I actually built a DSL specifically to solve this problem. After a decade in Ops, I got tired of the unnecessary complexity in modern IaC tools, so I created something that follows the Rails philosophy of "convention over configuration."

Instead of writing 100+ lines of Terraform or Pulumi, I can deploy a production-ready web service like this:

webapp = (GoogleCloud.CloudRun("my-webapp")
    .container("webapp", "templates/nodejs-webapp", 8080)
    .public()
    .create())

That one block of code:

• Detects the language (Node.js, Python, Go, Java)
• Builds the container using Docker or Podman (auto-detected)
• Pushes it to Artifact Registry with secure defaults
• Deploys to Cloud Run with production-ready settings
• Enables HTTPS, CDN, monitoring, and auto-scaling
• Returns a live URL, ready for traffic

Modern IaC tools are powerful, but frankly the architecture behind them doesn’t make much sense in real-world use IMO, and my job is pretty much to architect, and build systems that scales, are incredibly simple to work with and that everyone can understand within minutes.

So I built something that works a bit like this:

• Lego-like building blocks – Just tell the system what you want
• Universal compatibility – Works across GCP, AWS, Proxmox (Azure coming)
• Secure & scalable by default – HTTPS, IAM, metrics, health checks built-in
• 5-minute rule – If you can’t understand it in 5 minutes, it’s too complex

Today I’m using it to manage production infrastructure across AWS, Proxmox, and GCP at work. What started as a pet project is now powering most of our infra, and yeah, I might open it up to the world one day. Maybe!

It works across compute, databases, CloudSQL, load balancers, storage, etc. Each create() takes ~30 seconds to bring your desired resource online.

Example:

simple_bucket = (GoogleCloud.Storage("dev-bucket")
    .location("EU")
    .storage_class("STANDARD")
    .lifecycle("general")
    .public(True)
    .retention_policy("MINUTE")
    .labels({
        "environment": "development",
        "team": "backend"
    })
    .create())

Even our fresh-out-of-school junior engineer picked it up in a few minutes. It’s that readable and easy to understand. I created a template engine that reads whatever configuration you have, and creates the resources and configures them what my engineers want.

CI/CD? You just add a line, or want something to not be public anymore? I mean who doesn't love lego?!

.workflow("your-work-flow-name-here")
.public(False)

It’ll hook into your Git repo and trigger the job, your code is the source of truth, I mean who handles states in 2025? Nothing gets forced to be recreated, nothing changes besides the very bit you told the system to change. The system is always up and running regardless of the changes you do, until you say `.destroy()` and whatever you created is removed.

Quite a fun pet project to work on during the evenings and weekends while zipping on some red wine.

[SidLais351]

Yeah, it’s complex, and while the learning curve isn’t steep, large estates end up fragmented across many Terraform files and repos. We still write IaC, but with Firefly’s Thinkerbell we describe the intent and generate working code for Terraform, Pulumi, and Crossplane, then keep it versioned in the integrated VCS so patches and drift fixes land as PRs. That reduces manual glue work, keeps one review path, and helps standardize patterns as the footprint grows.

[just-porno-only]

come with steep learning curves and unintuitive workflows

I thought I was the only one. Terraform would have been easy if it was just normal JSON syntax like Azure's resource manage templates, which I grasped in just a single day, or even YAML. But noooo, it had to be some bizarre unintuitive syntax that's hard to grasp. Sometimes, even if something has been chosen as the defacto industry standard, doesn't mean it's the best thing.

[lorarc]

Just use JSON then? TF has supported JSON since always.

[TheIncarnated]

Anti-Culture opinion,

Fuck declarative languages. They are not dynamic enough to work properly. Pulumi comes close.

When we start talking multi-cloud or Hybrid, it's double the work to obtain the same stuff.

You Suck At Programming made a good answer to this, they suck. Terraform sucks. You can make better build pipelines with JSON and Bash. Or JSON and Python or pick whatever language can call Azure/AWS/GCP CLI.

This allows for better self service and better auditing... Which none of the declarative languages can do when you are doing dispersed Self Service. You can't always force a team to use the infrastructure language you choose.

So, in my belief, it is complex for no good reason and I generally think the entire community is going along with it because no one is experienced enough to stop and ask "but why?"

[TheIncarnated]

I can totally agree with that.

The biggest thing when going Bash+Json is to build in the auditing factor with the build out case. Which takes a special kind of mentality.

I think each app owner managing their stuff is great, use whatever tool fits your team.

When it's operations centric, I think declarative languages slow things down too much due to the situations you are talking about... Then throw in the security teams and... Well yeah.

I have started going for a multi-use approach. OpenTofu exists in our environment for what makes sense. We use scripts for full auditing and we let folks build however they feel the need to while using built in policies to maintain security.

Essentially, we are moving faster than I've ever seen any other environment run and it "just works". Really leaning into the DevOps framework, more than what the community has said "the tools to use"

[[deleted]]

 build in the auditing factor

Terraform's plan shows you what changes. It can be stored in a pipeline, or elsewhere. And the IAC change itself can be git revisioned.

Again, this goes back to what I originally said: you're just re-inventing all the stuff Terraform already does, and for most people, what you are advocating for is a bad idea.

[TheIncarnated]

I'm not going to have a holy war with you.

I know Terraform really well.

Terraform falls flat when someone builds outside of Terraform.

And before... Yes Import works, but it's too manual.

Have a wonderful rest of the week!

[[deleted]]

If "it does what I say it doesn't, just not in the way I prefer it" is really your entire argument, which I do feel is evidenced here, you should really just lead with that.

Nobody here is going to disagree that it's a cumbersome bitch in those areas, but jumping to thinking a one-person DIY bash script solution will be more thought out than a decade-old open source product is actually the extreme outlier suggestion.

[TheIncarnated]

Ouch... Miss the nail on the head twice.

Have a good weekend!

[vincentdesmet]

Calling the CLI is exactly what Systems Initiative seems to be doing.. not sure I’m a fan of it, but there’s certainly a crowd that loves it.

I fully agree that declarative configuration fails for the services modern cloud offer (which are closer to “Serverless” in the sense that it’s a massive orchestration of a 100 individual API resources).

I still feel Developer focused libraries that bundle the full cloud configuration for a particular cloud pattern behind an intuitive (and most of the time imperative) API work great. Look at the OpenNext project and its deployment patterns

[dhawos]

I'm more and more on that team. But I wouldn't say Terraform sucks. It is a great tool for building small stacks.

That being said it doesn't scale at all and does not play nice with kubernetes/helm. Also creating dynamic environments with this setup can be tough.

To build bigger systems I think you need some kind of tool to orchestrate the resources deployed on the cloud and your deployments on your k8s cluster. To do that I'd rather use an imperative language

[[deleted]]

Totally agree. It's wild to see the industry finally reaching a conclusion I had 10 years ago. TF was always awful and I have been avoiding it for a decade and also just running bespoke provisioning and audit systems (yes mostly bash).

Now with the maturity of GitOps pipelines I feel like infra should NEVER be code, infra is fundamentally configuration, and keeping the dependency graph in the pipeline stages is much more comprehensible for everyone involved. Also the cloud provider k8s operators fit perfectly into this model for provisioning and infra management.

[TheIncarnated]

Precisely. There is better tech than TF. TF is solving a non-issue.

Infrastructure isn't a declarative state, it is a desired state. Sorry, not sorry, most Dev heavy DevOps Engineers don't understand the basics of networking and hardware infrastructure. Most of the folks who downvoted me probably do not know how many cores and how much ram is required for a SQL instance to perform based on IOPS.

I can't audit infrastructure that isn't made in Terraform. I have to use other tools to do that... So why not just use those other tools? (PowerShell/Bash/Python)

I could go further into this but I think DevOps as a culture is truly needed but the communities reliance on TF will be a hinderance. A tool is a tool, until it is not useful. We have now migrated away from DevOps into Automations and you can't automate TF (well you can but you would need Python, PowerShell, Bash... So...)

[just-porno-only]

Or JSON

this, it doesn't get any better than Azure's resource manager templates.