Last week we talked about Deployment Pipelines and Zero Downtime Deployment.
After reading Chad Fowlers excellent blogpost about immutable deployments at 6Wunderkinder, we wanted to share our views on immutability in infrastructure.
For example, instead of deploying into an existing EC2 instance, start a new server, deploy there and point your load balancer to the new server. Then remove the old server.
Replacing a system at the lowest level you can forces you to automate every deployment step.
Immutable infrastructure and Continuous deployment work great together. Completely replacing, instead of updating, an existing part of your infrastructure makes your deployments less complex.
For Immutable Infrastructure you need cloud servers and a virtualised environment.
In his AWS re:Invent Keynote Werner Vogels talked about Cloud servers as building blocks for larger systems. Jamie Begin wrote a great blog post on cloud serves as building blocks, based on the Keynote.
Today cloud instances are still used like physical hardware in the past. You set it up once and update it whenever necessary. The problem is that cloud servers are not meant to be reliable or durable.
Their advantage is that they are standardised and easy to replace. Cloud servers are like Lego pieces that can be changed whenever necessary. If you want to have a different color or the lego piece breaks, just put in a new one. You wouldn’t repair a lego piece, would you?
Our web application, the Mothership, is hosted on Heroku and has therefore always been immutable. Whenever we deploy a new version, Heroku builds the Slug and replaces current instances with it. We have enabled Herokus Zero Downtime support.
Our test server infrastructure, the Checkbot, is hosted on AWS since August 2012. Whenever we want to change the test servers, we build a completely new Amazon AMI, test it and replace the old machines with the new AMI. We will go into more detail about this in our next blogpost.
By replacing every part of our infrastructure, often several times a day, we feel very comfortable with releasing changes. This workflow allows us to improve our service very quickly.
There are many more advantages to Immutable Infrastructure than the following, but we have found these to be the most important ones to us:
Of course this approach also has its challenges. Especially around tooling.
Fixing broken servers instead of replacing them is a waste of time. It slows down the development and deployment cycle.
Test-Driven Development, Continuous Deployment and Immutable Infrastructure are practices every team should use. Together these practices help build reliable and high quality software that can be changed at any time. Being able to go back to an old version of your system in seconds allows you to experiment and innovate at a much faster pace.
In our next blog post we will show you in detail how we deploy our testing infrastructure several times a day. In future blog posts we will introduce Packer, Docker and other tools and show you how to rebuild your infrastructure constantly. Stay tuned!
About the Author
Florian Motlik: At Codeship I am responsible for the general tech vision and making sure that all of our users are happy and keep their build green. I've always been interested in helping people build great software, great products and just in general make something happen.
About the Codeship
The Codeship provides Continuous Integration and Deployment with a simple hosted system. We test every change you do in your application and if everything works we deploy to your staging or production environment. We strongly integrate with all the major Platform as a Service providers like Heroku and Engine Yard. We support GitHub, BitBucket, Amazon Web Services, Digital Ocean and many more.
Go check us out!
Posted by Florian MotlikLinkedIn Twitter Website