Free Trial

Understanding Mutable and Immutable Infrastructure

A Practical Guide for Deploying Immutable Infrastructure

Subscribe to RSS

Topic Filter


We are entering the next age of computing where IoT (Internet of Things), Big Data (Analytics), and Cloud Computing are the core building blocks. In this new era, immutable infrastructure is becoming the norm. That’s a big change because historically, virtually all infrastructure has been mutable.

Definitions of Mutable and Immutable

Let’s start out by defining what we mean by mutable and immutable.

From Merriam Webster:
Definition of MUTABLE

  1. prone to change : inconstant
  2. a: capable of change or of being changed; b: capable of or liable to mutation

Definition of IMMUTABLE

  1. not capable of or susceptible to change

What Is Mutable Infrastructure?

So, what does mutable mean within the context of infrastructure?

Essentially, it means the infrastructure will be continually updated, tweaked, and tuned to meet the ongoing needs of the purpose it serves.

Mutable Infrastructure goes by many names, from the trendy artisanal infrastructure to traditional IT operations. Some people call the individual servers snowflakes, other people call them pets.

Mutable Infrastructure extends to every server and switch that is unique. The IT staff knows each server, its quirks, and often has spent countless hours finding where the problem came from just to resolve it because that is faster and far less scary than the idea of rebuilding the system in question. This goes for everything from the ERP systems in large companies to the file and print server in small shops.

This model is what the Information Technology and Services industry has been based on, and it has dictated how it runs. This is the model outsourcing companies thrive on, and that traditional IT operational staff feels gives them their value.

Example of Real-World Mutable Infrastructure

To solidify the idea of how common mutable infrastructure is in the IT industry, this is a common use case that shows a server evolving through continually being updated in-place.

Step 1 – Deploy a new Ubuntu 14.04 server on DigitalOcean

Using the web console:
Step by step tutorial provided by DigitalOcean.

Or via the API:

$ curl -X POST "" \
$ -d'{"name":"My-Droplet","region":"nyc2","size":"512mb","image":"ubuntu-14-04-x64"}' \
$ -H "Authorization: Bearer $TOKEN" \
$ -H "Content-Type: application/json"

Step 2 – Connect to the server

Connect to the server, and apply the latest updates, and install and configure Apache with PHP

$ ssh root@ubuntu-512mb-nyc2-01
$ apt-get update
$ apt-get upgrade
$ apt-get install apache2
$ apt-get install php5 libapache2-mod-php5 php5-mcrypt

Step 3 – Render the graphics

A few days later developers require a new php library for rendering graphics.

$ ssh root@ubuntu-512mb-nyc2-01
$ apt-get update
$ apt-get install php5-gd

Step 4 – Patch the server

Monthly server patching, for security and support reasons.

$ ssh root@ubuntu-512mb-nyc2-01
$ apt-get update
$ apt-get upgrade

This cycle will continue until there is a reason to rebuild the server. For example, when the OS is upgraded.

What Is Immutable Infrastructure?

Now that we have an idea of what mutable Infrastructure is, and we know the definition of immutable, let’s go over what the concept of immutable infrastructure brings to the table.

The concept for immutable infrastructure is to build the infrastructure components to an exact set of specifications. No deviation, no changes. It is what it is. If a change to a specification is required, then a whole new set of infrastructure is provisioned based on the updated requirements, and the previous infrastructure is taken out of service as it is obsolete.

This concept is similar to what is happening in other industries like consumer electronics. It is now very common for mobile phones to have batteries that cannot be replaced, or storage that cannot be upgraded. So instead of upgrading devices in the field, those devices are now immutable and the whole device needs to be replaced. This provides a level of consistency that makes support easier. Regardless of the number of devices in service, you know exactly what the specifications of each device are and can easily replace as-is in the event of a problem.

The primary technology that makes immutable infrastructure possible at any scale is virtualization (both software and hardware) across networking, servers, and storage. Virtualization is at the core of the modern data center, and makes cloud computing possible. Provisioning and retiring physical hardware to accommodate for every change is cost and time prohibitive. That is why mutable Infrastructure has been the norm in all but the biggest companies, until very recently when virtualization became commonplace. Containers (ex: Docker) are the newest trend in the immutable infrastructure space, and they are simply another layer of virtualization.

What is the best way to make an object reproducible? There are three basic steps:

  1. Document exactly what is done to create the object.
  2. Create scripts that will build and assemble the components into the object as described in the documentation.
  3. Automate the process.

Each version of the documentation and scripts should be tracked through some kind of version control so changes can be recorded.

Infrastructure as Code is the ideal way to create immutable infrastructure. Run it on virtualized platforms and public cloud providers, and you have what is commonly referred to as DevOps.

Continuous Delivery Drives Immutable Infrastructure

DevOps is an overarching term that includes the culture and tools that strive towards agile development, with continuous delivery as the Holy Grail.

The core philosophy of continuous delivery is to deploy a package and its dependencies the same way every time so there is no doubt that the environment is the same. The dependencies are where immutable infrastructure comes into play. The infrastructure build, scripted and part of the package that is being pushed, eliminates the single biggest source of problems during deployments.

Continuous delivery is built on the concept of versioning and automation to push deployments to variable environments on its pipeline.

Continuous delivery uses automation with embedded testing to make deployments so routine they become mundane.

Think of places you have worked that handle application deployments to multiple environments, including production. Wouldn’t boring deployments be a nice change? It would not matter what staff members are on vacation with embedded tests and proven pipeline changes that can be pushed constantly.

Immutable infrastructure as the underpinning component of the currently running version of the application makes the job of operations so much easier. If there is a problem, just rebuild that instance. If load increases, spin up a couple extra instances without having to think about it.

Need to include a security patch to one or more components in the infrastructure? Deploying it to the existing running production instances causes change, change increases risk, and people love to manually validate changes in production. Take advantage of the fact that immutable infrastructure that is being created through a continuous delivery pipeline. Update the scripts, push them into version control, and let the pipeline worry about deployments and testing. By following the same steps every time, with as much automation as possible, new instances come online and old unsecure instances just disappear.

Practical Example of Immutable Infrastructure and Continuous Delivery

Now that we have covered the concepts, let’s walk through a simple scenario showing how simple immutable infrastructure can be. It can be triggered from a code check-in, which is the first step towards having a continuous delivery pipeline.

Deploying a simple PHP app on Heroku

Heroku is a developer-friendly platform for deploying applications. It is an easy first step to immutable infrastructure. With every application you create, you pick a runtime version, and that version is used until the system has to retire it, usually for support or security reasons.

Steps to build and deploy an application called yet-another-test-app:

Step 1 – Create the App

First let’s create a very simple application that prints the environment information:

$ mkdir yet-another-test-app
$ cd yet-another-test-app
$ echo "# yet-another-test-app" >>
$ echo '' > index.php
$ composer require "php:^5.6|^7.0"

Step 2 – Enable version control

$ git init
$ git add .
$ git commit -m "first commit"

Step 3 – Select the web server

Now, we set the type of engine we run in on Heroku:
$ echo “web: vendor/bin/heroku-php-apache2” > Procfile

Step 4 – Create a repository

Now it’s time to create a server-side repository that can be accessed by other people (team members), and will be accessible to Heroku.

First, create an account on GitHub and create a public repository (so it is free). Next, push the local git repository to GitHub:

$ git remote add origin
$ git push -u origin master

Step 5 – Deploy to Heroku

Create an account on and follow the wizard to create an app that is connected to the repository you created on GitHub. Don’t worry, you get one dyno (web runtime) for free. Once you have connected it to your GitHub repository, there are two choices. The first is to enable “Automatic Deploys” which will redeploy the application anytime there is a commit on the GitHub repository master branch. This is the most basic form of continuous delivery you can have.

The second option is “Manual Deploy,” which is a one-time deploy. This takes advantage of Heroku’s immutable infrastructure.

Note: Heroku has an option for a continuous delivery pipeline that is simple and easy to enable and allows additional steps like reviews, and a staging environment that needs to be passed before production. This guide assumes that you are not enabling that feature.

Step 6 – Run the App

After a deploy, the application becomes available at

With this step complete, you have now taken advantage of immutable infrastructure created through Infrastructure as Code as part of the continuous delivery spectrum.

Back to top
Sign up for your 30 day free trial!
Sign up for
Sumo Logic Free
  • No credit card required to sign-up
  • Create your account in minutes
  • No expiration date
  • After 30 day trial period, reverts to Sumo Logic Free
    View All Pricing Options Privacy Policy