There have been and continue to
be significant changes to the style of
computation, to storage, and to how
these application patterns are used to
This is only a partial list of storage
and compute models. It is not meant to
Challenges in modern microservice-based applications. These days, microservices power many scalable apps.
Microservices are pools of identical or
equivalent services running over a collection of servers. Incoming requests
are load balanced across the pool.
When a request waits for a microservice, any one from the same pool will
do the job. Sometimes, systems implement affinitization, where a subsequent
request is likely to go to the same specific microservice. Still, the outcome
must be correct if you land on any of the
Microservices help scalable systems
in two broad ways:
˲ Improved software engineering.
Building systems consisting of small
and independent microservices results
in agility. Teams owning the microservices must be accountable and have
independence and ownership. When
something needs changing, change it.
When something is broken, the owning
team is responsible.
˲ Improved operations.
Health-medi-ated deployment allows for slow rollout
of new versions into the running system.
By watching the system’s health, new
versions can be rolled back. These rolling upgrades to the microservices can
be sensitive to fault zones so an independent failure during a flaky upgrade
is not too damaging. Simply having a lot
of separate and equivalent microservices means a failure of one or more of
them is automatically repaired.
Durable state is not usually kept
in microservices. Instead, it is kept in
back-end databases, key-value stores,
caches, or other things. The remainder
of this article looks at some of these.
Microservices cannot easily update
the state across all of the microser-
vices in the pool. This is especially true
when they are coming and going willy-
nilly. It is common to keep the latest
fulfillment of the business needs and
clarity of expectations.
This article provides a partial taxonomy of diverse storage solutions available over a distributed cluster. Part of
this is an exploration of the interactions among different features of a
store. The article then considers how
distinct application patterns have
grown over time to leverage these
stores and the business requirements
they meet. This may have surprising
The Evolution of State, Storage,
And Computing … At Least So Far
This section starts by examining some of
the profound changes that have occurred
in both storage and computation. The
focus then turns to a discussion of both
durable state and session state and how
they have evolved over time. Finally, there
is a brief reminder of how data is treated
differently inside a classic database and
outside as it moves across trust and transactional boundaries.
Trends in storage and computing.
Changes in storage and computing
have put demands on how storage is
accessed and the expected behavior in
doing so. This is especially interesting
as work is smeared over pools of small
computation known as microservices.
Storage has evolved. It used to be
that storage was only directly attached
to your computer. Then came shared
appliances such as storage area networks (SANs). These are big, expensive
devices with a lot of sophisticated software and hardware to provide highly
available storage to a bunch of servers
attached to them. This led to storage
clusters of commodity servers contained in a network.
Computing has evolved. A few decades ago, it was only a single process on a single server. Years went by
before people started worrying about
communicating across multiple processes on a single server. Then the
world moved on with great excitement
to RPCs (remote procedure calls)
across a tiny cluster of servers. At the
time, we didn’t think about trust since
everyone was in the same trust zone.
We were all in the family!
In the 2000s, the concept of services
or SOA began to emerge, sometimes un-
der different names. 6 The basic aspect
of a service is trust isolation. This natu-
rally leads to applications and app code
encapsulating the data so the distrusted
outsider cannot just modify the data
As the industry started running stuff
at huge scale, it learned that busting a
service into smaller microservices has a
couple of big advantages:
˲ Better engineering. Breaking your
services (that is, trust boundaries) into
smaller pieces allows better engineering flexibility as small teams make
˲Better operability. Making these
smaller pieces stateless and restartable
allows for more resilient operations as
failures, rolling upgrades of versions,
and adjustments for varying demand
are dynamically handled.
Microservices became an essential
part of the software engineering and operations landscape.
Careful Replacement Variations
˲A write may trash the previous
value … write somewhere else first.
˲A client crash may interrupt a
sequence of writes … plan carefully.
Computing’s use of storage has
evolved. It has been quite a wild ride of
application changes as their use of storage has evolved:
˲ Direct file I/O used careful replacement for recoverability. Careful replacement is a technique that is at least as
old as the 1960s. It involves thoughtful
ordering of changes to durable storage
such that failures can be tolerated.
˲ Transactional changes were supported for application developers, providing a huge improvement. It meant
the app developer did not need to be
so careful when dealing with storage.
It also allowed a grouping of changes
to records so a bunch of records were
atomically updated. This was a lot easier. SANs implemented the required
careful replacement for the hardware
storage, allowing bigger and better databases. Databases evolved to support
two-tier and N-tier applications using
˲ Key-value stores offered more scale
but less declarative functionality for
processing the application’s data. Mul-tirecord transactions were lost as scale