Use these DevOps examples to reimagine an IT organization
A comprehensive collection of articles, videos and more, hand-picked by our editors
The technology industry is continuously obsessed with the shiny new thing.
Often, after scratching the surface of such conceptual innovation, one finds a core of old ideas newly applied and wrapped in ambiguous jargon. The result is an appealing idea, open to multiple interpretations, that leaves everyone free to project meaning and relevance to their particular situation.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Such is the case with immutable infrastructure. The term describes a modern application of a well-worn build automation concept that, in practice, is more about automatable change and software platforms than immutable systems and hardware infrastructure.
We aren't talking about a hardware appliance molded in ceramic that does one thing, one way, for all time, i.e., actual immutable infrastructure.
The term immutable infrastructure, in the current context of programmable automation and cloud deployment of system and application images, was arguably coined in a 2013 blog post by Chad Fowler, the developer of Wunderlist (since sold to Microsoft). The blog post was headlined, "Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components." It sowed the seed of an idea that has since blossomed into a widely used concept.
Testing the concept allowed Microsoft to rapidly iterate on its back-end infrastructure as it continued to make things faster, more scalable and more dependable. Who wouldn't want that? And immutable infrastructure nicely dovetails with four software development and deployment trends -- Agile development processes, DevOps, continuous integration and cloud services -- which undoubtedly enhances the appeal.
Although Fowler and the other immutable infrastructure enthusiasts apply the concept to the entire software stack -- including the OS, libraries, application modules and software platform -- wholesale, automated system construction has been around since before Linux. Going back to the origins of the GNU software project and the birth of open source code, installing a new version of the OS or an application meant building the entire thing from scratch using Makefiles.
Indeed, Gentoo Linux has been distributed as locally compiled source code since its initial release 14 years ago. While immutable infrastructure isn't conceptually innovative, it does apply system build automation and deployment in new ways. It uses virtual machines or software containers as the target, forming a virtuous circle with cloud services in which the cloud enables immutable infrastructure while immutable infrastructure optimizes the reliability, consistency and agility of cloud-deployed applications.
Build, don't change
Immutability means that, once deployed, objects aren't modified or patched; they're rebuilt. It entails wholesale replacement of the entire OS and application stack for every incremental fix or upgrade. Gone is the notion of patching existing systems. Instead, whether it's a complete VM OS image or containerized application, the code is rebuilt and deployed with every change. Patching moves from inserting binary modules into a running system to the controlled addition and modification of source code updates to a golden release, using a source code control system to manage changes and the build process. The same build automation approach applies whether adding new application features or forking an OS configuration for a new use. The point of reference is the source tree for the whole infrastructure stack, not an individual application module or OS library. Each change involves rebuilding and redeploying the entire application stack.
The difference between immutable infrastructure and golden VM images is best explained with pizza. The common way to deploy cloud and virtual servers uses a model similar to frozen pizza, where all the ingredients are preassembled in place, ready to bake when needed. A vast and expanding list of golden images is analogous to a freezer full of different complete combinations of pizza crust, sauce and toppings. Immutable infrastructure replaces that pie with images built for every new application, feature update or patch like a pizza cooked from scratch with a new mix of ingredients each time.
Tools and implementation
Immutable infrastructure exploits existing trends in build automation that feature infrastructure as code. This dovetails with the integration of application development and IT operations as exemplified by DevOps and associated methodologies, including Agile software development and continuous integration. Treating each deployed infrastructure stack as an application release allows immutable infrastructure users to exploit existing software development tools as part of an expanded infrastructure toolchain.
The Netflix build pipeline is a prime example of immutable infrastructure. Deployments start with code check-in using a source management system, such as Git, and build events are executed by an orchestration engine, such as Jenkins. From there, automation software -- such as Gradle, the official build automation system for Android -- takes over with dependency management and programmable logic for build construction. Netflix uses an extension, Nebula, that provides a collection of Gradle plugins to eliminate boilerplate build logic and provides a simple domain-specific language that simplifies production of RPM package management files or Debian Linux packages. For the tail end of the process, Netflix uses a continuous delivery pipeline by Spinnaker to automate image deployment to multiple cloud platforms.
The connection of immutable infrastructure with cloud services cannot be overstated. By abstracting infrastructure as a collection of services that are consumed with little regard for the underlying infrastructure and that are readily automated, the cloud is the primary enabler for immutable infrastructure. Furthermore, by exposing application programming interfaces for higher-level infrastructure services and adding richer automation and infrastructure services, the cloud is arguably a prerequisite for immutable infrastructure.
Application containers and associated management stacks, whether Docker or equivalent cloud services such as Amazon EC2 Container Service, Microsoft Azure Container Service or Google Container Engine, are a natural fit with the immutable infrastructure philosophy. They provide greater granularity in the consumption of infrastructure services. Since containers reduce the deployment footprint, they also streamline the code-to-binary deployment process, improving responsiveness to changing application requirements and newly discovered bugs.
The frozen pizza model of using a collection of application-specific system images is a cloud-management version of VM sprawl. The number of VMs mushroomed once virtualization eliminated the friction and overhead of system build and deployment, creating a problem for app developers and infrastructure managers. Developers quickly found themselves overrun with an unmanageable collection of machine images as their cloud deployments aged and new applications came online, each with slightly different OS configurations and application code versions. Immutable infrastructure replaces image sprawl with time-tested source code management -- versioning, branches, merges, forks and distributed development -- that provides a single version of the truth for infrastructure deployments. As such, immutable infrastructure nicely complements DevOps and continuous integration.
It also eliminates the complexity of tracking the often subtle differences in scores of system images used in a virtual infrastructure. Gone is the worry of figuring out which images use a version of an application module or system library that contains a newly discovered vulnerability or bug and then patching each image with the new binary code. Instead, one checks in the fixed code version or library and rebuilds every image with a dependency on that module.
Use of a single code tree with source code control and build automation eliminates configuration drift that happens as system images get a different collection of patches, accumulate extraneous configuration cruft and unused modules or libraries. Immutable infrastructure delivers all the usual benefits of build automation: repeatability, scalability, lower overhead, fewer errors and consistent fixes that collectively enable developers to increase the pace of new releases. As Fowler noted in his blog, immutable infrastructure allowed Wunderlist to more rapidly incorporate changes to their back-end infrastructure and have greater freedom to improve their applications. The gain is faster innovation at a lower cost.
Immutable infrastructure is the latest example of Mark Twain's astute observation that there is no such thing as a new idea: "It is impossible. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope. We give them a turn, and they make new and curious combinations." For immutable infrastructure, the mental turn involves pairing infrastructure abstraction layers such as VMs and containers with time-tested software build automation concepts to realize the ideal of infrastructure as code.
The biggest roadblocks to implementing immutable infrastructure are likely to be cultural, not technical. Immutable infrastructure automation pipelines have been proven at some of the largest online businesses. However, the melding of IT operations and application development into DevOps teams that can implement continuous delivery and integration is tricky given organizational inertia and entrenched fiefdoms.
Kurt Marko is the founder of MarkoInsights, an independent IT analysis and consulting shop.