Infrastructure From Code

Right idea, wrong language. At least for me. Not really into Rust a lot and trying to figure it out gives me a headache. I've tried. Also, I think the severe risk here is that anyone who knows Rust well enough to like it for this would probably pull up their nose for devops jobs and find something more interesting to do with their skills.

But, I like the idea of using a statically compiled language rather than some yaml (terraform), json/xml cloudformation, etc.

I'm kind of liking Kotlin and Kotlin script right now (KTS). I might be biased because I write a lot of Kotlin. But it seems to have some unique features that make it suitable for developing your own DSLs.

BTW. I think Gradle's KTS support is actually a bad example of KTS because it inherits a lot of its complexity from when it was still exclusively a Groovy thing (which is of course a scripting language). The Gradle APIs tend to give me a headache. It's never obvious what you need to do. And it keeps on changing as well over time. Which makes Googling the solution really tedious because 95% of what you find is usually a combination of obsolete, wrong, and outdated. Automcomplete via Google is broken. And because Groovy is so dynamic, it also complicates autocomplete in Kotlin Script (which is a major selling point otherwise).

And autocomplete via Google is exactly what makes many solutions in the devops/PAAS/IAAS/configuration management etc. sphere so tedious to deal with. There's just no way around wading through lots of misinformation, product/marketing pages that try to tell you wonderful the shit you are trying to get working is, blog articles, poorly written/structured documentation, etc.

One of our people actually hacked together a little KTS script that generates our github action yaml files. If you've ever dealt with GH actions, they are nice but the yaml sure is fiddly. Having a KTS script that generates those is wonderful:

- A lot less errors that you discover after you commit because if it compiles, it's probably fine. Which means I can tinker with it, commit my changes, and have it work correctly the first time. Amazing.

- No more copy paste 'reuse'. We can have functions and reuse them across different workflows and we can actually reuse bits and pieces that we figured out. I'm always amazed at how much copy paste and adapt is still the leading paradigm in devops automation.

- No more dealing with yaml syntax, it's quirks, and limitations. Kotlin has types, DSL support, multi line strings, string templates, etc. In other words, it's very suitable for this kind of stuff. And when it doesn't have a feature you need, you can just add it because it's a programming language. Not that hard.

This should be a thing in more devops stuff. Terraform would probably be easier with KTS, for example. And I'm pretty sure people are working on that. Though of course the support in Intellij for Terraform is not bad.

Probably because you are conflating Infrastructure as code with Infrastructure from code.

> it would be great if they had a hosted service

Actually we do[0]! You can deploy a shuttle app with an annotation and a single cargo command -> `cargo shuttle deploy` :)

[0] https://www.shuttle.rs/

There is no such thing as default infrastructure if you care if your application works. Hiring "experts" later is really just hiring someone to do what the developer should have done, and will probably have to ask the dev to do more work anyway. To an Ops person it's literally a black box. To "fine-tune" the infrastructure, they have to interrogate the developer, and learn only the bare minimum of whatever app stack the developer decided to use. The end result is literally black box reverse engineering, which is wasteful and leads to bad outcomes.

Imagine being a fashion designer making clothes without ever seeing a human being put them on. There's fabric that covers skin, and there's arm holes and leg holes and buttons, so they are "feature-complete" clothes. But just because you pinned up a bunch of fabric on a dummy doesn't mean you know what a person looks like when they put it on and move around in it, or whether a person will want to wear them, or if they'll fall apart after a week. You have to know about different body shapes, how bodies move, evaluate their fit, adapt them to the wear and tear of the real world, and be interested in the outcome. You don't have to be a medical doctor, and you don't have to be an engineer, but you do need to know the absolute minimum of how those different domains interact with clothing.

The fact that people use Heroku, Firebase, Vercel, and other infrastructure providers means that there are plenty of developers out there that don't write their code around infrastructure at the beginning.