more quickly than the competition.
Netflix took this to a new level with
the Simian Army, which is constantly
breaking the Netflix infrastructure in
order to continuously test the resilience of its systems.
Architecture. In the context of enterprise architecture, there are typically
multiple attributes to be concerned
about—for example, availability, security, performance, usability, and so
forth. Continuous delivery introduces
two new architectural attributes: testability and deployability.
In a testable architecture, software
is designed such that developers can
(in principle, at least) discover most
defects by running automated tests on
their workstations. They shouldn’t have
to depend on complex, integrated environments to do most acceptance and
In a deployable architecture, deployments of a particular product or service
can be performed independently and
in a fully automated fashion, without
the need for significant levels of orchestration. Deployable systems can
typically be upgraded or reconfigured
with zero or minimal downtime.
Where testability and deployability are not prioritized, much testing
requires the use of complex, integrated
environments, and deployments are
“big bang” events that require many
services be released at the same time
because of complex interdependen-cies. These big bang deployments require many teams to work together
in a carefully orchestrated fashion
with many hand-offs and dependencies among hundreds or thousands of
tasks. Such deployments typically take
many hours or even days, and require
scheduling significant downtime.
Designing for testability and deployability starts with ensuring that
products and services are composed
of loosely coupled, well-encapsulated
components or modules.
A well-designed modular architecture can be defined as one in which it is
possible to test or deploy a single component or service on its own, with any
dependencies replaced by a suitable
test double, which could be in the form
of a virtual machine, stub, or mock.
Each component or service should be
deployable in a fully automated fash-
ion on developer workstations, in test
environments, or in production. In a
well-designed architecture, it is possi-
ble to achieve a high level of confidence
that the component is operating prop-
erly when deployed in this fashion.
To aid the independent deployment
of components, creating versioned
APIs that have backwards compatibil-
ity is worth the investment. This adds
complexity to systems, but the flexibil-
ity gained in terms of ease of deploy-
ment will pay for it many times over.
Any true service-oriented architecture
should have these properties—but,
unfortunately, many do not. The microservices movement, however, has
made explicit priorities of these architectural properties.
Of course, many organizations are
living in a world where services are distinctly hard to test and deploy. Rather
than re-architecting everything, we recommend an iterative approach to improving the design of an enterprise system, sometimes known as evolutionary
1 In the evolutionary architecture paradigm, we accept that
successful products and services will
require re-architecting during their life
cycles because of the changing requirements placed on them.
One pattern that is particularly valuable in this context is the strangler application, shown in Figure 2. In this pattern,
a monolithic architecture is iteratively replaced with a more componentized one
by ensuring new work is done following
the principles of a service-oriented architecture, while accepting that the new
architecture may well delegate tasks to
the system it is replacing. Over time,
more functionality will be performed
in the new architecture, and the old system being replaced is “strangled.” (See
Continuous delivery is about reducing
the risk and transaction cost of taking
changes from version control to produc-
tion. Achieving this goal means imple-
menting a series of patterns and prac-
tices that enable developers to create
fast feedback loops and work in small
batches. This, in turn, increases the
quality of products, allows developers
to react more rapidly to incidents and
changing requirements and, in turn,
build more stable and higher-quality
products and services at lower costs.
If this sounds too good to be true,
bear in mind: continuous delivery is
not magic. It’s about continuous, daily
improvement at all levels of the organi-
zation—the constant discipline of pur-
suing higher performance. As present-
ed in this article, however, these ideas
can be implemented in any domain;
this requires thoroughgoing, disci-
plined, and ongoing work at all levels
of the organization. Particularly hard,
though essential, are the cultural and
architectural changes required.
Nevertheless, as organizations of
all types and sizes from fintech startups to the U. S. government implement
these ideas, they have transitioned
from being exceptional to standard. If
you have not yet started on this path,
don’t worry—it can be achieved, and
the time to begin is now.
The Hidden Dividends of Microservices
A Conversation with Tim Marsland
The Responsive Enterprise:
Embracing the Hacker Way
Erik Meijer and Vikram Kapoor
1. Ford, N., Parsons, R. and Kua, P. Building Evolutionary
Architectures: Support Constant Change. O’Reilly
Media, 2017; ( http://evolutionaryarchitecture.com).
2. Forsgren, N. et al. State of DevOps Report. Puppet and
DevOps Research and Assessment LLC, 2014–2017;
3. Gray, J. A conversation with Werner Vogels.
acmqueue 4, 4 (2006); http://queue.acm.org/detail.
4. Humble, J., O’Reilly, B. and Molesky, J. Lean
Enterprise: How High Performance Organizations
Innovate at Scale. O’Reilly Media, 2014, 280–281.
5. Jenkins, J. Velocity culture (the unmet challenge in
ops). O’Reilly Velocity Conference, 2011; http://assets.
6. Schein, E. The Corporate Culture Survival Guide.
7. Westrum, R. A typology of organizational structures.
BMJ Quality and Safety 13, 2 (2004); http://
Jez Humble is coauthor of The DevOps Handbook, Lean
Enterprise, and Continuous Delivery. He is currently
researching how to build high-performing teams at his
startup, DevOps Research and Assessment LLC, and
teaching at UC Berkeley, CA, USA.
Copyright held by owner/author.
Publication rights licensed to ACM. $15.00.