Sacrificial Architecture

Nov 19, 2014

Martin Fowler recently posted a new bliki about the concept of sacrificial architecture. He’s done a nice job of illustrating the concept so I won’t repeat too much here. This definitely falls hand-in-hand with not falling too much in love with your code. I can think back to instances where I or some colleagues may have been resistant to changing portions because they worked well and probably, secretly, we just liked how we put it all together.

At some point, parts of your code may let you down because of something you didn’t know years or possibly months or weeks ago. I think we’ve all learned the lesson at one point that this secret love is probably going to cause issues and that it may be best to be somewhat humble about your code.

This also seems to apply quite well to servers/infrastructure as we see with the movement towards using configuration management and orchestration tools such as Puppet, Chef, Vagrant, and Docker to codify, modularize, and automate infrastructure configuration. If your infrastructure configuration is giving you problems and you’ve procured better hardware or have discovered a better configuration you simply start swapping out “modules” (after testing your changes in some way of course). I don’t recall who said it but I have enjoyed a line I heard at a conference that “we need to stop treating servers like pets and instead treat them like farm animals. Go ahead and put them down if they’re diseased or are going to hurt others.”

In the end, modularity and following good design principles should lead you to more easily sacrifice portions of your code or infrastructure to add features or improve performance (another feature).