Thanks for the comments @michael.dehaan.

Engineering Manager, Systems Engineer, former fireman, living in Los Angeles, CA

Apr 28, 2016

Our resistance to change has sent us the long way round to where we’re going

I am not saying that CM cannot do immutable infrastructure. I’m saying it’s not a practical way to build it. It simply becomes too easy for a person to update a running server. It introduces opportunities for drift to happen across an environment. It takes longer to rebuild a server with CM than it does to deploy a new container. These points alone are enough to validate the idea that CM is not a practical path towards immutability.

Working backwards through the rest of the points you made:

I see no connection between immutable systems and “describing 100 different microservices in copy/pasted bash”. I’m not sure if you mean to compare immutable infrastructure with copy/pasted bash. To me CM is just copy and pasted bash scripts that grew up and went to school. They’re a holdover from a time when we did things manually. We just automated the manual bits and ignored the chance to do the work in a more efficient and safer manner. That’s why I called CM the configure; make; make install of infrastructure. Figuratively we’re not deploying packages when we’re rebuilding things with CM. We’re just automating the configure; make; make install.

There’s nothing preventing people from safely and efficiently running their databases and zookeeper servers in containers. This isn’t the argument where it was a performance issue of running a database in the cloud. If you need all of the resources of the server (bare metal or cloud) then only deploy the one container and give it all of the resources.

The orchestration that’s possible with CM is closer to a script when compared with the reboot strategies possible with CoreOS updates daemon , fleet or other orchestration tools like Mesos. Applying a hot fix for the OS or to anything anything else would just be a deploy of a new container or allowing the OS to reboot.

Immutable systems are more needlessly complex when expressed with some sort of a CM system. My gut feeling is we’ve allowed the tools we use dictate how the infrastructure and related system ecosystem should look instead of matching them to the actual needs from the applications and services we’re supporting.

Our definition of immutable infrastructure was and should always be based on the best tools available. When the best tools available were CM that is how we envisioned immutable should look like. After CoreOS and containers that vision needs to be updated.