Immutable Infrastructure: Production Release
This article is part of a series on Immutable Infrastructure and discusses the scenario of production release. It may be valuable to review Immutable Infrastructure Basics before reading this article.
What is production? At first glance one might expect a straight forward answer to that question like: Any system that directly serves authoritative resources to the intended end user. That might be broad and general enough to capture most situations, but what about
- A single user’s laptop that is setup to compiler a binary that controls a production machine. Is that laptop considered production, even though it may only be used occasionally for that purpose?
- An agent server used by a testing platform and configured with a specific set of software to validate new releases. Is that agent considered production, even though no end user will ever interact with it and it’s only used to validate releases?
Whichever resource is in play, there are big potential benefits from immutable infrastructure approaches. Consider the following illustration that shows the differences in managing a production resource over time.
Pitfalls of Mutable Infrastructure
In the case of traditional, mutable infrastructure, there is a stream of updates always changing the host in some way or another. This highlights the following characteristics:
- Change is mostly irreversible. While it may be possible to return a system to a previous state, the analogy I think is most helpful is that of painting. Imagine painting a wall to a new color and then deciding you actually want the old color. You can’t just remove the paint. Even if you know exactly what the original paint was, it will not look identical due to aging of the original paint and the fact that it’s on top of a new color that didn’t work out.
- Change is risky because the end user will be impacted. In some cases, the duration and extent of the impact aren’t fully known until the change is applied.
- Each change causes divergence among related components in a system. Extra care is required to make sure that all changes are applied in the same way to each system and to guard against out of band changes.
Benefits of Immutable Infrastructure
As can be seen in the illustration above, a production instance is never modified, which is true for any instance based on immutable infrastructure. Once created, the instance exists in the same state until it is destroyed. This allows new instances to be created without disruption to the end user. Some other direct benefits of immutable infrastructure include:
- Instances can be recreated (or new identical instances created) without any variation from the original instance
- Start up times are fast
- Creation of a new production instances can be fully automated (no human action is required).
- All of the above makes scaling capacity very straight forward (at least for stateless workloads)
- Instances can be retained after a new release. This can reduce the risk of a bad release by making a fallback to the (actual) original possible.
- Distributing instances across zones/regions is also straight forward
Multiple Versions of Production
Various advanced models of software life cycle management become easier with immutable infrastructure. As mentioned above, multiple versions of production can be live at the same time. This can go a step further by having multiple versions of production. For example, imagine that a company has one large client that accounts for a disproportionate amount of total revenue, and that customer wants some changes made to the interfaces they consume, but those changes would not benefit the remaining customer base. The process of delivering a specialized interface alongside the original can be easier with immutable infrastructure due to the decreased risk and the ability to automate so much of the software life cycle.
Many organizations perform regular scans of their systems to check for known vulnerabilities. These will then be incorporated into the stream of changes applied to affected hosts. With immutable infrastructure, this scanning can take place against an image repository without the need to touch each running instance. When vulnerabilities are discovered, these can be addressed starting with the image and promoting the change forward toward production. Scanning can also occur without requiring credentials or access to running instances.
In this short series of posts, key concepts of Immutable Infrastructure have been introduced. The impact this can have on Development, collaboration, CI/CD and even production have been explored at a high level. Containers are the most compelling option available for the design and delivery of immutable infrastructure. With broad support for these technologies in the cloud and on the developer machine, there’s no better time to get started.
For additional details, please review the related posts below.
- Immutable Infrastructure Basics
- Immutable Infrastructure: Development Environments and Team Collaboration
- Immutable Infrastructure: CI/CD (test/stage/audit/etc.)
- Immutable Infrastructure: Production Release (you are here)