Planned Downtime

Automated deployments

In the last chapter, we were stuck in a living nightmare, one of many endless deployments that wasted countless hours and dollars. Now we turn to sweeter dreams as we contemplate automated deployments and even continuous deployments. In this chapter we’ll learn how to design our applications for easy rollout. Along the way, we look at packaging, integration point versioning, and database schemata.

Automated deployment terms

Given the diversity of virtualization and deployment options we have now, words like server, service, and host have gotten muddy. For the rest of this chapter, the word “machine” will be a simple stand-in for configurable operating system instances. If we’re running on real metal, then it means the physical host. If we’re running a virtual machine, container, or unikernel, then that is the unit. When the distinctions matter, the text will call them out.

Service will refer to a callable interface for others to use. A service is always made up of redundant copies of software running on multiple machines. So where are we now? We have more ways to run software in production than ever. The net result is that our environments have more machines than ever, mostly virtual. We talk about pets and cattle, but given their ephemeral life- spans, we should call some of them “mayflies.” There are machines that operators never touch because they’re created by other machines. That means yet more configurations to manage and more configuration management tools to aid us. If we accept this complexity, we should certainly get something back out of it in the form of increased uptime during deployments.

The fallacy of planned downtime

Throughout this course, our fundamental premise is that version 1.0 is the beginning of the system’s life. That means we shouldn’t plan for one or a few deployments to production, but many upon many. Once upon a time, we wrote our software, zipped it up, and threw it over the wall to operations so they could deploy it. If they were nice, then maybe we would add in some release notes about whatever new configuration options they should set. Operations would schedule some planned downtime to execute the release.

Planned downtime

I hate the phrase “planned downtime.” Nobody ever clues the users in on the plan. To the users, downtime is downtime. The internal email we sent announcing the downtime doesn’t matter a bit to our users. The best downtime is downtime that the users know nothing about! Most of the time, we design for the state of the system after a release. The trouble is that they assume the whole system can be changed in some instantaneous quantum jump.

Most of the time, we design for the state of the system after a release. The trouble is that they assumes the whole system can be changed in some instantaneous quantum jump.