Infrastructure, Configuration, and everything else as code
I’ve swiveled back and forth between development, and infrastructure for most of my career, and sometimes been squarely in the middle. In some ways development makes more sense than infrastructure work. The abstraction layer that frameworks and languages provide makes it easier to express yourself than the vendor specific implementations that most infrastructure projects seem to require.
Over the last few years, and in the case of containers, months the process of developing and deploying infrastructure projects has been dramatically improved by the “as code” movement. However there’s so much new in this space that it took me a while to wrap my head around what they all are and what role they each play in an architecture.
After the my last few weeks of working with companies around individual components I put together the following model to keep my thoughts aligned. If anyone’s struggling with where everything fits feel free to use this as a place to start. I’m not sure its entirely accurate, but it’s how I’m viewing the world today.
Overview
The basics of the model is that infrastructure solutions flow from bottom to top. The components of the solution also become more specialized as they move up the stack. You may serve all workloads with the same physical switch for example, but the they are less likely to share the same code base. I’ve left a few components in the basic light blue color as they aren’t terribly new. We’ve all been deploying applications on top of hardware and hypervisors for several years now and nothing about this model changes what those components do.
Right before app deployment the model splits into 3 paths. The industry is in little bit of flux in this space which drives some of the choice, but this is also the result of different apps using different deployment mechanisms. The deployment end of the dev pipeline intersects and in some cases overlaps with this layer.
Most of the enterprises I work with don’t currently have the colored layer cleanly implemented. What’s important to understand is that if you don’t have these components as tools you have them as documentation, manual process, tribal knowledge or luck. Using tools in this space reduces the documentation burden, and also reduces the risk that your documentation is translated incorrectly at implementation.
Infrastructure as Code
Description:
A template or scripting language that is used for deploying infrastructure components(VMs, Network Rules, Storage, etc) related to the solution.
Examples:
Terraform, ARM Templates, CloudFormations, VRealize Blueprints
Detail:
This set of tools is a designed to assist with the deployment of infrastructure components of your solution. As an easy button you can think of these as the details of your configuration that exist below the operating system. You define the VMs or PaaS services that are required, the network configuration, and the firewall rules associated with a solution. Depending on the solution you may define auto-scaling rules at this layer as well.
This layer can be platform specific, or cross platform. If you choose a platform specific solution be aware that you may need to rewrite templates to work on alternate platforms.
Platform as a Service
Description:
PaaS comes in many forms but in general it’s a service that simplifies the deployment and management of a well known workload.
Examples:
Azure App Services, Azure SQL, Elastic Beanstalk, RDS, CloudFoundry
Detail:
PaaS is great, you should use it. If you have a workload that fits into a PaaS offering that you have access to you should use it. It will save you operational effort. Unfortunately not all workloads have a PaaS offering, and even if they do they may not be available on your premises.
Configuration as Code
Description:
These are templating/scripting tools that provide deployment of configuration above the operating system.
Examples:
Chef, PowerShell DSC, Ansible, Puppet, Salt
Detail:
Some of these tools have been around a long time. Their purpose is to configure the OS, and deploy custom built, and COTs applications. Some of them create packages that can be invoked by your IaC layer at the time of OS deployment. Others define node types that map to configurations that again would be configured as part of your IaC layer.
Most of us have written deployment runbooks or at least used deployment runbooks in our careers. These are the long documents of click here, select ok, etc. The goal of these tools is to automate these processes for consistency and faster deployment.
A few of these products support compliance tracking, and drift correction. This is a valuable tool that prevents the worst case scenario, the elimination of runbooks, but the continued manual configuration of environments leading to untracked state.
Container Scheduler
Description:
A system that manages the deployment and availability of containers, or groups of containers in a cluster of servers or virtual machines.
Examples:
Detail:
Containers are awesome. If you’re still not sold go build one right now. Container schedulers provide a way to deploy groups of containers into clusters of hosts. Typically they provide a templating language like helm, or docker compose to support this.
The role of the scheduler is to take care of the hard bits. You build your application out of a collection of docker images that you explain through templates to the scheduler. The scheduler goes out and runs them on the cluster, separates them between servers for availability, and scales them as needed to meet demand.
Conclusions
When I stopped actively working in the systems management space about 5 years ago this stack looked very different. For configuration management we would typically rely on a database to track what we were manually doing. For deployment, and infrastructure configuration tasks we would use a combination of deployment scripts and runbooks. Automated runbooks were starting to mature but were not as complete as what we have today.
Today the world is very different place we have languages that allow us to express our deployment architectures fully. This leads to less error prone deployments, better understanding and testing of system changes, and faster deployments. Hopefully this mental model of how these components interact and fit inside an environment will help you with your environment.
