Give me Terraform (as much as I hate it) any day.
I won't go as far as to say we burned bridges arguing back and forth about it but they were definitely significantly singed.
Config files simply don't work until they do. And if it's your job to stare at them for hours and hours a day then maybe that's okay with you, but if you expect other people to 'just learn' it you're an idiot or an asshole. Or both. Ain't nobody got time for magic incantations.
I also think it should tell you you're on the wrong path when your app is named after a verb and the data it deals with is all declarative.
Sure "use code to deploy infrastructure" sounds great, and that is why we get stuff like Ant, Gradle, Pulumi, Jenkins Groovy scripts, .NET Aspire,.... until someone has to debug spaghetti code on a broken deployment.
* You can't make have variables in an import block (for example, to specify a different "id" value for each workspace)
* There is no explicit way to make a resource conditional based on variables. Only a hacky way to do that using "count = foo ? 1 : 0"
* You can't have variables in the backend configuration, making it impossible to store states in different places depending on the environment.
* You can't have variables in the "ignore_changes" field of a resource, making it impossible to dynamically ignore changes for a field (for example, based on module variables).
* The VSCode extension for HCL is slow and buggy. Using TS with pulumi or TFCDK makes it possible to use all the existing tooling of the language.
You get the bonus of controlling the resource id and being able to selectively delete resources without worrying about ordering.
I find that with some handwringing, C# can be forced to do almost anything. between extension methods, dispatch proxies and reflection you can pummel it into basically any shape.
Having to write a little boilerplate to make it happen can be a drag though. I do sometimes wish C# had something from a blank project that let me operate with as much reckless abandon as Object.assign does in js land.
Terraform sure is a quirky little DSL ain’t it? It’s so weirdly verbose.
But at the same time I can create some azure function app, setup my GitHub build pipeline, get auth0 happy and in theory hook up parts of stripe all in one system. All those random diverse API’s plumbed together and somehow it manages to work.
But boy howdy is that language weird.
But yeah, at $previous_job, Terraform enabled some really fantastic cross-SaaS integrations. Stuff like standing up a whole stack on AWS and creating a statuspage.io page and configuring Pingdom all at once. Perfect for customers who wanted their own instance of an application in an isolated fashion.
We also built an auto-approver for Terraform plans based on fingerprinting "known-good" (safe to execute) plans, but that's a story for a different day.
https://helm.sh/docs/chart_template_guide/control_structures...
the complexity in one way or another must be preserved within the abstraction (in all likelihood) or you will have cases you cannot create in that layer or breakages which now have the total complexity of both the abstraction itself AND kubernetes itself required to fix.
i would not say IaC is going to provide you a magic solution to learning k8s, although the value in using IaC (e.g. Argo CD / Flux CD + Kustomize + ...) in K8s land is that you are no longer imperatively managing your cluster resources and therefore can keep them within a repository, managed like code. the point of the solution is not to make it easier for newcomers, but to make it easier to have teams manage and work together on an established cluster for deployments, ...
in the case of Pulumi, you leverage the single language with typechecking instead of relying upon K8s flavoured YAML, which is itself beneficial in many ways (since you can use your regular developer tooling)
wrt pkl, pretending K8s manifest structure underneath does not help because you will need to know how the keys within a manifest interact with the underlying system regardless, especially to understand functionality, e.g. node selectors, taints and tolerations, node affinity, ...
i prior managed a terraform-based deployment of several k8s clusters and it still required knowledge of those keys and values, alongside knowledge of the underlying resource types.
without those you can't implement things like GPU-based node selection for jobs which require a GPU, ...
Just use CloudFormation. Easy to write, declarative, vars (Parameters and Output exports). Trick is not to pile everything in one Stack. Use several.
It’s got everything you want:
- strong type system (TS),
- full expressive power of a real programming language (TS),
- can use every existing terraform provider directly,
- compiles to actual Terraform so you can always use that as an escape hatch to debug any problems or interface with any other tools,
- official backing of Hashicorp so it’s a safe bet
It’s a super power for infra. If you have strong software dev skills and you want to leverage the entire TF ecosystem without the pain of Terraform the language, CDKTF is for you.
(No affiliation)
But all in all, it works. It's just a bit limited on what you can do with the actual language.
I suppose TypeScript does count as a real programming language, in that it’s Turing complete. But I can use Pulumi from (they claim) any programming language. Specifically, I can use it from Go. Why would I add TypeScript to my project when I can live in one language?
> - official backing of Hashicorp so it’s a safe bet
Given the number of folks leaving the Hashicorp platform, I think it’s arguably no longer a ‘safe bet.’
It turns out terraform is actually quite acceptable when you slap a decent language on top of it. Passable, even :)
Pro vs pulumi: you get a declarative template to debug and review
Pro vs CDK: The declarative template is applied via APIs instead of CloudFormation. The CDK CloudFormation abstraction leaks like hell
All of CDK does things in cloudformation, which made the whole thing stillborn as far as I’m concerned.
The CDK team goes to some lengths to make it better, but it’s all lambda based kludges.
Just write CloudFormation directly. Once you get the hang of the declarative style and become aware of the small gotchas, it's pretty comfy.
Exactly this. And don't make huge templates, split stuff logically to several stacks and pass vars via export/importvalue.
The problem with upserting is that if the resource already exists, its existing attributes and behavior might be incompatible with the state you're declaring. And it's impossible to devise a general solution that safely transitions an arbitrary resource from state A to state A' in a way that is sure to honor your intent.
So dumb. Trying to move to SST for only that reason
but if you add cdk to the path, you can still deploy, its just that your cicd and deployment scripts are not all using bun anymore
You have to do a few adjustments which you can see here https://github.com/codetalkio/bun-issue-cdk-repro?tab=readme...
- Change app/cdk.json to use bun instead of ts-node
- Remove package-lock.json + existing node_modules and run bun install
- You can now use bun run cdk as normal
I don't care about powerful. That's the opposite of what I want. I could just use k8s if I cared about that.
Why is this better then Ansible + Docker Compose?
What it provides is a set of conventions based on what most web apps look like.
Eg. built-in proxy with automatic TLS and zero downtime deployments, first-class support for a DB and cache, encrypted secrets, etc.
It’s definitely not for every use case, but for your typical 3-tier monolith on a handful of servers I found it does the job well.
Give me a forum (even Discourse will do) , I'm tired of needing 3rd party spyware to interact with developers. That it is all closed off from search engines makes it even worse
We've gone through a lot of pain to get this blueprint working since our AWS costs were getting out of hand but we didn't want to part ways with CDK.
We've now got the same stack structure going with Pulumi and Digital ocean, having the same ease of development with at least 60% cost reduction.
It’s not a drop in replacement. It might be worth it depending on what you’re doing.
Anyone using CDK should switch to Pulumi though.
Using a complex programming language (C++ of the browser world) just for this has a big switching cost. Unless you're all in on TS. And/or have already built a huge complex IaC tower of babel where programming-in-the-large virtues justify it.
If I had to guess it's because
- more imperative background developers need to work with infrastructure and they bring over their mindset and ways of working
- infrastructure is more and more available through API's and it saves a lot of effort to dynamically iterate over cattle than declaratively deal with pets
- things like conditionals, loops and abstractions are very useful for a reason
- in essence the declarative tools are not flexible enough for many use cases or ways of working, using a programming language brings infinite flexibility
Personally I am more in the declarative camp and see the benefits of it, but there is certain amount of banging ones head against it's rigidity.
It is classic "every problem is a nail to the person with a hammer". Complex languages - by definition - can solve a wider variety of problems than a simple declarative language but - by definition - are less simple.
Complex languages for infra - IMO - are the wrong tool for the wrong job because of the wrong skills and the wrong person. The only reason why inefficiencies like this are ever allowed to happen is money.
"Why hire a dev and an ops when we can hire a single devops for fractionally less?" - some excited business person or some broken dev manager, probably.
(For bigger stuff apparently CF has some limits relating to resoures per single stack)
the property that equates to config files is "being static", which modern deployments are not.
We've also started switching our custom Docker compose + SSL GitHub Action deployments to use Kamal [1] to take advantage of its nicer remote monitoring features
Terraform or CDK I would want a simple shareable thing that did the boilerplate that I called with any variables I needed to change.
On EKS, you need to do the same version updates with the same amount of terror.
You do pay the extra for the further management to just run containers somewhere!
(you might want to say "every" instead of over, "is" instead of "ist")
on one hand, I can see how this is an unfalsifiable standard, on the other hand I can see the utility of solving a friction for people that messed up
The alternative, which I feel is far too common (and I say this as someone who directly benefits from it): You choose AWS because it's a "Safe" choice and your incubator gets you a bunch of free credits for a year or two. You pay nothing for compute for the first year, but instead pay a devops guy a bunch to do all the setup - In the end it's about a wash because you have to pay a devops guy to handle your CI and deploy anyway, you're just paying a little more in the latter.
I won't touch DO after they took my droplet offline for 3 hours because I got DDoS'd by someone that was upset that I banned them from an IRC channel for spamming N-bombs and other racial slurs.
And can you name a real cloud that charges a half-reasonable price for bandwidth? I consider $10/TB to be half-reasonable.
