Information Technology Reference
In-Depth Information
11.12 Release Atomicity
Does a release involve a specific component or the entire system?
Loosely coupled systems include many subsystems, each with its own sequence of ver-
sions. This increases the complexity of testing. It is difficult, and often impossible, to test
all combinations of all versions. It is also often a waste of resources, as not all combina-
tions will be used.
One technique is to test a particular combination of component versions: for example,
Service A running release 101, Service B running release 456, and Service D running re-
lease 246. The “(101 + 456 + 246) tuple” is tested as a set, approved as a set, and deployed
as a set. If a test fails, one or more components is improved and a new tuple is tested from
scratch. Other combinations might work, but we develop a list of combinations that have
beenapprovedanduseonlythosecombinations.Ifrollbackisrequired,werollbacktothe
previous approved tuple.
Thistechniqueisgenerallyrequiredwhencomponentsaretightlycoupled.Forexample,
loadbalancersoftware,itsplug-ins,andtheOSkernelbeingusedareoftentestedasatuple
in highly demanding environments where a performance regression would be devastating.
Another example might be the tightly coupled components of a virtualization management
system,suchasGanetiorOpenStack;virtualizationtechnology,suchasKVMorXen;stor-
age system (DRBD); and OS kernel.
The problem with this technique is that it reduces the potential rate of change. With all
components moving in lock-step, one delayed release will mean the components that are
ready to move forward have to wait.
If the components are loosely coupled, then each component can be tested independ-
ently and pushed at its own velocity. Problems are more isolated. The changed component
may fail, in which case we know it is a problem with that component. The other compon-
ents may fail, in which case we know that the changed component has introduced an in-
compatibility.
Such a system works only when components are loosely coupled. For example, at
Google the entire infrastructure is an ecosystem of small, loosely coupled services. Ser-
vices are constantly being upgraded. It is not possible to ask the entire company to stop
so that your system can be tested. Google's infrastructure is more like a biological system
than a mechanical clock. Because of this, each service has to take upward compatibility
seriously.Incompatiblechangesareannouncedlonginadvance.Toolsarecreatedspecific-
ally to help manage and track such changes. For example, when an API will change in an
incompatible way, there is a way to detect uses that will soon be deprecated and warn the
service owners who are affected.
Search WWH ::




Custom Search