Since my last post exploring the platform shift happening in today’s datacenter, the question I’ve been asked most often is, “sure, microservices, distributed architectures and containerization might make sense for the Google’s and Facebook’s of the world, but what about everyone else who doesn’t operate at Web scale?”
It’s true that the never-before-seen scale requirements thrust upon this generation’s consumer Internet companies necessitated a redesign of applications and their underlying systems, but scale is only part of the explanation. Rather, the wholesale
changes seen at the infrastructure and code levels and across the software
development lifecycle were born out of the fundamental desire to win, which
ultimately comes down to delivering the best software to millions (or billions)
of end-users fastest.
is top-of-mind, but just as important is creating organizational and software development
structures that support innovation, agility and resilience. After all, I would
argue that Facebook became
because Zuck was maniacal about 1)
maintaining hacker culture to buoy innovation which enabled the company to bring
superior software to market faster than the competition and 2) eliminating
downtime which he knew would be a growth killer. Without this focus on agility
and resilience, Facebook’s ability to scale would be moot.
enterprise IT has been consumerized, the lessons learned by the IT pros at places
like Twitter and AirBnB have made their way to the Fortune 2000. And while
enterprise apps don’t necessarily need to scale to even hundreds of thousands
of users, business agility and risk mitigation are always top-of-mind strategic
initiatives for CIOs. It follows that as every organization becomes a software organization, competitive advantage will be
characterized by companies’ ability to innovate, bring product to market faster
and navigate risk.
So, how and
why does this relate to the adoption microservices in the enterprise?
set, microservices implies an architectural choice to build and deploy
applications as suites of discreet, modular services, each running its own
process with a minimal amount of centralized management. Microservices
encourage devs to decouple software into smaller, functional components with
the expectation that they fail but don’t bring down the entire app. This, at
least in theory, results in applications that are highly available, faster to
build and easier to maintain. And consequently, adopting this architectural
paradigm enables organizations of all sizes to innovate faster and mitigate
risk. To fully appreciate this, it’s helpful understand how enterprise
applications have been traditionally built and deployed and why and how this
Challenge of the Monolith
app architecture hasn’t fundamentally changed for decades. Most apps are built
using the three-tier model which became the dominant methodology in the
client/server era. The idea is to split applications into independent,
functional code bases consisting of the front-end (presentation tier), the back-end
(logic tier) and data storage (data tier). See below for more details:
there’s a common saying that goes something like, “every successful application
is an architectural nightmare.” Problems arise when systems become too big and
unwieldy. The reason being that as the application grows and features,
integrations, etc. are added, it’s not uncommon for the code base to balloon to
millions of lines of code.
nothing inherently flawed with this; far from it. However, in a today’s world where
scalability is table stakes and new releases are expected weekly or daily, managing
these giant monoliths becomes a…nightmare. Any change, no matter how tiny, to
any module requires rebuilding and testing the entire application. This, in
turn, creates downtime, which we know is a killer. Moreover, because the
functional components of the application are packaged together as a single
unit, the only way to respond to changing levels in user demand is to scale the
entire application; another giant headache.
Promise of Microservices
of building applications as series of composable, modular services is nothing
new, dating back as far as the first UNIX operating systems. However, two more recent phenomena
explain the uptick in adoption.
First is the
ascension of open source software and the corresponding comfort of devs integrating
external libraries and APIs into their applications. Second is the rise of
containers – namely Docker – which offer a light-weight form of virtualization making
applications fast and portable across infrastructure. The beauty of containers
lies in this portability and the idea of “code once, run anywhere.” Because
containers hold the application logic and all of its dependencies, running as
an isolated process, they execute the same in any environment. This creates parity
between dev and production, and enables developers to confidently break up apps
into discreet chunks knowing they’ll run the same from their terminal to test
to production. Suffice to say, containers have been a key enabler of
You can see
from the chart below that interest in microservices has grown in lock-step with
interest in containers.
So what are
the actual benefits of microservices architecture?
A few weeks
ago I had the opportunity to visit with Mike
Bryzek, co-founder and CTO of Gilt. Mike and his team are one of the most
forward-looking technical organizations in the world, let alone New York. They
were early adopters of continuous delivery
methods and were successfully using Docker containers in production almost a
year before Docker released v1.0. Today, Gilt’s platform is composed of over
400 unique applications, spanning the gamut from pure RESTful APIs to full
stack databases and applications.
The primary goal
of this massive technical transformation was to become a product-centric,
developer-driven organization. To do so meant to enable individual tech teams
across Gilt to drive innovation as quickly as possible, providing isolation for
each team which, in turn, enabled safe iteration. Further, Mike characterized
the shift to microservices as enabling three organizational initiatives:
1. Growth – Innovation drives growth; organizations
should strive to maximize opportunities to innovate. Microservices enabled Gilt
to create self-contained teams that are responsible for their discreet application.
Test and QA are performed within each team who then also determines release
cycles, thereby owning the end-to-end product experience. This sense of
ownership, in turn, drives quicker decision making and higher levels of
innovation. Finally, empowering developers has proven to be a key selling point
in attracting top technical talent.
2. Agility – Gilt’s platform is composed of 400+
independent services, implying the organization can release and respond to bugs
and feature requests faster.
3. Risk – Gilt characterizes the expected cost
of risk as follows:
R = Probability(bad event)
* Cost(bad event) * Duration(bad event) where bad event means anything degrading the customer experience.
Microservices, if designed properly, provide significant isolation. As a result
applications are built such that any and all dependencies between services are
remote with the expectation that dependencies will fail. Whereas in a monolith
a bug can bring down the whole app (“cascading failure”), in a microservices
architecture only the compromised service goes down. As a result “bad events”
are not so bad, so risk “R” is minimized.
There are advantages
to adopting microservices in your organization that go far beyond scale, but let’s
be clear: microservices
are not a panacea for all that ails your software org and come with added
complexity. Instead of managing across three or four tiers and, you’ll have dozens
or hundreds of disparate services to build, test, deploy and run, likely in
polyglot languages and environments. This creates significant operational and technical
investor’s standpoint however, this also creates immense opportunity.
Microservices represents not only a shift at the code and infrastructure levels
of how software is designed and deployed, but also an organizational shift in
how software development pipelines are constructed and managed. Therefore we’re
likely to see not only a new set of tools to manage applications through dev,
test and production, but also a new organizational tool kit for managing people
and processes. In my mind, this trend promises to produce dozens, if not
hundreds, of exciting new companies.