White Paper

Six Advantages
of Microservices
White Paper
Six Advantages of Microservices | White Paper

Six Advantages of Microservices

The topic of microservices continues to get significant buzz as businesses
build more and more complex solutions. There are many advantages to
microservices, and this paper aggregates them into six buckets to discuss
why a microservices architecture can work well for you.

Introduction
Microservices are simply a set of software applications microservices. Each station/microservice has expertise
designed for limited scope that work with each other in the respective responsibilities, thus promoting
to form a bigger solution. Each microservice, as the efficiency, consistency, and quality in the workflow
name implies, has minimal capabilities for the sake and the outputs. Contrast that to a manufacturing
of creating a highly modularized overall architecture. environment in which each station is responsible for
A microservices architecture is analogous to a building the entire product itself. That is analogous to a
manufacturing assembly line, where each microservice is monolithic software application that performs all tasks
like a station in the assembly line. Just as each station is within the same process.
responsible for one specific task, the same holds true for

Inputs Task 1 Task 2 Task 3

Inputs Tasks 1 - 9 Outputs Task 6 Task 5 Task 4

Monolithic Application Task 7 Task 8 Task 9 Outputs

Microservices

Microservices are individual components that work together to deliver an overall solution.

2
Six Advantages of Microservices | White Paper

To be clear, the assembly line analogy does not imply

a single linear flow, since microservices and assembly
lines do not have to run in a strictly serialized order.
With microservices, data can easily be copied and then
distributed to multiple locations as part of the data pipeline,
and thus can take multiple paths and be processed in
different ways as in a directed acyclic graph (DAG). This gives
you more flexibility in how you define the data pipeline, and
also simplifies the effort in expanding your pipeline in case
you want to create more outputs in the flow.

Final Raw and

Raw Data HTML Data HTML Data
Data HTML Store Publish to
Source Creation Data Website

Linear Pipeline

Directed Acyclic Graph

Data Final Raw Data Store

Source Data

HTML Data
Final Raw Data
HTML Publish to
Creation Website
HTML Data

The data flow in a microservices architecture can be represented by a DAG.

Although microservices have recently grown in popularity,

the concepts behind them are not new. Topics like modular
programming, separation of concerns, and service-oriented
architecture (SOA) all have principles that align with the
objectives of a microservices architecture. This means that
microservices are based on best practices that we have
used over the years, so their use can be easily justified.
Some development teams may have already adopted a
microservices architecture without necessarily calling it
that. Big data pipelines typically process data one step at
a time, which aligns well with a microservices approach. If
you have a streams-based architecture (more on this later),
you likely are running microservices within that framework.
By having a more deliberate approach to microservices
using the techniques you have already practiced, you can
potentially get even more value out of your deployments.
And microservices are a great fit for cloud environments, so
if you have a Kubernetes cluster and/or are running in the
public cloud, microservices represent a great architecture
to take advantage of cloud capabilities.
3
Six Advantages of Microservices | White Paper

Microservices Architecture the last microservice in the series). The output message is
sent in a format that makes the most sense for the given
Requirements microservice, and it is then up to the next microservice in
the flow to know what that message format is, and how
Building your applications and solutions in a to consume it. In general, any microservice only needs to
microservices architecture does not require any write to (at most) one topic, since multiple downstream
specialized knowledge or experience. Much of the microservices can independently read from that same
strategy will sound familiar, and again leverages topic without conflict.
concepts like modularity
that you have likely practiced Microservices Messages
before. Certainly, inter-
microservice communication is M1 M2 M3
a key part of the architecture,
and REST services are
commonly used for data
exchange. However, an Topic 0
increasingly popular design Topic 1
Topic 2
pattern for data exchange that Topic 3

might be new to you is the

use of a central, lightweight Apache Kafka
messaging bus in an event-
driven architecture. Since each
Microservices can use Kafka topics to pass data to the next microservice.
microservice is related to one
another as part of a larger solution, there needs to be To continue with the assembly line analogy, the
an easy way to track its state and pass data between messages are like the work-in-progress products,
individual microservices. Since there are advantages of and each microservice performs more work on those
using a messaging bus with microservices over other products. Topics are like the conveyor belts that
means of data exchange, this paper will focus on that transport products between assembly line stations.
design pattern.
Since Kafka is often used for microservices
One option for the messaging system is Apache architectures, it makes sense that terms like “streaming
Kafka. Apache Kafka is a publish/subscribe (pub/sub) architecture” or “streams-based architecture” are closely
messaging bus that stores data in separate channels related to (and sometimes used interchangeably with)
called “topics.” A topic is a data structure that tracks “microservices architecture.” Although those different
data elements (or “messages”) in order. Topics are terms imply a different focus of the architecture, the
flexible and can store messages in almost any format. basic foundation is the same.
From a coding perspective, it is easy to read and
Another option for the messaging system is an in-
write messages to topics. And since this approach to
memory data grid (IMDG), which is a distributed
messaging is decoupled from the microservices code,
computing system that lets you store and process
you get more flexibility in how you can exchange data
data with extreme speed due to the emphasis on RAM
versus having microservices communicate directly with
and parallelization. An IMDG stores data structures in
each other.
memory, unlike Kafka, which relies on hard drives or
You can set up a series of topics as sources and solid-state drives (SSD). This means an IMDG lets your
destinations for your microservices to make up microservices access data at much higher speeds, which
the messaging system for your deployment. Each significantly accelerates the performance of your
microservice will retrieve ordered data from one or more overall solution.
of its designated source topics, and after processing
the data, will write the output in an ordered way to its
designated destination topic (or writes no messages if it is

4
Six Advantages of Microservices | White Paper

IMDGs also include topics as data structures, similar to Other technologies can be used for microservices
Kafka, which you can use to pass messages between messaging but are far from ideal. File systems and
microservices. There are other data structures that can databases (either RDBMS or NoSQL) can be used, which
be used for messaging in IMDGs, such as maps (i.e., data are sometimes implemented as REST services, but they
structures that act like a key/value store), but for the suffer from a significant performance disadvantage
sake of simplicity, our discussion will center on topics. In versus the technologies described above. Plus, the
addition to speed, another advantage for using IMDGs coding and administrative overhead to use these
for microservices is that you can leverage more data systems as a messaging system make them far from
structures for your microservices to store and retrieve ideal for an otherwise agile-focused microservices
data beyond messages. The IMDG acts like a database architecture. Certainly, these technologies have been
that provides lookup data for stream enrichment, and used for earlier generations of microservices, but
also can store data to track state for your microservices. application developers are recognizing the need for
better suited technologies to ensure the performance
By using a message bus as the messaging layer in a
levels and maintainability they seek.
microservices architecture, it makes sense to also use
a stream processing engine (like Hazelcast Jet) to
build the microservices. This is only one example of a
technology you can use, as microservices are actually
great for supporting any technology for coding the
business logic, as we’ll discuss later in this paper.

Microservices Messages
Other Data

M1 M2 M3

Topic 0
Topic 1
Topic 2
Topic 3

Data Data Data

Objects Objects Objects

In-Memory Data Grid

(e.g., Hazelcast IMDG)

In-memory data grids provide fast messaging and data storage/retrieval.

5
Six Advantages of Microservices | White Paper

Why Microservices? Thinking in a microservices context can help reinforce

good development practices. If you can define your
Microservices are ideal for modern deployments that solution as a series of small tasks, then you can focus
use popular technologies like cloud (private, public, more on getting each task right with less concern on
hybrid, multi), cloud object storage, Docker containers, how each task will affect the next task in the process.
Kubernetes, and RAM alternatives like Intel® Optane™ This is where a decoupled messaging system like
DC Persistent Memory. Below are some of the technical Kafka or Hazelcast IMDG will also help simplify the
use cases that benefit from microservices: microservice development process. Each microservice
can write to Kafka/IMDG in its own standardized
T Operationalizing machine learning models (machine format that the next microservice in the flow can
learning inference) understand. There is no strict messaging format that
T Internet of Things data analytics and processing, from the microservices have to adhere to. For example,
edge to cloud if a microservice only needs to send a comma-
delimited list of integers, it can do so, and the next
T Fraud/anomaly detection microservice is responsible for reading that format
T Large-scale extract-transform-load (ETL) to do its own processing. This decoupling encourages
experimentation and A-B testing to compare different
T Transaction monitoring and processing (such as online
versions of code in the same environment since it is easy
payments and e-commerce)
to add in new code to the data pipeline.
The common theme among those use cases is that there The simplicity and modularity of each microservice
are huge volumes of data, service-level agreement (SLA) also contributes to reusability. If a microservice is
requirements that need to be met, and a significant responsible for a generalized task such as converting
amount of code. Rather than trying to tackle such use CSV into JSON, then that module can be easily plugged
cases with a monolithic approach, consider the following into any microservices deployment that needs that
six reasons why microservices provide an advantage. conversion. This helps with rapid development and
expansion for all subsequent microservices-based
1. Microservices Are Easier to Build and
solutions. Of course, the microservice needs to be
Enhance
written to handle any type of CSV input, so you simply
Microservices enable higher quality code by encouraging need to keep generalization and reusability in mind
more focus. Since individual microservices, by definition, during development, which tends to be easier to do
are smaller than monolithic applications, they have when coding limited-scope tasks.
less scope and less code. This makes experimentation
and testing with incremental code updates much A microservices architecture is not necessarily an
easier. While the overall amount of code for an entire all-or-nothing endeavor. You can incrementally add
microservices-based solution may be similar to a microservices to an existing monolithic application if
functionally comparable monolithic application, the you want to add more capabilities to that application.
enforced separation of code makes each part easier to You can also incrementally migrate a monolithic
manage. Less code at a microservice level means less application into a microservices architecture to gain
complexity, lower testing effort, easier unit testing, and all the advantages described in this paper. While
lower risk for problems. And all of those traits mean it this may sound like SOA, the key difference is that
is easier to maintain and enhance the code, thus giving a microservices architecture makes each of your
you greater agility and higher quality. It is easier for applications small and manageable, while SOA was
new members of the development team to understand largely about making large applications communicate
the objectives of each microservice and to more easily with each other. With an SOA mindset, you would be
contribute, and there is a lower risk of applications able to share data in a less complicated way, but you
becoming “black boxes” in which the source code is too would still deal with complicated applications that were
complex to dive into. not necessarily easier to build.

6
Six Advantages of Microservices | White Paper

A microservices architecture also enables you to to be simple. They can be deployed on-premises, in
take advantage of a wider talent pool, because the cloud, at the edge, in virtualized environments
each microservice can be based on almost any (especially Docker containers), in serverless
programming language and environment, independent environments, on one node, or on a cluster of nodes. In
of all the others. There is no requirement on how fact, microservices can be deployed in several different
each microservice is built. You can choose the most locations as part of the same overarching applications to
appropriate technology stack for each microservice. take advantage of any of your available resources.
Separate application development teams with different
You can also deploy new versions of microservices
skills can work together on a microservices architecture
without waiting for updates to other microservices. As
without requiring commonality on technologies and
long as your messaging format remains intact, you can
skill level. This also means that you are better able to
redeploy updated versions of microservices without
incorporate newer technologies into your architecture
negatively impacting the rest of your system. If a
in the future. Instead of struggling with technology
problem occurs with your new microservice, you can just
standardization across the board, you can incrementally
swap in the prior microservice to get the system fully
leverage new technologies to update only the
running again.
microservices that can be made faster and/or more
efficient. This gives you an opportunity to experiment 3. Microservices Are Easier to Maintain,
with new technologies on a controlled basis to see how Troubleshoot, and Extend
well they may work in other capacities.
Microservices more seamlessly enable ongoing
2. Microservices Are Easier to Deploy maintenance and fault tolerance, which are major
challenges in any large-scale software environment.
Microservices are easier to deploy than monolithic
Troubleshooting is difficult when a problem arises in
applications because they are smaller and thus have
a monolithic application since it is not always obvious
fewer environmental dependencies. One common
how data is processed within the internal workflow.
problem with deploying monolithic applications is
Isolating the source of the problem requires a good
the unknown discrepancies between development
understanding of the entire code base. On the
environments and production environments. There
other hand, since each microservice has its own set
are dependencies on OS versions, library versions,
of outputs, it is easier to identify which output has
the amount of RAM, etc., and if you have a complex
an issue, and therefore, which microservice needs
application with many dependencies, you may
attention. For example, if you discover that the
encounter deployment problems that are difficult to
final calculations in a microservice-based system are
pinpoint. If you deploy microservices in an incremental
incorrect, you can trace back the lineage of the data
manner, any issues you encounter with each individual
within the system, one microservice at a time, to find
microservice will be easier to track down since their
the problematic calculation. The limited scope of each
smaller scope means they have fewer dependencies.
microservice, plus the fact that microservices make it
The reduction of dependency discrepancies from easy to run automated, standardized test scenarios,
development to production is also a key advantage makes them easier to debug and thus easier to create
of a containerized architecture. The minimalist higher quality code.
nature of individual microservices makes them even
The distributed nature of microservices across multiple
easier to deploy in a container and with other
computer servers and resources helps with fault
virtualized technologies, and doing so lets you further
tolerance strategies to enable 24x7 deployments. Any
reduce the potential for dependency conflicts.
given microservice can be deployed redundantly so that
Combining a container-based deployment with
there is no single source of failure. Each microservice
Kubernetes as the orchestration system further
performs independently of the other instances, and if
simplifies the deployment by efficiently allocating
any fail, the others will pick up the slack. This is another
microservices to available resources.
area where the decoupled messaging layer is valuable,
Microservices are easy to deploy in a variety of as each microservice acts as an independent consumer,
deployment options, again because they are designed so a microservice failure will not disrupt the messaging

7
Six Advantages of Microservices | White Paper

system. Deploying microservices in Docker containers To support this simplification, microservices should
in a Kubernetes cluster also simplifies the maintenance, leverage a lightweight messaging system to let
as Kubernetes can manage some of the fault tolerance microservices communicate, which simplifies the
requirements and restart failed microservices. coordination across development teams. Each
microservice can send messages/data in whatever
Making incremental updates to your application is
format you want, which naturally encourages
easy and relatively low risk due to the highly modular
you to adopt the simplest format possible. There
architecture. You can either plug in updated code to
is no requirement around a universal messaging
improve existing functionality, or you can add new
standard, which ironically tends to complicate future
code to extend your system to provide more outputs.
communication. Once each format is documented,
The decoupling of the messaging layer reduces the risk
the development team of the next microservice in the
of losing data (or other dramatic failures) if the new
pipeline can use that format to accept messages. And
updates are found to be problematic. Even if you need
since each microservice performs a limited task on the
to make sweeping changes to your application, you can
data, there is no need for complicated outputs. The
do so with far less risk than in a monolithic application.
complicated messaging formats of years ago are not
For example, if you change your messaging format in
needed since a comprehensive message does not need
an updated microservice, you can send out both the
to be shared. This simplicity in messaging helps when
old format and the new format at the same time to
the type of information changes. The updates in the
separate topics. The existing microservices that are next
format will likely be simple, thus making it easier for the
in the pipeline will continue using the old format from
next microservice to accommodate those updates.
the original topic, and in the meantime, you can write
an updated microservice that will leverage the new This lightweight messaging pattern helps to avoid
format from the newly added topic. This lets you run old overly complicating the communications topology. Risks
code alongside new code as an extra defensive measure such as those expressed in Conway’s Law, which states
against problems. that your designs will become copies of your team’s
communications structures, still exist, but only if you
And should an unforeseen error occur later, you can
retain a monolith mindset. For example, if you build a
shut down a given task which will temporarily stop the
single large team where each developer believes his/her
flow of data, but the messages will be simply queued up
modules need to integrate with all the others, you end
in the messaging layer and will be read once the task in
up with a complex architecture with many integrations,
question is restored. The message bus ensures all data is
APIs, and data structures throughout. On the other
preserved until all microservices are operational again.
hand, if an architect can define the components of a
4. Microservices Simplify Cross-Team microservices architecture, and then have the team
Coordination leaders define the team structures to reflect the
architecture, you will simplify the effort to implement
One of the challenges of any large-scale software
the system’s communications.
development effort is the risk of over-complicating
the integration points. In a microservice, the internal
workflow can be as simple as reading data from a
source, performing an action on the data, and then
sending outputs to a destination. There is no need for
extensive planning for what data should be shared on
which integration points, as was the case with SOA.
Microservices typically deal with small amounts of
data at a time, so it is easier to manage and share the
output once the data is processed. This simplicity in the
processing and the data scope leads to simplicity in
the handoff.

8
Six Advantages of Microservices | White Paper

5. Microservices Deliver Performance 6. Microservices Simplify Real-Time

and Scale Processing
The distributed architecture of microservices opens The demand for immediacy continues to grow, and
opportunities for increasing performance and scaling businesses need to respond more quickly than before
out. Just as each microservice can be run redundantly to maintain a competitive advantage. That is why
for fault tolerance, this redundancy also enables greater streaming architectures and real-time processing
parallelism that adds performance and scale. More are hot topics today, and those align well with
microservice instances mean more computing resources microservices. Real-time processing introduces many
allocated to the respective tasks. At the same time, this challenges around performance, scale, reliability, and
approach enables greater scale, so more data can be maintainability, and the microservices approach can help
processed via increased parallelism. This is essentially a alleviate the difficulty.
divide-and-conquer approach to processing your data,
Real-time processing typically starts with a continuous
where you spread out work across more microservices
flow of data, like from a number of Internet of Things
to take advantage of more CPU power and RAM.
devices. The incoming data typically has to go through
Whenever a bottleneck in the pipeline arises, more
several processing tasks like enrichment, aggregation,
instances can be deployed (either manually or with
and filtering. Each of these steps can be done by a
Kubernetes in a containerized environment) to provide
microservice to form a clear separation of tasks that
load balancing. Again, the decoupled messaging layer
hand off data to the next. The messaging layer helps to
helps in the easy incremental deployments of additional
facilitate this real-time flow, and perfectly aligns with
microservices.
the incoming flow of streaming data.
The ability to add performance and scale is not merely
In some cases, the processing must be done
about meeting SLAs with future growth in mind. It is
immediately at the edge, where there is typically
also about having the extra headroom to experiment
limited physical space that requires smaller footprint
with new capabilities. This is especially critical in
hardware. Since these hardware systems tend to be less
production machine learning deployments where
powerful than servers in data centers or in the cloud,
experimentation is inherent to the deployment lifecycle.
lightweight, efficient software packages are necessary
A machine learning model is rarely considered good
to run with the reduced computing power. Technologies
enough, and the accuracy can only be fully assessed
like Hazelcast Jet were designed for a wide variety of
by running the models on live data. With the ability to
deployments, including at the edge, to let you offload
experiment, you can keep your day-to-day operations
some processing to edge computers rather than trying
running reliably while simultaneously exploring new
to transmit all data to a centralized data center. This
opportunities for improvement.
deployment model is essentially a widely distributed
Of course, the performance and scale advantages microservices architecture, where some of the tasks are
only apply to code that is specifically part of the performed close to the data source, and then data is
microservices deployment. In other words, if there are delivered to the cloud or other data center to perform
external resources like a remote, third-party API that additional processing on higher-powered computers.
is called as part of the pipeline, then a microservices
architecture will not necessarily help you there. You
need to make sure that the external resource can
scale as well so that your redundant microservices can
leverage it in a parallelized manner.

9
Six Advantages of Microservices | White Paper

Conclusion The Hazelcast In-Memory Computing

Platform
As discussed in this paper, there are several good Hazelcast delivers the industry-leading in-memory
reasons to adopt a microservices architecture. Now computing platform that provides Global 2000
that we are dealing with more data than ever before, enterprises with ultra-high performance for time-
thinking more strategically about how to handle that sensitive, cloud-native applications.
data is an important priority today. Investigating the
new technology innovations today will further help your The Hazelcast In-Memory Computing Platform
journey with microservices. comprises Hazelcast IMDG, the most widely deployed
in-memory data grid, and Hazelcast Jet, the industry’s
Innovation is not limited to software technologies, most advanced in-memory stream processing solution.
as we earlier alluded to the Intel Optane technology This technology is uniquely designed to allow you to
which introduces us to a new level of hardware gain computing insights faster, enable actions within
performance. Leveraging in-memory RAM has, in the shorter durations, and engage new data at the speed
past, been an expensive proposition, so with Optane, with which it is arriving. In addition, a distributed
in-memory speeds are more economically accessible. caching architecture allows you to scale up to hundreds
In volatile memory mode, Optane behaves like RAM of terabytes and scale out for maximum efficiency when
with comparable speeds (depending on the workloads dealing with remote data or edge processing.
and data models), but at approximately half the cost.
This encourages more businesses to turn to in-memory Built for ultra-fast processing at extreme scale,
technologies to accelerate application performance. Hazelcast’s cloud-native in-memory data grid and
Not all in-memory technologies can take advantage event stream processing technologies are trusted by
of Optane off-the-shelf, but you should consider the leading companies such as JPMorgan Chase, Charter
Hazelcast suite of technologies (Hazelcast IMDG and Communications, Ellie Mae, UBS, and National Australia
Hazelcast Jet) which are certified to use Optane (along Bank to accelerate business-critical applications. The
with other Intel technologies) for much higher-speed world’s largest e-commerce sites rely on the Hazelcast
processing compared to your disk- or SSD-based systems. Platform for sub-millisecond response times to support
massive volume spikes associated with Black Friday,

Relevant Technologies for Cyber Monday, or Singles’ Day.

Microservices Intel® Optane™ DC Persistent Memory

Since many of the performance requirements are
As discussed in this paper, microservices architectures dependent on in-memory processing, the one big hurdle
can benefit from in-memory, cloud, and streaming that emerges is the cost of random-access memory
technologies. Hazelcast, IBM, and Intel are working (RAM). In many cases, the investment in more RAM-
together to offer solutions that deliver on today’s heavy hardware servers is justifiable, and as RAM prices
demanding requirements around data. Performance, continue to decrease, the use of in-memory processing
scale, security, reliability, and agility, especially in becomes more accessible.
cloud-native environments, are the key components
to deploying successful, business-critical systems. With Recent innovations make the adoption of in-memory
the in-memory computing platform from Hazelcast, processing even more practical. The Intel Optane DC
the innovative hardware from Intel, and the edge-to- Persistent Memory technology offers two ways in which
cloud enterprise-wide solutions from IBM, data-driven in-memory processing can be more cost-effective. The
businesses have solid technology choices for their first way is in volatile memory mode, in which Optane
current and future digital strategies. chips act as an alternative to RAM and run at nearly the
same speed but at a much lower cost and much higher
capacities. This lets businesses more easily justify in-
memory technologies and thus take advantage of the
performance benefits that in-memory processing offers.

10
Six Advantages of Microservices | White Paper

The second way in which Optane supports in-memory secure way to move core business applications to any
technologies is in the persistent mode. In this mode, cloud environment through an enterprise-ready, cloud-
Optane can be used as a faster alternative to solid state native software stack. Built with Kubernetes on Red
drives (SSDs). For example, Hazelcast provides a hot Hat OpenShift, the Cloud Paks give customers flexibility
restart capability in which in-memory data is persisted and agility to drive digital transformation strategies.
in non-volatile memory so that if a node goes down Hazelcast is included in the Cloud Paks to provide
temporarily, it can be restored quickly by reading data in-memory speeds in a cloud-native framework to all
from the hot restart store. If the hot restart data is applications deployed in the Paks.
stored in Optane in persistence mode, recovery of that
The IBM Edge Application Manager (EAM) extends the
node can be up to 3.5x faster than using SSDs.
reach of business data by enabling computing at the
IBM Cloud Paks and Edge Application edge. Since edge computing typically entails remote,
Manager hard-to-access locations with limited physical space
and thus limited computing power, some of the most
As more businesses pursue cloud strategies around
important factors for a successful deployment are
public, private, multi, or hybrid cloud, the right
efficiency, reliability, and security. Together with IBM
foundational software will help on that journey. Cloud
EAM, Hazelcast provides portable and lightweight
deployments are just one part of an overall distributed
yet powerful in-memory and stream processing
computing system that includes computing at the edge,
technologies to enable edge computing and let
making system deployment more complex.
businesses process, analyze, aggregate, and/or filter
IBM has key initiatives around solving edge-to-cloud data where it is created.
challenges to help businesses get more value out
of their distributed data. With their six Cloud Paks
(Applications, Data, Integration, Automation, Multicloud
Management, Security), IBM provides a faster, more

2 West 5th Ave., San Mateo CA 94402 USA

Email: sales@hazelcast.com Phone: +1 (650) 521-5453 @hazelcast
Visit us at www.hazelcast.com
https://www.linkedin.com/company/hazelcast

https://www.facebook.com/hazelcast
All rights reserved.