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

A simple example of this technique involves a database that stores user profiles. Suppose
the ability to store the user's photograph is being added. The new field that stores photo-
graphic information is added to the schema (Phase 2). A software release is pushed that
handles the new field, including the situation where the field is empty. The next software
release removes the legacy code and the need for the flag. There is no need for Phase 5
because the schema change only adds fields.
As the next example, suppose a field is replaced by new fields. The user's entire name
was stored in one field. The new schema uses three fields to store the first name, middle
name,andlastnameseparately.InPhase2,thethreenewfieldsareaddedtotheschema.In
Phase 3, we introduce a software release that reads the old and new fields. The code does
the right thing depending on whether the old or new fields are populated. Updates from the
users write to the new individual fields and mark the old field as unused. At this time a
batch job may be run that finds any profiles still using the old field and converts them to
the new fields.
Oncealllegacydataareconverted,anycodethatusestheoldfieldisremoved.Thisnew
releaseispushedintoproduction(Phase4).Oncethisreleaseisdeployed,Phase5removes
the old field from the database schema.
One way to streamline the process is to combine or overlap Phases 4 and 5. Another
optimization is to lazily remove old fields, perhaps the next time the schema is changed. In
other words, Phase 5 from schema version n is combined with Phase 2 from schema ver-
sion n + 1.
During Phase 2, software will see the new fields. This may cause problems. Software
mustbewrittentoignorethemandotherwisenotbreakwhenunexpectedfieldsexist.Gen-
erally this is not a problem, as most SQL queries request the exact fields they need, and
software accessing NoSQL databases tends to do this by convention. In SQL terms, this
means that any use of SELECT * should not make assumptions about the number or posi-
tion of fields in the data that is received. This is generally a good practice anyway, because
it makes your code more robust.
11.9 Live Code Changes
Some systems permit live code changes. This makes performing upgrades much easier.
Generally we frown on the technique of modifying a live system but some languages are
designed specifically to support it.
Erlang is one such language. A service written in Erlang can be upgraded while it is
running. Properly structured Erlang programs are designed as event-driven finite-state ma-
chines(FSM).Foreacheventreceived,aspecificfunctioniscalled.Oneeventthattheser-
vice can receive is a notification that code has been upgraded. The function that is called