Fractal Architectures: A Software Craftsman's take to Infrastructure as Code

The cloud providers enabled all that.

To summarize: even if most of "Infrastructure As Code" is implemented via descriptive language and not procedural, it still follows the best software development practices.

While TF is the most popular interpretation of IaC these days it is definitely not the only way to do it. I have maintained that HCL is the worst part of Terraform -- it's likely that DSL will grow until it very nearly rivals a full grown language, when they could have gone with full blown languages to start (like Pulumi[0]). Terraform does now support native programming language via their CDK support[1]. This meets the "code" requirement.

There is a trade-off of course -- opening up the door to a fully powered programming language means opening the door to infinite complexity, but I think I'd rather have that than have the DSL that has spiky (though constrained) complexity.

> . As GraphQL has led people to question the applicability of REST type API's in SPA contexts, so I believe IaC will eventually suggest a transition towards single Cloud API endpoints where the entire required state is described; reducing IaC to configuration

Agree -- the interface will likely be kubernetes-like.

> Currently the programming or Code aspect is required as a function of API design and the corresponding wiring of components together. Potentially not necessary and not particularly helpful.

On the meta level, it looks like we've run into the ol' "are declarative languages code" (alternatively, "is HTML code?") question.

A free unsolicited hot take on GraphQL: In my opinion GraphQL is just funny looking SQL, which offers every codebase the opportunity to become as complex as the time-tested query execution engines in real production-ready databases. It's almost like how mongo let you pull schema validation and constraint checking from your relational database up to your application language, which as far as I'm concerned is a bad idea most of the time. That said, just like mongo, the productivity brought about by GraphQL is undeniable (whether real or imagined), so I tread lightly and often don't speak ill of it.

[0]: https://www.pulumi.com/docs

[1]: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...

About the AWS CDK I completely agree, we refer to CloudFormation in the article as that is ultimately the "output" of CDK, but we definitely agree that is a really good step in the right direction for IaC tooling. We "just" need someting portable across clouds now :)

About management, totally agree. That's why we are already working on the next two articles.

I'm sorry but there is no sane reason why you need to enable javascript to read a site that is 100% static content of text and images.

All the other tools are more approachable and show the user more value quicker.

This is similar to all the Dropbox naysayers “I can just use (rsync|ftp|etc)”

That said, knowing what to mix and match to create a "pattern that you can learn and everyone uses and learns too" does contribute value, its essentially parallel to the value provided by linux distros.

I can "docker pull" from many different distros, with lots of premade apps.

I think the lesson for the "hard technology" folks is when you solve a hard technical problem DO think about setting up and promoting high-level standards with sane defaults. You are the most knowledgable person(s) for your "hard tech problem", and thereby often in the best position to standardize the default pattern by which it can be used.

That can contribute as much or more value than the hard technical work itself.

EDIT: also, don't forget to publish and promote STANDARDS giving a well documented "if you don't have a reason not to, do it this way" path for integrating useful tools together. That's essentially what docker is/did, and even though it can be recreated in a 100 lines of bash (https://github.com/p8952/bocker) the branding led to ~100,000 developers publishing containers that are fairly easy for anyone else to understand and build from.

Docker for example includes a bunch of features to help build a strong community of Docker users (image standards, tooling to make building & sharing images easy, public registries, etc.).

For us, having production go down for 2~5 minutes while we spin up a prior VM snapshot is totally acceptable for our customers. I have a hard time believing this RTO does not exceed what would be meaningfully required for most businesses (i.e. actual $$$ impact vs someone's paranoid fantasies).

I totally concur on your 10x point. If you find your engineering staff arguing over containerization technologies or multi-cloud event-driven virtual actor architectures, you are probably wasting a lot of time. I would state that simply making the arbitrary decision to use containers is a massive mistake. All that overhead and complexity for what? You better have a damn good reason. Maintaining a typical Dev/QA/Staging/Prod stack is not sufficient justification. Unless you seriously fucked something up, your software should be able to be cloned+built+deployed+started in a few lines of powershell, et. al. What is stopping you from running this script on 4 servers or writing a little tool to do it from a web interface every time you click a button? Oh right, can't write your own CI/CD tools when there are so many on the market. So it goes. Down the rabbit hole and to the right.

For those who can handle a 2-5 minute RTO, and have business application performance requirements that can be addressed by a single 32+ core server, there is no reason you should be screwing around with anything beyond your basic language+framework tooling, SQLite, source control, and project management tools. This is an engineering paradise if your constraints allow for it. I would never squander this opportunity with shiny bullshit.