Build, manage, and monitor

microservices
So!ware is eating the world
MARC ANDREESEN

Companies thriving in the new world order

for developing cloud applications

have technology as a core competency. They

microservices.

build complex cloud applications. They

constantly bring new capabilities and

The velocity that microservices is giving

features to the market. And despite the

these disrupters is even raising so!ware

constant iteration and updates to their cloud

architecture to board agendas.

application, their so!ware is rock-solid

reliable. How do they achieve such agility

Whether the term microservices is vaguely

and reliability?

familiar or something you havent

encountered yet, this article will cover what it

Over the past few years, Amazon, Uber,

is, why it matters, and what will change in

AirBnb, Netflix, Yelp, and many other industry

your company when you adopt it.

disruptors adopted a new paradigm

What are
microservices?

Traditionally, cloud applications were built as single large application (popularly known as the
monolith). Some describe microservices as a splintering of monolithic so!ware applications
into smaller pieces.

2 of 11

What are
microservices?

that misses the essential benefit of

(continued)

That is a true but incomplete explanation

of smaller microservices.

microservices each of your development

In the original Amazon architecture, a bug fix

teams can work on an independently

to the recommendation service would

shippable unit of code, called a microservice.

require changing some C++ in the monolithic

It is better to describe microservices as an

application, waiting for other groups to

architecture for the distributed development

complete their respective changes to the

of cloud applications.

monolithic application, and testing the

entire application for release. In the

For example, the original [Link] was a

microservices architecture, the

monolithic application, consisting of millions

recommendation development team can

of lines of C++. Over time, Amazon has split

make changes to their microservice and

the functionality of that single application

release it without waiting to coordinate with

into smaller services, so there is a separate

the other feature teams.

service for recommendations, for payment,

for search, and so forth. In turn, each of these

Yelp has also adopted a microservices

separate services may consist of dozens

architecture, consisting of hundreds of

services. Just loading the Yelp homepage
invokes dozens of microservices, as shown in
the example below.

3 of 11

Why
microservices?

Increased Agility

Microservices empower development organizations to respond much more quickly to market and
customer feedback. Whether its a game-changing feature or a tweak to make an existing feature
eminently more usable, no longer will its release be delayed by the schedule of the single release
train. Instead, each microservice can be released independently.

Long Iteration
Cycle of
Monolithic
Apps
Faster Iteration Cycle
of Microservices

Organizational scale

With a monolith, the risk of breaking each others code rises dramatically with each additional
developer. This slows development, as additional testing, debugging, and integration is required
to prevent inadvertent errors. In a microservices architecture, each team works on an independent
code base, so bugs are isolated to a single microservice.

4 of 11

Why
microservices?
(continued)

Development eiciency

Monolith development teams are constrained to a common technology stack and process.
Microservices architecture enables independent teams to choose the right processes and
technology for a given service. For example, the PCI standard requires that any code base that
handles credit card data be subject to compliance audits. With payment processing handled by a
single or a set of microservices, the amount of code that is in scope is substantially reduced. Or a
recommendation engine might be written in Python to use the TensorFlow machine learning
library, while other services are written in Java.

Cost eicient scaling

In a traditional monolith, the entire application must be scaled when it reaches its limits. For
example, if the application is not performing, new servers must be added that are capable of
running additional instances of the monolith. In a microservices architecture, each
microservice can be individually scaled. Thus, new servers are only added for a given
microservice that is a bottleneck. This more granular approach to scaling enables a more cost
eicient compute model.

Faster onboarding

With microservices, new engineers can safely start coding on a small microservice. Theres no
need for an engineer to learn a monolithic code base just to fix a bug.

5 of 11

Why
microservices?
(continued)

Attract more talented engineers

Microservices enables you to incrementally adopt and test new technologies and good
engineers want to work with the latest technology.

Microservices are not for everyone

While there are many benefits to microservices, microservices is not a
fit for everyone. In particular, organizations with small engineering
teams should consider a monolith-first approach. In these
organizations, the development team does not have the capacity to
independently iterate on multiple features at the same time. Adopting a
monolith first, and adding microservices as the team grows, is typically
a better strategy.

6 of 11

The impacts of
adopting a
microservices
architecture

Adopting a microservices architecture yields significant benefits, but also drives some
change. There are three types of changes to anticipate: culture, deployment infrastructure,
and developer infrastructure.

Teams gain greater autonomy

Perhaps the biggest change in adopting

This is not to say that technology stack

microservices is cultural. In order to increase

standards or architectural review boards will

agility and eiciency, microservices

disappear and chaos reign. But flexibility in

development teams make decisions that

technology and processes will increase and

were previously out of their control, such as

the review process will be more open to

ship dates. Many organizations also

team needs.

empower teams to customize their QA

strategy or technology stack.

The role of VP of Engineering will also evolve

significantly. They will orchestrate the

This reallocation of decision-making

cultural change along with changes in job

authority requires changes in people and

descriptions and training. They will evaluate

education. Handing o more responsibilities

and implement the tools and infrastructure

for ship-date decisions as well as technology

described below. And they will revamp

and process selection to teams requires at

metrics. Engineering throughput will no

least one team member capable of making

longer be measured by story points per

these decisions or some up-front investment

sprint but also by speed at which new and

in training and mentoring to develop these

updated features are deployed. Application

skills.

reliability will no longer be measured simply

by Mean Time Between Failure but also by
Mean Time To Recover for microservices.

7 of 11

The impacts of
adopting a
microservices
architecture
(continued)

Deployment Infrastructure becomes fully automated

At scale, a cloud application may have

builds it, packages it into a deployment

hundreds of individual microservices, each of

artifact such as a container or AMI, and then

which may consist of multiple instances (for

deploys the entire artifact into staging or

availability and scalability). Moreover, these

production. This is o!en referred to as

microservices will be independently updated

Continuous Delivery.

by their respective development teams. The

ballooning number of moving parts and

Elastic scaling

frequency of updates quickly require a fully

Microservices by nature are fairly ephemeral

automated deployment workflow and

new versions get deployed, old versions are

infrastructure is essential.

retired, and new instances are added or

removed based on utilization. A deployment

While there are many technology choices to

infrastructure such as Amazons Elastic

fully automate deployment workflow, there

Compute Cloud, Docker Datacenter, or

are a few common capabilities in the

Kubernetes that supports elastic scaling is

deployment infrastructure that weve

essential to support these use cases.

observed in all successful adopters of

microservices.

While many other capabilities can be added

to deployment infrastructure such as

Full automation from code to customer

automated regression testing, weve seen

Typically, once a developer commits code to

organizations successfully adopt

a source repository, there is a push button

microservices by investing in automation

process that automatically takes the latest

and elastic scaling.

source code,
8 of 11

The impacts of
adopting a
microservices
architecture
(continued)

Developer infrastructure for the microservices

network
The last challenge in adopting microservices

Some examples of the common services and

is perhaps the most poorly understood

technology needed for microservices

aspect of microservices. If a monolithic

include:

application resembles a house with dierent

features in separate rooms, a microservices

Locating the network address of a

application is more like a neighborhood of

microservice, or service discovery.

houses each hosting a microservice.

Since microservices can be ephemeral,

Communication in the microservices

microservices need to understand in real-

neighborhood requires a dierent paradigm.

time what the network addresses of

Like houses speaking by phone (instead of

available microservices.

yelling downstairs), microservices

communicate over a network. This requires a

A common interface for shared logging. In

set of common services and enabling

a monolith, log information is saved into a

technology. These tools and technologies

single file. With microservices, log

are used by developers who are coding

information is saved into a single file for each

microservices, and are distinct from the

microservice. Reconstructing a request for

deployment infrastructure used by DevOps

debugging requires assembling data from

engineers.

multiple files.

9 of 11

Eat or be eaten.
Given that the benefits of microservices require new investment and trigger changes, you may ask, as a VP Engineering was recently asked Why are
you doing microservices? He replied, Because if we dont do it, we will die from the competition moving faster.
There is incredible momentum in adopting microservices because of the benefits around agility, eiciency, onboarding, and recruiting. The number
of developers who have experience in adopting microservices is growing. The eort to adopt microservices is rapidly shrinking, and will continue to
go down over time.

Learn more
If youre interested in learning more about how to get started with microservices, visit [Link]/getting-started for
information on 5 simple steps on getting started with microservices. While the microservices journey may be a long one, getting
started is not as hard as you might think.

10 of 11

More about developer infrastructure

The basic use case for developer infrastructure is to provide a common protocol so that all microservices can connect to each other. Libraries that
support these protocols need to be available in every technology stack used by an organization. HTTP is popular choice of protocol in monolithic
architectures, but the synchronous nature of HTTP erodes reliability as you add more microservices to your network. (Microservices connected
together using HTTP are analogous to Christmas tree lights wired serially. If one light bulb goes out, your entire strand no longer lights. More
sophisticated protocols oer the ability to wire your services in parallel.)
In addition, in a microservices architecture a typical service request spans multiple microservices. For example, the process of loading all the tweets
in your Twitter feed invokes advertising-related microservices, microservices that display a tweet (including adding hashtag links and images), and
microservices that display tweets from the people you follow. Specialized tools designed to trace errors and performance to a specific microservice in
this scenario are important to insure developer productivity.
There are two fundamental capabilities required of microservices developer infrastructure:

Enable loosely coupled services. Services need well-defined protocols to communicate, and dependencies need to be contained within each
microservice. Ben Christensen, one of the architects of the Netflix microservices architecture, speaks about this challenge in his talk Dont
Build A Distributed Monolith. Loosely coupled services let you update the code for a single microservice without aecting any other services
that depend on it. Your developer infrastructure needs to provide implementations of these protocols across all your microservices.

Application resiliency. When a microservice is unavailable for whatever reason so"ware bug, network outage, machine failure the entire
cloud application must continue to function and recover gracefully with minimal human intervention. Techniques for service availability (e.g.,
load balancing), service isolation (e.g., circuit breakers), and service recovery (e.g., rollback) are an essential part of the developer toolkit.

11 of 11