Immutable Infrastructure
Immutable Infrastructure
Immutable Infrastructure
Josha Stella
Immutable Infrastructure
by Josha Stella
Copyright © 2016 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
O’Reilly books may be purchased for educational, business, or sales promotional use.
Online editions are also available for most titles (http://safaribooksonline.com). For
more information, contact our corporate/institutional sales department:
800-998-9938 or [email protected].
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Immutable Infra‐
structure, the cover image, and related trade dress are trademarks of O’Reilly Media,
Inc.
While the publisher and the author have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the author disclaim all responsibility for errors or omissions, including without limi‐
tation responsibility for damages resulting from the use of or reliance on this work.
Use of the information and instructions contained in this work is at your own risk. If
any code samples or other technology this work contains or describes is subject to
open source licenses or the intellectual property rights of others, it is your responsi‐
bility to ensure that your use thereof complies with such licenses and/or rights.
978-1-491-94374-8
[LSI]
Table of Contents
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
3. Pressing Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
What Are the Central Challenges with Immutable
Infrastructure? 33
Where Do You Put the Data? 35
How Does Immutability in Programming Inform
Infrastructure? 36
What’s Next? 38
iii
Acknowledgments
While I’m the author of this report, it was really a team effort. Credit
goes to Dan Kerrigan, a senior engineer at Fugue for the detailed
examples, to Henry Harding, our director of design for the dia‐
grams, and especially to Racquel Yerbury, our lead for publications
for taking my ideas and making them into a finished product. Other
team members lent a hand too and everyone’s efforts are much
appreciated.
Our editor Brian Anderson and the other talented professionals at
O’Reilly could not have been more helpful and supportive—thank
you for great ideas, critique, and encouragement. Finally, sincere
thanks to our external reviewers for your time and thoughtful input.
– Josh
v
CHAPTER 1
Here Then Gone: What Is
Immutable Infrastructure?
You’re standing on the beach on a bright day. You look out. There’s a
constant renewal of pointed, flashing light, here then gone, convey‐
ing energy, then ceasing to exist without any consequential decay.
The sun automates an optical phenomenon on water in motion: glit‐
ter patterns that comprise millions of ephemeral glints. In applied
optics, physicists who study the properties of light have long mar‐
veled at the Phoenix-like effect we see. Back on the beach, other
glints are immediately visible, carrying out the same energetic tasks,
then gone. No decay.
It’s an imperfect, but provocative, analogy: machines in a data center
seem like a far cry from points of natural, strobed light—not least
because we relate to them as physical items rather than as organized
energy, as long-lived rather than as ephemeral. We tend to rack
machines in an n-tier framework in our minds to a greater or lesser
degree, instead of thinking in terms of distributed, abstracted
instances or resources capable of spanning multiple availability
zones in cloud computing. But when infrastructure becomes code,
resources are, in fact, more akin to those glints on the sea than to
dedicated boxes.
1
Toward Cloud Thinking
For decades, we’ve mulled over basic questions around how we pro‐
vision machine resources—and those questions are under new scru‐
tiny with cloud computing. The techniques we’ve traditionally used
to manage machines struggle in distributed, scaled environments.
Historically, we’ve thought of machine uptime and maintenance as
desirable complements because we associate them with the overall
health of a service or application. But cloud computing lends itself
to a substantially different model of health. You drill into a more
granular kind of abstraction where component replacement makes
more sense than traditional server maintenance. Think about this
contrast:
13
For big, complex deployments involving multiple team members,
integrating immutable patterns into your workflow involves signifi‐
cant automation and testing, but it pays off. The system will be effi‐
cient with its use of resources and resilient to infrastructure quality
issues and human error.
Fundamental Patterns
Immutable infrastructure on cloud compute resources has some
fundamental patterns that should be followed:
1. You can build the new component version alongside the exist‐
ing one, then change pointers, such as DNS records, to the new
one.
Network services
Long-lived components need to conform to a declaration for them
to be immutable. Some parts of the infrastructure, such as the net‐
work, cannot have the short life spans of a compute instance. How‐
ever, they can have their configurations declared in a specification.
The runtime environment should be continuously checked against
that declaration to ensure conformance. You can do this in a unified
system, as discussed in the last section of this chapter.
A common example of where the mutability of Software Defined
Networking (SDN) services often causes pain is the reuse of security
groups on AWS across different applications or parts of an applica‐
tion. One user might depend on a certain port being open, while
another user decides it’s not necessary. If the second user modifies
the definition of the security group, it can break the first user’s appli‐
cation.
A good immutable infrastructure networking solution constantly
monitors the network configuration against the declaration and
either alters or, preferably, self-heals the network to conform to the
declaration.
Data services
Data services are used for many things, but we can consider three
categories for our purposes:
Management services
Services such as key management and access management also can
be automated to function well with immutable infrastructure pat‐
terns. A complete expression of immutable infrastructure patterns
should be a single place that configures, deploys, and manages your
application, so automation of management services is a worthy goal.
You can execute that with a system like Fugue, described in the next
section.
In this last part of the guide, we attempt to answer some tough ques‐
tions. It’s our hope that contemplation here spurs many more ques‐
tions and observations about immutable infrastructure. The point is
to spark minds to go further—to encourage individuals and shops
with deep reservoirs of talent and creativity to sharpen solutions,
explore the cloud’s intrinsic nature, and tap into its fullest capacities.
Process Challenges
To do immutable infrastructure means to fully confront everything
about distributed and stateless systems head on. If you end up build‐
ing big, monolithic programs, you’ll find that those don’t work effi‐
ciently in this environment, nor do they work with immutable pat‐
terns because immutable patterns require the ability to replace com‐
ponents automatically and often. Large, monolithic programs gener‐
ally contain many services that need to be patched and maintained
in situ. If you go too small, that can gum a system as well, as you will
have more components to keep track of than are necessary. Going
33
too small also can cause underutilization of resources. Knowing how
to measure services and determining what to do at what scale is
tough for even seasoned architects.
A mature DevOps process is also a prerequisite. Developers need to
intimately understand the operating environment due to the auto‐
mation that immutable infrastructure requires. With demand and
services scaling up and down all the time, there’s a huge impact on
application development itself—the application changes the infra‐
structure. They become a deeply connected concern.
Organizational Challenges
Crafting good processes around immutable infrastructure assumes
you have architects and developers with relatively rare skill sets.
Expensive skill sets. You also need those individuals to be agile, curi‐
ous, and willing—spreading that ethic across the team. Because the
approach is new and because the use of distribution can be tough
architecturally, those people tend to be hard to find. But once you
have a resilient architecture using immutable patterns, it’s actually
easier for programmers to write code.
Leveraging multiple tools and/or complex tools usually also necessi‐
tates the formation of multiple teams in your organization. Figuring
out who’s on first can be really tough because the human challenge
of coordinating the information exists. No single person probably
has expertise across all of the tools.
So, a CIO charged with looking at where and when to use immuta‐
ble patterns has a lot to weigh. From a business perspective, there’s
high risk up front in determining whether a shop can pull it off
without significant time, costs, and production errors. Some will feel
pressure to be more conservative about making the choice until
there are dominant, well-tested designs and systems that function
with excellence. On the other hand, once your shop is cloud native,
you can do things that your peers can’t, such as having much greater
agility in deploying and managing services, having greater deter‐
minism in your environment, reducing maintenance overhead, and
ultimately spending more of your time and money on growing your
business, rather than on maintaining your infrastructure.
What’s Next?
With cloud computing, we’re increasingly composing systems of
elastic collections of services running on many compute instances.
We now commonly employ application statelessness in order to
exploit cloud system elasticity and to achieve the performance
required of web-scale systems. We’re discovering the advantages of
automating the creation and destruction of components of a system,
incorporating changes only on replacement. But we’re also finding
that our existing methods to do so are complex and undergoing the
rapid and uneven development typical of new technologies. It’s our
contention that automated immutable infrastructure in a unified
system, via declaration and enforcement, fortifies applications. It
provides consistent resilience to cloud quality issues. As a pattern
native to the cloud’s resource abstraction, interfacing, and distribu‐
tion, immutable infrastructure is likely here to stay.
New questions will continue to emerge as we consider how legacy
and hybrid systems ultimately will undergo migration. How will the
rise of services like Lambda on AWS and similar direct compute
services play into cloud systems architecture? What abstractions will
be useful five years from now? Ten? What patterns and principles
are sound enough to not just withstand but feed evolving technolo‐
gies? Whether it’s manipulated by DevOps-style users or eventually
maintained within the guts of cloud providers’ internal systems, our
money is on immutability.