What Version is Your Infrastructure?

Can you tell me what version is your infrastructure?

Being able to answer this question is at least as important as being able to answer about your application’s version.

  • What do you consider infrastructure? What is meaningful to you about the platform in which your application is running?
  • What is the first question you're asked after you report a bug?
  • How do you know what shared libraries an application is using at runtime?
  • What is the version of the application framework or server running your application?
  • What version of the OS is running your application? When was it last patched?
  • What deviations to your OS’s configuration were made since it was installed? Better yet, what install options were used when it was set up?
  • What is the version of the database that your application is connecting to?
  • What are the firewall rules needed to secure your application?
  • What scheduled jobs need to be run to make your application function? Are they invoked from another system?
  • Are you selling a (metaphorically or literally) boxed software product that you have zero control over where it is run? In that case, this article may not be very helpful because you are out of luck unless you can run it in a container. If you can do that, then keep reading.

Converging on Immutable Infrastructure

Two decades before the term Immutable Infrastructure was ever used, Software Configuration Management (SCM) was an area of study for academics and professionals alike. This discipline is somewhat generalized because it focuses on all aspects of the state in which a software system could be configured. Yet, infrastructure state changes were very much within its domain, so in fairness, we can't begin to talk about Immutable Infrastructure without acknowledging the efforts of the SCM community. Moreover, just the creation of this discipline alone was a jump forward in the knowability of production applications because it brought some modicum of self-awareness to the act of software deployment and hence infrastructure state changes.

A Old Solution Re-emerges

At the same time that script-driven configurations were taking off, the market share of platform as a service (PaaS) models on the cloud started to gain market share. Compared to the script-driven configurations and virtual disk images, PaaS promised to simplify the process of knowable infrastructure. You would just write an application and it would run on someone else’s infrastructure. As long as your application conformed to the limitations of the platform, you didn't need to worry about the underlying infrastructure. You could just move a slider to create more running copies of your program that got auto-added to a load balancer. This was an amazing promise — now we can just outsource our infrastructure. For simple applications, this pattern worked well and still works well. That’s why many startups deploy their applications to Heroku. It saves you a lot of time in the simple use cases. However, once your application starts to demand more from the underlying infrastructure this model can become untenable. Most of the PaaS providers provided a means to customize their base deployment images, but it was often poorly documented, cumbersome and specific to a single vendor.

Separating the infrastructure SDLC and the application SDLC is now easy

What Good is a Container if You Don’t Know the Ship it is on?

With containers you can shorten the time of unknowable mutability in infrastructure, but it doesn’t address the problem of the mutability of the underlying host platform. We just have faith that it works and do whatever incantations that we can to ward off the evil spirits from host running the container. However, even though containers are a great step forward towards Immutable Infrastructure, it is only addressing a single computational unit (ie machine) and they don't address the complex interaction of all dependent systems that are interacting with the application over the network or other IO channels. In other words, versioning containers doesn’t address the versions of everything else that you connect them to, but it is a step in the right direction.

An example of how a version could represent the knowable state of a virtual data center.

An Exercise for the Reader

As I stated in the beginning, I’m worried about what is not being versioned more than what is being versioned. In that spirit, I've composed a questionnaire for your enjoyment. Check each practice that you are doing.

Next Steps

I've laid out above the conceptual framework about how it is now possible to design systems such that they always have a knowable state. Naturally, the next questions are: How do we build it? How much work does it take to set up? Are there trade-offs between knowability and productivity? Can we use an existing project to set this up?



Seattle resident. programmer and Japanese linguistics geek.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Elijah Zupancic

Elijah Zupancic

Seattle resident. programmer and Japanese linguistics geek.