Upgrading Live Services - The Practice of Cloud System Administration - page 221

Chapter 11. Upgrading Live Services
The things that make you strong, and make you feel as though you've accom-
plished something, are not the easy ones.
—Dr. Jerri Nielsen
This chapter is about deploying new releases to the production environment. It is different
from deploying into any other environment.
The process of upgrading an environment with a new software release is called a code
push . Pushing code into production can be tricky because we are modifying a system while
it is running. This is like changing the tires of a car while it is speeding down the highway
at 90 km/h: you can do it, but it requires a lot of care and planning.
Luckily there are many techniques available, each appropriate for different situations.
This chapter catalogs the most common techniques. We then discuss best practices such as
continuous deployment and other practical matters.
11.1 Taking the Service Down for Upgrading
One way to upgrade a service is to take it down, push the new code out to all systems, and
bringtheservicebackup.Thishasthebenefitofbeingverysimpletoimplement,anditper-
mits testing of the service before real users are given access to the newly upgraded service.
Sadly, this technique requires downtime, which makes it unacceptable for most services.
However, it may be appropriate for development and demo environments where presched-
uled downtime may be permitted.
This technique also works when the service is replicated in its entirety. Each service rep-
lica can be taken down, upgraded, and brought back up if there is enough spare capacity. In
this case, usually a global load balancer (GLB) divides traffic among the working replicas.
One replica at a time is drained by removing it from the GLB and waiting until all in-flight
requests are completed. The replica can then be taken down without affecting the service.