The Future of Config-file-based IT Infrastructure

I saw this tweet by Dan Kaminski recently, and gave a quick response as one does on Twitter. But I think the thougt is worth a bit more time.

Dan’s defense of Docker resonated with me because I see it as the start of something big. I did a Kubernetes class a while back and it fundamentally altered how I look at information technology.

What it taught me is to not see servers, and apps, and systems as hardware, or software—but rather as text files. Their configs. Infrastructure configs.

That’s insane to me.

While I was in the class I kept talking about how I love my Linux servers, and my Linux distributions, and customizing my system, tweaking, polishing, etc. The command-line for my servers are homes for me. They’re friends.

At one point I SSH’d into a particular lab system during the class, and the guy teaching it was like:

I told him I wanted to optimize something, and he’s like:

You’re basically saying, “Here’s the exact environment I want to be up and perfect at all times, and bring things up and down as necessary to make sure it stays that way.” That’s godlike.

I feel like the levels of ephemerality go something like:

• Iron

• Virtual machine

• Container

• Function

Anyway, what interests me about this is that the last two are designed to be programmatically created, maintained, and destroyed. To me that mixes perfectly with something that’s ripe for text-file-ification—the creation of business requirements.

So imagine a world where both business requirements and IT infrastructure were able to be communicated using standard syntax.

It’s a long way away still, but this will become a config. Let’s call it BRL, for Business Requirement Language.

Unsupervised Learning — Security, Tech, and AI in 10 minutes…

Get a weekly breakdown of what's happening in security and tech—and why it matters.

Then you have another language that describes IT infrastructure, called Infrastructure Description Language (IDL). And tools will exist to read BRL and create an implementation on any cloud infrastructure, since they’ll all speak BRL and IDL.

Of course this doesn’t build your entire application, since that requires proprietary code, content, and or data, but all those will have their own hooks and handles as well.

The next natural step is to be able to have your Digital Assistant help you do the whole thing. So, dictation–>BRL–>IDL.

From there, it’ll be another step to desploy your specific application and data to the infrastructure, which I think will get its own optimization. Perhaps a middle layer that understands both infrastructure and, data, platforms, stacks, etc, which can naturally match those up and turn them into a deployment script.

That’s further away for sure, but I don’t think the business requirements and infrastructure description piece is all that distant—at least not for simple deployments.

This is the way we should be thinking about IT—as an unimportant, text-file-based abstraction layer. You just feed it requirements, like how many users, the type of apps it needs to support, how secure you need it to be, how reliable, etc.—and everything gets created for you.

There is an actual stopping point for all this, in a theoretical sense, which is a world where you articulate an idea and it’s brought into being. So, you describe how the app would look, how it would make people feel, the colors you’d like to use, etc.—and it would build it all for you.

Intermediate steps will see various Mechanical Turk Style people working in the background to make that happen “automatically”, but over time this will all get automated.

Anyway, that’s multiple decades away—if we ever get there.

But this translation between business need and infrastructure is something we should start looking to come over the horizon soon.

Related posts:

1. The Real Internet of Things: Details and Examples

2. Vim Config Update: 2019 Edition

3. When Companies Stop Caring About Data Loss, Risk Will Be Resilience-based and Focused on Business Disruption and Human Safety