A decade ago, server and datacentre management were prohibitively expensive and were a major hurdle for early stage startups in going live with their product.
Virtualisation and cloud changed the face of IT infrastructure, democratising IT. One of the key benefits of cloud is the conversion of capital expenses to operating expenses, making initial IT investments more modest and affordable for startups.
Combined with self-service, cloud instantly became the darling of startups. Early success stories of The New York Times, Animoto and Smugmug encouraged mid-sized companies and enterprise IT teams to consider cloud.
But the biggest benefit of cloud infrastructure came from inexpensive and disposable virtual servers that could be easily provisioned and reprovisioned. IT operations teams realised that it is far more expensive to debug and fix a faulty virtual server than to replace it with a new server.
On the other side, developers are building cloud-native applications that take advantage of capabilities such as elasticity and self-healing. This phenomenon of replacing infrastructure instead of upgrading or fixing the servers is called immutable infrastructure.
Web-scale applications are the new-generation applications that scale infinitely to support tens of thousands of concurrent users. They need infrastructure with the following capabilities:
The underlying infrastructure needs to be reliable in terms of delivering the maximum uptime and availability. Even though the software is designed for resiliency, it all depends on the infrastructure on which it runs.
Contemporary web applications start small and grow big. They need an infrastructure layer that can scale-out and scale-in based on the traffic patterns.
Predictability is getting consistent performance from the infrastructure. The application should be able to get predictable performance throughout from the CPU, disk and network.
This is an important aspect of web-scale applications. The application should gracefully handle the disruptions caused by infrastructure or code. It should deliver optimal experience to consumers in all scenarios.
To meet the above requirements, developers and operations professionals are moving towards immutable infrastructure.
Evolution of immutable infrastructure
The concept of immutability is not new for the software industry. During the transition from object-oriented development to component-oriented development, Corba and COM encouraged developers to build immutable interfaces and components.
Retaining existing method signatures and adding newer versions ensured that the compatibility is maintained between the component providers and consumers. This philosophy exists in the modern-day service-oriented architecture (SOA). However, the motivation for creating immutable infrastructure is different from designing immutable software components.
Amazon EC2, one of the first infrastructure as a service (IaaS) offerings in the market, introduced the concept of golden images. Developers and administrators could create a base image of a virtual server that consisted of code and configuration required by the application. In the event of disruption or downtime, this image could be used to stand up new servers that reduced the meantime between failures.
Frozen pizza model
When a fully configured server needs to be provisioned, the IT team will simply launch a new virtual server from a golden image. Since this is analogous to dumping a pizza in a deep freeze and heating it up before consuming, long-time Amazon Web Services (AWS) customers refer to this concept as the “frozen pizza model”. The drawback with this approach is that the code baked inside the golden image may become obsolete, causing unwanted issues.
To avoid this, AWS customers switched to a “frozen base pizza model”, in which the golden image will have the entire software stack pre-configured, except the code. The virtual server is designed to pull the latest version of the code after successfully booting up and configuring the dependencies. This reduced the chances of launching the servers with obsolete code.
The more recent trend is to deal with the infrastructure based on the “made-to-order pizza model”. With software components such as operating systems (OSs), web servers, middleware, database drivers and libraries getting updated almost on a daily basis, it is not a good idea to bake them into a “frozen” golden image, as it introduces the risk of using outdated software that may be vulnerable to attacks and security breaches.
The “made-to-order pizza model” relies on the latest OS image provided by the cloud supplier and then uses a script to download and configure the latest software stack and code.
Since the virtual server is built from the latest base image maintained by the cloud provider, which is patched and updated, it is secure and reliable. This model also ensures that the server has the latest software stack and code that are compatible with each other. Many businesses are moving towards this model, where servers are bootstrapped to pull the latest stack and code. Modern IaaS platforms, such as Microsoft Azure and Google Compute Engine, also support bootstrapping servers.
The concept of immutable infrastructure has evolved from dealing with disposable infrastructure resources. When the DevOps team detects an issue with one of the servers, they replace it instead of fixing it. The logs generated by the faulty resource will be analysed for root cause analysis.
What is immutable infrastructure?
Immutable infrastructure is the practice of replacing infrastructure, instead of upgrading or fixing faulty servers.
The architecture pattern for immutable infrastructure is based on the made-to-order pizza model. The server gets built from scratch to include the chosen versions of software stack and code. The new server always uses the “last known good configuration” to deliver predictable performance.
One of the side effects of the frozen pizza model is image sprawl, where the DevOps team ends up creating multiple versions of golden images containing multiple versions of software stack and code. This leads to confusion and causes maintenance overhead. Immutable infrastructure avoids image sprawl by encouraging the teams to focus on configuration/metadata then defines the stack rather than the stack itself.
Immutable infrastructure focuses on atomic deployments. Each module/component of the application is treated as an independent entity with isolated configuration. When a specific component malfunctions, only that gets replaced while keeping the rest of the stack intact. This enables the DevOps teams to quickly isolate the issue than dealing with the whole stack.
There are tools that help DevOps teams in creating and managing immutable infrastructure. They focus on the definition of the infrastructure requirements than the infrastructure. Here are some examples:
CloudFormation uses a JSON-based template to declare the stack. Administrators will populate the template with the details of the base image, security groups, network configuration, software dependencies and pointers to the source code repository. CloudFormation is used to instantiate the whole stack, including the software dependencies and integration points, with other Amazon services like load balancers and database.
Vagrant is popular is among both developers and administrators. By abstracting the underlying virtualisation layer, Vagrant uses a common configuration that is based on Ruby. Vagrantfile is a classic example of declarative software stack. By changing the provider, developers will be easily able to switch between the local development environment running on VirtualBox or VMware to the production environment running on a public cloud such as AWS or Rackspace.
Docker is quickly becoming the key driver of immutable infrastructure. With the concept of one container per process, developers and operations teams are creating modular containers that are loosely coupled. Like Vagrant, Docker also relies on a declarative form called Dockerfile to describe the stack. Evolving orchestration and provisioning tools like Kubernetes, Fleet, Orchard and Fig are based on declarative provisioning of containers.
Packer is a tool for creating reusable machine images that can be deployed on a variety of platforms. It makes it easy to use by automating the creation of machine images. Based on automated scripts, it embraces modern configuration management by encouraging DevOps teams to install and configure the software declaratively.
Immutable infrastructure is becoming popular for running modern web-scale applications. But this may not be appealing to enterprise IT teams that still manage monolithic, legacy software. They still prefer to manage the infrastructure in traditional ways, with the help of configuration management tools such as Chef and Puppet.