THINKSTOCK

DeepDive

Copyright 2016 InfoWorld Media Group. All rights reserved. $129

PH
T
AE
A SE S S E N T I A L G U I D E T O M I C R O S E R V I C E S

InfoWorld.com

DEEP DIVE SERIES

Deep Dive

Why you should be

using microservices
Todays applications need
to be modified, scaled, and
updated constantly to meet
changing business needs.
Microservices enable you to
manage that flux easily and
reliably. BY LUCAS CARLSON

So youre sitting on hundreds of thousands

of lines of legacy C++. Oh, who are we trying to
kid? Its millions of lines of Vectran, a short-lived
Fortran variant created by IBM in the 70s.
But hey, if it aint broke, right?
Except it is broken. Anytime
someone tries to add a feature, the
thing breaks. Even trying to fix bugs
creates more bugs. But if you just
dont touch it, it keeps on working.
The problem is that innovation
demands agility and velocity. All the
cool companies that never had to worry
about Y2K are outpacing your clunky old legacy
software. Investors are demanding the next big
thing. Customers are jumping ship in droves.
The good news is that youre not alone.
Believe it or not, even the cool kids have faced
similar problems. Netflix, eBay, Amazon, Twitter,
PayPal, and more didnt start out with beautifully
architected scalable code that was fast and agile.

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive

How did eBay

overcome its
overburdened
legacy architecture? The
same way
PayPal, Twitter,
Amazon, and
Netflix did:
by killing their
application
monolith.

In 2006, eBay did a presentation at the SD

Forum about its architecture. The company
confessed to having built a monolithic 3.3-millionline C++ ISAPI DLL that compiled into a 150MB
binary. eBay developers were hitting compiler
limits on the number of methods per class, while
being expected to add over 1,200 new features
a year with 99.94 percent availability.
How did eBay overcome its overburdened
legacy architecture? The same way PayPal,
Twitter, Amazon, and Netflix did: by killing their
application monolith. They re-architected their
infrastructure using microservices, a technique
that breaks large applications into lightweight
apps that can be scaled horizontally.

Breaking down monoliths

Microservices segment functionality into separate
applications that are loosely coupled by RESTful
APIs. For example, eBay created different Java
servlet applications that handled users, items,

accounts, feedback, transactions, and more than

70 other elements back in 2006. Each of those
logical functional applications is now considered a microservice. Now eBay probably runs
hundreds of microservices.
Each of these microservices is self-contained.
They do not share a data layer. Each one has its
own database and load balancer. Isolation is a
critical component of microservices architectures;
different microservices require different scaling
techniques. For example, some microservices
might use relational databases whereas others
might employ NoSQL databases.
Building applications this way increases the
scalability of teams building applications. With
monolithic code, you have one big team of
people working on one big piece of code and
stepping on each others feet all the time. The
speed of development slows exponentially with
the growth of the code monolith. With microservices architecture, apps are built by small,

A database for every service

In a conventional architecture, a single database supports one monolithic application. In

microservices architecture, each service has its own database, which could be an RDBMS or a
NoSQL database depending on the requirements. Together, these services and their databases
deliver the user experience.
Monolith - Single database

Microservices - Application databases

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive
decentralized development teams that work and
change microservices independently. This makes
it easier to upgrade services and add functionality. Both the software and the development
process become more agile.
For all these reasons, microservices have
enjoyed increasing popularity. But every architecture has its strengths and weaknesses. Microservices architectures bring a whole new set of
problems that are hard to tackle.
In this Deep Dive, well explore the pros and
cons of microservices as we unpack this modern
method of building applications. Then well walk
through how to build a microservices-based
blogging application step by step to show how
microservices work in the real world. Finally, well

address some of the most frequent concerns

about microservices and answer the biggest
question: Should you be using microservices?
The answer to that last question may
surprise you.

The pros and cons of microservices

Microservices philosophy tears down large
monolithic applications with massive complex
internal architectures into smaller, independently
scalable applications. If youre eBay, for example,
you can imagine that the user feedback microservice would be smaller and less complex than the
bidding microservice.
When you think about it, why should those
functionalities need to be built into a single

How microservices affect who does what

Conventional application architecture groups people according to their technical expertise. Microservices architecture tends to result in multiple small teams,
each dedicated to a single service that can be updated independently. This new
arrangement encourages ownership over particular functions.

UI Team

Supply

Middleware g uys

Orders

DBAs

Recommender

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive
application in the first place? In theory, at least,
you can imagine they would live in separate application and data silos without major
problems. For example, if the average auction
received two bids, but only a quarter of all sales
received feedback, the bidding service would
be at least eight times as active as the feedback
application at any time of day.

In that way, separating different functionality

groups into separate applications makes intuitive
sense. Yet the benefit of being able to build and
scale different parts of your application independently comes with a whole new set of concerns
specifically around logging, monitoring,
testing, and debugging your newly decentralized, loosely coupled application.

FAQ: Your
microservices
questions,
answered

THINKSTOCK

AS DEVELOPERS
AND MANAGERS
WADE INTO
microservices,
many of the same
questions arise
again and again.
Here are some of
the most common
queries and their
responses.
If each service should have its own
database, then how do you associate
data between different databases?
The first concern that people have
when building microservices architectures is letting go of join tables. Once
you start building applications more
complicated than the simple blog
example in this article, this problem
becomes very apparent.
The simple solution is to use
application-level joins instead of database-level joins. This results in more
database queries more often than
a single SQL command might incur,
but you can mitigate that by incorporate caching within the microservice

layers. After all, each microservice

can have its own caching technology.
Over the long haul, this approach
might be less elegant than a straightforward database join, but its
certainly more scalable.
A more sophisticated solution
is to incorporate an event-driven,
pub-sub message bus into your
microservices architecture. The
message bus lets various microservices communicate with events
happening throughout the application. This architecture is the foundation of building truly rich and
complex microservice-based applications, because you no longer need
to rely on service APIs being instantly
available 100 percent of the time.

How do you orchestrate

microservices?
The operational overhead of running
dozens or hundreds of smaller
microservices instead of one big
monolithic application might seem
daunting. Without question, keeping
track of all the dependencies adds
complexity. Fortunately, new orchestration solutions for these problems
are becoming more stable and reliable every day.
Whether you are looking at
Kubernetes, Mesos, Swarm, or Fleet,
these orchestration tools all basically do the same thing: They let you
declaratively architect your devops
platform.
Traditional devops tools are

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive
If theres a bug, which microservice is responsible for it? The interdependencies between
microservices can make that question maddeningly hard to answer. Microservices communicate
with each other, generally through lightweight
JSON REST APIs. Unlike their predecessors
XML-RPC and SOAP, REST interfaces tend to be

THINKSTOCK

great at launching, managing, and

monitoring individual applications,
but the difference between devops
tools and orchestration services is
that orchestration services are built
to manage complex microservice
environments with dependencies
between running services.
At their foundation, all the
orchestration tools are just jobscheduling message buses. If you are
already using a message bus in your
architecture, you may want to build
your orchestration engine on top of
your message bus.
How do you decompose
existing applications?
You may not have the luxury of
rebuilding your application using
microservices architecture from the
ground up. The great thing is that
you dont need to.
If you are sitting on a significant legacy application and want
to dip your toes into breaking it
into microservices, you can start by
building faux microservices.
A faux microservice is the same as
a regular microservice except the data
store isnt isolated from other parts
of the application yet. For example, if
you have a complex custom blogging
application, you could create a faux
Article microservice that is a separate
application whose only responsibility is

more loosely defined. These lighter-weight APIs

are more flexible and easier to extend, but also
add a new interface that needs monitoring, may
break, or causes bugs.
In the old days with monolithic applications,
you could add debugging hooks within the code
and logically step through every execution layer

doing the Article REST API.

The underlying articles database, however, is still in the
same big relational database
model. That way the data is
not duplicated.
Eventually, when
enough of the faux
microservices are built
out, you can work on
segmenting the data stores
into separate silos.
Arent microservices just SOA
(service-oriented architecture)?
Microservices are kissing cousins
to SOA, but there are significant
differences. On the surface, SOA is
associated with SOAP and XML-RPC
whereas microservices are associated
with JSON. But in some ways the API
format is rather cosmetic.
Likewise, SOA uses enterprise
service buses and microservices use
more lightweight pub-sub service
busses. Again, the principle is similar,
though lighter weight.
Bob Rhubart might have put it
most eloquently when he said that
microservices must be independently deployable whereas SOA
services are often implemented in
deployment monoliths.
Microservices philosophy is
fundamentally about killing application and database monoliths. It is

about creating highly distributed,

autonomous, horizontally scalable applications. The hallmarks of
microservices are lightweight components and independent deployability.
Lightweight APIs. Lightweight service
bus. Lightweight data storage.
What about background processes?
Long-running background processes
are becoming more and more
common with the rise of big data
analytics. Fortunately, microservices are well suited for this kind of
problem.
If you have already incorporated
a pub-sub message bus into your
application architecture, background
processes are just another microservice
without the need for a port binding.
They can attach themselves by
subscribing to the message bus and
wait until an event is triggered. n

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive
to discover the problem areas. When you are
dealing with a mesh of dozens or even hundreds
of separate applications talking to each other
with loosely defined APIs, you lose that luxury.
Nonetheless, with careful planning you
can overcome these difficulties. At the present
moment, you have relatively few off-the-shelf
microservices debugging tools to choose from.
You will probably have to stitch together your
own solutions based on other, partial situations out there. But when you architect around
microservices philosophies, you gain hidden benefits, such as tying in with other new technologies
such as PaaS, Linux containers, or Docker.

The easiest
way to think
about building
a microservicebased application is to start
with the front
end and work
backward.

unless you commit the change.

The horizontal scaling philosophy of
microservices architecture promotes the concept
of share-nothing, stateless applications. That
is, they do not store or modify the underlying
file system. You can see why people conflate
microservices with Linux containers: Both retain
their state.
Microservices offer a sound approach to
application development, as long as you are
aware of the problems and shortcomings. Its not
just another tech trend that will go away next
season. Its the way many of the biggest names
in technology have tackled the problems of
large-scale growth during the past 10 years.

Microservices, containers, and PaaS

Theres a common misconception floating
around right now that to use microservices you
need to use PaaS or Linux containers or something similar. Its simply not true. You can use
PaaS and Linux containers without microservices,
and you can use microservices without PaaS or
Linux containers. Neither requires the other.
But in many ways, they do complement
each other well. PaaS environments optimize
for running many smaller applications, whether
public clouds such as Heroku or private clouds
such as Cloud Foundry or OpenShift. Porting
a 3.3-million-line C++ application to a PaaS
platform will never happen.
If you deconstruct your application into
smaller, bite-sized applications that are each
self-contained and scale independently, those
bite-sized applications often end up being good
candidates for a PaaS environment.
For that reason, thinking about adopting
microservices architectures can help accelerate
adoption of other technologies that might
already be on your road map. Likewise, Linux
containers are better suited for small, stateless
applications than large monolithic ones.
After all, one of the biggest and most obvious
differences between a virtual machine and a Linux
container is the lack of state. Virtual machines can
be configured to keep their state, whereas the
architecture of Linux containers intrinsically throws
out any differences from the base image. With
Linux containers, you can mount stateful folders
in them, but the container itself wont change

How to think about building

microservices apps
If youve never created a microservices architecture before, it takes a different way of thinking.
Many developers start application design by
starting with the database layout. They create a
whole slew of tables, including complicated join
tables. Then the application logic is built on top
of the database. Finally, the user experience is put
on top of the application logic. Like a three-layer
cake, this approach to building applications can
work well at first.
The problem with this architecture is that as
features are added to the application, new tables
and join tables are added to the database. Then
new functionality is grafted to existing code.
Over time, this becomes a huge rats nest.
The easiest way to think about building a
microservice-based application is to start with
the front end and work backward. Turn traditional architectural practice on its head.
To illustrate this inverted approach, lets
consider a simple blogging application. Traditionally, you might start building a blog app by
creating one database with an articles table, a
comments table, an authors table, etc. An article
might have various writers, so you may want to
create a join table for articles and authors.
With microservices, you might start out by
taking the blogs homepage mockup and considering the elements within it. Comments are not
on the homepage of a blog, so theres no need
to find them at this point. You dont even need

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive

Its important
to remember
that microservices are a
response to
hitting a glass
ceiling.
At some point,
traditional
monolithic
application
architectures
dont scale
anymore.

to build a comments database yet. That can

happen later.
First, you could create a self-contained REST
API microservice called Article. The front-end
mockup could become functional code by integrating a JavaScript client such as Backbone,
Angular, or Ember. All three of these JavaScript
clients natively work with any REST API and can
pull data into a design that was previously just
a mockup.
The Article REST API microservice would be
a lightweight application that focuses on the
core functionality of storing and retrieving article
data. In this stage of the microservice application
development, you dont need to worry about
authentication or security models. Additional
microservices can be layered in later. Dont
overburden any microservice with more functionality than necessary hence the micro in
microservice.
One of the important things to point out at
this stage is that since each microservice has a
very limited scope of functionality, you end up
having a lot more flexibility for the data storage
options. Without large, complicated database
designs, relational databases become less relevant, and NoSQL databases such as MongoDB,
Couchbase, Cassandra, Redis, Riak, and others
might end up working better. In theory each
microservice could use a different underlying
data storage mechanism that is best suited for
that microservice.
Once you have built your Article REST API
and its serving dynamic data to the front-end
client, you might want to tackle comments. You
can build a new self-contained Comment REST
API microservice that incorporates spam filters
and identity technology unique to commenting.
The Comment microservice fully encapsulates
all the fancy commenting code. Your front-end
client can now pull dynamic data from this new
API as necessary.
Finally, you might think about building an
Author microservice that handles authentication
and permission for creating new articles. The
author service would presumably have a control
panel front-end. It would let blog authors log
in and write new blog posts. The microservice
can then be integrated into both the front-end

client and the Article microservice itself. The

Article microservice could make an API call to the
Author microservice during the article creation
process to ensure that the author has permission
to write new blog posts.
In the past, permissions-checking might have
been done through a join table in a relational
database. The lightweight interservice API calls
can sometimes replace the join tables.
The front-end microservices application now
pulls from three separate microservices, two of
which also talk to each other. Everything in this
application is decentralized. Instead of one big
relational database, each microservice has its
database. Each microservice can scale independently. You might set up a load balancer with
dozens of application servers for the Article
microservice, but need only one instance of the
Author microservice with no load balancer.
Finally, this decentralized, loose coupling
philosophy lends itself well to leveraging thirdparty services. For example, instead of building
your Comment microservice, you might use
Disqus. Instead of creating your own authentication microservice, you might employ Janrain.
This approach to building application
architectures might seem strange at first. But
microservices architecture has proven itself as a
viable alternative to the old monolithic beasts.
If you decide to go down this path, you will be
standing on the shoulders of giants.

Should you be using microservices?

Earlier I suggested that the answer to the question of whether you should be using microservices might surprise you. The answer is not
always going to be yes. As microservices consultant Chris Richardson says, It is not simple, but
then again, the reason you are using microservices is to tackle complexity.
Its important to remember that microservices
are a response to hitting a glass ceiling. At some
point, traditional monolithic application architectures dont scale anymore. This happens to every
successful software project. Either the database
grows too large, or there are too many millions
of lines of code, or you simply cant add features
quickly enough anymore.
If you have not hit a glass ceiling yet that

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com

DEEP DIVE SERIES

Deep Dive
is, if your legacy application is still working well
and doesnt need to be changed much then
adopting microservices for their own sake will
gain you very little other than headaches.
After all, microservices bring quirks and
difficulties to the development process. Keeping
all these new services running can sometimes feel like juggling a dozen balls in the air.
Adopting declarative orchestration tools such
as Kubernetes can take some adjustment as
well. Complex microservices architectures have
their own lexicon to cover all the new software
patterns you will need to adopt.
Yet microservices arent nearly as daunting as
SOA used to be. In fact, microservices practices
can be implemented in even the smallest software projects and you dont need to throw
away all your old code to get started. You can
start by building faux microservices.
If you have a large application
that is getting out of hand,
with software lifecycles that

take too long and a pace of innovation that

has ground to a standstill, then microservices
might be just the thing you need. Alternatively,
if you are just starting out, it would be smart to
consider building a microservices-based application from the beginning.
eBay has said that microservices architecture
has enabled the company to expand to massive
scale, increased code scalability and maintainability, spurred rapid business innovation, created
faster product delivery, and even enhanced
security. Google, Amazon, Twitter, PayPal, and
Netflix have all had similar experiences. Many of
these companies have also created tools to make
adopting microservices easier.
Whether you are currently suffering from the
problems of maintaining legacy code and dont
know how to move forward, or you are starting
out with a brand-new greenfield application, now would be a good time to
evaluate a microservices approach
to application development. n

now would be a good time to evaluate a microservices

approach to application development