Event-Driven

Microservices
The Architect’s Guide to Building a Responsive,
Elastic and Resilient Microservices Architecture
“Ifincrease
we are to exponentially
agility through
microservices, we need to
replace our static, stove-piped,
monolithic thinking.
JONATHAN SCHABOWSKY

Text copyright © Solace

All rights reserved. No part of this work may be reproduced, or stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, or otherwise without permission from Solace.

For inquiries about permissions, contact:

Solace
535 Legget Drive, 3rd Floor
Ottawa, Ontario K2K 3B8
Canada

Phone: +1 613-271-1010
Web: solace.com
 TABLE OF CONTENTS
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

The Service Decomposition Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

The Integration Conundrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

The Incredible Dancing Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

The Copernican Shift to Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Realizing the Agility Provided by a Modern Central Nervous System . . . . . . . . .9

Think Event-Driven and Choreograph Service Execution . . . . . . . . . . . . . . . . . . .9

Embrace Eventual Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Databases + CQRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Integrate Event-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Utilize Events to the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Events as the Cornerstone of DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Use Vendor Agnostic Standard API or Wireline Protocols for Events . . . . . . . 16

Overcoming the Barriers Between You and Event-Driven Microservices . . . 17

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

About Solace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Event-Driven Microservices
 INTRODUCTION
Many organizations migrate to microservices architecture for one reason: Agility. The
ability to very quickly create and modify components in a way that offers bottom line
business value is mission critical in a world where your competitors are a click away
and time to market is everything. But the speed with which you develop components
is just one piece of the puzzle.

How quickly can you integrate them with significant risks or barriers to agility:
the rest of your system? How completely
• Brittleness of distributed processing;
can you embrace innovative new
techniques and technologies? • Ecosystem integration challenges; and,

For your microservices initiative to be • A lack of service harmony.

successful, your organization must
If we don’t respect the realities of
realize that agility hinges on a holistic
distributed systems, we will repeat the
approach leveraging practices such as CI/
failures of the past, like the SOA hype of
CD, automated infrastructure, DevOps
the 2000s. Fortunately, there is one really
and agile development. An average
powerful way to compensate for these
microservices architect combines these
realities: event-driven (also called reactive)
concepts into a lean, mean development
architecture.
machine. A great microservices architect
goes beyond that by appreciating and Jonathan Schabowsky, a senior architect
finding ways to overcome the undeniable in Solace’s Office of the CTO, will explain
– but predictable – pitfalls that accompany the massive benefits of combining event-
highly distributed systems. driven architecture and microservices,
starting with the fact that decomposing
The key to ensuring a microservice
applications, while in many ways beneficial,
initiative’s success is appreciating the
can make life a little more complicated.

1 Event-Driven Microservices
“Application leaders engaged
in digital transformation
initiatives must add ‘event
thinking’ to their technical,
organizational and cultural
strategies.
YEFIM NATIS
GARTNER

Source: Gartner “Business Events, Business Moments and Event Thinking in Digital
Business,” 4 August 2017, Yefim Natis
 THE SERVICE DECOMPOSITION PARADOX
The theory of microservices is simple: you make each microservice, the larger
achieve better agility, scalability and your service count, the more the fallacies
reusability by breaking monolithic of distributed computing impact stability
applications into small, purpose-specific and user experience/system performance.
microservices. This makes it mission critical to establish
an architecture and implementation that
The real-world implementation of
minimizes latency while handling the
microservices is, as always, more
realities of network and service outages.
complicated than that. This is in large part
because of the fallacies of distributed Much of the tooling related to
computing – a set of false assumptions microservices involve the use of CI/
that programmers and architects make CD, automated infrastructure, DevOps
when they enter the world of distributed and agile software development. A
applications. This list was written in 1994 great example would be Pivotal Cloud
by L. Peter Deutsch and others at Sun Foundry, which gives developers an easy
Microsystems, but it holds true today. way to create, test, deploy and update
microservices using modern, cloud-native
THE FALLACIES OF DISTRIBUTED
COMPUTING techniques.

• The network is reliable. The challenge is that microservices require

connectivity/data in order to perform their
• Latency is zero.
roles and provide business value, and
• Bandwidth is infinite. data acquisition/communication has been
largely ignored, so much so that the tooling
• The network is secure.
has severely lagged behind. For example,
• Topology doesn’t change. API management/gateway products only
support synchronous, request/reply
• There is one administrator.
exchange patterns, which exacerbates the
• Transport cost is zero. challenges of distributed computing. And
they don’t have the ability to integrate with
• The network is homogeneous.
or acquire data from legacy systems.
While all of these fallacies are relevant,
At the same time, eventing/messaging
those in bold are of special importance
tools have been stuck in the antiquated,
to the world of microservices. The smaller
non-agile world too, being incompatible

3 Event-Driven Microservices
with many of the guiding principles of In the days of SOA, you’d create massive
microservices such as DevOps and self- monolithic services that directly
service. But it’s eventing/messaging that implemented all facets of the use case as
best deals with the idiosyncrasies of a set of services orchestrated using BPEL
distributed computing and is the key to engines or an ESB. They weren’t reusable
unlocking the potential of microservices and were difficult to scale because ESBs/
architecture. BPEL orchestration moved too much
logic into the network, leading to “dumb

“Eventing/messaging tools have endpoints and smart pipes” that were

expensive, complex and nearly impossible
been stuck in the antiquated,
to troubleshoot.
non-agile world. Many are
incompatible with the guiding Today, we recognize that the way to go is
principles of microservices, such small, single-in-purpose microservices and
a “smart endpoints, dumb pipes” approach
as DevOps.”
to connectivity and communications. But
TWEET that lingering question persists:

How can we enable service collaboration

As services become smaller and their
in order to offer business value without
purpose more singular, the potential for
falling back to those failed monolithic or
reusability increases, but that’s contingent
orchestration techniques?
on the ability for services to collaborate.

DID YOU KNOW ?

83% of enterprise workloads will be

in the cloud by 2020, according to

the Cloud Vision 2020 survey from

LogicMonitor
 THE INTEGRATION CONUNDRUM
Because all microservices need data for When you add it all up, there are
processing, and since 12-Factor Apps impedance mismatches everywhere you
are stateless, data needs to come from look:
somewhere. Acquiring data for greenfield
1. Updates to legacy systems are slow, but
systems is easy, but microservices almost
microservices need to be fast and agile;
always come to be as a side effect of digital
transformation, modernization or the need 2. Legacy systems use old communication
to build new capabilities at a more rapid mediums, but microservices use modern
pace. So you’re almost always dealing with open protocols and APIs;
an ecosystem of legacy systems; some will
3. Legacy systems are nearly always on
be modernized, others will remain as is for
premise and at best use virtualization,
the foreseeable future.
but microservices rely on clouds and
The existing business ecosystem is IaaS abstraction;
the unavoidable burden that most
4. IoT systems use highly specialized
businesses must deal with when they
protocols, but most microservices APIs
start their microservices journey. Most
and frameworks don’t natively support
existing systems live on premises, while
them; and,
microservices live in private and public
clouds. The ability for data to transit the 5. Mobile devices may use REST but also
often unstable and unpredictable world of require asynchronous communication,
wide area networks (WANs) is tricky and but most API gateways only support
time consuming. Then we need to factor synchronous RESTful interactions.
for the emergence of and specialization
How can an organization resolve all of
caused by IoT, mobile devices and big data.
these mismatches?
The volume and variety of these systems
results in a very large upfront risk to
microservices initiatives.

5 Event-Driven Microservices
THE INCREDIBLE DANCING MICROSERVICES
As I described earlier, the smaller the and the performance will suffer, if not be
service, the less value it discretely ruined.
offers the end user – value comes from
Dancing is different. A choreographer
orchestration. Historically, orchestration
listens to a song and creates a routine
was handled by a central component like
based on events in the music. The dancers
BPEL engines or ESBs, or, these days, API
may do completely different moves or
gateways.
steps from each other, but as long as it was
I’ll use a musical analogy to explain the choreographed together based on those
problem with that approach. audio cues (or events) then the routine
will be a success. Even if someone messes
Most composers create music by trial and
up by doing the wrong step or losing the
error (just like a software developer). Their
beat, the show can continue because each
output? Musical scores containing sheets
dancer is listening to the music for their
of music which will be played by each
specific event rather than being told what
instrument. For this analogy each musician
to do by an orchestrator.
is like a microservice. If the composer
is writing for a heavy metal band, there To bring it back to microservices, a given
are only a few instruments (guitar, bass, microservice will perform a series of steps
drummer, vocalist) and a conductor isn’t within the code which is an example of
needed. micro-orchestration. The input or output
of a microservice is a data event which has
But a symphony orchestra consists of
domain significance. The key is that since
around one hundred musicians playing a
the microservice is merely producing an
wide range of instruments. In this instance,
event, it does not have knowledge of if or
they absolutely need a conductor to ensure
when it will be processed. Other services
that every musician starts playing at the
register their interest in an event or set of
right moment, stays on beat, speeds up
events and react accordingly. Just like a
and slows down when necessary, plays
dancer executing the steps of the routine.
louder or softer.
Ironically, the common enabling theme
Unfortunately, if the conductor can’t between microservice execution and a
communicate with the musicians – or dance move is the event (data event or
even just a section or potentially a single audio event).
musician – things will quickly fall apart
 THE COPERNICAN SHIFT TO EVENTS
FROM DATA-CENTRIC TO EVENT-CENTRIC IT PRIORITY – A COPERNICAN SHIFT

computing universe. This traditional

“Similar to the mistakes that viewpoint is based on the belief that data
astronomers made before is job one, and that once it’s preserved

Copernicus, many architects and it will be viewed, updated and deleted

using command-style request/response
technologists are obsessed with
interactions.
the idea that data is the center of
the computing universe.” The reason for this extreme focus on data is
simple: all interactions with databases are
TWEET
performed by command-style interactions!
The problem with this viewpoint is that
Copernicus was a Renaissance-era enterprises end up making a bunch of
mathematician and astronomer who microservices with databases at their core,
formulated a model of the universe that leading to many stove-piped application
placed the Sun rather than the Earth at enclaves that can’t share data in a fast,
the center of the universe. Game-changing flexible manner. In other words, money
stuff at the time. was spent to create a different type of
monolithic application, one that is doomed
Similar to the mistakes that astronomers
to the same lack-of-agility fate.
made before Copernicus, many architects
and technologists are obsessed with So what should be at the center of the
the idea that data is the center of the microservices universe? That’s easy: Events.

7 Event-Driven Microservices
If we are to exponentially increase agility platform. Just like how our sensory
through microservices, we need to replace system fires events to the central nervous
our static, stove-piped, monolithic thinking system for interpretation. In the world of
with a desire to get the right event to the microservices, we need a central nervous
right service at the right time. system that can:

Consider your own body. We constantly • be receptive to different stimuli;

react to and act upon events that arrive via
• provide fast, rock-solid reliable transport;
our senses of touch, vision, taste, hearing
and,
and smell. This events relay information
that’s stored in our memory, replayed in • adapt to changes in event reception.
our minds, and acted upon if necessary in
Not adopting event-driven thinking
the form of some action that produces new
will forestall the success of digital
events for our universe to react to.
transformation and microservices
Thinking in an event-driven manner turns initiatives by increasing costs and
organizations into a sensory element in the decreasing productivity. So what are the
universe of computing. New events sensed patterns and approaches that will enable
by web/mobile applications, IoT sensors, you and your organization to achieve
or legacy systems of record are forwarded success with events at the center of your IT
to the eventing/messaging platform which universe?
distributes them to the microservices
 REALIZING THE AGILITY PROVIDED BY A
MODERN CENTRAL NERVOUS SYSTEM
As Gartner states in their August 2017 organizational and cultural strategies.”
report titled Business Events, Business
That is a bold statement, but obviously I
Moments and Event Thinking in Digital
couldn’t agree more. The goal of this paper,
Business, “Application leaders engaged
after all, is to lay out the actionable steps
in digital transformation initiatives must
you must take to realize the agility of event-
add ‘event thinking’ to their technical,
driven microservices.

THINK EVENT-DRIVEN AND CHOREOGRAPH

SERVICE EXECUTION

The first step towards adopting the event-

driven mindset is to change the way you
think about designing and architecting
solutions. Initially the tendency is to think
about all interactions between services
as a series in a sequence of request/
reply service calls. In fact, if you or your
team uses the terminology of “invoking,”
“requesting,” or “calling” then it is a sure It is common for architects to think in

sign you are still thinking in the paradigm terms of “service A will call service B which

of command style. will call service C” and then implement that

model through a chain of invocations (a->b-
Instead, try these: “What events should my >c) or by creating an orchestrator service
service process?” and “What events will my such that x->a, then x->b, then x->c.
service emit?”
Both approaches will cause chaos when the
Once you adopt event-driven thinking, you realities of distributed computing kick in,
need to make the shift from orchestration especially when you start to scale.
to choreography.

9 Event-Driven Microservices
The alternative is to follow the philosophy • Enables fine-grained scaling. Each
of choreography. Going back to the analogy service can be independently scaled up
of dance, services should react to changes or down based on demand. This ensures
in their environment just like a dancer a good user experience and is less
reacts to musical cues. The benefits are wasteful of compute resources.
immense:
• Easy to add new services. Due to less
• Better agility. Agile development coupling, a new service can come online,
teams are more independent and are consume events and implement new
significantly less impacted by changes to functionality without changes to any
other services. other service.

• Services are smaller/simpler. Each This litany of benefits doesn’t come for
service is not required to have complex free; there is no such thing as a free lunch.
error handling for downstream service or
Consistency of state then becomes an
network failures.
area of focus, because a service, being
• Less service coupling. Services have no temporarily down, means that the event
knowledge about the existence of other state changes may not be processed
services. immediately. Fundamentally, how do we
deal with this negative side effect?

EMBRACE EVENTUAL CONSISTENCY

Eventual consistency is the idea that lost before being appropriately handled by
consistency will occur in the future, and it a service and acknowledged.
means accepting that things may be out
Some think the only benefit of eventual
of sync for some time. It’s a pattern and
consistency is performance, but the
concept that lets architects remove costly
real advantage is the decoupling of the
XA transactions from the mix. It’s the job of
microservices since individual services are
the eventing/messaging platform to ensure
merely acting upon events that they are
that these domain change events are never
interested in.
“The road to microservices is
paved with good intentions.
But more than a few teams are
jumping on the bandwagon
without analyzing their needs
first.
NATHANIEL T. SCHUTTA

11 Event-Driven Microservices
DATABASES + CQRS

The thought process regarding using amount)

events typically leads to an interesting Public void creditAccount(name,
question: If data is no longer the center of amount)
my universe, where do I now persist these Public AccountList
events? getInactiveAccounts()

Databases take our thinking back to Public AccountList

command (Create, Read, Update, Delete) getOverdrawnAccounts()

style interactions. The database dilemma is }

extremely interesting, and using a pattern The CQRS pattern simply separates this
called Command Query Responsibility single service into two different and
Segregation (CQRS) can provide large independently scalable services:
benefits. The key is that CQRS is not an
AccountChangeService
architecture; it’s a simple pattern that can
help to enable event driven-architecture {

since, yes, the events at the center of our Public void createAccount(name,
universe must be persisted somewhere. acctMetadata)

Public void debitAccount(name,

Ultimately, that somewhere will be a
amount)
database for most cases.
Public void creditAccount(name,
So what is CQRS, exactly? amount)

Let’s explore a trivial banking use case as }

an example of what we are talking about And

with CQRS. Traditionally we would have
AccountReaderService
an Account service deal with all account
{
interactions. Its API would be defined as:
Public Account getAccount(name)
AccountService
Public AccountList
{ getInactiveAccounts()
Public void createAccount(name) Public AccountList
Public Account getAccount(name) getOverdrawnAccounts()

Public void debitAccount(name, }

 The execution of commands and queries focus for the architecture and is also the
is fundamentally different. For example, most natural way to model the domain.
commands and queries are always
The huge advantage is that you can easily
scaled differently because they occur at
siphon these domain change events into
different rates and have different overhead
new microservices (easily adding new
penalties.
capabilities and features) or into the
So why should we combine event-driven world of big data (where analytics can be
architecture with the simple CQRS pattern, performed and new discoveries made).
and what are the benefits?
An example of a new feature for our
Consider this: typically with databases you bank example would be implementing
start with a data design and data models. a marketing campaign for a new bank-
The decisions in that design affect all offered credit card. The use of EDA and
upstream services and processing because CQRS makes it easy to consume account
it has to work within the constraints of creation events and market the bank’s
the data model. This thinking puts data credit card to the new customer based off
squarely into the center of the architecture the acctMetadata (e.g. opening balance,
rather than the event. address, job, etc.).

If you separate command actions such as What you do sacrifice with CQRS is
create, update and delete from query, you consistency, but you enhance both
essentially have segregated events which performance and availability and, as
change domain state from the queries mentioned earlier, embracing eventual
which do not. It is these events which move consistency alleviates this concern for most
your thinking back into events being the use cases.

INTEGRATE EVENT-DRIVEN ARCHITECTURE

The enterprise is chock-full of events and philosophy is straightforward for systems
data stores that contain game-changing and devices which are already event-
potential. It’s really important that you driven, but not so for database-centric
not let the world outside of your event systems.
driven-microservices architecture pull you
One way of helping microservices coexist
back into command-style interactions or
with the legacy world of data-centric
worse than that (shudder) batches. This
systems is to implement change data

13 Event-Driven Microservices
capture (CDC) on the underlying databases. It’s easier to integrate modern systems
An example of this technique with Oracle and devices. For example, IoT devices
databases is to leverage Golden Gate, are inherently event-driven, social media
a CDC utility. As events occur they are platforms are stream-enabled, and even
written to the database. By capturing these many JEE applications utilize message
changes and treating them as events you driven beans (MDB) which can easily be
can leverage them in our microservices exploited. The key is to avoid allowing
platform. This eliminates any impact on integrations to lead you back into the non-
existing systems, and the need to make event-driven world.
costly code changes. Most of the work
here is transforming CDC events into the
domain data structure.

DID YOU KNOW ?

By 2021, according to research from IDC,

enterprise apps will shift toward hyper-agile

architectures—80% of app development

will take place on cloud platforms using

microservices and functions, and 95% of new

microservices will be deployed in containers.

 UTILIZE EVENTS TO THE UI
Now that you understand the power users make use of this web application,
EDA can bring to backend microservices they will dramatically increase the traffic
processing architecture, you should hitting these update services (most
consider bringing that same power to the returning no new result) and cost the
user experience. business more money.

Let’s face it, while AJAX provides a user A better approach would be to use an
experience that seems asynchronous to asynchronous protocol such as MQTT or
the user, under the covers it’s just polling WebSocket. The web application opens
web resources. If the polling interval is a connection, subscribes to the data the
too long, user experience suffers and they user wants, and waits for events to stream
cause unnecessary load on the system by to the browser. User experience is better
attempting to refresh. because events are arriving in real-time,
and it will save your business money as
Conversely, if the polling interval is
bandwidth and compute resources aren’t
too short, the chance that an update
wasted on pointless requests.
has actually occurred is low and again
resources are wasted. As more and more

EVENTS AS THE CORNERSTONE OF DR

Let’s look at the airline industry for a prime system was designed improperly. In others,
example of struggling to respond to IT their disaster recovery systems were ill
disasters. conceived or took too long to do their
thing.
Within the last few years, tens of thousands
of passengers have been stranded not This relates directly to event-driven
due to terrorism, geopolitics, or disease microservices. Events can be easily
outbreak, but by the cascading effect of replicated to other active or disaster
IT failures. In many of these cases, the recovery sites so systems are always in

15 Event-Driven Microservices
sync and ready for action. Historically, this many cases the same event was stored
was done at a data store level where each in multiple locations. A great side effect
database type used its own replication of designing your system around events
mechanism. instead of data is enabling your business
to continue executing through potentially
This was complex as it involved many
disastrous situations as though nothing
components and different strategies.
had happened.
It was also really expensive because in

USE VENDOR AGNOSTIC STANDARD API OR

WIRELINE PROTOCOLS FOR EVENTS
• Lack of APIs. One of the key benefits of
“The existing business ecosystem microservices is that it does not dictate
is the unavoidable burden that what programming language is used.
most businesses must deal Proprietary APIs and wirelines typically
with when they start their only support a small subset of languages,
microservices journey.” thus limiting agility and choice.

TWEET • Inhibited Innovation. Another benefit

of microservices is the ability to use
new technologies and techniques as
It may seem appealing to leverage cloud
industries and products evolve. Being
provider eventing/messaging offerings
locked in to a vendor’s proprietary
such as AWS’s SQS/SNS, Google Cloud Pub/
APIs can mean that your locked out of
Sub, Azure Service Bus, or proprietary
innovation since the cost to switch is
solutions for event transport like Apache
so high. Sounds like the problem with
Kafka, IBM MQ, and TIBCO EMS. There are
monolith applications!
multiple problems with this approach:
When choosing an implementation for your
• Lock-in. Problems arise when for
eventing/messaging platform it’s important
technical or business reasons you want
to make sure it supports standard APIs like
to move away from the solution. This
Spring, JMS, NMS, Paho and Qpid and/or
requires significant investment to undo
wirelines such as MQTT and AMQP v1.0.
the mistake as nearly all services and
integrations are affected.
OVERCOMING THE BARRIERS BETWEEN YOU
AND EVENT-DRIVEN MICROSERVICES
EDA has tremendous potential, as long in the configuration dictated by business
as architects and developers embrace requirements such as on premise and/
the mindset required for success. or in a variety of public clouds. They don’t
The challenge is the lack of tooling provide federation, synchronization or
to implement EDA in the context of recovery across wide area networks.
microservices. Finally, API management/gateway solutions
are simply not the right tools for event-
The tooling is not modern, performant,
driven microservices. Here are 7 reasons
open or stable. It also cannot be deployed
why:

DID YOU KNOW ?

67% of middleware respondents & 79%

of OpenShift respondents said that

microservices are being used to re-architect

existing applications as much as for brand

new projects, according to Red Hat’s 2017

Microservices Survey.
 Lack of Modernization. Messaging itself has been around a long time.

1
Fifteen years ago, there was no agile development — waterfall ruled the
day and messaging infrastructure was managed by specialized teams.
Today, the concept of DevOps and its associated agility means that
developers cannot wait for messaging infrastructure to be installed,
configured and data made available. Everything must be automated,
DevOps-friendly and self-service. This means that while messaging is the
right tool, the tools are no longer compatible with the agility needs and
requirements of today. This is magnified by the promises of speed, scale
and the agility of microservices architecture.

High, Unpredictable Latency. As monolithic applications are broken

2
into discrete services there is a point where latency will increase and
performance will decrease, impacting user experience and your ability to
satisfy SLAs. The need for the eventing/messaging platform to be as low
latency as possible has direct implication on the ultimate success of the
implementation. When this occurs, the initial reaction is to reverse course
and construct larger, more monolithic, less reusable and agile services
to decrease network hops and thus latency. This step completely undoes
many benefits of microservices but, in many cases, the enterprise is locked
in due to proprietary APIs and wirelines and therefore takes the path of
least resistance.

Proprietary Protocols and APIs. Years ago there weren’t any standard

3
wirelines or protocols, so IBM, TIBCO and other enterprise messaging
companies implemented their own. Today, they do so because they
(correctly!) worry that open standards will increase competition and
enable their customers to easily abandon their product as competitors
innovate and differentiate their offerings. Most vendors implement, at
most, a single standard wireline or open API, thereby constraining the
languages in which microservices can be implemented and excluding the
larger ecosystem of events such as those from IoT devices. This reduces
the overall value and agility that microservices provide and results in
integration shims intended to unify data movement.
 Poor Stability. No service will ever achieve 100% availability and no

4
system will operate perfectly at all times. Bugs within service, network
outages, and poison messages are all real examples of how services can
slow down or tax the microservices ecosystem. When these off-nominal
events occur, we as architects expect that our foundational services, such
as messaging, weather the storm, buffer the requests, and ensure no data
loss. It turns out the reality is that many messaging systems work well until
these scenarios occur. In other words, they let us down when the going
gets tough. Ironically, this is when we needed them the most!

Deployability Risk. The cloud providers all have messaging/eventing

5
platforms that can’t be deployed in their competitor’s clouds or on
premises where many businesses maintain core business functions.
Legacy messaging systems cannot easily be deployed into cloud
environments and some simply cannot because of their use of multicast.
Deployability is an important consideration given today’s climate of ever-
evolving cloud strategies. The pain to migrate can be large when the
decision to move towards hybrid and/or multi-cloud architectures arises.

WAN Weakness. The use of hybrid cloud and multi-cloud architectures

6
are extremely common for both economic and continuity of operations.
All of these strategies require events to be propagated across WANs in
a reliable, secure and performant way. Since legacy messaging products
were originally used in datacenter environments, they respond poorly to
the common WAN attributes of jitter and slow round-trip times.

API Management/Gateways - Wrong Tool. The API management/

7
gateway space is booming. This component is necessary because in many
cases B2B and web applications need to integrate using web-friendly APIs
such as REST/HTTP. These interactions, where they represent domain
change events, must be quickly transformed into events for downstream
processing. API management and gateways simply do not attempt to
enable the interactions between event-driven microservices, nor do
they enable many asynchronous protocols for streaming events to web
applications.

19 Event-Driven Microservices
CONCLUSION
While event-driven microservices may world. Engineered as a modern eventing
seem difficult initially, they are the future platform, Solace can be deployed in every
of most microservices and IT strategies. cloud and platform as a service, and can
Choosing the right eventing/messaging easily span WANs. It supports DevOps
platform is one of the most critical steps automation and provides an almost
in the path to realizing the vast benefits of completely self-service experience for
microservices. developers. Solace is the only stable and
performant solution that fits the unique
Architects and developers simply need
needs of microservices architects.
a platform that has been engineered to
thrive in today’s modern, rapidly-evolving

JONATHAN SCHABOWSKY is a senior architect in Solace’s Office of the CTO. His

expertise includes architecting large-scale, mission critical enterprise systems
in various domains, such as for the FAA, satellite ground systems (GOES-R) and
healthcare. Recently, Jonathan has been focused on the use of event-driven
architectures for microservices and their deployments into platform-as-a-services
(PaaS) running within public clouds.
 ABOUT SOLACE
We are the creators of PubSub+, an advanced message broker that
can be used to create an event distribution mesh. As the only unified
message broker that supports publish/subscribe, queueing, request/
reply and streaming using open protocols and APIs across hybrid cloud
and IoT environments, we rapidly and reliably route information between
applications, devices and people across clouds. Established enterprises
such as SAP, Barclays and American Express as well as high-growth
companies such as VoiceBase and Jio use our smart data movement
technologies to modernize legacy applications and successfully pursue
analytics, hybrid cloud and Internet of Things strategies. Learn more at
solace.com.

A FEW OF OUR CUSTOMERS

OUR FEATURED PARTNERS

R
solace.com