Moving towards
Microservices?
Dont forget DevOps.
Red Hat Developers helps you assess the tools available to
solve the problem at hand, guides you through the process
to get the job done and lets you use new technology trends
so you can do your job better and faster.
Join now at
developers.redhat.com
BROUGHT TO YOU BY:
Getting Started with
What Are Microservices?
C O NT E NT S
Get More Refcardz! Visit DZone.com/refcardz
215
Key Characteristics of
Microservices
Microservices
Benefits of Microservices
Operational Requirements for
Microservices
Good Design Principles for
Existing Monoliths... and more!
By Arun Gupta
3. Explicitly Published Interface: A producer service
publishes an interface that is used by a consumer service.
I N T RO D U C T I O N
The term microservices describes a new software development
4. Independent DURS (Deploy, Update, Replace, Scale):
pattern that has grown from recent trends in software
Each service can be independently deployed, updated,
development/management practices meant to increase the
replaced, and scaled.
speed and efficiency of developing and managing software
5. Lightweight communication: REST over HTTP, STOMP
solutions. Agile methods, DevOps culture, PaaS, application
over WebSocket, and other similar lightweight protocols
containers, and the widespread adoption (both culturally and
are used for communication between services.
technically) of CI/CD methods across the marketplace are
making it possible to consider building truly modular large-
B E N E F I TS O F M I C RO S E RV I C E S
scale service systems for both internal and commercial use.
1. Independent scaling: Each microservice can scale
W H AT A R E M I C RO S E RV I C E S?
independently via X-axis scaling (cloning with more
CPU or memory) and Z-axis scaling (sharding), based
Microservices involve an architectural approach that emphasizes
upon their needs. This is very different from monolithic
the decomposition of applications into single-purpose, loosely
applications, which may have very different requirements
coupled services managed by cross-functional teams, for delivering
that must be deployed together.
and maintaining complex software systems with the velocity and
2. Independent upgrades: Each service can be deployed
quality required by todays digital business.
independent of other services. Any change local to a
Microservices are language-, platform-, and operating system-
service can be easily made by a developer without requiring
agnostic. They break down a big monolithic application,
coordination with other teams. For example, performance
typically packaged as a single archive, into smaller and simpler
of a service can be improved by changing the underlying
G E T T I N G S TA R T E D W I T H M I C R O S E R V I C E S
applications. Each application does one thing, and does it
implementation. As a result this maintains the agility of
well, so the micro in microservices refers to the scope of the
the microservice. This is also a great enabler of CI/CD.
services functionalities, as opposed to the number of Lines of
3. Easy maintenance: Code in a microservice is restricted
Code (LOC).
to one function and is thus easier to understand. IDEs
Each application is built by a full-stack team, which reduces
can load the smaller amounts of code more easily, and
potential communication mismatch between different teams
increased readability can keep developers more productive.
that could exist otherwise. Microservices may not be suitable
4. Potential heterogeneity and polyglotism: Developers are
for simpler applications and are better suited for complex
free to pick the language and stack that are best suited
applications that have grown over a period of time.
The availability of an application on a mobile device; the
frequency with which an application needs to be updated; and
the responsiveness of an applications design are a few key
Share more.
Learn more.
Code more.
factors driving this style of architecture.
The concept behind microservices is similar to Service-oriented
Architecture (SOA), which is why this style of architecture has
been referred to as SOA with DevOps, SOA for hipsters,
and SOA 2.0.
Red Hat Developers gives you access
to products, experts, and new ideas.
KEY CHAR ACTERISTICS OF M ICROSERVICES
1. Domain-Driven Design: Functional decomposition can be
Get involved at developers.redhat.com
easily achieved using Eric Evanss DDD approach.
2. Single Responsibility Principle: Each service is responsible
for a single part of the functionality, and does it well.
D Z O NE, INC.
DZ O NE .C O M
MICROSERVICES
for their service. This enables one to rewrite the service
deal with failure. Its important for services to automatically
using better languages and technologies as opposed to being
take corrective action to ensure user experience is not
penalized because of past decisions, and gives freedom of
impacted. The Circuit Breaker pattern allows one to build
choice when picking a technology, tool, or framework.
resiliency in softwareNetflixs Hystrix and Ribbon are good
libraries that implement this pattern.
5. Fault and resource isolation: A misbehaving service, such
5. DevOps: Continuous Integration and Continuous
as a memory leak or an unclosed database connection, will
only affect that service, as opposed to an entire monolithic
Deployment (CI/CD) are very important in order for
application. This improves fault isolation and limits how
microservices-based applications to succeed. These practices
much of an application a failure can affect.
are required so that errors are identified early, and so little to
no coordination is required between different teams building
6. Improved communication across teams: A microservice is
different microservices.
typically built by a full-stack team. All members related to a
domain work together in a single team, which significantly
GOOD DESIGN PRINCIPLES FOR
E X ISTING MONOLITHS
improves communication between team members, as they
share the same end goal.
Refactoring a monolith into a microservices-based application will
O P E R AT I O N A L R E Q U I R E M E N TS F O R
M I C RO S E RV I C E S
not help solve all architectural issues. Before you start breaking up
a monolith, its important to make sure the monolith is designed
Microservices are not the silver bullet that will solve all
following good software architecture principles. Some common
architectural problems in your applications. Implementing
rules are:
microservices may help, but that is often just the byproduct of
1. Practice separation of concerns, possibly using Model-View-
refactoring your application and typically rewriting code using
Controller (MVC)
guidelines required by this architecture style. True success requires
2. Use well-defined APIs for high cohesion and low coupling
significant investment.
3. Dont Repeat Yourself (DRY)
1. Service Replication: Each service needs to replicate, typically
using X-axis cloning or Y-axis partitioning. There should be a
4. Use Convention over Configuration (CoC)
standard mechanism by which services can easily scale based
5. Separate interfaces/APIs and implementations, and follow
upon metadata. A PaaS, such as OpenShift by Red Hat, can
the Law of Demeter. Classes shouldnt call other classes
simplify this functionality.
directly just because they happen to be in the same archive
2. Service Discovery: In a microservice world, multiple services
6. Use Domain-Driven Design to keep objects related to a
are typically distributed in a PaaS environment. Immutable
domain/component together
infrastructure is provided by containers or immutable VM
7. Dont build something that you dont need now (YAGNIYou
images. Services may scale up and down based upon certain
Arent Going to Need It)
pre-defined metrics. The exact address of a service may not
be known until the service is deployed and ready to be used.
R E FAC T O R I N G A M O N O L I T H T O
M I C RO S E RV I C E S
The dynamic nature of a services endpoint address is
handled by service registration and discovery. Each service
registers with a broker and provides more details about itself
Consider a Java EE monolithic application that is typically
(including the endpoint address). Other consumer services
defined as a WAR or an EAR archive. The entire functionality
then query the broker to find out the location of a service
for the application is packaged in a single unit. For example, an
and invoke it. There are several ways to register and query
online shopping cart may consist of User, Catalog, and Order
services such as ZooKeeper, etcd, consul, Kubernetes, Netflix
functionalities. All web pages are in the root of the application, all
Eureka, and others.
corresponding Java classes are in the WEB-INF/classes directory,
3. Service Monitoring: One of the most important aspects
and all resources are in the WEB-INF/classes/META-INF directory.
of a distributed system is service monitoring and logging.
This enables one to take proactive action if, for example,
a service is consuming unexpected resources. The ELK
Stack can aggregate logs from different microservices,
provide a consistent visualization over them, and make that
data available to business users. Other possible tools for
distributed logging are Syslog, Logentries, and Loggly.
4. Resiliency: Software failure will occur, no matter how much
Figure 1: Monolith Architecture
and how hard you test. This is all the more important when
multiple microservices are distributed all over the Internet.
Such an application can be refactored into microservices, which
The key concern is not how to avoid failure but how to
would create an architecture that would look like the following:
D Z O NE, INC .
DZ O NE.C O M
MICROSERVICES
M I C RO S E RV I C E S D E S I G N PAT T E R N
Multiple microservices can be composed with each other to
provide composite microservices. Some common design patterns
are explained below.
AGGREGATOR
Results from multiple microservices are aggregated into one
composite microservice.
In its simplest form, an Aggregator would be a simple web page
that invokes multiple services to achieve the functionality
required by the application. Since each service (Service A, Service
B, and Service C) is exposed using a lightweight REST mechanism,
the web page can retrieve the data and process/display it
accordingly. If processing is requiredfor example, if you need
Figure 2: Refactoring to Microservices
to apply business logic to the data received from individual
servicesthen you will likely need a bean to transform the data
1. The above application is functionally decomposed where User,
before being displayed by the Aggregator web page.
Order, and Catalog components are packaged as separate WAR
files. Each WAR file has the relevant web pages, classes, and
configuration files required for that component.
2. Java EE is used to implement each component, but there is no
long term commitment to the stack, as different components
talk to each other using a well-defined API.
3. Different classes in this component belong to the same
domain, so the code is easier to write and maintain. The
underlying stack can also change, possibly keeping technical
debt to a minimum.
4. Each archive has its own database (i.e. data stores are not
shared). This allows each microservice to evolve and choose
whatever type of data storerelational, NoSQL, flat file, in-
Figure 3: Aggregator Pattern
memory, or some thing elseis most appropriate.
An Aggregator can also act simply as a higher-level composite
5. Each component registers with a Service Registry. This is
required because multiple stateless instances of each service
microservice which can be consumed by other services. In this
might be running at a given time, and their exact endpoint
case, the Aggregator would collect the data from each individual
locations will be known only at the runtime. Netflix Eureka,
microservice, apply business logic to it, and publish it as a REST
etcd, and Zookeeper are some options for service registry/
endpoint.
discovery.
This design pattern follows the DRY principleif there are
6. If components need to talk to each other, which is quite
multiple services that need to access Service A, B, and C, then
common, then they would do so using a pre-defined API. REST
you should abstract that logic into a composite microservice and
for synchronous or Pub/Sub for asynchronous communication
aggregate that logic into one service. An advantage of abstracting
are the most common means to achieve this. In this case, the
at this level is that the individual services (i.e. Service A, B, and C)
Order component discovers User and Catalog service and talks
can evolve independently, and the needs of the business logic are
to them using a REST API.
still provided by the composite microservice.
7. Client interaction for the application is defined in another
application (in this case, the Shopping Cart UI). This application
PROXY
discovers the services from the Service Registry and composes
The Proxy microservice design pattern is a variation of the
them together. It should mostly be a dumb proxy (discussed
Aggregator. In this case, aggregation does not need to happen
in a later section), where the UI pages of the different
client-side. Rather, a different microservice may be invoked as
components are invoked to display the interface. A common
required by the business logic.
look and feel can be achieved by providing standard CSS/
Just like in the Aggregator pattern, a Proxy can scale independently
JavaScript resources.
on the X-axis and Z-axis. You may want to do this in cases
More details can be found at: http://github.com/arun-gupta/
where each individual service does not need to be exposed to the
microservices.
consumer and should instead go through an interface.
D Z O NE, INC .
DZ O NE.C O M
MICROSERVICES
BRANCH
The Branch microservice design pattern extends the Aggregator
design pattern and allows simultaneous response processing
from two (likely mutually exclusive) chains of microservices. This
pattern can also be used to call different chains, or a single chain,
based upon the business logic needs.
Figure 4: Proxy Pattern
A Proxy can be classified in one of two ways. A dumb proxy just
delegates any request to one of the services. Alternatively, a smart
proxy applies some data transformation before the response is
served to the client. A good example of this would be where the
presentation layer to different devices can be encapsulated in the
smart proxy.
Figure 6: Branch Pattern
CHAINED
Service Aeither a web page or a composite microservice
The Chained microservice design pattern produces a single
may invoke two different chains concurrently, resembling the
Aggregator design pattern. Alternatively, Service A may invoke
consolidated response to a request. In this case, the request from
the client is received by Service A, which then communicates
with Service B, which in turn may communicate with Service C.
only one chain, based on the request received from the client.
All of these services are likely using a synchronous HTTP request/
SHARED RESOURCES
response messaging.
One of the design principles behind microservices is autonomy.
This means the service is full-stack and has control of all the
componentsUI, middleware, persistence, transactions. This
allows the service to be polyglot, so the right tool can be used for
the right job. For example, if your application uses some data that
fits naturally in a graph store, while other data fits naturally in a
relational database, you can use the appropriate storage model
for each domain, rather than jamming everything into a SQL or
NoSQL database.
However, a typical problem (especially when refactoring from
an existing monolithic application) is database normalization:
ensuring that each microservice has the right amount of data
nothing less and nothing more. Even if only a SQL database is
used in a monolithic application, denormalizing the database
would lead to duplication of data, and possibly inconsistency. In
Figure 5: Chained Pattern
a transition phase, some applications may benefit from a shared
One important thing to understand here is that the client is blocked
until the complete chain of request/response (i.e. Service A
Service B and Service B
data microservice design pattern.
Service C), is completed. The request
from Service B to Service C may look completely different from
the request from Service A to Service B. Similarly, response from
Service B to Service A may look completely different from Service
C to Service B. And thats the whole point; different services are
adding their own value.
This means its important to remember not to make the chain too
long because the synchronous nature of the chain will appear like
a long wait at the client sideespecially if its a web page that is
waiting for the response to be shown. There are workarounds to
the blocking caused by this request/response, which are discussed
in a subsequent design pattern.
Note: A chain with a single microservice is called singleton chain.
D Z O NE, INC .
Figure 7: Shared Resources Pattern
DZ O NE.C O M
MICROSERVICES
Some microservices, likely in a chain, may share caching and
and D asynchronously using a shared message queue. Service A
database stores. This only makes sense if there is a strong
Service C communication could also be asynchronous, possibly using
coupling between the two services. Some people might consider
WebSocket, to achieve the desired scalability.
this an anti-pattern, but business logic needs might require it in
A combination of REST request/response and pub/sub messaging
some cases. This would certainly be an anti-pattern for greenfield
may be used to accomplish the business logic need.
applications implementing a microservices design pattern.
CO N C L U S I O N
ASYNC MESSAGING
While the REST design pattern is quite prevalent, and well
Microservices model has well-known advantages and can certainly
understood, it has the limitation of being synchronous, and thus
help your business evolve faster. But monoliths have served us
blocking. Asynchrony can be achieved, but must be done in an
well so far, and will continue to work for years to come. Consider
application-specific way. Because of this, some microservice
the operational requirements of microservices in addition to the
architectures may elect to use message queues instead of REST
benefits before considering refactoring your monolith to a
request/response.
microservices architecture. Many times, better software engineering
and architecture will be enough. But if you decide to follow the
microservice route, then the advice in this Refcard should help to
get you started.
ABOUT THE AUTHOR
Arun Gupta is Director of Developer Advocacy at
Red Hat, focusing on Red Hat JBoss Middleware.
As a founding member of the Java EE team at Sun
Microsystems, he spread the love for technology all
around the world. At Oracle, he led a cross-functional
team to drive the global launch of the Java EE 7
platform, including strategic planning and execution,
content development, and the execution of marketing campaigns and
programs. After authoring ~1,400 blogs at blogs.oracle.com/arungupta
on different Java technologies, he continues to promote Red Hat
technologies and products at blog.arungupta.me.
Figure 8: Async Messaging Pattern
In the preceding design pattern, Service A may call Service C
synchronously, while Service C is communicating with Service B
CREDITS:
Editor: G. Ryan Spain | Designer: Yassee Mohebbi | Production: Chris Smith | Sponsor Relations: Chris Brumfield | Marketing: Chelsea Bosworth
BROWSE OUR COLLECTION OF 250+ FREE RESOURCES, INCLUDING:
RESEARCH GUIDES:
REFCARDZ:
Unbiased insight from leading tech experts
Library of 200+ reference cards covering the latest tech topics
COMMUNITIES: Share links, author articles, and engage with other tech experts
JOIN NOW
DZONE, INC.
150 PRESTON EXECUTIVE DR.
CARY, NC 27513
DZone communities deliver over 6 million pages each month to more than 3.3 million software
developers, architects and decision makers. DZone offers something for everyone, including news,
tutorials, cheat sheets, research guides, feature articles, source code and more.
888.678.0399
919.678.0300
REFCARDZ FEEDBACK WELCOME
[email protected]
"DZone is a developer's dream," says PC Magazine.
Copyright 2015 DZone, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any
DZONE,
DZONE, INC.
INC.
form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.
SPONSORSHIP OPPORTUNITIES
DZONE.COM
DZONE.COM
[email protected]
VERSION 1.0
$7.95
