Infrastructure as Code – The magic that fizzled out

When I first heard about Infrastructure as Code (henceforth IaC) I was fascinated. Finally, something that would make my life easier, creating the resources I needed, allowing for duplication in various environments, able to handle rapid changes in requirements and be easily version controlled, moving between providers a breeze

In short it sounded like magic.

But the more I dig into it, the more I found it to be unwieldy, very stale, highly provider and tool dependant and not able to do something I wanted it to do most: make it easy to move from one provider to another.

The magic was gone, just fizzling out with every further sentence I read about it.

Don’t misunderstand me, IaC is a good idea and in the right context and use-case it can serve as an invaluable tool, not only in terms of repeatability and predictability, but also cost as money and effort. And freed from its provider dependency, by using tools like Terraform, it can make large and complicated multi-cloud environments easier to keep updated with new requirements, as long as you are willing to walk to walk to get there.

But also understand that using the provider specific tools like ARM, Bicep, CF, GCDM etc. will always be more powerful for the specific provider.

What is it that that is the root of the problem?

It’s the difference between declarative/imperative and descriptive syntax.

IaC frameworks, rely on a declarative/imperative syntax where the infrastructure you desire is spelled out in detail with anything unspecified using default values or being ignored.

This gives it excellent repeatability with new variations becoming new versions that can be managed. All well and good, but on the flipside, it is a snapshot and research intensive, because with total control comes the need to exert said control for it to work. You will need to specify EXACTLY what you want, using the platform specific service names, conventions and parameters. Otherwise, it will be rejected, either in part or completely. Even a simple case-error can halt the deployment or make it go awry. And third-party tools are almost always just a minor revision out of date.

And before diving into the descriptive world there is one more thing about declarative IaC that needs to be highlighted. There is no standard, neither in syntax nor file format. So, you essentially lock yourself into a platform or tool. Sound familiar? This is the kind we should avoid.

If there are so, depending on your view, many caveats with a declarative syntax, why not use a descriptive one?

Well, for starters, there isn’t any.

At least none that I’ve found. And that is, at least in this day and age, is in my eyes quite surprising. You would assume that someone else has tried this before in some way but searching for “descriptive infrastructure as code” on google gave we a lot on “declarative infrastructure as code” results, but none of the other flavour.

But why is this? Wouldn’t it be a subject that would be interesting to the point of commercializing a product around it? Why isn’t there one (or why haven’t I found one)? And if there isn’t one, you read the idea here first.

Because it is … (drum roll) … amazingly difficult.

Just have a look at this chart:

For any one service from one provider there are either none, one or multiple different services at another provider that can potentially fulfil the need, either individually or as a collection of services . And with different services come differencing points of view on how the services is leveraged and what parameters are required, and which are up to the user to set and what values are specific to a certain provider.

And therein lies the difficulty of moving providers without a complete rewrite of all the underlying architecture, and somewhat advanced search/replace won’t cut it, since it has to answer the following questions…

• What service will be a 1:1 match or close to 1:1 equivalent to the one I want to move?
• And since you might have several services that can match, which one of those is the correct one given the specific need or requirement?
• If no equivalent service exists, can one be built from several different services with the new provider? And in that case how?
• If there is no equivalent service and one can’t be built from different services with the new provider, what alternatives exist?

.. and understand what the previous setup actually did on a more functional level. So, you’d have to add analysis and understanding of the underlying code that runs in some components to the mix to make it work on a different platform.

Easy, right?

Well…no. For those reasons I mentioned.

But, There might be a solution that applies technology that has come to the forefront within the last couple of years. Namely, generative predictive algorithms, or what in the popular vernacular is called AI.

Syntax, descriptions of best-practise cases, and real-life implementations fed into this algorithm could provide a basis for a possible translation between a descriptive syntax to a platform specific declarative syntax of the IaC code. Ideally this would also enable hybrid and multi-platform architectures. There would however be several hurdles that need to be overcome.

These would be:

• The algorithm would need to be constantly updated.
• It would need to be able to run both on-prem and as a SaaS application.
• It would need to understand the workflow that the architecture is meant to support, be this by example or an understanding of written requirements.
• and when it comes to hybrid/multi-cloud it would also need to provision the links between these environments or have knowledge of existing links it cannot self- provision or control.

The key problem here would be one of understanding. Today's generative algorithms don't really understand what data is being fed to them, as it is more of a template of how an answer to a question would be constructed.

I have no doubt that within the next year or so functionality in this specific context would be possible or even exist, but since this is a very specific use case there might be limited economic interest in developing a generative algorithm for this purpose as the mass market appeal simply isn't there. It would be a very tailored and specific tool used by a very specific group of people and as a result the tool might become very expensive.

Or the open source community would embrace the challenge and make an open source tool bypassing any economic interest.

What is your take?

Did you also see IaC as magic box that would solve the problems of architecture definition in a general sense or were you enticed of the ability to have a blueprint for a perfect copy of your target environment ready to go within a few hundred lines of code to run it and then lean back and watch magic happen?

Or is it a technology that promised the moon and stars, but ended up as a burnt piece of coal?

But this is just my view and opinion. Do write your thoughts in the comments.

Finally:

Will we see a cloud translator using a descriptive syntax soon/in the near future or will we remain relegated to manual or assisted cloud-to-cloud translations, for I feel the possibility for all providers to agree on a common syntax is extremely slim to non-existent.