Software Infrastructure 2.0: A Wishlist

I am constantly amazed that software engineering is as difficult as it is in ways like this. Half the time I just figure I'm an idiot because no one else is struggling with the same things but I probably just don't notice when they are.

We're still largely making and running software the same way we did 20 years ago. The only major differences are the principles that underpin the most modern best practices.

"What the fuck does that mean," you say? It means that I can take a shitty tool and a shitty piece of infrastructure, and make it objectively more reliable, faster, and easier, by using modern practices. Conversely, I can take the latest tools, infrastructure, etc, and make them run like absolute dogshit, by using the practices of a decade ago.

Let's take K8s for example. It's like somebody decided to take the worst trends in software development and design-by-committee and churned out something that is simultaneously complicated and hard to use [correctly]. Setting it up correctly, and using it correctly (no, Mr. I'm A Javascript Developer, however you think you're supposed to use it, you are wrong), for a medium-scale business, requires banging your head against a hodge-podge of poorly designed interfaces and bolting on add-on software for at least a month.

This is ridiculous, because what you actually needed was something whose principles match those of K8s. You want immutable infrastructure as code. You want scalable architecture. You want (in theory) loosely joined components. Do you need K8s to do that? No! K8s is literally the most complicated way that exists to do that.

Next let's take Terraform. A clunky DSL that is slowly becoming sentient. Core functionality that defeats itself (running terraform apply is unpredictable, due to the nature of the design of the program, even though it was created with the opposite intention). Kludgy interfaces that are a chore to cobble together. Dependency hell. Actual runtime in the 10s of minutes (for the infra of a single product/region/AWS account). And no meaningful idea if the state of the infrastructure matches its state file matches the code that generated it all. To say nothing of continuous integration.

Do you need all of that to do infrastructure as code? Of course not. A shell script and Make could do the same thing.

So, you have a kludgy Configuration Management tool (terraform), and a kludgy Cluster Management tool (k8s), and all just to run your fucking Node.js webserver, make sure it restarts, and make sure a load-balancer is updated when you rotate in new webservers. Did you need all of this, really? No. The end result is functionally equivalent to a couple of shell scripts on some random VMs.

To get the best out of "Software Infrastructure" you don't need to use anything fancy. You just need to use something right.

---

But there's a different problem with infra, and it's big. See, Cloud Infrastructure works like a server. Like a physical server, with a regular old OS. To manage it, first you "spin up" the physical server. Then you "configure" the server with some "configuration management" software. Then you "copy some files to it". Then you "run something on it". And while it's running, you change it, live. This is how all Cloud Infra is managed. This is known as Mutable Infrastructure. Modern best practices have shown that this is really bad, because it leads to lots of problems and accidental-yet-necessary complexity.

So what is the solution? The solution is for cloud vendors to supply interfaces to manage their gear immutably. And that is a really big fucking problem.

Say I have an S3 bucket. Let's say I have a bucket policy, lifecycle policy, ACLs, replication, object-level settings, versioning, etc. The whole 9 yards. Now let's say I make one change to the bucket (a policy change, say). Production breaks. Can I "back out" that change in one swift command, without even thinking about it, and know that it will work? No.

Assuming an AWS API call even has versioning functionality (most don't) I can use some API calls to query the previous version, apply the previous version as the current version, change some other things, and hope that fixes it. But there's no semblance of `rm S3-BUCKET ; cp -f S3-BUCKET-OLD S3-BUCKET`. You have to just manually fix it "live". Usually with some fucked up tool with a state file and a DSL that will randomly break on you.

There is literally no way to manage cloud infrastructure immutably. Cloud vendors will have to re-design literally all of their interfaces for a completely new paradigm. And that's just interfaces. If trying to do the S3 bucket copy fails for "mysterious reasons" (AWS API calls fail all the time, kids), then your immutable change didn't work, and you still have a broken system. So they actually have to change how they run their infrastructure, too, to use operations that are extremely unlikely to "misbehave".

Do you know how much shit that covers? It took them like 20 years to make what we have now. It may take another 10 to 20 years to change it all.

Therefore, for a very, very long time to come, we will be stuck with shitty tools, trying to shittily manage our infrastructure, the way we used to manage web servers in the 90s. Even though we know for a fact that there is a better way. But we literally don't have the time or resources to do that any time soon, because it's all too big.

It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.

my first HAproxy setup wasn't great, my 10th is rock solid, just needed a bit of context-specific learning.

same with PG replication (locical and archive) but 3rd go was awesome.

its a flawed expectation to get it right the first time.