I attended the Watch Party hosted by Octopus Deploy yesterday which was awesome, and one topic that arose in discussions is that not everyone uses Kubernetes (not surprising!). Looking around this morning, I'm curious to see which open source IaC (and other) tools are out there that are declarative vs. imperative. Crossplane looks but good but seems very tied to Kubernetes. Are there other alternatives people are using in this space that are more versatile or am I missing something with Crossplane here? I'm thinking on-prem as well as public cloud also.

crossplane is great but it does run only in kubernetes. if you’re already a gitops shop, this is a really great evolution for that shop, particularly the terraform crossplane provider in my opinion. --- the more popular command line iac tools that i know of in the wild are include terraform, pulumi, opentofu (terraform oss fork), and opencp (uses kubectl plugin). --- i wrote a story not too long ago breaking down gitops versus command line iac if that’s interesting to you. in the story i talk a little bit about crossplane’s terraform provider and how you can govern it with gitops or eject from gitops for day-2 and manage your iac as a command line tool as your permanent posture. happy to chat over dm any time. https://thenewstack.io/bridging-the-gap-between-infrastructure-as-code-and-gitops/

Cool, I shall have a read! At the moment this is more for my own information and learning. I have a fairly strong background in platforms and infrastructure, but it's dated as I've been hands off since around 2017, and it was largely on-prem with a little AWS/Azure before I moved into leadership focused roles.

yeah terraform and opentofu are what a ton of us are using who like iac to be simple flat code with little room for interpretation. these use the hcl language written by hashicorp. some folks like pulumi instead because you can write it in modern languages and as such, can code your own iac with all the bells and whistles of a full blown language - for better or for worse depending on the implementer’s vision.

I had some hands on with Terraform back then but assume it's changed a bit since. I remember the original Azure provider was terrible!

yeah terraform got nice and stable with 1.0 what feels like about 2 years ago and as long as you don’t get too creative with it, maybe trying too hard to be DRY as an example, it’s really hard to beat in my opinion. the world wishes they didn’t switch to the busl license a few months ago so keep your guard up on compliance if you use it, you basically just can’t commercially compete with them. they also just got acquired by ibm so it feels shakier than usual. that license change to busl is what has a lot of folks switching to opentofu. it’s still open-code, so many are staying with their product for its maturity and how engrained it is in so many organizations infrastructure story. it remains true that tf is only as good as its provider can produce, but any common providers including azure should be very stable and dependable these days. with all that said however, yaml is the now-and-future, and simple declaration of state is what we’re all driving toward, so any instinct to buy into kubernetes and yaml is a good instinct to follow in my super-biased opinion.

I think there will be a looooooong tail (maybe a forever tail) of non kubernetes infra and tooling. Even if that tail is actually just companies that jump past k8s and into wasm etc. But one thing I love about a lot of the k8s backed tooling is how it manages off k8s infra with ease. Crossplane is all about any api being configured using declarative definitions and reconciliation loops. Kratix is all about any business workflow and destination being orchestrated including manual and heritage mainframes etc. So I think one of the things we are exploring as an industry is what it means to make k8s closer to a means, or an OS (finally), versus the only end (a developer facing environment).

If Crossplane is your choice of weapon and you don’t mind using the k8s API and it’s extension points as your API, when writing configuration / IaC for Crossplane, I would not let “but it only runs on k8s” stop me. It’s a tool after all - you don’t need to run the results it creates on top of k8s as well. You can treat the k8s cluster running Crossplane in the same way as you would treat a Tower that is running Ansible. I guess that we’ll see many more tools adopting what k8s offers - the desired state checking loop, the object model and clear API with extension points - in the future.

Thanks Abby and Jay, interesting thoughts! I wondered if it might be worthwhile running Crossplane even if you only run k8s to support it. I have many things yet to learn!

They have a hosted version (upbound) if you can do that

Right @Abby Bangser! Upbound cloud is basically like Terraform cloud - you get the runtime and state storage “as a Service”, so you don’t need to dabble in running k8s on your own. Totally dropped that from my mental map for the moment as I am so used to run these things on my own 🙂

And I know for us, we are looking at making Kratix a utility that can run on a VM etc despite dependency on the k8s API as the k8s API continues to be trimmed down. So I suspect in the next year or so with the improvements that are pouring into k8s core, the ability to manage k8s for an individual workload will lower a bit. But A) that will take some time to become mainstream and B) it may be more limited value as there are so many additional tools that integrate well with projects built on k8s that brings a lot of value.

At the moment this is just for my own learning and understanding, so running all locally on my PC is fine if I do that. The extension of this is seeing if it all has a place in supporting our devs and customers (I work for a product development/software engineering consultancy). I haven’t heard of specific customer demand for this, but given we work with startups through to enterprise, I wonder if there are benefits in developing patterns we can take with us to new engagements to help our teams and our customers.