Martin Fowler: Snowflake Servers

it can be finicky business to keep a production server running. you have to ensure the operating system and any other dependent software is properly patched to keep it up to date. hosted applications need to be upgraded regularly. configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. this requires some mix of command-line invocations, jumping between gui screens, and editing text files.

the result is a unique snowflake - good for a ski resort, bad for a data center.

the first problem with a snowflake server is that it's difficult to reproduce. should your hardware start having problems, this means that it's difficult to fire up another server to support the same functions. if you need to run a cluster, you get difficulties keeping all of the instances of the cluster in sync. you can't easily mirror your production environment for testing. when you get production faults, you can't investigate them by reproducing the transaction execution in a development environment. [1]

making disk images of the snowflake can help to some extent with this. but such images easily gather cruft as unnecessary elements of the configuration, not to mention mistakes, perpetuate.

the true fragility of snowflakes, however, comes when you need to change them. snowflakes soon become hard to understand and modify. upgrades of one bit software cause unpredictable knock-on effects. you're not sure what parts of the configuration are important, or just the way it came out of the box many years ago. their fragility leads to long, stressful bouts of debugging. you need manual processes and documentation to support any audit requirements. this is one reason why you often see important software running on ancient operating systems.

a good way to avoid snowflakes is to hold the entire operating configuration of the server in some form of automated recipe. two tools that have become very popular for this recently are puppet and chef . both allow you to define the operating environment in a form of domainspecificlanguage , and easily apply it to a given system.

the point of using a recipe is not just that you can easily rebuild the server (which you could also do with imaging) but you can also easily understand its configuration and thus modify it more easily. furthermore, since this configuration is a text file, you can keep it in version control with all the advantages that brings.

if you disable any direct shell access to the server and force all configuration changes to be applied by running the recipe from version control, you have an excellent audit mechanism that ensures every change to the environment is logged. this approach can be very welcome in regulated environments.

application deployment should follow a similar approach: fully automated, all changes in version control. by avoiding snowflakes, it's much easier to have test environments be true clones of production, reducing production bugs caused by configuration differences.

a good way of ensuring you are avoiding snowflakes is to use phoenixservers . using version-controlled recipes to define server configurations is an important part of continuous delivery .

further reading

the visible ops handbook is the pioneering book that talked about the dangers of snowflakes and how to avoid them. continuous delivery talks about how this approach is a necessary part of a sane build and delivery process. true artists, however, prefer snowflakes .