Immutable means something does not change over time or is unable to be changed. An immutable deployment is the approach that once an application stack is deployed and configured, its state is fixed. If there are any necessary modifications, the entire application stack or stack element is redeployed.

Cloud VMs are inherently no more reliable or durable than on-premise machines. Their primary advantage is that they are standardized and easy to replace. Imagine you are building a complex Lego building set. If you break one yellow 4 x 2 brick, you wouldn't wait to repair that brick, so you can continue building your structure. You would reach into the bucket and find the next identical brick and continue building. Treating cloud resources in a similar fashion is appropriate. More succinctly and ruthlessly put, a common adage is "Treat your resources like cattle, not pets." Be ready to cull the underperforming cattle in order to free your pastures for healthy ones.

If we continue with the Lego analogy, we can gain several advantages by treating the whole completed structure (a castle, for example) as immutable. Any changes that we want to make to the castle (adding a drawbridge, for example) would be built and tested in a second castle that we would build. The first functions normally until we have completed testing and are ready to promote the new castle with its updated drawbridge.

Treating application stacks in this manner, by replacing the entire system at the lowest level possible each time, triggers several benefits:

• Replacing a system at the lowest level encourages you to automate every deployment step.
• Failing back to a previous version is easy and straightforward since the healthy, old stack remains running until the new stack is tested and ready, as opposed to rolling updates, where the live stack is updated with the changes you want to make. If something goes wrong, one has to roll back the updates, hoping that they can reverse all changes made. Each phase of a rolling update and rollback bring the system down. This is unnecessary with immutable deployments.
• By encouraging automation, every change will need to exist as a script. There will be tough lessons for teams who continue to make manual changes, as no server is special and may be de/re-commissioned at any time.
• Scripting everything means you can build production-like systems for development and testing very easily by changing a few lines of code.
• Most importantly, new infrastructures can be tested in isolation, without risking the production stack. For business critical applications, this is paramount to ensure revenue generating systems are unaffected.

Treating your deployments as immutable isn't a configuration change, but a mindset and cultural shift that needs to occur in the organization. It's become an option because of the new capabilities that cloud offers, specifically IaC (whether it be AWS CloudFormation, Azure ARM, or Terraform).

There are other cloud tools available as well that help provide yet more automation and ease the deployment burden. Cloud services such as AWS Elastic Beanstalk manage the operational burden of a deployment, leaving the user to focus on building and owning the code development of the application. The user simply uploads their code to the service and Elastic Beanstalk handles the rest (with a few configuration parameters given by the user). Services such as Elastic Beanstalk have immutability at the heart of the deployments, allowing you to provision a new 2.0 stack alongside your original 1.0 stack. You can perform testing and slowly accept more user traffic in the 2.0 version. When you are sure the 2.0 stack is ready for production, you can complete the cutover. If the new stack is faulting, you can fail back quickly to the original environment. This is done simply by changing the load balancing settings to direct traffic from the old to the new stack (or vice versa).

Furthermore, there are now cloud services that enforce configuration rigidity and help you maintain immutability. Services such as AWS Config and Config Rules help track configuration changes over time, allowing users to monitor changes of resources and view states. These metrics can be consumed through the API to feed your own notification/remediation system, or you can use Config Rules to automatically enforce certain actions based on how the resources have changed.

Immutability is a key design paradigm to adopt in the journey to cloud native maturity. By managing deployment changes at the lowest resource level, you are encouraging automation and increasing the availability of the application.