Immutable infrastructure is the idea that your servers can not and do not change. As opposed to mutable infrastructure, where servers can and do change. Mutable servers are what everyone who has ever had to manage a physical server did. You can’t throw away your hardware and replace it every time you need to make an update. A system administrator would go in and manually or via script update, for example, the firewall rules, upgrade an application, or adjust log rotation. Immutable servers are never updated, but replaced when any configuration or application changes.
In practical terms, what does it mean to run immutable infrastructure?
- Your servers are entirely provisioned via automation. Technically you could manually create machine images and deploy them, but this isn’t the spirit of immutable infrastructure. You would generally use something like HashiCorp Packer, AWS CloudFormation, or other configuration management tools, to procedurally generate your server’s software and configuration.
- Version controlled automation. Your automation “scripts” are in version control and you are able to easily revert to a previous version of your infrastructure. This is especially important if a bug is found and you need to quickly rollback to a previous version of your servers.
- Blue-green deployments are easy. Since you are replacing servers rather than updating them, it’s simple to leave your old servers in place, start up new servers, switch some or all traffic to the new servers, test, and then shut down the old servers when you are confident there are no issues with the new servers.
- No configuration drift. When humans have access to servers, it’s too easy to make a quick change to fix simple issue or even accidentally make a minor change in configuration. If servers are manged manually, the changes are compounded. These changes are rarely tracked or codified. Recreating the exact changes made to one server is difficult leading to slight differences from one server to another. Since no humans are making changes, there is no configuration drift with immutable infrastructure.
- Heightened server security. Since all configuration is automated, there are no differences. Security can be handled centrally by experts and pushed throughout the entire infrastructure. Organizations serious about security and immutable infrastructure go so far as to eliminate SSH or RDP access to their servers. Logs and diagnostic information are automatically collected using tools so no access to the server is ever necessary. No access means no possibility of accidentally or a rogue employee maliciously causing security breaches.
Some of the most important benefits of immutable infrastructure is what implementing it forces you to do, rather than a benefit of immutable infrastructure itself. In order to be able to monitor and troubleshoot your servers, you must set up log aggregation and monitoring, core principles of DevOps. Something like Amazon CloudWatch Logs, Logstash, Sumologic, and Splunk are common tools to pull log data from your servers and provide an aggregate view where no access to the server is needed. Similarly monitoring using something like Amazon CloudWatch, New Relic, Nagios, or DataDog to get detailed information about your servers and applications for troubleshooting and server health monitoring. In other words, immutable infrastructure forces to use some well-architected best practices when it comes to managing infrastructure in the cloud.
