Watch the recording of the Live Hangout on Immutable Infrastructure!
Immutable Infrastructure is not a new concept and while there are many examples of successful implementations it would be a lie if we said that the recent hype around containers in general and Docker in particular hasn’t made the concept more widespread.
As it often happens in these cases, we see a lot of different interpretations of its meaning, benefits, challenges, and adoption paths. We asked 6 experts who have been thinking, writing and implementing Immutable Infrastructures to share their experience by answering 6 questions on the topic:
1) What does Immutable Infrastructure mean to you?
2) What’s your position on Immutable Infrastructure and why?
3) What are the main benefits you see/care about?
4) Biggest adoption challenges/things that are not there yet in your opinion?
5+6) Starting from scratch is (relatively) easy. What about those with existing systems? any hints on how others could get started moving towards an Immutable Infrastructure?
The 6 experts
- Kief Morris: Continuous Delivery Practice Lead for Europe with ThoughtWorks in London, specializing in tools, practices, and processes for the Continuous Delivery of software
- Andrew Phillips: heads up product management at XebiaLabs, building tools to support DevOps and Continuous Delivery
- Florian Motlik: CTO and Founder of Codeship where he makes sure the System is up and running as well as getting it into as many hands as possible
- Julian Dunn: engineering manager at Chef, where he helps to build products on top of the core Chef product portfolio
- Matthew Skelton: Continuous Delivery specialist, DevOps enthusiast, and an Operability nut. He set up and co-runs both LondonCD and PipelineConf. He is co-founder and Principal Consultant at Skelton Thatcher Consulting
- Ben Butler-Cole: likes to build systems rather than software. He has spent the last twelve years looking for ways to avoid unnecessary work. When all else fails he likes to write code in languages that haven’t been designed to hurt him. He currently works for Neo Technology.
Highlights
1) What’s an Immutable Infrastructure?
A pattern or strategy for managing services in which infrastructure is divided into “data” and “everything else”. “Everything else” components are replaced at every deployment, with changes made only by modifying a versioned definition, rather than being updated in-place.
2) What’s your position on Immutable Infrastructure and why?
Definitely a good idea that all components of a running system should be in a known state. Worth exploring as long as it doesn’t become yet another silver bullet. We still have a lot to learn about how to make it work well and really need to analyse the problem we are trying to solve, which is minimising errors in deployment, configuration, or runtime.
On one hand it’s a myth, because it ignores the actual operating conditions of systems, because servers and network devices are changing all the time (e.g. RAM) but seen as one point on a continuum or plane of configuration options, it can be useful because incremental configuration management tools can never control everything; in particular it’s impossible to be certain that things are absent.
3) What are the main benefits you see/care about?
It’s a way to simplify change management: servers never rot and you can think of an application as a single deployable artefact, you can reason about it at a higher level.
It also promotes better understanding across the whole delivery chain making it more resilient, flexible, portable and with better safeguards because it forces you to expect failures and have a reliable process to rectify them simply.
4) Biggest adoption challenges/things that are not there yet in your opinion?
We don’t know the best way to do it yet; not only does it require a bigger shift in mindset than things like Infrastructure as Code, but the publicly available technology is still very new. Tooling needs to evolve considerably and a lot of the plumbing (e.g. orchestration and resource allocation primitives) isn’t there yet.
It also requires a high degree of maturity from organisations, processes and operational knowledge, advanced networking and storage.
Last but not least, creating servers from scratch is generally slower than updating them in- place and you need to wean yourself off existing tools which have been created to patch the old way of doing things.
5+6) Starting from scratch is (relatively) easy. What about those with existing systems? any hints on how others could get started moving towards an Immutable Infrastructure?
Determine if it makes sense: only consider it if you have a lot of pain in areas that it could address and stop once you have addressed the problems you had with that service – don’t “boil the ocean”.
Identify specific elements of your infrastructure to trial it, and work on it incrementally and iteratively. A good place to start is often the build & test environments but be prepared to need a lot more plumbing than just the AMI factory or Packer or Docker.
Or try it out on a smaller, green-field system first in order to iron out problems and properly understand the implications. Since it currently works well if you have a 12-factor, stateless SaaS app you can start with that.
Full transcript PDF
You can download the free, 14-page PDF that includes both the highlights above and the full transcript of all the answers grouped by questions here: