patternMajor
What are immutable servers?
Viewed 0 times
areimmutablewhatservers
Problem
There are some questions about immutable servers, such as:
It seems obvious that it has to do with servers (that part I get). And just digesting the grammar of immutable, I would think it has something to do with "not possible to mute". If that guess is close, I'd have no clue what exactly cannot be muted (and I doubt it has to do with soundcards or something ...).
My questions:
- How to implement the immutable server pattern without loosing the ability to do post-mortems?
- What role do Configuration Managment tools play in immutable infrastructure?
It seems obvious that it has to do with servers (that part I get). And just digesting the grammar of immutable, I would think it has something to do with "not possible to mute". If that guess is close, I'd have no clue what exactly cannot be muted (and I doubt it has to do with soundcards or something ...).
My questions:
- What is actually a "immutable servers" (in the context of DevOps)?
- Why are they used?
Solution
Immutability is a term often used in computer science circles, which generally boils down to "not possible to change after creation". It is typically used in reference to parallelism, concurrency, and thread safety.
The discussion of that topic is fascinating, but can generally be found elsewhere on Stack Overflow. I'm resisting the urge to dive into it here. The key concept is 'not possible to change after creation'.
Imagine if, on Amazon, you deploy a web service by baking it into a Machine Image (AMI - a pre-built instance you can repeatedly re-provision). It connects to a backend database via credentials it gets out of a registry on startup. It dumps logs into a logging tool like Splunk. For normal day-to-day operation, you have no reason to ssh into this box. If you need to scale up that service, you just create more instances of that AMI and adjust a load balancer. Spinning it down is simply the destruction of instances and load balancers.
For the day-to-day operation, this box has no reason to change. We can just fire up more off of the AMI.
What happens when you need to provide an OS-level security patch? This is when you have a decision to make... do you bake a new AMI with the patch installed and redeploy all running instances, or do you ssh into existing images and update the patch? There are plenty of people who would just ssh in. The adherents of 'immutable architecture' just yelled at me for even suggesting such a thing is possible.
Immutabilists (if there is such a word) advocate baking the new ami. They advocate removing all reason to ssh into a machine ever. They advocate that any specific machine configuration should happen on the startup of that machine by pulling config details out of a repository. This is the ultimate expression of 'cattle, not pets'.
Immutable architecture is specifically about machine configurations that have no reason to change after the creation of the machine image. If something needs to change, bake a new instance image, shut down the old, bring up the new.
The discussion of that topic is fascinating, but can generally be found elsewhere on Stack Overflow. I'm resisting the urge to dive into it here. The key concept is 'not possible to change after creation'.
Imagine if, on Amazon, you deploy a web service by baking it into a Machine Image (AMI - a pre-built instance you can repeatedly re-provision). It connects to a backend database via credentials it gets out of a registry on startup. It dumps logs into a logging tool like Splunk. For normal day-to-day operation, you have no reason to ssh into this box. If you need to scale up that service, you just create more instances of that AMI and adjust a load balancer. Spinning it down is simply the destruction of instances and load balancers.
For the day-to-day operation, this box has no reason to change. We can just fire up more off of the AMI.
What happens when you need to provide an OS-level security patch? This is when you have a decision to make... do you bake a new AMI with the patch installed and redeploy all running instances, or do you ssh into existing images and update the patch? There are plenty of people who would just ssh in. The adherents of 'immutable architecture' just yelled at me for even suggesting such a thing is possible.
Immutabilists (if there is such a word) advocate baking the new ami. They advocate removing all reason to ssh into a machine ever. They advocate that any specific machine configuration should happen on the startup of that machine by pulling config details out of a repository. This is the ultimate expression of 'cattle, not pets'.
Immutable architecture is specifically about machine configurations that have no reason to change after the creation of the machine image. If something needs to change, bake a new instance image, shut down the old, bring up the new.
Context
StackExchange DevOps Q#412, answer score: 22
Revisions (0)
No revisions yet.