Sporadically delivered thoughts on Continuous Delivery

Immutable Server Blikis

| Comments

Martin Fowler has published a couple of bliki entries I wrote. The main piece is a definition of Immutable Servers, which is a term that our colleague Ben Butler-Cole coined to describe the practice of not making configuration changes to servers once they’ve been provisioned. In contrast to the better known Configuration Synchronization approach, where automated configuration updates are continuously applied using a tool like Chef or Puppet, a team that uses immutable servers makes configuration changes to the base images, and frequently destroys and rebuilds servers to keep them up to date.

The main advantage of this approach is that, by avoiding changes to a running system’s configuration, you reduce the risks that changes bring. You make changes to a base image, and can then run it through a battery of tests to make sure it’s OK before using it to create server images. This applies the principles behind Deployment Pipelines to infrastructure.

Ben and Peter Gillard-Moss have been evangelizing this approach within ThoughtWorks with their use of it on the Mingle SaaS project. Netflix are arguably the pioneers of this approach, and have released some open source tools to help manage AMI images on AWS for this purpose.

I’m running into increasing numbers of folks in the DevOps community who see infrastructures managed through heavily automated, continuous synchronization as too complicated and fragile.

If the chef-server, puppet-master approach to configuration management is Cloud Computing 2.0, immutable servers are the next thing. Interestingly, at least one commentator has confused this next generation of infrastructure management with pre-cloud practices. My (now-former - sniff) colleague Nic Ferrier responded to this based on a conversation with (still!) colleague Jim Gumbley.

These are truly interesting times in the world of IT infrastructure. The way we do things now is quite different from the way we did them ten years ago (albeit probably not for the majority - as with much technology, the future is not evenly distributed), and certainly different from the way we’ll do things in ten more years. It’s a blast to be involved in the shift!