What do “immutable servers” and AWS environments have in common?

Riccardo-AWS=tips

Deploying servers in the cloud is the easy part. The more challenging bit is to update them in a consistent way across all your environments, from QA to staging to production. In this video, I share tips on how to keep your cloud infrastructure layer up to date, specifically in AWS.

Environment updates can involve any of these changes:

  • Releasing new versions of your application
  • Updating dependencies
  • Applying security updates
  • Making configuration changes

To handle environment changes consistently, many configuration management tools are available. But none of them can guarantee that your machines will be exactly the same across all your environments. That’s because the state of a machine depends heavily on its history.

One way to achieve consistent environments is to use Immutable Servers.

What is an immutable server?

An immutable server is an image of a machine pre-configured to a desired state. It includes everything required to run in your existing cluster without any further configuration.

And how to create one? Just deploy an instance from your base operating system image. Install all the software and system dependencies your application requires. Include a specific release of your application too. And configure all of the above including any startup scripts.

You can do this using any configuration management tool you’re already comfortable with or use ElasticBox, which integrates most of them.

At this point, you can test this instance to ensure that the current state is the desired one. Then save a snapshot of the machine as an AWS AMI. You then use this AMI to provision new machines in your environments to replace existing ones.

So what are the advantages of immutable servers?

For one, you don’t have to worry about how to update your application or any of the installed software on the machines. Or worry about the downtime such updates may cause. You don’t have to fret over inconsistent states either.

Consider, for example, that a bad deployment created some extra files not cleaned up. Those files are there in some instances but not in others, and this at some point may cause failures in your application. As another example, you may remove some installed packages from a machine because you don’t need them anymore. But the state of such a machine is not the same as a new machine that does not have the package.

Immutable servers allow machines to recycle more frequently. Recycling reduces issues like memory leaks in long-running daemons, potential noisy neighbors, AWS termination notices, and kernel upgrades that require reboots.

Last but not least, if you’re using an autoscaling group, machines will provision faster with immutable servers. They’ll be ready directly after the boot without needing any additional time to install and configure the application. This allows you to respond quicker to any unexpected spikes in your workloads.

Of course using the immutable server approach requires a different deployment lifecycle. It needs some attention to the data you want to keep when disposing machines, monitoring systems, and logging aggregators given that the machines recycle often. Bear in mind that you cannot hard-code configuration information such as IPs, so it’s better to use automatically updated DNS records instead to auto-discover machines.

Hope you find these tips for AWS environments useful. Watch the video for a quick roundup. And if you have specific questions, feel free to reach me. Thanks.

Hacker News

Categories: AWS, Cloud Application Management, Cool Features & Tutorials, DevOps, Nerd Culture
Tags: , , , ,
  • Khurram Malik

    How can you use the AMI across all environments qa, stage and production when configs are different. e.g. all envs talks to different databases hence each have different datasources?