T H E 2 01 8 DZON E G U I D E TO

Microservices
S P E E D, AG ILITY, AND FLEX IBILITY

VOLU M E I I

BROUGHT TO YOU IN PARTNERSHIP WITH

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Dear Reader, Table of Contents

It seems like the major themes in software development over 3 Executive Summary
BY KARA PHELPS
the past few years have been focused on making applications as
highly scalable as possible. New advancements in technology such 4 Key Research Findings
BY JORDAN BAKER
as cloud computing and the Internet of Things created the need,
and so new tools and strategies such as serverless, functions, 7 How Kafka Solves Common Microservice
Communication Issues
containers, and microservices are helping developers achieve
BY HANNU VALTONEN
those goals.
9 Monolith to Microservices with the Strangler Pattern
BY SAMIR BEHARA
Microservices, in particular, help developers create scalable
applications by breaking up components into different services 14 Lessons From the Birth of Microservices at Google
BY DANIEL SPOONHOWER
that can be changed in isolation from the rest of the application.
When something breaks, you'll know where to look, and you 18 Introduction to Microservices Messaging Protocols
BY SARAH ROMAN
shouldn't have to worry about breaking the rest of the app as a
result. They also have an added benefit of facilitating continuous 20 Infographic: Big Things Come In Microservices
delivery and continuous deployment practices due to the speed
24 FaaS vs. Microservices
at which developers can make changes. New applications built BY CHRISTIAN POSTA

with microservices can also allow developers to experiment with

28 Angular Libraries and Microservices
various languages, technologies, and tools without changing an BY ANTONIO GONCALVES
entire application.
34 Executive Insights on Microservices
DZO N E .CO M/G U I D E S

BY TOM SMITH
In this year's edition of DZone's Guide to Microservices: Speed,
37 Diving Deeper Into Microservices
Agility, and Flexibility, we surveyed our users about how they were
using microservices since our first guide on the subject last year. 40 Microservices Solutions Directory
We've found that developers are still thrilled about microservices
46 Glossary
and feel that the hype surrounding them is still warranted. We've
also seen that there is a steady adoption of microservices in
DZone is...
development, though not everyone is playing with microservices
BUSINESS & PRODUCT PRODUCTION EDITORIAL
in production yet. MATT TORMOLLEN CHRIS SMITH SUSAN ARENDT
CEO DIRECTOR OF PRODUCTION EDITOR-IN-CHIEF

MATT SCHMIDT ANDRE POWELL MATT WERNER

PRESIDENT SR. PRODUCTION COORD.
You'll also find articles written by several experts across the world PUBLICATIONS COORDINATOR
G. RYAN SPAIN
JESSE DAVIS SARAH DAVIS
and the industry about utilizing microservices on the application EVP, TECHNOLOGY
PRODUCTION COORD.
PUBLICATIONS ASSOCIATE
BILLY DAVIS
frontend, Kafka and other messaging protocols, comparing KELLET ATKINSON
MEDIA PRODUCT MANAGER
PRODUCTION COORD. KARA PHELPS
CONTENT & COMMUNITY
NAOMI KROMER
microservices with functions-as-a-service (FaaS), moving from SR. CAMPAIGN SPECIALIST
MANAGER

TOM SMITH
a monolith to microservices, and case studies from adopting SALES JASON BUDDAY
CAMPAIGN SPECIALIST RESEARCH ANALYST
CHRIS BRUMFIELD
microservices at Google. SALES MANAGER MICHAELA LICARI MIKE GATES
JIM DYER CAMPAIGN SPECIALIST CONTENT TEAM LEAD
SR. ACCOUNT EXECUTIVE
JORDAN BAKER
MARKETING
Microservices may not be "new," but the challenge of adopting ANDREW BARKER CONTENT COORDINATOR
SR. ACCOUNT EXECUTIVE SUSAN WALL
CMO ANNE MARIE GLEN
and maximizing their potential is still present. We hope the articles BRETT SAYRE CONTENT COORDINATOR
AARON TULL
ACCOUNT EXECUTIVE
and research in this guide helps clear the air around the subject, DIR. OF MARKETING
ANDRE LEE-MOYE
ALEX CRAFTS SARAH HUNTINGTON CONTENT COORDINATOR
and that they encourage you to explore new ways to build better KEY ACCOUNT MANAGER DIR. OF MARKETING
LAUREN FERRELL
SEAN BUSWELL WAYNETTE TUBBS
applications. SALES DEV. REP. DIR. OF MARKETING COMM.
CONTENT COORDINATOR

ASHLEY SLATE LINDSAY SMITH

JORDAN SCALES CONTENT COORDINATOR
SR. DESIGN SPECIALIST
SALES DEV. REP.
Happy reading! KRISTEN PAGÀN
DANIELA HERNANDEZ MARKETING SPECIALIST
SALES DEV. REP.
COLIN BISH
MARKETING SPECIALIST

By Matt Werner LINDSAY POPE

CUSTOMER MARKETING MAN.
PUBLICAIONS COORDINATOR, DEVADA SUHA SHIM
ACQUISITION MARKETING MAN.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 2 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Executive Summary
BY KA R A PH E LPS - CO N T EN T A N D CO MMU N IT Y MA N AGER, DEVA DA

Early adopters like Netflix and Amazon first began experimenting with IMPLICATIONS Java is the most popular programming language
microservices nearly a decade ago. Since then, their popularity has ecosystem used at companies where survey respondents work, sitting
grown exponentially. Rather than relying on monolithic applications that at 85%. Likewise, it’s also one of the most commonly used worldwide.
are difficult to maintain and scale, microservices break down large tasks Java is a mature language with a wide variety of resources — libraries are
into simple, independent processes that communicate with each other more readily available, and tools for microservice orchestration abound.
via APIs. Developers adopt microservices architectures to help solve In addition to developers’ familiarity with Java, these factors often make
common, complex issues like speed and scalability, while also support- the choice a straightforward one.
ing continuous testing and continuous delivery.
RECOMMENDATIONS The challenge of picking the right program-

To see what’s changed in the microservices space this year, we surveyed ming language for microservices isn’t much different than it is for other

548 tech professionals on how and why they use microservices, the service-oriented architectures. Talent and support are major consider-

challenges they face in developing microservices, and the frameworks ations. If your organization is already committed to the Java ecosystem,

and tools they find most helpful. it makes sense to continue using Java. Java 8 took some major steps
forward in its support for microservices development, as well.

The Web Apps and the Enterprise Business Apps

DZO N E .CO M/G U I D E S

DATA Among survey respondents who reported building web applica- The Not-So-Rosy Side, and What to Do About It
tions and services, 43% said they use microservices in development and DATA When asked what challenges they face when building apps with

production. 30% said they are considering them. Among survey respon- microservices, 37% of survey respondents building web apps and 39%

dents who are building enterprise apps, 36% said they use microservices of those building enterprise apps said that monitoring was the most

in development and production. 28% said they are considering them. significant issue. When asked what challenges they face when refactor-
ing legacy apps to a microservices architecture, responses were slightly
IMPLICATIONS Most organizations are either considering imple- more diverse. For those developing web apps, the largest share went to
menting microservices, or already have. Microservices have a wide range “overcoming tight coupling” at 28%, closely followed by “finding where to
of applications, addressing many of the more troublesome issues faced break up monolithic components” at 27%. Those developing enterprise
in modern IT. apps also named those two categories the most frequently, each at 31%.

RECOMMENDATIONS If you’re planning to develop a new appli- IMPLICATIONS Monitoring microservices is a more complex task
cation, whether it’s web-based software-as-a-service (SaaS) or designed than monitoring monolithic applications due to multiple potential
for the enterprise, microservices may be the best way to future-proof it. points of failure. Systems degrade, and any slowdowns in performance
Still, they aren’t a one-size-fits-all solution — among survey respondents could impact your app’s dependencies. When it comes to refactoring
who said they aren’t interested in microservices, 58% said it was due to legacy apps, tasks like updating databases for loose coupling and
a lack of applicable use cases. The rest attributed their disinterest to a deciding how to divide capabilities among microservices are crucial and
lack of knowledge on the subject or a lack of training. resource-intensive.

Microservices By Any Other Language RECOMMENDATIONS This all might sound a bit daunting, but

DATA Among survey respondents working at companies with Java don’t worry! You can choose from a wide variety of tools and resources

ecosystems, 52% said using a microservices architecture has made their designed to help with these common problems. Application perfor-

job easier, compared to 40% who work with JavaScript, 26% who work mance monitoring and structural code analysis can be automated.

with Node.js, and 21% who work with Python. Among respondents Check out the Solutions Directory in this Guide for a convenient place to

developing web apps, 83% said Java is the programming language that start your research.

best supports microservices development. Among those developing

enterprise business apps, 85% agreed.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

• 82% work on developing web applications/services, 46% devel-

Key
op enterprise business applications, and 14% develop high-risk
software.

• There were five main programming language ecosystems reported:

Research
–– 85% Java
–– 70% JavaScript (client-side)
–– 38% Node.js

Findings
–– 34% Python
–– 33% C#

• The average respondent has 17 years of experience in the soft-

ware industry.

BY JORDAN BAKER - CONTENT COORDINATOR, DEVADA

THE WHO, WHEN, AND WHY OF MICROSERVICES

59% of respondents reported using microservices in some capacity, though
DEMOGRAPHICS
where they implemented microservices in the SDLC proved somewhat
For the 2018 DZone Guide to Microservices, we surveyed developers,
variant. 38% use microservices in both development and production,
architects, and technologists from across the software and IT industry.
while 16% use them in development only, and just 5% use microservices in
We received 682 responses with a 79% completion rate. Based on these
production only. If we compare these numbers to the two most prominent
numbers, we’ve calculated the margin of error for this survey to be 2%.
types of developers in this survey (web app and enterprise business app),
Below is a brief look into the demographics of our survey takers.
we see that using microservices in both development and production

• 43% live in Europe, 23% in the USA, and 10% in South Central Asia. proved more popular among web developers. 43% of web app developers
DZO N E .CO M/G U I D E S

(versus 36% of enterprise business app developers) reported using

• 43% work for companies headquartered in Europe and 32% work microservices in both dev and prod.
for US-based companies.
Comparing the data regarding where in the SDLC respondents use
• Most survey takers work for enterprise-sized organizations.
microservices to the data regarding language ecosystems used by
–– 28% work for organizations sized 100-999 employees. respondents, web development technologies come to the fore. 50%
–– 18% work for organizations sized 1,000-9,999 employees. of respondents who work with the Node.js ecosystem reported using
–– 18% work for organizations sized 10,000+ employees. microservices in both development and production; this proved the
highest percentage of any language ecosystem. Following Node.js, 47%
• Respondents were split into three main job categories:
of those who work with the Python ecosystem use microservices in both
–– 37% work as developers/engineers.
dev and prod, while 43% of client-side JavaScript developers and 42% of
–– 25% serve as developer team leads.
Java developers use microservices architecture in both environments.
–– 20% work as architects.

ARE YOU CURRENTLY USING A MICROSERVICES ARCHITECTURE

WHY ARE YOU USING MICROSERVICES?
FOR ANY OF YOUR APPLICATIONS?


   

  

 
 
  
 
  
   

  


      
 

  
 
   



  


        

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Now that we know who is using microservices, and where in the SDLC has a lack of applicable use cases among this group went up by 19%.
microservices are prominent, let’s examine why developers use this But also with the passing of a year, the percentage who claimed a lack of
architectural pattern. At 68%, microservices’ ability to make applications knowledge on the subject fell by 4%.
more easily scalable proved the most popular answer to this question
among respondents. In a close second, 64% of survey takers told us that DEVELOPING MICROSERVICES
they use microservices to enable faster deployments to just one part Among our general survey population, 70% (434 respondents) reported
of an application. These two uses of microservice architectures were implementing DevOps processes such as continuous delivery. Of those
by far the most popular, with a statistical differential of 23% separating 434 respondents, 39% told us they use microservice architecture in both
enabling faster deployment from the third most popular use case, development and production, 16% use microservices in development
improving quality by having teams focus on just one piece of an app. The only, and another 6% use microservices in production only. Adding these
other notable uses, each chosen by about a third of respondents, were to all up, 61% of the 434 respondents who work with DevOps processes
improve quality by narrowing down the source of failures to a particular use microservices in some capacity when developing applications. The
piece of an app (35%) and to experiment with the architecture (34%). mean number of applications respondents are currently running with a
microservices architecture came out to five; the highest number of apps
Interestingly, if we compare this data to the type of programming reported was 50 and the lowest 0. And, of those respondents who have
language ecosystems respondents use, we find that each language refactored legacy apps to take advantage of a microservice architecture,
ecosystem lends itself to a different benefit of microservices. Among the mean number of refactored apps per respondent came out to two,
those working in the Java ecosystem, the most popular use case for with 15 being the highest number of applications reported.
microservices (chosen by 86%) was experimenting with architecture.
For those working in the JavaScript ecosystem, improving by having When asked for the language they feel best supports this type of

teams focus on just one piece of an app (chosen by 72%) came out as the microservices-based development, an overwhelming majority, coming

most popular option. For Node.js (45%) and Python (28%) ecosystem in at 82% of respondents, said Java. The second most popular option

developers, making applications easily scalable won out. was the JavaScript-based runtime environment, Node.js, with a 40%
DZO N E .CO M/G U I D E S

adoption rater among survey takers. And, with a 31% adoption rate,
Due to the benefits delineated above, 68% of respondents told us they client-side JavaScript and Python also proved rather well-liked. If we
feel microservices architecture has made their job easier, and 72% said compare the adoption rate of these languages to our data on the types of
they think the excitement around microservices is indeed warranted. applications that respondents develop (and how respondents choose to
secure their microservices), we get some intriguing results.
While a large majority of respondents enjoy working with microservices,
we did have a small faction (99 respondents) who reported to be Among both web application (83%) and enterprise business application
uninterested in microservices. The most notable reason being a lack (85%) developers, Java proved the most popular language. Python,
of applicable use cases (58%). Other responses included a lack of similarly, was statistically stable between these two user groups, with
knowledge on the subject (34%) and a lack of training (25%). All three of a 32% adoption rate among web app developers and a 31% use rate
these critiques exhibit a rather interesting year-over-year pattern. While among enterprise business devs. When we get to the data on client-side
microservices detractors decreased from 125 respondents in 2017 to the JavaScript and Node.js, however, interesting fluctuations appear. While
99 in 2018 noted earlier, the percentage of those who feel microservices 45% of web app developers reported using Node.js, only 34% reported

HAS USING MICROSERVICES AS ARCHITECTURE MADE YOUR DO YOU THINK THE EXCITEMENT AROUND MICROSERVICES
JOB EASIER? IS WARRANTED?

   

   

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 5 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

using client-side JavaScript for their microservices; among enterprise frameworks/tools reported for building microservices. The platforms
business devs, 42% reported using Node.js, while only 28% claimed to used to manage microservices once built, however, had a more even
use JavaScript on the client-side. This is interesting to note, as one of the spread. 32% of those who microservices management platforms told us
main advantages of Node.js is the ability to code both server-side and they use Istio, 18% use Kong, 17% use Conduit, and 13% used Linkerd.
client-side applications in the JavaScript language. And yet, we see far
Looking at the data for communication protocols, three main choices
more respondents interested in using Node.js for their microservices-
emerged: HTTP (84%); Apache Kafka (25%); RabbitMQ (22%). If we
based development than client-side JavaScript.
compare this data to the four largest programming language ecosystems
When we asked respondents how they secure their microservices, 47% delineated in the Demographics section (Java, JavaScript, Python, and
said JSON web tokens, 43% reported using OAuth 2, and 28% told us Node.js), we find that HTTP remains the first choice for communication
they implement user authentication. When we compare these numbers protocols among a large majority of respondents. Here’s a breakdown
to the data on the top microservices-friendly languages, we find that of HTTP users per ecosystem: 84% Java; 86% Node.js.; 85% JavaScript;
JSON web tokens proved more popular among these respondents than 84% Python. Apache Kafka proved more popular among Python
among the general survey population. 55% of those who use Node.js ecosystem developers than anyone else, with a 33% adoption rate.
for microservices development reported using JSON web tokens, 52% Similarly, RabbitMQ saw a 30% adoption rate among Node.js ecosystem
who use JavaScript use JSON web tokens, and 49% who use either Java developers, an 8% increase over the general survey population.
or Python use JSON web tokens to secure their microservices. User
For the environments used to build, host, and deploy their microservices-
authentication, too, proved more popular among users of these four
based applications, over half of respondents (70%) use containers.
languages than the general population, while OAuth 2’s adoption rates
Container technology factored in heavily in development, with 27% of
witnessed far less fluctuation.
respondents using containers only in the development stage and 35%
Despite the popularity of microservices, this architectural pattern using containers in both development and production. Among this
comes with its own set of challenges. 58% of respondents reported that group of survey takers doing microservice development in containerized
DZO N E .CO M/G U I D E S

monitoring can present an issue when building apps with microservices. environments, 51% use Kubernetes as their container orchestration
Fascinatingly, the second most oft reported challenge of building apps tool. To delve deeper into the topics of containerization and container
with microservices was changing culture to be open to microservices. orchestration, head over to the DZone Guide to Containers: Development
40% of respondents told us cultural shift presents an issue. Though and Management.
other, more technical, challenges were reported — like changing API
Even with all these statistics, developers still appear split on the
contracts (34%) and communicating between microservices (32%) — it
usefulness of tools and frameworks for microservices development. 60%
appears that organizational structure has become a bigger roadblock to
of respondents told us they feel that tools and frameworks have provided
microservice adoption.
sufficient best practices for working with microservices, with 40% feeling
there is still work to be done on this front.
TOOLS FOR BUILDING MICROSERVICES
Given that 82% of respondents said they felt Java was one of the
languages that best supports microservices, it comes as no surprise
that Spring Boot (57%) and Java EE (22%) were the two most used

WHAT PROTOCOLS DO YOU USE TO COMMUNICATE WHAT CHALLENGES DO YOU FACE WHEN BUILDING APPS
BETWEEN SERVICES? WITH MICROSERVICES?

   

   

    

   


    

    



  
    

     

 

    

   

            

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 6 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. There are multiple approaches

to handling microservices
communication.

How Kafka Solves 02. HTTP REST APIs are often simple
to start with but become complex as
systems grow.

Common Microservice 03. Having centralized message

queues simplify certain aspects of

Communication Issues
microservices architecture, but have
scaling limitations.

04. Apache Kafka decouples

message senders from receivers and
extends message queuing systems
towards being able to handle
BY HANNU VALTONEN streaming data.
VP PRODUCT, AIVEN

Microservices have communicated with each other in different ways queuing and what to do if the amount of incoming requests exceeds
since their inception. Some have preferred to use HTTP REST APIs, but the node's capacity. For example, if you assume that you have a long
these come with their own queuing issues, while some have preferred chain of services preceding the one exceeding its capacity, all of the
DZO N E .CO M/G U I D E S

older Message Queues, like RabbitMQ, which come with scaling and preceding services in the chain will need to have the same sort of back
operational concerns. pressure handling to cope with the problem.

Kafka-centric architectures aim to solve both problems. Additionally, this model requires that all of the individual HTTP REST
API services need to be made highly available. In a long processing
In this article, I'll explain how Apache Kafka improves upon the pipeline made of microservices, none of the microservices can afford
historical HTTP REST API/message queuing architectures used in to lose all of their component parts and this only works as long as at
microservices and how it further extends their capabilities. least one process from any given group is still operating normally.

A TALE OF TWO CAMPS This often requires load balancers to be put in front of these

The first camp in our story is one where communication is handled microservices. Also, service discovery is often a must since the different

by calling other services directly, often over HTTP REST APIs or some microservices need to find out where to call in order to communicate

other form of Remote Procedure Calls (RPC). with each other.

One advantage of this model is that it provides for potentially excellent

The second camp, while borrowing from the Service-Oriented
latency, as there are few middle-men in a given request path and
Architecture (SOA) concept of an Enterprise Service Bus, uses an
those components, like web servers and load balancers, are highly
intermediary that's in charge of talking to the other services and
performant and thoroughly battle-tested.
operates as a message queue.

General dependency handling between different RPC microservices

This role has often been accomplished by using a message broker
often quickly becomes more complex and eventually starts to slow
like RabbitMQ. This way of communicating removes much of the
development efforts. New approaches like Envoy proxy, which provides
communication burden from the individual services at the cost of an
a service mesh, have also been introduced to solve these issues.
additional network hop.
Although these address many of the load balancing and service
MICROSERVICES USING HTTP REST APIS discovery problems with the model, they necessitate an increase in the
HTTP REST APIs are a popular way of performing RPC between services. system's overall complexity from just using simple, direct RPC calls.
Its main benefits are simplified setup in the beginning and relative
Many companies start with only a few microservices talking to each
efficiency in sending messages.
other but eventually their systems grow and become more complex,
However, this model requires its implementor to consider things like creating a spaghetti of connections between each other.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 7 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

MESSAGE QUEUES
Another way of building microservices communications revolves around In many other message broker systems, foreknowledge of who would

the use of a message bus or message queuing systems. Old-fashioned be reading the message was needed; this hampered the adoption of

Service-Oriented Architecture called these enterprise service buses new use cases in traditional queuing systems.
(ESBs). Often, they've been message brokers like RabbitMQ or ActiveMQ.
When using Apache Kafka, messages are written to a log-style stream
Message brokers act as a centralized messaging service through called a topic and the senders writing to the topic are completely
which all of the microservices in question talk to each other, with the oblivious as to who or what will actually read the messages from there.
messaging service handling things like queuing and high availability to Consequently, it is business as usual to come up with a new use case to
ensure reliable communication between services. process Kafka topic contents for a new purpose.

By supporting message queuing, messages can be received into a Kafka is completely agnostic to the payload of the sent messages,
queue for later processing instead of dropping them when processing allowing messages to be serialized in arbitrary ways, though most
capacity is maxed out during peak demand. people still use JSON, AVRO, or Protobufs as their serialization format.

However, many message brokers have demonstrated scalability You can also easily set ACLs to limit which producers and consumers
limitations and caveats around how they handle message persistence can write to and read from which topics in the system, giving you
DZO N E .CO M/G U I D E S

and delivery in clustered environments. centralized security control over all messaging.

Another large topic of conversation around message queues is how It's common to see Kafka employed as a receiver of firehose-style
they behave in error cases, e.g. whether the message delivery is data pipelines where the data volumes are potentially enormous. For
guaranteed to happen at least once, at most once, etc. example, Netflix reports that they process over two trillion messages a
day using Kafka.
The semantics chosen depend on the message queue implementation,
meaning you will have to familiarize yourself with its message One of the important properties that consumers have is that when
delivery semantics.
message load increases and the number of Kafka consumers changes
due to faults or increased capacity, Kafka will automatically rebalance
Additionally, adding a message queue to an architecture adds a new
the processing load between the consumers. This moves the need to
component to be operated and maintained, and network latency
is also increased by having one additional network hop for sent handle high availability explicitly from within the microservices to the

messages, which incurs extra latency. Apache Kafka service itself.

Security matters are slightly simplified in this model by the centralized The ability to handle streaming data extends Kafka's capabilities
nature of the Access Control Lists (ACLs) that can be used with beyond operating as a messaging system to a streaming data platform.
message queuing systems, giving central control over who can read
To top it all off, Apache Kafka provides fairly low latency when using
and write what messages.
it as a microservices communication bus, even though it incurs an
Centralization also brings some other benefits in regard to security. additional network hop for all requests.
For example, instead of having to allow all services to connect to each
This powerful combination of low latency, auto-scaling, centralized
other, you can allow only connections to the message queue service
management, and proven high availability allows Apache Kafka to
instead and firewall the rest of the services away from each other,
extend its reach beyond microservices communications to many
decreasing the attack surface.
streaming real-time analytic use cases that you’ve yet to imagine.

ADVANTAGE OF A NEW KAFKA-CENTRIC AGE

Apache Kafka is an event streaming platform created and open-sourced HAN N U VALTON EN is VP Product at Aiven, a DBaaS
by LinkedIn. What makes it radically different from older message queuing company, and an open source expert. He has decades of
systems is its ability to totally decouple senders from receivers in the experience in designing large-scale distributed systems
sense that the senders need not know who will be receiving the message. and their assorted communications architectures.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 8 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. Due to complexity, difficulty of

scaling, and technical debt, main-
taining monolithic legacy applications
can be incredibly difficult.

Monolith to 02. When moving from a monolith to

microservices, the Strangler Pattern
allows you to replace application

Microservices with
functionality step-by-step, rather than
all at once.

03. Learn how to implement the

the Strangler Pattern

Strangler Pattern in your refcatoring
efforts using the three-step transform,
co-exist, and eliminate pro

BY SAMIR BEHARA
SOLUTION ARCHITECT, EBSCO INDUSTRIES
DZO N E .CO M/G U I D E S

Working in a legacy codebase has its own challenges. With teams from pushing any of their code changes until Team
the advent of new technologies, organizations have found it B pushes a code fix. Since you are dependent on a single
difficult to continue delivering and staying competitive with pipeline to deploy changes from multiple teams, there is a
their monolithic legacy applications. To keep up with the market high chance of one team blocking the other, causing delays in
demand, its necessary to continuously evolve your applications. feature delivery to the business.
Transforming your current legacy applications into a number of
small microservices seems to be the best approach. 


Maintaining a legacy application is cumbersome and often 


leads to additional work because of multiple reasons:  



 
• Lack of unit tests  

 


• Violation of the Single Responsibility Principle 



• High complexity leads to more time spent in mainte-

nance activities
I have worked with clients on their mission-critical insurance
• Inability to scale individual components to meet in- and manufacturing applications operating on older technologies
creased demand with manual deployments. Even though there were multiple
• Tight coupling between components makes it difficult to teams working on making changes to cater to new business
deploy regularly requirements, we were not able to deploy the monolithic
application regularly. We used to have monthly releases since
• Technical debt is accumulated over time and makes
manual testing of the new changes was time-consuming and
future development difficult
also critical in an integration/staging environment. Most of the
Consider a scenario where you have multiple teams working time, even the monthly deployments could not be done because
on a monolithic application. If Team B deploys bad code to new defects were identified during the testing phase a couple of
a lower environment, it is going to block all the remaining days before the production deployment.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 9 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Over the years, the code complexity for these applications has component is strangled, the new service is put into use, and
grown and components were tightly-coupled with each other, the old component is decommissioned altogether.
which makes it difficult to implement good automated testing
Any new development is done as part of the new service and
around the codebase. Making a simple change in one class has
not part of the Mmonolith. This allows you to achieve high-
the potential to break an existing functionality implemented in
quality code for the greenfield development. You can follow
an interconnected module. Rather than relying on failing tests,
Test-Driven Development for your business logic and integrate
we have to depend upon a few key people who have been
SonarQube with your deployment pipeline to prevent any
working on these systems for an extended period of time. This
technical debt from accruing.
creates dependencies and delays in getting changes reviewed.
In the below diagram, the Order Service is eventually strangled
Finally, when everyone realized that this was not a
from the monolith into an independently deployable service
sustainable model to deliver business features, we decided
with its own CI/CD pipeline. Team A is now not dependent
to make architectural changes to decompose the monolithic
upon any issues with other teams.
application into smaller, loosely-coupled services. This would
enable teams to deploy changes to production more frequently. 

 
   
REFACTOR THE MONOLITH OR REBUILD IT
FROM SCRATCH?      

Rewriting a large monolithic application from scratch is a big 

  
  
effort and has a good amount of risk associated with it. One of 
   
the biggest challenges for us was having a good understanding
    

  
of the legacy system. We did not want to carry forward the 
DZO N E .CO M/G U I D E S

technical debt associated with the legacy system into our new
modern system.
You need to have processes in place to streamline this

Also, if you go ahead with rewriting the monolith from scratch, transition from monolith to microservices. To implement

you cannot start using the new system until it is complete. the Strangler Pattern, you can follow three steps: Transform,

You are in a corridor of uncertainty until the new system is Coexist, and Eliminate.

developed and functioning as expected. Depending upon the


size and complexity of the application, this might take over a
year in a lot of scenarios. During this period, since you are busy
developing the new system, there are minimal enhancements
  
or new features delivered on the current platform, so the
business needs to wait to have any new feature developed and
pushed out of the door.    
 
  

The Strangler Pattern reduces the above risk. Instead of

rewriting the entire application, you replace the functionality You can develop a new component, let both the new and the
step by step. The business value of new functionality is old component exist for a period of time, and finally terminate
provided much quicker. If you follow the Single Responsibility the old component.
Principle and write loosely-coupled code, it makes future
refactoring work very simple. Based on the diagram below, the steps can be summarized:

• Initially, all application traffic is routed to the legacy

WHAT IS THE STRANGLER PATTERN?
application.
The Strangler Pattern is a popular design pattern to
incrementally transform your monolithic application into • Once the new component is built, you can test your
microservices by replacing a particular functionality with new functionality in parallel against the existing mono-
a new service. Once the new functionality is ready, the old lithic code.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 0 O F 47

 THE DZONE GUIDE
THE
TODZONE
MICROSERVICES:
GUIDE TO MICROSERVICES:
SPEED, AGILITY, AND FLEXIBILITY

• Both the monolith and the newly built component need not a big undertaking when you plan to do the migration in
to be functional for a period of time. Sometimes the tran- increments and small pieces.
sitional phase can last for an extended duration.
Reducing the complexity of an application enables you to
• When the new component has been incrementally deliver business features faster. It also allows you to scale your
developed and tested, you can get rid of the legacy application based on increasing load. Having an automated CI/
monolithic application. CD pipeline makes it a lot easier to deploy the microservices
and can make the transition from monolith to microservices

much smoother.

When you are finally able to decompose your monolithic

application into a number of microservices, the representation
   will look like the diagram below. Each microservice has its own
data store and CI/CD pipeline.

   



   

 



HOW DO YOU SELECT WHICH COMPONENTS  
TO STRANGLE/REFACTOR FIRST?

• If you are following the Strangler Pattern for the first  

time and are new to this design pattern, playing it safe

DZO N E .CO M/G U I D E S




and selecting a simple component is not a bad option. 

 
 
This will ensure that you gather practical knowledge and
acclimatize yourself to the challenges and best practices
CONCLUSION
before strangling a complex component.
Transforming your existing legacy monolithic application into
• If there is a component which has good test coverage and cloud-native microservices is a nice end goal to have, but
less technical debt associated with it, starting with this the journey is challenging and needs to be well architected
component can give teams a lot of confidence during the and planned. In this article, we discussed a design pattern
migration process. called the "Strangler Pattern," which can assist you in this
journey. Teams can continue delivering business value by
• If there are components which are better suited for the
doing all greenfield development as part of new services
cloud and have scalability requirements, then start with
and incrementally migrate from monolith to microservices.
one of those components.
However, keep in mind that strangling a monolith is not a
quick process and may take some time.
• If there is a component which has frequent business
requirements and hence needs to be deployed a lot Please let me know if you have any questions and I would be
more regularly, you can start with that component. This happy to discuss them.
will ensure that you don't have to redeploy the entire
monolithic application regularly. Breaking it into a sep-
arate process will allow you to independently scale and
SAMIR BEHARA is a Solution Architect with EBSCO
deploy the application.
Industries and builds cloud native solutions using
cutting edge technologies. He is a Microsoft Data
The cloud migration journey is not an easy one and you will Platform MVP with over 12 years of IT experience.
bump into multiple hurdles. The Strangler design pattern Samir is a frequent speaker at technical conferences and is the
assists you in making this journey a bit painless and risk-free Co-Chapter Lead of the Steel City SQL Server UserGroup. He is
since you are dealing with small components at one time. It's the author of www.dotnetvibes.com.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 1 O F 47

SERVICE MESH
SIMPLIFIED

Microservices are complex

Managing them in the enterprise… even more so
We did the heavy lifting, so you don’t have to

ENTERPRISE FULLY EMPOWER

READY SUPPORTED YOUR TEAMS
Everything you expect Our fanatical engineers Thrill your developers
from Istio plus help you overcome any with a powerful
additional policy, challenges, ensuring platform that provides
analytics, and RBAC success on your the scalability and
capabilities microservices journey stability they need

For Kubernetes.
Built on Istio.
Any questions? TRY IT FOR FREE
aspenmesh.io
 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

what technologies, frameworks, and tools are best for their do-
main. The downside is that several different teams, composed of

The Importance many developers, require widely varying levels of access. Access
control that provides an appropriate separation of concerns is

of RBAC for
critical for large organizations. The ideal balance is providing the
lowest level of access that enables developers to see and control
all that they need to.

Microservices in the Role-based access control solves the challenges that come with
needing to provide varying levels of access to distributed teams

Enterprise in the enterprise. Providing RBAC is a task made easy with a ser-
vice mesh. Service mesh enables platform owners to ensure app
developers can only write policy for their own apps so that they

Microservice architectures come with huge upsides. They can move quickly without impacting other teams.

enable enterprises to develop more quickly, lead to higher avail-

To address the pressing need for enterprises to more effective-
ability, and make it easier to scale. Microservices also present
ly manage microservices, continue speeding development,
a unique set of challenges, of which one of the most pressing is
and protect network integrity, Aspen Mesh provides advanced
managing large, distributed development teams contributing to
service mesh policy and RBAC features. Try them out for free by
a single application.
signing up for Aspen Mesh beta access.

Large organizations usually consist of several independent

development teams contributing code to a single project. This is
DZO N E .CO M/G U I D E S

W RITTEN BY Z ACH JORY

advantageous as it allows them to act autonomously and decide H EA D OF M A R K ET IN G , A S P EN M ES H

PARTNER SPOTLIGHT

Aspen Mesh
Aspen Mesh makes service mesh easy with an enterprise-ready distribution of Istio

PRODUCT OPEN SOURCE? RELEASE SCHEDULE

Service Mesh No Continuous

CASE STUDY STRENGTHS

Aspen Mesh is working with a US-based bank as they're migrating to a • Intuitive UI

microservice architecture so their development teams can move more quickly
• Advanced policy capabilities
to create solutions for emerging customer needs.
• Analytics and alerting
Shortly after starting this this transition, this bank found that they didn't • Multi-cluster/multi-cloud
have the visibility they were used to with the tooling they had built up
• Fully supported
around their monolith. They struggled to identify, understand, and address
performance issues. They weren't sure how to understand their security
posture and identify vulnerabilities.

They started testing Istio, and found it powerful, but complicated.

They decided to work with Aspen Mesh to harness the power of Istio with the
ease of a fully-supported enterprise distribution.

WEBSITE aspenmesh.io TWITTER @AspenMesh BLOG aspenmesh.io/blog

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 3 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. As hardware started to fail more

Lessons From the

and more, Google needed to design
applications differently.

02. Projects like GFS, BigTable, and

Birth of Microservices
more were born from this need.

03. Review some of the lessons

Google learned from these

at Google
innovations.

04. Understand why you’re adopting

microservices, beware of giant
dashboards, and be sure to monitor
everything.

BY DANIEL "SPOONS" SPOONHOWER

CO-FOUNDER, LIGHTSTEP

Our story begins in the early 2000s when Google's Search and Ads with how your software scales: microservices are useful because they
products were really taking off. At the time, the conventional wisdom address engineering management challenges. Specifically, by defining
suggested that building a reliable internet service meant buying reliable service boundaries between teams and letting them work independently,
— and expensive — servers. To keep costs down, Google engineering teams will need to communicate less and can move more quickly.
teams switched to commodity hardware. While this approach saved
DZO N E .CO M/G U I D E S

The architecture developed for Google Search and Ads, while

on cost, these servers were (as you might expect) highly unreliable. As
superficially similar to microservices, was really there to support the
hardware failure became the common case rather than the exception,
scale needed to index and search the web while serving billions of
Google engineers needed to design accordingly.
requests every second. This scale came at a cost in terms of features, and
Today, we might start by going to GitHub to look for code that others there were hundreds of other smaller teams at Google who needed tools
have developed to tackle similar problems, but in 2001, this simply that were easy to use, and who didn't care about planetary scale or tiny
wasn't an option. While there were strong communities around projects gains in efficiency.
like Linux and the Apache Web Server, these projects were mostly
As you are designing your infrastructure, consider the scale of what you
focused on the software running on a single machine. As a result, Google
need to build. Does it need to support billions of requests per second...
had no choice but to build things from scratch.
or "just" millions?
What followed was an explosion of now-legendary infrastructure
LESSON 2: SERVERLESS STILL RUNS ON SERVERS
projects, including GFS, BigTable, and MapReduce. These systems, along
Many organizations are considering skipping microservices and moving
with widely used products like Google Search and Ads, had several
straight to a "serverless" architecture. Of course, serverless still run
characteristics that we now associate with microservice architectures:
on servers, and that has important consequences for performance. As
Google built out its infrastructure, measuring performance was critical.
• Horizontal scale points that enabled the software to scale across
Among the many things that Google engineers measured and used are
thousands of physical machines
two that are still relevant to serverless:
• Reusable code for RPC, service discovery, load balancing, distrib-
uted tracing, and authentication • A main memory reference is about 100 nanoseconds.

• Frequent and independent releases • A roundtrip RPC (even within a single datacenter) is about 500,000
nanoseconds.
However, even if Google arrived at the results we are hoping to
achieve with microservices, should we follow the same path? This means that a function call within a process is roughly 5,000 times
faster than a remote procedure call to another process.
THE LESSONS
LESSON 1: KNOW WHY (YOU'RE ADOPTING MICRO- Stateless services can be a great opportunity to use serverless, but even
SERVICES) stateless functions need access to data as part their implementation. If
The most important reason to adopt microservices has nothing to do some of these data must be fetched from other services (which almost

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 4 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

goes without saying for something that's stateless!), that performance LESSON 5: YOU CAN'T TRACE EVERYTHING...OR
difference can quickly add up. The solution to this problem is (of CAN YOU?
course) a cache, but caching isn't compatible with a serverless model. Like anyone who has tried to understand a large distributed system,
Google engineers needed tools that would cut across service
Serverless has its place, especially for offline processing where latency boundaries and give them a view of performance centered around end-
is less of a concern, but often a small amount of context (in the form of to-end transactions. They built Dapper, Google's distributed tracing
a cache) can make all the difference. "Skipping" right to a serverless- system, to measure the time it takes to handle a single transaction and
based architecture might leave you in a situation where you need to to break down and assign that time to each of the services that played
step back to a more performant services-based one. a role in that transaction. Using Dapper, engineers can quickly rule out
which services aren't relevant and focus on those that are.
LESSON 3: WHAT INDEPENDENCE SHOULD MEAN
Above, I argued that organizations should adopt microservices Tracing, like logging, grows in cost as the volume of data increases.
to enable teams to work more independently. But how much When this volume increases because of an increased number of
independence should we give teams? Can they be too independent? business transactions, that's fine — as presumably you can justify
The answer is definitely yes, they can. additional costs as your business grows. The volume of tracing data
also increases combinatorically with the number of microservices,
In adopting microservices, many organizations allow each team to
however, so new microservices mean your margins will take a hit.
make every decision independently. However, the right way to adopt
microservices is to establish organization-wide solutions for common Google's solution to this problem was simple: 99.99% of traces were
needs like authentication, load balancing, CI/CD, and monitoring. discarded before they were recorded in long-term durable storage.
Failing to do so will result in lots of redundant work, as each team While this may seem like a lot to throw out, at the scale of services like
evaluates or even builds tools to solve these problems. Worse, without Google Search, even as few as 0.01% of requests can provide ample
standards, it will become impossible to measure or reason about the data for understanding latency. To keep things simple, the choice about
performance or security of the application as a whole. which traces to keep was made at the very beginning of the request.
DZO N E .CO M/G U I D E S

Subsequent work, like Zipkin, copied this technique.

Google got this one right. They had a small number of approved
languages and a single RPC framework, and all of these supported Unfortunately, this approach misses many rare yet interesting
standard solutions in the areas listed above. As a result, product teams transactions. And for most organizations, it's not necessary to take
got the benefits of shared infrastructure, and infrastructure teams could such a simplistic view of trace selection. They can use additional
quickly roll out new tools that would benefit the entire organization. signals that are available until after the request has completed as part
of selection. This means we can put more — and more meaningful —
LESSON 4: BEWARE OF GIANT DASHBOARDS traces in front of developers without increasing costs. To do so will
Time-series data is great for determining when there is a regression
require rethinking the data collection and analysis architecture, but
but it's nearly impossible to use it to determine which service was the
the payoff, in terms of reducing mean-time-to-resolution and improved
cause of the problem. It's tempting to build dashboards with dozens or
performance, is well worth the investment.
even hundreds of graphs, one for each possible root cause. You aren't
going to be able to enumerate all possible root causes, however — let SUMMARY
alone build graphs to measure them. While Google built systems that share many characteristics with
microservices as they exist today (as well as a powerful infrastructure
The best practice is to choose fewer than a dozen metrics that will give
that has since been replicated by a number of open source projects),
you the best signal that something has gone wrong. Even products as
not every design choice that Google engineers made should be
large as Google Search were able to identify a small number of signals
duplicated. It's critical to understand what led Google engineers down
that really mattered to their users. In this case, perhaps unlike others,
these paths — and what's changed in the last 15 years — so you can
what worked for Google Search can work for you.
make the best choices for your own organizations.

Ultimately, observability boils down to two activities: measuring these

DAN IEL "SPOON S" SPOON HOW ER is a co-founder at
critical signals and then refining the search space of possible root
LightStep, where he’s building performance management
causes. I use the word "refining" because root cause analysis is usually
tools for modern software systems. Previously, Spoons
an iterative process: establishing a theory for what went wrong, then
spent almost six years at Google where he worked
digging in more to validate or refute that theory. With microservices, on developer tools as part of both Google’s internal
the search space can be huge: it must encompass not only any changes infrastructure and Cloud Platform teams. He has published papers on
in the behavior of individual services, but also the connections between the performance of parallel programs, garbage collection, and real-time
them. To reduce the size of the search space effectively, you'll need programming. He has a PhD in programming languages from Carnegie
tools to help test these theories, including tracing, as described next. Mellon University but still hasn’t found one he loves.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 5 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

stateless systems, they often struggle in handling data persistency

efficiently and scalably.

State for
Specialized cloud services, such as Aiven
Microservices data cloud, are often a better choice for
handling stateful data for microservices.
Microservices architectures offer a wide array of benefits over
traditional monolithic architectures. The decoupling of individual
Thus, integrating and managing those database engines in the
components allows for independent and much faster development
microservice ecosystem remains a tough problem and could feel
cycles and evolution of system components.
like a step back in flexibility. Specialized cloud services, such as our
Aiven data cloud, are often a better choice for managing databases
While microservices architectures make application development
and other stateful systems for microservices workloads.
easier and faster, they also introduce new requirements for
handling, communicating, and persisting data which traditional
Aiven makes the best open source data infrastructure systems
monolithic shared databases do not usually play well with. Instead,
like Kafka, Cassandra, and PostgreSQL available as fully-
microservices should own their own data and use a common
managed services in all public clouds and integrates into existing
messaging platform for interservice communications.
development workflows, with open APIs and tools like Terraform to
make developers' lives easier to allow you to focus on applications,
Apache Kafka is an excellent choice for an interservice messaging
not infrastructure.
platform, and there's a variety of excellent open source database
engines supporting different use cases for your applications.
DZO N E .CO M/G U I D E S

W RITTEN BY OSKARI SAAREN MAA

However, although microservice platforms excel in running C EO, A IV EN

PARTNER SPOTLIGHT

Aiven Kafka
Aiven Kafka provides high-availability and low-latency at scale for your app’s most critical workflows.

PRODUCT OPEN SOURCE? RELEASE SCHEDULE

Managed distributed cloud data systems Yes Continuous

CASE STUDY STRENGTHS

Comcast Xfinity Home is Comcast Corporation’s (Nasdaq: CMCSA) • Fully automated: The Aiven platforms handles operations such as
home security and automation product providing 24/7 monitoring balancing, failed-node replacement, and security patches.
and smarter home security features, as well as management of
• Service integrations: Aiven Kafka can be integrated with other Aiven
third-party IoT devices.
and external services.

With millions of customers using millions of networked devices • Management dashboard: Manage your Kafka topics and ACLs from
across many regions, they needed a scalable, durable solution our UI.
that could maintain sub 50ms end-to-end latency. Apache Kafka's
• Terraform support: Include your Aiven infrastructure in your
profile made sense, but it’s notoriously difficult to manage.
Terraform tooling.
After evaluating vendors according to Comcast’s strict
• Secure: Single tenant VMs with encryption at transit and rest.
requirements, they chose Aiven Kafka because of Aiven's price,
support, and performance. Aiven Kafka now forms the backbone
CUSTOMERS
for the critical workflows within their asynchronous architecture
design driving Xfinity Home. • Comcast • Toyota • Atlassian • OVO Energy • Sphero

WEBSITE aiven.io TWITTER @Aiven_io BLOG aiven.io/blog

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 7 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. A microservice-based
architecture thrives on the autonomy
of the microservices and their instant

Introduction to availability to the consumer.

02. Since a microservices-based

application could be running across

Microservices Messaging a large variety of servers, hosts, and

processes, we see communication
tilted towards HTTP (hypertext trans-

Protocols
fer protocol), TCP (transmission con-
trol protocol), and AMQP (advanced
message queuing protocol).

03. Replication, propagation, or

duplication will help sidestep the
synchronicity issue.

BY SARAH ROMAN
CONTENT MANAGER, ROBUSTWEALTH
DZO N E .CO M/G U I D E S

When companies have pulled together an application based across a distributed, independent set of processes? A few
on a variety of services, you can expect that they’re running intersecting ways:
the microservice architectural structure. Used primarily for
• Synchronous protocol
implementation, microservices provide patterns, protocols, and
deployment of complex applications. Foundationally, this architectural • Asynchronous protocol

style subverts many of the problems associated with monolithic • Single receiver
scaling, speed, language barriers, and organization. • Multiple receivers

While there’s large-scale adoption of microservices technology due to Since services, hosts, and clients communicate differently,
these reasons, we should home in on two parts of the microservices microservices-based messaging or communication is built on the
architecture that is often a stumbling block for developers: intersections of protocols and receivers.
communication and messaging.
SYNCHRONOUS PROTOCOL
WHAT’S SO DIFFERENT ABOUT You’ll find yourself engaging in a synchronous protocol process every
COMMUNICATION IN A MICROSERVICE
day, as it’s built into chat functions, HTTP, instant messaging, and “live”
ARCHITECTURE?
capabilities. It’s a data transfer that occurs at regular intervals and is
When transitioning from a monolithic application structure to a
usually dependent on the microprocessor clock, as there needs to be a
multi-independent structure, you’ll find immediately that calling on
clock signal between the sender and receiver. You can also understand
other components isn’t aligned to a single-process system. Within
this as a protocol that requires a primary/replica configuration, as one
the single-process system, you would typically call on components
device has control over another to ensure synchronicity.
using various language methods or via Dependency Injection, like we
see with Angular. Since a microservices-based application could be
ASYNCHRONOUS PROTOCOL
running across a large variety of servers, hosts, and processes, we see
The opposite of synchronous, asynchronous protocol works outside
communication tilted towards HTTP (HyperText Transfer Protocol),
of the constrains of a clock signal and occurs at any time and at
TCP (Transmission Control Protocol), and AMQP (Advanced Message
irregular intervals. As mentioned above, the synchronous protocol is
Queuing Protocol). All of these protocols are built out for IPC, or inter-
microprocessor dependent, meaning that these protocols are often
process communication, since they’re managing shared data.
used for the processes occurring inside a computer. With asynchronous
So, how does the microservices architecture tackle communication processes, the lack of this dependence makes them widely-used for

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 8 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

cloud environments and operating systems. There is no need to wait a server). This greatly improves the availability of data and reduces
for a response from receiver after sending information. inconsistency. With propagation, you can push and pull the data from
server to client, understandably helpful for local access scenarios.
SINGLE RECEIVER
Implicit in the name, a single receiver setup denotes that each request If replication and propagation aren’t current routes to be taken, you
must be processed by one receiver. So, in the case of data transmission, could also duplicate data across microservices. This works hand-in-
requests need to be staggered in order to be received, as they cannot hand with domain-model boundaries for each microservice. When
be received at the same time. working with domain-model boundaries, you’re looking to focus in
on the scope of business capabilities and create understandable and
MULTIPLE RECEIVERS meaningful separations between services. If you achieve meaningful
Multiple receivers can process multiple requests, as each request
separation, this will also help boost scalability and domain-driven
can be processed by zero to multiple receivers. For example, you’ll
choices for data and iteration.
usually see multiple receivers used in a Saga pattern, as it needs to be
asynchronous and simultaneously promote data consistency. WHAT ARE THE POPULAR COMMUNICATION
STYLES?
WHAT INTERSECTION IS POPULAR FOR So, after the larger considerations of microservice to microservice
MICROSERVICE-BASED ARCHITECTURE? communications, what do most people do?
As you can see, the architecture relies on combinations of protocols
and receivers due to the wide variety of services that need to be • Use HTTP/REST (synchronous) communication for services

consolidated and managed. The most commonly-used combination outside of the internal microservices structure. The HTTP/REST

tends to be single-receiver communication with synchronous protocol, communication is ideal for external requests, as it’s built to

like HTTP or HTTPS, as it’s calling on a regular web service. You can easily handle items like real-time interactions from a client.

imagine its frequency when we think about how Docker enabled the • Use AMQP (asynchronous) for communication methods within
use of containers that can easily run web applications.
DZO N E .CO M/G U I D E S

the internal microservices structure.

WHAT’S THE OVERALL IMPORTANCE OF THIS? Ultimately, the microservices architecture follows logical conclusions
While these discussion points could be somewhat topical for you, for the application of messaging and communication protocols within
maintaining and integrating microservices is really the crux of the an application. When adopting microservices, there are forward-
matter when it comes to communication. Developers want to be able thinking pieces that you have to make sure you address as you develop
to maintain the independence of each microservice while seamlessly and build a multi-faceted application: scalability, infrastructure, and
and asynchronously integrating them into an application. transitions. It’s prudent to lay a strong foundation of communication
throughout the services, as it helps it grow and affects other parts of
Synchronous communication among microservices in an application is
the application down the line.
often viewed as a complication, headache, and, at worst, a death knell.
This is due to the fact that a microservice-based architecture thrives As you broaden your knowledge on microservices and potentially head
on the autonomy of the microservices and their instant availability into development and implementation, you’ll want to explore more
to the consumer. So, even if another microservice is crippled within around creating consistency within the application, exploring the
the application, there isn’t a ripple effect throughout all of the case studies around adopting microservices, and the microservices’
microservices due to synchronous dependencies. impact on the DevOps lifecycle. The microservices-based architecture
is extremely agile and powerful, especially when approached
From anecdotal research, developers often are troubled when building
after developing the foundational aspects behind communication,
out architecture due to data dependencies. Sometimes, you’ll find that
understanding the scope of each service, and the front-end needs for
one microservice needs the data from another microservice within the
clients and consumers.
application. If you were to use synchronous communication to request
the data, there’s no backup in place if that requested microservice
SARAH ROMAN is currently the Content Manager for
were to suddenly stop working. Instead of just one microservice in an the FinTech company RobustWealth. She has a technical
“out-of-order” state, there would now be two (or more). background in microcomputers and microcontrollers
and has worked on a variety of writing projects that cover
HOW DO I AVOID SYNCHRONOUS how-tos and implementations. She primarily writes
DEPENDENCIES? articles geared towards technology information and education. Prior
Replication and propagation will help sidestep the synchronicity to her roles in technical writing and content management, she was a
issue. With replication, you can store data in more than one site (like high school English teacher.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 1 9 O F 47

 r
Shape Creato Microservices are simultaneously a new and old concept. They were born out of SOA
architectures, but with the intended purpose of being used to build distributed applications
across a network. While on the surface this seems like a simple change to a
well-established practice, it has created a tidal wave of interest, excitement,

discusion, and inevitable disillusionment from developers across the web. For
DZone's Guide to Microservices, we decided to walk down the modular
architecture assembly line and ask 548 DZone Readers whether they’re
using microservices or not, and what they think of them so far.

Stage One (S HAPE C RE ATOR)

38% of developers are using Microservices in both dev

and prod, and 31% are considering using them. Only 1% of
survey respondents have tried using Microservices and decided
against using them. 

Smile Station

Hat Depot (S MI L E S TATI O N )

Stage Two
The most popular reason to adopt microservices is to create
easily scalable apps (69%), followed by enabling faster
deployments (64%) and improving quality by letting developers
focus on specific pieces of an app (42%).

Arms & Legs

Stage Three (HAT DE POT )

Of developers who use microservices, 69% have

reported that their jobs are easier as a result.

(A R MS & L EGS ) Stage Four

Regardless of whether they use microservices or not, 73%
of DZone members believe the excitement around micro-
services is warranted, though those that are interested but not
using them are more likely to be excited than those who are
actually using them.

C O PY RI G HT DZO N E .C O M 201 8
 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

March 4-6 | Orlando, Florida

21-22 March | Chantilly, France
DZO N E .CO M/G U I D E S

Microservices. Massive
Modernize the Mega
innovations. monolith
fast.
Break up applications
Modernize the monolith with into microservices
AMPLIFY™ API Builder
to innovate
• Accelerate faster
building of microservices and
APIs that drive business value
• Quickly build mediations
• Mobilize microservices and APIs that drive
as independently
scalable
business microservices
value
• Target
• Mobilize new channelsas
orchestrations and devices with
independently
fast, easy,
scalable and secure access to
microservices
enterprise resources
• Target new channels and devices with easy AMPLIFY™ API Builder
TRY IT FOR FREE
and secure access to enterprise resources
axway.com/api-builder-free-trial
T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 2 2 O F 47
 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

and deployment point of view. These kinds of systems are

Modernizing the
complex to scale out and manage, so you absolutely need a
solution that lets you quickly orchestrate and mediate APIs

Monolith: Accelerate Your

if you want to have a production-ready application to target
new channels or devices.

Microservices Projects 2. Service mesh enables safe and reliable fast inter-service
communication

With Axway To simplify service-to-service communication, use a

configurable service mesh for service discovery, load
balancing, encryption, authentication and authorization,
support for the circuit breaker pattern, and other capabilities.
Modernizing IT is about breaking down the monoliths of the past so
the business can innovate faster and stay competitive and relevant By creating a dynamic infrastructure layer for communication
in the future. Implementing microservices efficiently is essential to at varying degrees of granularity, you can unlock the data
getting it done. trapped in your organization and mesh it up to deliver new
business value.
To build microservices that do one thing and do it well, you’ll need
to focus on making sure they are independently scalable, quickly 3. An API-first strategy offers speed and flexibility
deployable, and reliably consistent. Here are three key factors to Don’t be afraid to start designing an API before you start imple-
keep in mind. menting the microservice that will consume it. This approach ac-
celerates projects by letting you validate your API design before
1. Orchestration and mediation deliver scalability and
investing too much in writing the actual microservice.
high availability
DZO N E .CO M/G U I D E S

In a microservice-based approach, each microservice owns its

W RITTEN BY SHRAVAN THI REDDY
model and data so it will be autonomous from a development D IR ECTOR , A P I A N D A P P D EV ELOP M EN T S OLU T ION S , A X WAY

PARTNER SPOTLIGHT

Axway AMPLIFY™ API Builder

Build, assemble, and deploy APIs and microservices faster with a low-code/no-code approach based on node.js/express

PRODUCT OPEN SOURCE? NEWEST RELEASE

Building microservices and APIs No Version 4.0

PRODUCT OVERVIEW STRENGTH

API Builder provides everything you need to rapidly create microservices or APIs • Simplifies orchestration and mediation with visual
accessing enterprise resources on-premises or in the cloud, quickly orchestrate creation of custom reusable nodes
and mediate them to target new channels or devices, and deploy them to your own
• Connects faster to enterprise and cloud services to
private cloud no matter where it is running.
expose their value

Use API Builder to: • Replaces monolithic deployments with a container-

• Design your APIs using a model-first approach or API-first approach ized environment

• Add value to existing APIs or create new APIs • Increases speed and frequency with an independent-
ly deployable solution
• Read and write data to and from an external data source (such as MySQL,
• Relieves the pain of scaling for each API
MongoDB, Oracle 12g DB, or in-server memory) using a library of free, open
source, and enterprise-grade connectors

• Bake docker containers to deploy in any containerized platform

WEBSITE axway.com TWITTER @axway BLOG apifriends.com

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 2 3 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. Just because FaaS is the latest

trend doesn’t mean you necessarily
need to skip over microservices.

FaaS vs. 02. There is no “one size fits

all” strategy when adopting
microservices. 

Microservices
03. You need a pragmatic lens
through which to judge and apply
microservices and FaaS to your
existing technology stack.

BY CHRISTIAN POSTA
CHIEF ARCHITECT, RED HAT

In your journey to cloud-native nirvana, you may be adopting apply it in the context of our existing technology and IT departments.
microservices architectures for your next-generation applications. Let's take a look at a model for understanding how microservices
You may have had some initial successes with DevOps and architectures and serverless along with Functions as a Service fit
DZO N E .CO M/G U I D E S

automating your builds to help forge a path forward for your into our toolbox.
microservices journey. After a year or so, you may also be trying to
First let's understand why we would use a microservices architecture.
convince the rest of the organization to go down this path as well.
The main reason you'd opt to use a microservices architecture is to
Unfortunately, whether anticipated or not, you'll run into issues.
improve the speed at which you're able to make changes to your
Microservices is a complex architectural pattern and distributed
application when your application's monolithic nature has become
systems themselves are difficult to get right. While you march down
the source of bottlenecks and impedance for change. All of the other
the path of working through and solving some of these challenges,
benefits of microservices are derived from that basic premise. Of
you will certainly have naysayers and folks who wish to go in a
course, the reason why we'd want to go faster with our changes to
different direction. With how fast technology moves, and with the
our applications is to quickly get new features and functionality out
new shiny options for building services and applications, can you
to our customer to test whether we can achieve the expected positive
be sure your effort to make microservices a successful endeavor for
outcomes as a result of these changes. If we make changes to our
your organization is not in vain?
software in an effort to improve our business value and it does not pan

The simple answer is yes. out, then we need to quickly know that and move on to try something
new. Microservices is an optimization of our application architecture to
These days, "serverless" and "functions as a service" (FaaS) have allow us to move faster and get those changes out quicker.
found themselves at the early side of the hype cycle. Some folks
Most organizations will find that some percentage of their custom-
have gone so far to say that serverless and functions are the next
built applications will benefit from an iterative progression to a
evolution of microservices, and that you should just skip the whole
microservices architecture. These applications will benefit from
microservices architecture trend and go right to serverless. Just
this change, and as architects and developers we should not get
as you'd expect, this is a bit hyperbolic; by which you shouldn't
discouraged with the hurdles we'll see. The important thing here
be surprised. There's a lot of exciting, new technology available to
is to identify and measure improvement indicators, like how many
us as architects and developers to improve our ability to achieve
changes we can make to the software per day, how safely we're able
our business outcomes. What we need is a pragmatic lens through
to make these changes, and so on.
which to judge and apply these new technologies. Although as
technology practitioners it's our responsibility to keep up with the On the other hand, not all applications require a highly complex,
latest technology, it's equally our responsibility to know when to decomposed set of services to move faster. On the contrary, when

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 24 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

you're first experimenting with a minimum viable product and having to worry about solving all of the difficult technology
you're testing whether your idea has any market value, you may problems that need to be solved in order to make this happen. It's
opt for a different architecture more amenable to this part of someone else's (the service provider or cloud provider's) problem.
the lifecycle of an application. There's a good chance that for If you're able to outsource a lot of those difficult infrastructure
an MVP test, you strike out and there is very little, if any, market challenges to someone else, focus squarely on the business logic
value. In that case, you would just throw that MVP application that's differentiating to your business, pay as you go and on
away. You will probably be iterating it very quickly and eliciting demand, you're able to more quickly experiment, try out ideas,
feedback from potential users. In this case, the business value is and deliver business value for your customers.
not understood, the domain that you implement in code will be
Outsourcing this kind of functionality may not always be possible,
constantly changing (if not disappearing altogether), and you'll
however. When we decide to leverage cloud services, we give up
gain insight into your code as you go. In this environment, you'll
control of uptime/SLA, feature road-map, bug fixing, regulatory
be changing APIs, boundaries, components, etc. that make up
compliance, et. al. to someone else. This may be an appropriate
your system. Prematurely optimizing all of these components into
tradeoff for a part of the portfolio or for parts of the organization.
distributed services with API contracts et. al, will actually slow you
Others may not be comfortable doing this.
down. You'll be constantly changing your APIs and components
together and coordinating with all of your small "two-pizza" teams,
Serverless doesn't have to be a full "public cloud or nothing"
which smells of a distributed monolith. You might as well just use a
proposition, however. If we look within a single organization, parts
monolith for that and you'll be able to go faster and get farther.
of it may be "serverless" to other parts. For example, the "buying"
side of a retail operation may provide services to other parts of the
At this point, we see that microservices can be appropriate for
organization or even third-party vendors/partners that help others
some percentage of the application portfolio, while monolith
applications make sense for some other percentage. There is no build analytics, recommendations, or other applications using the

single "one size fits all" strategy. Another angle to consider when "buyer" services. With well-defined APIs, a workflow for subscribing
DZO N E .CO M/G U I D E S

building either microservices or monoliths (and it follows whether and paying for the APIs, you could use microservices/monoliths

you're optimizing an existing architecture or building to test ideas) on your own infrastructure (or cloud) and provide serverless

is whether the functionality you need to build already exists either capabilities. In many ways, this is just an evolution of Service-

as third-party services or as existing services you own within your Oriented Architecture (SOA). The big difference when you're doing

enterprise. The idea that we can fully leverage existing services to it yourself (or one part of the organization providing services

build our applications without having to procure hardware, install to another) is that the organization as a whole is not serverless;

and patch operating systems, and optimize our capacity for the someone still has to set up, manage, patch the servers and all of

highest expected throughput for the life of the software is what the the supporting infrastructure.

cloud and its services are really all about. Cloud providers and their
Ultimately, business decisions, business goals, maturity and
partners regularly offer databases, message queues, caches, CDN,
capability of an IT organization, and any existing legacy constraints
etc. and even higher-order functionality like language translation,
come in to play when we decide what application architecture or
mapping/geo-spatial coordinate mapping, weather, etc. as on-
technologies we can leverage. If you're going down the path of
demand, pay-as-you-go services that can be combined in interesting
microservices for the right reasons, don't get distracted by other
ways to build applications. When we leverage existing higher-order
shiny things. Conversely, you will need to continually invest into
services without worrying about how to install, provision, and plan
the latest technology and skills and know when to use them.
for capacity, we are moving towards a "serverless" architecture.
Monolith, microservices, and serverless all have their place.
Serverless architectures strive to re-use existing services without
worrying about what it takes to run the service. CHRISTIAN POSTA is a Chief Architect of cloud applications
at Red Hat and well known in the community for being an
Functions as a Service is related to serverless because it allows author (Istio in Action, Manning, Microservices for Java
us to use a compute model (scoped down to that of a single Developers, O’Reilly 2016), frequent blogger, speaker, open-
application function) that helps stitch together the various services source enthusiast and committer on various open-source

we may consume to build an application. In this compute model, projects including Istio, Apache ActiveMQ, Fabric8, et.al. Christian has spent
time at web-scale companies and now helps companies create and deploy
functions are spun up on-demand and you're billed only for the
large-scale, resilient, distributed architectures - many of what we now
time a function was running. This fits well with being billed on-
call Microservices. He enjoys mentoring, training and leading teams to be
demand and pay-as-you-go with the various other services you successful with distributed systems concepts, microservices, devops, and
may consume. Now you can build applications that scale without cloud-native application design.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 2 5 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

messaging (Kafka, AMQP, NATS). Using a hybrid of synchronous

Eliminating Monolithic and asynchronous messaging styles is more pragmatic in most

use cases. Also, as part of microservices development, we need

ESB and Simplifying to create data compositions of multiple business entities that are
represented using diverse network-aware data types, such as JSON,

Microservices XML, ProtoBuf.

These network communications between services have to

Integration be implemented in a resilient manner using inter-service
communication resiliency patterns such as timeouts, retries,
bulk-head, and circuit breakers. Besides the business logic, there
A microservices-based application typically comprises multiple are cross-cutting concerns such as security, observability (logging,
business capability-oriented services that communicate over the tracing, metrics, services dependency visualization) that are
network using diverse communication protocols and patterns. essential for running microservices in production.
Integrating these services is one of the most challenging tasks in
realizing microservices architecture. Therefore, to implement microservices, we need a microservices
development technology that offers native support for network
Rather than using a conventional, centralized ESB-based approach, interactions, network resiliency patterns, network-aware data
we need to build smart-endpoints and dumb pipes to decentralize types, and integration styles, along with support for cross-cutting
and disperse the integrations across all the services. When creating concerns such a security and observability.
service integrations or compositions, we must use different
integration styles such as synchronous request-response style
W RITTEN BY KASU N IN DRASIRI
messaging (REST, GraphQL, gRPC) and event-driven asynchronous D IR ECTOR - IN T EG RAT ION A R C H IT ECT U R E, WS O2
DZO N E .CO M/G U I D E S

PARTNER SPOTLIGHT

Ballerina
Ballerina makes it easy to write microservices that integrate APIs.

PRODUCT OPEN SOURCE? NEW RELEASE

Programming language Yes Continuously

PRODUCT OVERVIEW LANGUAGE DESIGN PRINCIPLES

Ballerina is a full-fledged, open source programming language • Sequence diagrammatic: Every Ballerina program can be displayed as a
that incorporates fundamental concepts of distributed system sequence diagram of its flow.
integration. The language offers a type-safe, concurrent
• Concurrency: The concurrency model is parallel-first since interactions
environment to implement and integrate microservices.
with remote parties always involve multiple workers.
By offering first-class support for network programming, it
aims to overcome limitations in conventional centralized and • Type system: Ballerina has a structural type system with primitive, record,
configuration-driven approaches to integration, such as those object, tuple, and union types.
with ESBs, and the complexity of programming languages,
• DevOps ready: The language includes a unit test framework, build system,
with frameworks such as Spring and Node.js, which offer
documentation generation, dependency management, and versioning, and
agility but require writing large amounts of complex and
a way to share modules of reusable code as part of its core distribution.
boilerplate code to integrate endpoints. Ballerina makes
writing and integrating microservices agile and intuitive so • Secure by default: Ballerina enforces multiple security checks and secure

that you can focus more on the business capabilities rather defaults to prevent critical security vulnerabilities.

than spending time on plumbing your services together. Find • Network-aware: Services, endpoints, and networking concepts are first-
out more: ballerina.io/learn. class constructs, which are represented graphically as well as textually.

WEBSITE ballerina.io TWITTER @ballerinalang BLOG blog.ballerina.io

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 27 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. Microservices are often

considered for use on the backend,
but there are applications on the
front-end as well.

02. Walk through the

Angular Libraries
implementation of a screen or page
that includes data from multiple
services using Angular CLI.

03. Review the basics of the client-

and Microservices side UI implementations and the

chassis patterns. 

BY ANTONIO GONCALVES
SENIOR SOFTWARE ARCHITECT,
DZO N E .CO M/G U I D E S

We live in a Microservices world, and this world is here to stay. • Inventory: Allows administrators to check the avail-
Back-end developers need to dive into Domain Driven Design, ability of an item in the warehouse and buy new items if
write stateless, resilient, highly available services, keep data needed.
synchronized through Change Data Capture, handle network • Generator: Generates ISBN numbers each time a new
failure, deal with authentication, authorization, JWT... and book is created.
expose a beautiful Hypermedia API so the front-end developers
We end up with two roles (user and admin) interacting with
can add a great user interface to it.
these 3 APIs through a single user interface:

Good! But what about the front-end?

Let's say we have several microservices, several teams, several

APIs and, therefore, several user interfaces. How can you create
an integrated and consistent user interface so your users don't
actually see that there are as many user interfaces as there are
Microservices? In this post, I'm implementing the Client-side
UI composition design pattern using Angular Libraries.

A MICROSERVICES ARCHITECTURE Client-side UI composition

Let's say we have a CD BookStore application that allows
In a perfect world, these three microservices are independent,
customers to buy CDs and Books online, as well as
administrators to check the inventory. We also have some developed by three different teams and, therefore, have three

complex ISBN number generator to deal with. If we model this different user interfaces, each released at its own pace. On

application into Microservices, we might end up splitting it into one hand we have three different UIs, and on the other, we

3 separate microservices: want our users to navigate into what they see as a single and
integrated application. There are several ways of doing it, and
• Store: Deals with displaying information on CDs and the one way I'm describing here is called the Client-side UI
books, allows users to buy them. composition design pattern:

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 2 8 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Problem: How to implement a UI screen or page that displays

data from multiple services?

Solution: Each team develops a client-side UI component,

such an Angular component, that implements the region of
the page/screen for their service. A UI team is responsible for
implementing the page skeletons that build pages/screens by
composing multiple, service-specific UI components.

The idea is to aggregate, on the client side, our three user

interfaces into a single one and end up with something that
looks like this:

Once you've executed these commands, you will get the

following directory structure:

• src/app/ is the good old Angular structure. In this di-

rectory, we will have the page skeleton of the CDBook-

Store application. As you will see, this skeleton page is
only a sidebar to navigate from one Microservice UI to
another one.
DZO N E .CO M/G U I D E S

• projects/ is the directory where all the libraries end up

Aggregating several UIs into a single one works better
• projects/generator: the UI for the Generator microservice
if they use compatible technologies, of course. In this
• projects/inventory: the UI for the Inventory microservice
example, I am using Angular and only Angular to create
• projects/store: the UI for the Store microservice
the 3 user-interfaces and the page skeleton. Of course, Web
Components would be a perfect fit for this use case, but
THE SKELETON PAGE
that's not the purpose of this article.
The skeleton page is there to aggregate all the other
components. Basically, it's only a sidebar menu (allowing us
ANGULAR LIBRARIES
to navigate from one Microservice UI to another one) and a
One novelty with Angular CLI 6 is the ability to easily create
<router-outlet>. It is where you could have login/logout and
libraries. Coming back to our architecture, we could say the
other user preferences. It looks like this:
page skeleton is the Angular application (the CDBookStore
application), and then, each microservice user interface is a
library (Store, Inventory, Generator).

In terms of Angular CLI commands, this is what we have:

# Main app called CDBookStore

$ ng new cdbookstore --directory cdbookstore

/
-routing
true

# The 3 libraries for our 3 microservices UI In terms of code, despite using Bootstrap, there is nothing
$ ng generate library store --prefix str special. What's interesting is the way the routes are defined.
$ ng generate library inventory --prefix inv The AppRoutingModule only defines the routes of the main
$ ng generate library generator --prefix gen
application (here, the Home and the About menus).

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 2 9 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

const routes: Routes = [

{path: '', component: HomeComponent},
{path: 'home', component: HomeComponent},
{path: 'about', component: AboutComponent},
];
@NgModule({
imports: [RouterModule.forRoot(routes)],
exports: [RouterModule]
})
export class AppRoutingModule { }

Notice the parent/child relationship between routers. In the

In the HTML side of the side menu bar, we can find the
image above, the red router-outlet is the parent and belongs
navigation directive and the router:
to the main app. The green router-outlet is the child and
<ul class="list-unstyled components"> belongs to the library. Notice that in the store-routing.module.
<li> ts we use str has the main path, and all the other paths are
<a [routerLink]="['/home']">
children (using the children keyword):
<i class="fas fa-home"></i>
Home const routes: Routes = [
</a> {
<a [routerLink]="['/str']"> path: 'str', component: StoreComponent,
<i class="fas fa-store"></i> children:
[
Store
{path: '', component: HomeComponent},
</a>
{path: 'home', component: HomeComponent},
<a [routerLink]="['/inv']">
{path: 'book-list', component:
DZO N E .CO M/G U I D E S

<i class="fas fa-chart-bar"></i> BookListComponent},

Inventory {path: 'book-detail', component:
</a> BookDetailComponent},
<a [routerLink]="['/gen']"> ]
<i class="fas fa-cogs"></i> },
];
Generator
@NgModule({
</a>
imports: [RouterModule.forRoot(routes)],
</li> exports: [RouterModule]
</ul> })
<!-- Page Content --> export class StoreRoutingModule {
<div id="content"> }
<router-outlet></router-outlet>
</div> The beauty of having a parent/child router relationship is
that you can benefit from "feature" navigation. This means
As you can see in the code above, the routerLink directive that if you navigate to /home or /about you stay in the main
is used to navigate to the main app components as well as application, but if you navigate to /str, /str/home, /str/book-
library components. The trick here is that /home is defined in list or /str/book-detail, you navigate to the Store library.
the routing module, but not /str, /inv or /gen. These routes You can even do lazy loading on a per feature based (only
are defined in the libraries themselves. load the Store library if needed).

Disclaimer: I am a terrible web designer/developer. If

someone reading this post knows about jQuery and Angular
and want to give me a hand, I would love to have the sidebar
to be collapsible. I even created an issue for you!

THE LIBRARIES
Now when we click on Store, Inventory, or Generator, we want
the router to navigate to the library's components:

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 0 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

The Store library has a navigation bar at the top, therefore, it CONCLUSION
needs the routerLink directive. Notice that we only need to We've been architecting and developing Microservices for
use the child path [routerLink]="['book-list']" without several decades now (yes, it used to be called distributed
having to specify /str (no need to [routerLink]="['/str/ systems, or distributed services), so we roughly know how to
book-list']"):
make them work on the back-end. Now, the challenge is to be

<nav>
able to have a user interface which communicates with several
<div class="collapse navbar-collapse"> Microservices, developed by different teams, and at the same
<ul class="navbar-nav mr-auto"> time feels consistent and integrated for the end-user. You
<li class="nav-item dropdown">
might not always have this need (see how Amazon has totally
<a class="nav-link dropdown-toggle">Items</a>
<div class="dropdown-menu" aria-labelledby=
different UIs for its services), but if you do, then the Client-side
"navbarDropdownMenuLink"> UI composition design pattern is a good alternative.
<a class="dropdown-item"
[routerLink]="['book-list']">Books</a> If you want to give it a try, download the code, install and run
<a class="dropdown-item" it (there is only the front-end, no back-end APIs). And don't
[routerLink]="['cd-list']">CDs</a>
forget to give me some feedback. I would be interested to
<a class="dropdown-item"
[routerLink]="['dvd-list']">DVDs</a>
know what you do to aggregate several user-interfaces into "a
</div> single one."
</li>
</ul>
REFERENCES
</div>
</nav> • Building and publishing Angular libraries using Angular CLI
<!-- Page Content --> • How to build a library for Angular apps?
DZO N E .CO M/G U I D E S

<div id="content">
<router-outlet></router-outlet> • Building an Angular Library with the Angular CLI (version 6)
</div>
• Building an Angular Library?

• Angular Routing
PROS AND CONS
The Client-side UI composition design pattern has some • Client-side UI composition pattern
pros and cons. If you already have existing user-interfaces • NG CLI
per microservices, and if each one is using totally different
• Bootstrap
technologies (Angular vs React vs Vue.JS vs ...) or different
• Bootstrap sidebar
framework versions (Bootstrap 2 vs Bootstrap 4), then
aggregating them might be tricky and you might have to • Why Google Stores Billions of Lines of Code in a Single
rewrite bits and pieces to have them compatible. Repository

• You too can love the MonoRepo

But this can actually be beneficial. If you don't have
extended teams with hundreds of developers, you might
end up being the one moving from one team to another
one and will be happy to find (more or less) the same
technologies. This is defined in the Chassis pattern. And for
your end users, the application will have the same look and
ANTONIO GONCALVES is a senior software architect living
feel (on mobile phones, laptops, desktops, tablets), which in Paris. Initially focused on Java development since the late
gives a sense of integration. 1990s, his career has taken him to different countries and
companies where he works now as a Java EE consultant in
With the way Angular Libraries are structured, having a mono software architecture. He is particularly fond of open source
repo is much easier. Of course, each library can have their and is a member of the OOSGTP (Open Source Get Together Paris). He is
also the co-creator of the Paris Java User Group and talks on Les Cast
own life cycle and be independent, but at the end of the day,
Codeurs podcast. He has also written numerous technical papers and articles
it makes it easier to have them on the same repo. I don't know for IT Web sites (DevX, JaxEnter, DZone) and IT magazines (Programmez,
if you love MonoRepos or not, but some do. Linux Magazine).

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 1 O F 47

 T ECH N O LO G IE S

THE FREEDOM OF OPEN SOURCE

FLEXIBILITY

INTEROPERABILITY

PRODUCTIVITY

SCALABILITY

SEE WHY ORGANIZATIONS CHOOSE CLOUD FOUNDRY

http://www.cloudfoundry.org/why-cloud-foundry
 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

with a Continuous Integration tool, which takes responsibility for

Cloud Foundry -
testing the code, approving it for release, compiling and publishing it.

Having a platform like Cloud Foundry when you go the micro-

Making Microservices
services route helps offset operational complexity. Both the Cloud
Foundry Application Runtime and the Cloud Foundry Container
Runtime manage the health of microservices. What does this mean?

Easy Your platform will automatically scale up your app when there’s
demand, watch for unhealthy instances, describe services talking
to each other, accept code being offered by Continuous Integration

Microservices add a layer of complexity to application development pipelines, and more.

— we can agree on that. But they also enable choice, flexibility

You don’t need to use a microservices architecture to get value out of
and independence far more than developing within a monolithic
Cloud Foundry — you can certainly run monolithic applications inside
architecture. Microservices enable small teams to work nimbly on
it too, and see the same benefits. But if you choose a microservices
a particular function apart from the larger team. You can iterate,
architecture, a platform like Cloud Foundry removes the operational
release and manage that function independently, giving you
complexity and manages your application lifecycle to allow you and
concentrated control.
your teams to focus on your business — and ship great software.

If you use microservices to help your teams move faster and release
code more frequently, the path from writing code to production
W RITTEN BY CHIP CHIL DERS
should be as quick as possible. Platforms play a big part in this, coupled CTO, C LOU D FOU N D R Y FOU N DAT ION

PARTNER SPOTLIGHT
DZO N E .CO M/G U I D E S

Cloud Foundry Technologies

Cloud Foundry makes it faster and easier to build, test, deploy and scale applications on any cloud,
developer framework, and application service.

PRODUCT OPEN SOURCE? RELEASE SCHEDULE

Cloud Application Platform Yes Continuous

CASE STUDY STRENGTH

Zipcar isn’t just in the business of car-sharing. The brand is a full-fledged software • Polyglot
company that depends on technology to manage reservations, memberships, logistics, • Multi-Cloud
vehicle tracking and maintenance. With one million customers across 10 countries,
• Runs apps at scale
Zipcar designed a bespoke solution to meet its specific needs, moving away from legacy
• Interoperability
architecture to a continuous delivery model built on cloud native technologies.
• Simplifies the developer lifecycle
The team credits Cloud Foundry Application Runtime, Cloud Foundry BOSH,
Concourse, Diego, Garden, and a customized cloud controller with having helped them
standardize across its data centers. NOTABLE CUSTOMERS

• American Airlines
Zipcar is currently running:
• The Home Depot
• 6,000 containers
• United States Air Force
• 12 BOSH directors
• Verizon Wireless
• 80+ services
• 25+ production environments
• Multiple clouds

WEBSITE cloudfoundry.org TWITTER @cloudfoundry BLOG cloudfoundry.org/blog

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 3 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

QUICK VIEW

01. The most important

elements of microservices are
business processes, scalability,

Executive Insights
agility, APIs, decoupling, and
management/culture.

02. Microservices have made

application development faster, it

on Microservices
has given developers and engineers
more autonomy, and it has
increased the agility and scalability
of applications.

03. There is rapid to moderate

adoption of microservices driven
by the adoption of mesh network
BY TOM SMITH
management (ISTIO).
RESEARCH ANALYST AT DEVADA

To understand the current and future state of microservices, we • Matthew Baier, COO, Contentstack
spoke to 25 IT executives from 21 organizations. Consistent with • Anders Wallgren, CTO, Electric Cloud
the early adoption of the technology, the answers to our questions
• Priyanka Sharma, Director of Alliances, GitLab
were diverse.
• Andrew Newdigate, Infrastructure Architect, GitLab
DZO N E .CO M/G U I D E S

Here’s who we spoke to: • Ben Sigelman, CEO, LightStep

• Jim Scott, Director, Enterprise Strategy & Architecture, MapR

• Heikki Nousiainen, CTO, Aiven.io
• Ariff Kassam, Vice President, Products, NuoDB
• Chase Aucoin, Technical Evangelist, AppDynamics
• Jim Walker, VP of Product Marketing, OverOps
• Assaf Mizrachi, Head of Software, Augury
• Bich Le, Chief Architect, Platform9
• Amit Ziv-Kenet, Backend Developer, Augury
• Mike LaFleur, Global Head of Solution Architecture, Provenir
• Bernd Ruecker, Co-founder and Developer Advocate, Camunda
• Christian Posta, Chief Architect, Cloud Application
• Jaime Ryan, Senior Director, Product Management and Strategy, Development, Red Hat
CA Technologies
• Setu Kulkarni, V.P. Strategy and Business Development,
• Brian Dawson, DevOps Evangelist, CloudBees Whitehat Security

• Viktor Farcic, Senior Consultant, CloudBees • Asanka Abeysinghe, V.P. of Architecture – CTO Office, WSO2

• Chip Childers, CTO, Cloud Foundry • Karun Indrasiri, Director, Integration architecture, WSO2

• Gwen Shapira, Chief Data Architect, Confluent • Roman Shaposhnik, Co-founder, Zededa

1. You can see how early it is in the adoption of microservices problems you’re trying to solve by decomposing the monolithic
as the “most important elements” are all over the place with processes. It doesn’t matter that a single microservice is
business processes, scalability, agility, APIs, decoupling, and elegantly architected If the big-picture business processes aren’t
management/culture all mentioned a couple of times. executed successfully, since these are what make the customers
happy and make the company money.
Think about breaking down a business plan or process.
Understand and define different business domains in an isolated Solve the real problem around engineering and scaling.
manner. Understand the original monolithic process and what Enforce an architecture that will help the organization scale

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 4 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

quickly while being agile. Microservices allow you to pull off A team bigger than ten people is not efficient and hinders
the inverse of Conway’s law. They should be independently autonomy. It has given architects more independence
developed, deployed, and scaled, allowing for faster delivery and choice in selecting the technologies used by a specific
of functionality with little impact to other systems. Improve the microservice. They can select technologies that are the “best
ability to make changes and get them to the customer quickly. fit” for their specific microservice.
Think through the responsibility for each microservice and how
they will interact with one another for greater agility and scale. Microservices are beneficial to the agility and vitality of an
organization. There is greater agility and alignment along a
Isolation and API guarantees are key elements. Isolation common, product-focused vision. Microservices force you to
enables developers to iterate quickly and independently. API adopt an Agile methodology to be flexible and responsive
compatibility is key so other microservices are not impacted or because there are so many moving pieces. Testing is easier.
dependencies are created that slow down iterations. You need Teams can be moved around, the learning curve is smaller,
well-defined APIs that can be easily discovered, understood, onboarding is quicker, small teams communicate more
and executed by service clients. efficiently, and smaller code bases are easier to maintain.

Ensure microservices are adequately decoupled but avoid 3. Respondents are seeing rapid to moderate adoption of
premature decomposition. Start small and evolve. Design microservices and it seems to be driven by the adoption
applications to small teams can have full control of a service of mesh network management tools, such as Istio. Tools,
or an app that’s fully independent of everything else. If you systems, and platforms are making it easier, reducing the
are breaking down a monolithic application, take an iterative downside, and making applications more consumable. The
approach, decompose incrementally. Break out, run, and transition to microservices-oriented networking has shifted
operate with a line of decomposition before you move on. thinking about sockets to microservices. The service mesh
DZO N E .CO M/G U I D E S

Ensure autonomy for a service. Deploy independently at the takes out the shared responsibility by putting everything
finest level of granularity. in a container enabling everyone to use the same sidecar.
Serverless computing also allows applications to be even
Microservices are a management issue moving from hundreds
smaller. The concept of a service mesh sprang from nothing last
of developers working on an application to no more than 10 to
year and is continuing to generate a lot of interest and some
12 people per team. The culture of the organization is critical
adoption. However, these technologies are still in their infancy
as this is where we see the manifestation of communication
and adopters are discovering the hidden pitfalls. Patience is
problems. Without meeting the communication challenge,
required as the industry sorts itself out.
organizations don’t get the outcomes they want. Monitoring
is a huge component of microservices with heavily decoupled 4. The majority of real world use cases provided by our
distribution, service visibility becomes an issue quickly. respondents were in financial services though several people
pointed out the benefits of microservices are irrespective of
2. Microservices have made application development faster, it
domain. Everything being done in financial services can be
has given developers and engineers more autonomy, and it has
used by a number of different verticals. The biggest and most
increased the agility and scalability of applications.
relevant use case is fraud detection built out machine learning
models and putting in line with microservices. A real challenge
Microservices enable everything to move faster – development,
is agility around making an easy change to a process – like the
onboarding, feature release, adoption, uptake, feedback, and
credit worthiness of a customer. Data scientists are able to
improvement. Things happen faster once you’ve broken things
make a change to a model quickly versus changing the entire
down. You get speed with quality because there’s a smaller
software development lifecycle. Large financial institutions
surface to test.
are able to deliver new functionality using microservices while
It changes how organizations work and meet business maintaining and continuing to leverage legacy applications
requirements. Application developers get a lot of freedom. through API-based integrations. They’re able to provide new,
They get an API and can look at end user, use, and release all-digital products and services because they are better able to
in a rapid way without dealing with backend complexity. respond to customer needs without needs to rip and replace.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 35 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

5. The most common issues affecting the creation and microservices are an important step on the learning journey
management of microservices are data, complexity, that will lead us closer to serverless. The promise for the
monitoring, skills, and security. A key challenge is managing software developer of getting rid of operational detail is
data and data sets with stateful and stateless data. You need to great, while the promise of huge cost savings by only
understand how to create data compositions. You need to think paying for the exact amount of compute power used is even
about monitoring and observability with autonomous services more appealing. FaaS is a few years behind microservices.
disbursed across an entire network. Infrastructure will be less of barrier to entry. Serverless and
FaaS will enable developers to go smaller. Microservices
Most traditional organizations have to move legacy apps.
are going to become even more micro with serverless.
That’s a multi-year journey. You cannot stop supporting the
Serverless and FaaS are different but are the next generation
monolith. Simplicity is the most fundamental thing to keep
of application development. There’s a lot of value in going to a
in mind. Have clarity of the domain problem you are trying
serverless model.
to solve. Create clean and simple APIs and logic that’s easy
to wrap your head around to create more complex apps and There will be improvements in the development of Kubernetes
behaviors. Microservices bring a lot of overhead. Microservices and tools provided by AWS and GCS to help go from
are more difficult to debug and troubleshoot. development to deployment and production more quickly
and easily. Simplifying as much as possible so developers,
There’s a pretty big skills gap when it comes to building,
operations, and DevOps can run the applications they want
delivering and managing microservices. Few developers
in a way that scales automatically, and everything is at their
have the skills necessary to understand the domain, code the
fingertips to troubleshoot any problems without worrying
services from data to API, understand the overall architecture,
about the underlying infrastructure and orchestration.
integrate with a CI/CD pipeline, and deliver a running service.
DZO N E .CO M/G U I D E S

Most do not understand the gravity of building services as fine

8. When working on microservices, developers need to keep
grain and collectively using a single application.
a lot in mind. Those items mentioned more than once are
APIs, security, reducing complexity, and remembering SDLC
6. The biggest concerns with the current state of microservices
principles. Every developer needs to have API development
are observability and maturity. It’s really important to have
and management skills in their toolbox. Make service calls as
visibility into business processes. How to know something is
autonomous as possible. Use APIs to minimize duplication of
going wrong when it’s going wrong is key. The ability to do
functionality across the organization. Concentrate on clean
distributed training through the whole system is necessary.
interfaces between modules.
Without monitoring, you’re not able to see where the problem
is. Istio helps with communication in a highly distributed
Focus on secure design patterns. End point security is crucial.
network. Enhanced automation and operational visibility help
Remove as much operational and design complexity as
shine light onto the increased complexity.
possible. Look for trends that hide complexity from developers
and make them as productive as they can be without
Microservices in production is more complex than we initially
worrying about infrastructure. Dive into core SDLC principles.
thought. We are confronting a lack of maturity in tools to
Understand the end-to-end lifecycle of a microservice to make
monitor and troubleshoot. This delays the ability to move to
production. Organizations adopting microservices need to yourself more valuable to employers and more marketable in

know what they are trying to accomplish rather than a desire the industry.

to be on the cutting edge. We need independent business

logic but not technology choices. A lack of standards is
TOM SMITH is a Research Analyst at DZone who
resulting in confusion but as more organizations adopt, best
excels at gathering insights from analytics—both
practices and standards will fall into place.
quantitative and qualitative—to drive business
results. His passion is sharing information of value
7. The future of microservices is FaaS and serverless with to help people succeed. In his spare time, you can find him
improved tooling. Serverless is gaining traction too, and either eating at Chipotle or working out at the gym.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 6 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

zones
Microservices dzone.com/microservices

diving
The Microservices Zone will take you through breaking down the monolith
step-by-step and designing microservices architecture from scratch.
It covers everything from scalability to patterns and anti-patterns. It
digs deeper than just containers to give you practical applications and
business use cases.

deeper
Integration dzone.com/integration
The Integration Zone focuses on communication architectures,
message brokers, enterprise applications, ESBs, integration protocols,
web services, service-oriented architecture (SOA), message-oriented
middleware (MOM), and API management.

Cloud dzone.com/cloud
I NTO M IC R OS ERV I C ES The Cloud Zone covers the host of providers and utilities that make cloud
computing possible and push the limits (and savings) with which we can
deploy, store, and host applications in a flexible, elastic manner. The
Cloud Zone focuses on PaaS, infrastructures, security, scalability, and
hosting servers.

twitter refcardz
DZO N E .CO M/G U I D E S

Getting Started With Spring Boot and Microservices

@jessfraz @jldeen
This Refcard will show you how to incorporate Spring Boot and
Hazelcast IMDG into a microservices platform, how to enhance the
@rhein_wein @christianposta benefits of the microservices landscape, and how to alleviate the
drawbacks of utilizing this method.

@b0rk @michelebusta
Patterns of Modular Architecture
Covers 18 modularity patterns to help developers incorporate modular
@crichardson @martinfowler design thinking into development initiatives.

Getting Started With Microservices

@simona_cotin @ThoHeller
In this updated Refcard, you will learn why microservices are becoming
the cornerstone of modern architecture, how to begin refactoring your
monolithic application, and common patterns to help you get started.

videos books
What Are Microservices? Building Microservices: Designing Fine-Grained Systems
Learn what microservices are, why people are moving to Get examples and practical advice to help you build, manage, and evolve
microservices, and how you can create effective microservices. your microservice architectures.

Mastering Chaos – A Netflix Guide to Microservices Spring Microservices in Action

Get insight into how Netflix does microservices, what the anatomy Learn how to build microservice-based applications using Java and the
of a microservice is, what cultural methods can help achieve Spring platform.
microservice mastery, and more.
The Tao of Microservices
Introduction to Microservices, Docker, and Kubernetes
Get yourself on the path to microservices with a conceptual view of
Learn about using microservices with two of the most popular
microservice design, core concepts, and microservices applications.
container platforms out there.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 37 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Solving the Microservices Murder Mystery

When you run microservices, every outage can feel like you’re solving a murder mystery. It’s hard to
DZO N E .CO M/G U I D E S

sift through performance data and find the true culprit.

LightStep [x]PM helps you pinpoint the root cause and gain control over microservices complexity.
It has tracing that scales and is a unique approach to application performance management.

[x]PM analyzes 100% of the performance data, 100% of the time, with no upfront sampling, so
you never miss an outlier.

IN PRODUCTION AT

Try the [x]PM guided demo

https://go.lightstep.com/Try-xPM.html

www lightstep.com LightStepHQ LightStep LightStepHQ

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 3 8 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

performance against past performance along any application

dimensions, so it’s immediately clear whether the behavior being
LightStep [x]PM: APM observed is normal or not. Finally, [x]PM follows entire transactions
from clients making requests down to low-level services and back,

for Microservices and revealing how every service interacted and responded. [x]PM
automatically computes a transaction’s critical path, so users can

Serverless quickly navigate to bottlenecks in the system.

[x]PM was built for the enterprise:

• Integrations with CNCF technologies including OpenTracing,

LightStep® [x]PM™ provides APM for today’s complex systems includ-
Envoy, gRPC, Istio, Linkerd, and Kubernetes
ing microservices and serverless functions. [x]PM helps organiza-
• Workflow integrations with Grafana, Slack, PagerDuty, and
tions running microservice architectures maintain control over their
Sumo Logic
systems, so they can reduce MTTR during firefighting situations and
make proactive application performance improvements. • RBAC, SSO with SAML, and OAuth support

• Secure TLS communication and robust APIs

[x]PM’s unique design allows it to analyze 100% of unsampled
transaction data from highly-distributed, large-scale production [x]PM is used in production by engineering leaders at Twilio, Lyft,
software to produce meaningful distributed traces and metrics that Medium, DigitalOcean, GitHub and many others to help them gain
explain performance behaviors and accelerate root cause analysis. control over their complex systems.
In addition, [x]PM’s intuitive user experience makes it easy to
discover, categorize, and explain distinct latency behaviors occurring W RITTEN BY DEN N IS CHU
DZO N E .CO M/G U I D E S

throughout an application. Users can even visually compare current D IR ECTOR OF P R OD U CT M A R K ET IN G , LIG H TST EP

PARTNER SPOTLIGHT

LightStep [x]PM
LightStep [x]PM: Taming Complexity with Distributed Tracing that Scales

PRODUCT OPEN SOURCE? NEWEST RELEASE

Application Performance Management for companies adopting microservices No Monthly

and serverless

PRODUCT OVERVIEW STRENGTHS

Twilio Improves Mean Time to Resolution (MTTR) by 92% with LightStep [x]PM. • Provides end-to-end distributed tracing that scales
Twilio wanted to go beyond traditional monitoring approaches and deliver a
• No upfront sampling so teams never miss a transac-
flawless experience to their 1.6M developers registered on the Twilio platform,
tion that matters
as well as provide additional service and insights for premium clients. Twilio
• Segments with unlimited cardinality
uses [x]PM to help them solve production-level issues, meet their operational
excellence goals, and deliver a higher level of operational maturity to their • Streamlines root cause analysis by revealing service
customers. Results include: dependencies

• Visualizes system performance and provides insight

• Improved MTTR by 92% for production issues
into what’s normal (and not)
• Reduced latency by 70%

• Saved Insight Engineering team 20 hours per week NOTABLE CUSTOMERS

• Launched segmented and detailed performance monitoring for each top • Lyft • GitHub • Segment
Twilio customer, including customer-specific root cause analysis • Twilio • DigitalOcean

WEBSITE lightstep.com TWITTER @LightStepHQ BLOG lightstep.com/blog

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 39 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Solutions Directory
This directory contains platforms, middleware, service meshes, service discovery, and distributed tracing tools
to build and manage applications built with microservices. It provides free trial data and product category
information gathered from vendor websites and project pages. Solutions are selected for inclusion based on
several impartial criteria, including solution maturity, technical innovativeness, relevance, and data availability.

COMPANY PRODUCT PRODUCT TYPE FREE TRIAL WEBSITE

Cloud database & management

Aiven Aiven 30 day free trial aiven.io
services

Amazon Web Services Amazon EC2 IaaS Free tier available aws.amazon.com/ec2
DZO N E .CO M/G U I D E S

Amazon Web Services Amazon API Gateway API gateway Free tier available aws.amazon.com/api-gateway

Simple Query Service

Amazon Web Services ESB Free tier available aws.amazon.com/sqs
(SQS)

AWS Application aws.amazon.com/application-

Amazon Web Services Service discovery Free tier available
Discovery Service discovery

Amazon Web Services Amazon ECS Container orchestration Free tier available aws.amazon.com/ecs

Apache Foundation Kafka Distributed streaming platform Open source kafka.apache.org

Apache Foundation Zookeeper Service discovery Open source zookeeper.apache.org

Apache Foundation HTrace Distributed tracing Open source htrace.incubator.apache.org

Apache Foundation ActiveMQ Message queue Open source activemq.apache.org

Apcera NATS Message-oriented middleware Open source nats.io

apigee.com/api-
Apigee Apigee API gateway, API management Free tier available
management/#/products

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 0 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

COMPANY PRODUCT PRODUCT TYPE FREE TRIAL WEBSITE

Containerized apps management Available by

Aspen Mesh Aspen Mesh aspenmesh.io
system request

API management, API gateway, Available by axway.com/en/products/

Axway Axway AMPLIFY
API builder request amplify

Buoyant Linkerd Service mesh Open source linkerd.io

Available by ca.com/us/products/api-
CA CA API Management API management, API gateway
request management.html

Canonical LXD Container management Open source linuxcontainers.org/lxd

Cisco AppDynamics Performance & monitoring tool 15 days appdynamics.com

Available by
Cloudentity Cloudentity Identity & API security cloudentity.com
request

github.com/cloudfoundry/
Cloud Foundry Diego Container runtime system Open source
diego-release
DZO N E .CO M/G U I D E S

Container deployment & cloudfoundry.org/container-

Cloud Foundry CF Container Runtime Open source
management runtime

Cloud Native Computing

Envoy Edge & service proxy Open source envoyproxy.io
Foundation

Cloud Native Computing

OpenTracing Distributed tracing APIs Open source opentracing.io
Foundation

Cloud Native Computing

containerd Container runtime system Open source containerd.io
Foundation

Docker Docker Container platform Free tier available docker.com/get-docker

Container orchestration &

Docker Docker Swarm Open source github.com/docker/swarm
clustering

Web services development

Dropwizard Dropwizard Open source dropwizard.io
framework

Dynatrace Dynatrace Performance & monitoring tool 15 days dynatrace.com

Reactive application
Eclipse Foundation Vert.x Open source vertx.io
development platform

elastic.co/products/
Elastic Elasticsearch Search & analytics Open source
elasticsearch

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 41 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

COMPANY PRODUCT PRODUCT TYPE FREE TRIAL WEBSITE

Elastic stack configuration &

Elastic Kibana Open source elastic.co/products/kibana
management

Fluentd Fluentd Unified logging layer Open source fluentd.org

cloud.google.com/kubernetes-
Google Kubernetes Engine Container orchestration $300 credit
engine

gRPC gRPC Protocol buffers, RPC system Open source grpc.io

Service discovery, configuration,

HashiCorp Consul Open source consul.io
& monitoring

IBM IBM API Connect API management Free tier available ibm.com/cloud/api-connect

Instana Infrastructure instana.com/infrastructure-

Instana Infrastructure monitoring 14 days
Quality Management management

Istio Istio Service mesh Open source istio.io

DZO N E .CO M/G U I D E S

github.com/jaegertracing/
Jaeger Jaeger Distributed tracing Open source
jaeger

Spring Boot & Angular

JHipster Jhipster application + microservices Open source jhipster.tech
development platform

API gateway & microservices Demo available by

Kong Kong konghq.com
management request

Kubernetes Kubernetes Container orchestration Open source kubernetes.io

Lightbend Akka Services communication Open source lightbend.com/akka

Microservices development lightbend.com/lagom-

Lightbend Lagom Open source
platform framework

Lightbend OpsClarity Reactive systems monitoring N/A opsclarity.com

Demo available by
LightStep LightStep Microservices management lightstep.com
request

Linux Foundation The Linux Foundation Open-source project hosting Open source linuxfoundation.org

Microservices development
Macaw Software Macaw Free tier available macaw.io
platform

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 2 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

COMPANY PRODUCT PRODUCT TYPE FREE TRIAL WEBSITE

mesosphere.github.io/
Mesosphere Marathon Container orchestration Open source
marathon

microfocus.com/products/
Micro Focus Artix ESB 30 days
corba/artix#

Micrometer Micrometer JVM application monitoring Open source micrometer.io

Java optimization project for

MicroProfile MicroProfile Open source microprofile.io
microservices development

Azure API azure.microsoft.com/en-us/

Microsoft API gateway, API management Free tier available
Management services/api-management

Azure Container azure.microsoft.com/en-us/

Microsoft Container orchestration Free tier available
Service services/container-service

azure.microsoft.com/en-us/
Microsoft Azure Service Bus ESB Free tier available
services/service-bus
DZO N E .CO M/G U I D E S

Microservices development azure.microsoft.com/en-us/

Microsoft Azure Service Fabric Free tier available
platform services/service-fabric

Available by
Mulesoft Anypoint Platform Integration platform mulesoft.com
request

Netflix Archaius Configuration managmeent Open source github.com/Netflix/archaius

Netflix Eureka Service discovery Open source github.com/Netflix/eureka

Netflix Hystrix Latency & fault tolerance library Open source github.com/Netflix/Hystrix

Netflix Ribbon Load balancing library Open source github.com/Netflix/ribbon

Dynamic routing & service

Netflix Zuul Open source github.com/Netflix/zuul
monitoring

Neuron ESB Neuron ESB ESB 30 days neuronesb.com/

NGINX Application Microservices development &

NGINX 30 days nginx.com/products/
Platform management

github.com/nginmesh/
NGINX nginmesh Service mesh Open source
nginmesh

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 3 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

COMPANY PRODUCT PRODUCT TYPE FREE TRIAL WEBSITE

Available by
Nutanix Xi Epoch Monitoring multi-cloud apps nutanix.com/products/epoch
request

OCI Grails Web application framework Open source grails.org

OpenESB OpenESB ESB Open source open-esb.net

OpenLegacy OpenLegacy API management N/A openlegacy.com

oracle.com/technetwork/java/
Oracle Java EE Java specifications Free solution
javaee/overview/index.html

oracle.com/technetwork/
Oracle Oracle Service Bus ESB Free solution middleware/service-bus/
overview

oracle.com/middleware/
SOA governance, integration
Oracle Oracle SOA Suite 30 days application-integration/
PaaS
products/soa-suite.html
DZO N E .CO M/G U I D E S

OW2 Middleware
Petals ESB ESB Open source petals.linagora.com
Consortium

Particular Software NServiceBus ESB Free tier available particular.net/nservicebus

network.pivotal.io/products/
Pivotal Software, Inc. RabbitMQ Message queue Open source
pivotal-rabbitmq

spring.io/projects/spring-
Pivotal Software, Inc. Spring Cloud Sleuth Distributed tracing Open source
cloud-sleuth

Spring application development

Pivotal Software, Inc. Spring Boot Open source projects.spring.io/spring-boot
platform

Prometheus Prometheus Systems monitoring & alerting Open source prometheus.io

Red Hat CoreOS Fleet Container orchestration Open source github.com/coreos/fleet

Red Hat CoreOS Flannel Container-defined networking Open source github.com/coreos/flannel

Red Hat CoreOS etcd Service discovery Open source github.com/etcd-io/etcd

redhat.com/en/technologies/
Red Hat JBoss Fuse ESB Open source
jboss-middleware/fuse

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 4 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

COMPANY PRODUCT PRODUCT TYPE FREE TRIAL WEBSITE

redhat.com/en/resources/
Red Hat Enterprise
Red Hat Container management Open source enterprise-linux-atomic-host-
Linux Atomic Host
datasheet

Red Hat Thorntail Java EE services development Open source thorntail.io

roguewave.com/products/
Akana API Demo available by
Rogue Wave Software API management akana/solutions/api-
Management request
management

SignalFX SignalFX Monitoring, alerts, & analytics 14 days signalfx.com/products

SimianViz SimianViz Microservices simulation Open source github.com/adrianco/spigo

Behavioral activity monitor w/

Sysdig Sysdig Falco Open source sysdig.com/falco
container support

mashery.com/api-
TIBCO Software Inc. Mashery API management 30 days
management/saas
DZO N E .CO M/G U I D E S

Twistlock Twistlock Container security 30 days twistlock.com

Twitter Finagle RPC system Open source twitter.github.io/finagle

github.com/TykTechnologies/
Tyk.io Tyk API management Open source
tyk

Container-optimized operating
VMWare Photon Open source vmware.github.io/photon
system

WSO2 WSO2 API management Open source wso2.com/api-management

X-Trace X-Trace Distributed tracing Open source github.com/rfonseca/X-Trace

Zapier Zapier API management Free tier available zapier.com

Zipkin Zipkin Distributed tracing Open source zipkin.io

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 5 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

DISTRIBUTED TRACING: A category of MESSAGE BROKER: Middleware that

tools & practices that allow developers translates a message sent by one piece
to analyze the behavior of a service of software to be read by another piece
G LOSSARY & troubleshoot problems by creating of software.
services that record information about
requests & operations that are performed. MICROPROCESSOR: An integrated
circuit that contains all the functions of a
ANGULAR: A platform for building HTML DOCKER: A computer program that central processing unit of a computer.
& JavaScript web applications, led by performs operating-system-level
Google & based on TypeScript; a rewrite virtualization & specializes in running MICROSERVICES ARCHITECTURE: A
of the AngularJS JavaScript framework. software packages within standalone development method of designing your
containers. applications as modular services that
APACHE KAFKA: An open-source
distributed stream processing platform seamlessly adapt to a highly scalable &
DOMAIN-DRIVEN DESIGN: A
based on an abstraction of a distribtued dynamic environment.
philosophy for developing software in
commit log.
which development is focused primarily
MONOLITHIC: An architecture that is
APPLICATION PROGRAMMING on the business logic (the activities &
reliant on a large, single code base that
INTERFACE (API): A software interface issues that an application is supposed to
lends to a unified application.
that allows users to configure &interact perform or solve).
w/other programs, usually by calling from
ENTERPRISE SERVICE BUS (ESB): ORCHESTRATION: The method to
a list of functions.
A utility that combines a messaging automate the management & deployment
system w/middleware to provide of your applications & containers.
CONTAINER: Resource isolation at
the OS (rather than machine) level, comprehensive communication services
for software applications. SERVERLESS: A platform providing
usually (in UNIX-based systems) in
user space. Isolated elements vary by computing, networking, & storage without
EVENTUAL CONSISTENCY: A data the need of managing (virtual) machines.
containerization strategy &often include
consistency model used to make
file system, disk quota, CPU &memory,
distributed applications highly available SERVICE DISCOVERY: The act of
I/O rate, root privileges, &network access.
Much lighter-weight than machine- by keeping data in sync & up-to-date finding the network location of a service
level virtualization & sufficient for many across all services or nodes. instance for further use.
isolation requirement sets.
FUNCTION-AS-A-SERVICE: A relatively
SERVICE MESH: An infrastructure
CONTINUOUS DELIVERY: A software new concept to describe a category of
layer focused on service-to-service
engineering approach in which continuous cloud computing services that deliver a
communication, primarily used for
integration, automated testing, & platform allowing users to develop, run, &
distributed systems & cloud-native
automated deployment capabilities allow manage application functionalities.
applications.
software to be developed & deployed
rapidly, reliably, & repeatedly w/minimal HOLACRACY: A management practice
SOCIOCRACY: A mode of governance
human intervention. for organizations that are separated
without a centralized power structure,
into autonomous & independent
aiming for less independence
DEPENDENCY INJECTION: This can departments based on roles, which can
between teams to focus on organization-
position a class to be independent of its organize themselves &make decisions
wide strategy.
dependencies, as one object supplies the based on their duties. Holacracies are
dependencies of another object. focused on rapidly iterating.
WEB SERVICE: A function that can be

DISTRIBUTED SYSTEM: Any system or JAVA VIRTUAL MACHINE (JVM): accessed over the web in a standardized
application that operates across a wide Abstracted software that allows a way using APIs that are accessed via
network of services or nodes. computer to run a Java program. HTTP & executed on a remote system.

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 4 6 O F 47

 THE DZONE GUIDE TO MICROSERVICES: SPEED, AGILITY, AND FLEXIBILITY

Start Contributing to OSS Communities and Discover

Practical Use Cases for Open-Source Software
COMMITTERS & MAINTAINERS

Whether you are transitioning from a closed to an open

community or building an OSS project from the ground
COMMUNITY GUIDELINES
up, this Zone will help you solve real-world problems with
open-source software.

LICENSES & GOVERNANCE

Learn how to make your first OSS contribution, discover
best practices for maintaining and securing your
community, and explore the nitty-gritty licensing and
legal aspects of OSS projects. TECHNICAL DEBT

BROUGHT TO YOU IN PARTNERSHIP WITH

T HE DZO NE GUIDE TO MICROSERVI CES: SPEED, AGI LI TY, AND F L E X I BI L I T Y PAG E 47 O F 47