Maybe “Infrastructure as Code” Isn’t the Right Way

Whenever luminaries speak of DevOps, they often use the phrase?Infrastructure as Code?to sum up some of DevOps’ major goals. However, I’ll argue that it’s both semantically and syntactically incorrect and undesirable.

If we were to just nitpick the syntax of the phrase, “code as infrastructure” would probably be more accurate. After all, DevOps isn’t about the infrastructure trying to be code, right? It’s about using code to drive the infrastructure.

But semantically, I still have problems with the phrase. You see, once you start down a path with DevOps, it becomes expensive and difficult to back up and change directions or approaches. So it’s important to take the right approach to begin with – and to be able to clearly communicate what that approach is.

I think we can all agree that?code?has never?not?had a major role in infrastructure. Even if you’re using a graphical “wizard,” there’s obviously code underneath. Routers operate on code.?Everything?is code. So DevOps has never been about introducing code to infrastructure, right? The phrase?infrastructure as code?must therefore refer to the?interface?that we use as Operations personnel. In other words,?infrastructure as code?is meant to differentiate?how we tell the underlying code what to do.?Do we use a GUI, or do we use code? Clearly, the argument goes that we used a GUI in the past, and that DevOps desires us to use code.

But I think that’s wrong.

If you’re writing code – such as systems scripts – to implement, maintain, and monitor your environment, then I’d argue that you’re taking a vastly more expensive approach than you should. Code requires maintenance. A script that serves today’s needs won’t necessarily suffice for next year’s needs, meaning you’ll have to re-code. And code requires special skills and knowledge to create. When you decide to base your infrastructure on code – which is what?infrastructure as code?pretty clearly suggests you should do – you’re committing to a very specific skill set that doesn’t happen to be in great supply. You’re telling all of your non-coding administrators that they’re no longer wanted or needed. You’re saying, “we don’t need operational skills, we need coding skills.” And that’s probably?not?what you really want to say.

So I’d argue that a better phrase – and approach – is something more like?policy as infrastructure.?Hear me out.

Having acknowledged that code is always necessary to actually make stuff happen, what we have to decide is the interface that Operations will use to call the shots. We’ve mostly all come to the point where we realize that GUIs aren’t the right way to go in the long term, and I’ve outlined some arguments why code-running-the-other-code isn’t the right approach, either. Instead, I propose a third kind of interface:?policies.?

This is, more or less, the approach Microsoft has taken with its Desired State Configuration (DSC), although they’re hardly the only ones advocating for policy as infrastructure. But DSC is a straightforward technology model, so it can serve as a useful example. The idea with DSC is that you create a text document?that doesn’t contain any programming code,?to represent the “desired state” of your environment. In generic, non-Microsoft terms, we can refer to this configuration document as a?policy.?“It is our company policy that this kind of server be configured thusly.” Such documents should be human-readable to some degree, but also be consumable by the code that actually causes the server (or other device) to be configured that way.

Yes, there’s still code under the hood that “makes it happen.” But there’s?always?code under the hood. There’s code behind a GUI, and an operating system is, really, nothing but code. But that under-the-hood code can be general purpose and modularized. It can be written by?coders,?who may have little understanding of a company’s specific operational needs. The under-the-hood code exposes?capabilities,?rather than directing the infrastructure how to behave. The code provides your options. The?policies,?on the other hand, can be written by non-coding Operations people. Policies look at all the capabilities, and all the options, and selects the specific combination that’s right for?your?organization.

I realize that this is ?a real exercise in hair-splitting, but I think it’s important because it impacts your selection of tools, technologies, and approaches. I mean, the concept of “stop using a GUI” is fine, but “write unique code for every operational scenario” isn’t actually a lot better. For example, let’s say you’re looking at a configuration state management platform. One option might require you to write Python scripts, which are deployed to managed nodes, and which might use chunks of code on those nodes to put the nodes into the desired configuration. That is?infrastructure as code,?and it depends on your Operations team having a very specific skill set, potentially tied to a proprietary set of coding interfaces.

By contrast, adopting a layered approach that uses more plain-language policies as an abstraction between your business desires and the underlying code, you can use a more readily available, more generalized skill set to manage Operations. Yes, there still needs to be code – but because the coders can write more general-purpose, capability-driven code, their efforts can be depreciated across a larger community, rather than just your one organization. Code becomes reused more readily, and policies help customize its application to each business scenario.

DevOps is all about making smart,?scalable?choices, and I firmly believe that?policy as infrastructure?represents a more accurate description of what we should all be striving for.