- Publisher: O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
- Editor: Brian Foster
- Edition: First Edition
- Available in: Pdf
- ISBN: 978-1-491-99492-4
- Published: August 28, 2017
An Introduction to Cloud Systems From the book
Somewhere around 2002, Jeff Bezos famously issued a mandate that
- described how software at Amazon had to be written. The tenets
were as follows:
- All teams will henceforth expose their data and functionality
through service interfaces.
- Teams must communicate with each other through these inter‐
- There will be no other form of interprocess communication
allowed: no direct linking, no direct reads of another team’s data
store, no shared-memory model, no backdoors whatsoever. The
only communication allowed is via service interface calls over
- It doesn’t matter what technology they use.
- All service interfaces, without exception, must be designed from
the ground up to be externalizable. That is to say, the team must
plan and design to be able to expose the interface to developers
in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired
The above mandate was the precursor to Amazon Web Services
(AWS), the original public cloud offering, and the foundation of
everything we cover in this book. To understand the directives
above and the rationale behind them is to understand the motiva‐
tion for an enterprise-wide cloud migration. Jeff Bezos understood the importance of refactoring Amazon’s monolith for the cloud,
even at a time when “the cloud” did not yet exist! Amazon’s radical
success since, in part, has been due to their decision to lease their
infrastructure to others and create an extensible company. Other
forward-thinking companies such as Netflix run most of their busi‐
ness in Amazon’s cloud; Netflix even regularly speaks at AWS’s
re:Invent conference about their journey to AWS. The Netflix situa‐
tion is even more intriguing as Netflix competes with the Amazon
Video offering! But, the cloud does not care; the cloud is neutral.
There is so much value in cloud infrastructure like AWS that Netflix
determined it optimal for a competitor to host their systems rather
than incur the cost to build their own infrastructure.
Shared databases, shared tables, direct linking: these are typical early
attempts at carving up a monolith. Many systems begin the modern‐
ization story by breaking apart at a service level only to remain cou‐
pled at the data level. The problem with these approaches is that the
resulting high degree of coupling means that any changes in the
underlying data model will need to be rolled out to multiple serv‐
ices, effectively meaning that you probably spent a fortune to trans‐
form a monolithic system into a distributed monolithic system. To
phrase this another way, in a distributed system, a change to one
component should not require a change to another component.
Even if two services are physically separate, they are still coupled if a
change to one requires a change in another. At that point they
should be merged to reflect the truth.
The tenets in Bezos’ mandate hint that we should think of two serv‐
ices as autonomous collections of behavior and state that are com‐
pletely independent of each other, even with respect to the
technologies they’re implemented in. Each service would be
required to have its own storage mechanisms, independent from
and unknown to other services. No shared databases, no shared
tables, no direct linking. Organizing services in this manner requires
a shift in thinking along with using a set of specific, now well proven
techniques. If many services are writing to the same table in a data‐
base it may indicate that the table should be its own service. By plac‐
ing a small service called a shim in front of the shared resource, we
effectively expose the resource as a service that can be accessed
through a public API. We stop thinking about accessing data from
databases and start thinking about providing data through services.