Microservices in the Enterprise: A Research Study and Reference Architecture

Microservices Architecture in the
Enterprise: A Research Study and
Reference Architecture
By Tellago, Inc

Contents
Overview.......................................................................................................................................................2
What are Microservices? ..............................................................................................................................2
Microservices in the Enterprise: The SOA Battle..........................................................................................3
Capabilities of Enterprise Microservices Architecture..................................................................................4
Service Discovery and Service Registry.....................................................................................................5
Microservices Description ........................................................................................................................7
Lightweight Middleware...........................................................................................................................9
Containerization of Microservices .........................................................................................................12
API Gateway............................................................................................................................................14
Inter-Service Communication .................................................................................................................15
One Microservice per Data Source Strategy...........................................................................................17
One Microservice per Use Case Strategy ...............................................................................................19
Microservices Monitoring.......................................................................................................................21
Other Relevant Capabilities of Enterprise Microservices Architecture ......................................................23
Summary.....................................................................................................................................................23

Overview
Microservices is one of the hottest trends in modern enterprise software. Created to
address some of the limitations of traditional service oriented architecture (SOA),
microservices proposes an architecture style of decomposing monolithic applications
into a series of smaller services that can accomplish atomic tasks. Despite its
undoubted popularity, most enterprises struggle with taking even basic steps
towards implementing microservices architecture. These challenges are a result of a
combination of the new architecture models, as well as the fundamental changes in
the software development processes introduced by microservices.
This paper explores some of the key features of enterprise microservices
architecture. The paper reviews a reference architecture based some of the lessons
we have learned implementing dozens of microservices solutions for enterprise
customers. From the technical standpoint, the paper reviews a series of new and
interesting technologies that can enable the foundation blocks of microservices
architecture.
What are Microservices?
Like any other hot technology trend, microservices has been surrounded with more
definitions than what we can cover in this article. However, in the context of
enterprise software solutions, there is a definition we think describes the
capabilities of microservices:
“Microservices are loosely coupled service oriented architecture with bounded
contexts.” (Adrian Cockcroft, Netflix)
The reason this definition of microservices is very relevant in the enterprise is
because it directly ties to SOA which is so common in corporate environments.
By loosely coupled SOAs, we refer to the principle that microservices should be very
autonomous and not highly dependent on other microservices. From that
perspective, microservices should avoid relying on common components or

infrastructure building blocks, like databases, that end up introducing direct
dependencies between microservices.
Bounded context is a concept from domain driven design (DDD) theory that
provides a methodology for dividing large architecture models into specific bounded
context and expressing the explicit relationships between them. In the context of
microservices, bounded context should allow a team to evolve a microservice
without having explicit knowledge of other microservices in the organization.
Microservices in the Enterprise: The SOA Battle
Microservices can very well become a fundamental building block of how enterprise
software will be written in the next few years. From a conceptual standpoint,
microservices offers models that enable levels of innovation and agility that have
been impossible with earlier architecture styles. However, the adoption of
microservices in the enterprise is also full of challenges.
One of the biggest challenges of implementing microservices solutions in the
enterprise is that organizations can’t buy a product or platform that provides a
microservices infrastructure. Instead, microservices architecture is typically a
combination of different technologies to power its different capabilities. This
approach contrasts with traditional SOA scenarios in which most requirements could
be addressed using the SOA platforms provided by enterprise software vendors.
Another obstacle encountered by microservices solutions in the enterprise is the
friction introduced by SOA frameworks and development processes. To some
extent, many organizations still struggle trying to find clear differentiators between
the traditional SOA approach and the new microservices model. To help with this
issue, we have listed some of the key differentiators between SOA and
microservices we consider relevant in enterprise solutions:
Capability SOA Microservices

Middleware Centralized ESB Lightweight, federated
Bus
Services Complex business services Small, atomic services
focus on individual use
cases
Protocols SOAP, WS-* REST and Lightweight RPC
Deployment Model Centralized Host Isolated container
infrastructure
Governance Centralized governance
based on a service
registry, repository
Federated governance
based on lightweight
discovery protocols
Development process Top-down (architect to
developer)
Bottom-up
Focus Control Speed, agility
While microservices architecture has evolved as an alternative to the limitations of
traditional SOAs, they still don’t enjoy the same level of enterprise tooling and
support as its predecessors. As a result, many organizations are still hesitant to
embrace microservices solutions. However, when implemented following best
practices microservices solutions deliver levels of agility and flexibility largely
exceeding what could be accomplished with SOA solutions.
Having implemented dozens of microservices solutions for Global 2000 companies,
we believe there are a series of capabilities and best practices that are foundational
to implement enterprise-ready microservices architecture. The next section
explores some of the key capabilities of enterprise microservices solutions.
Capabilities of Enterprise Microservices Architecture

While there is no well-established architecture reference for microservices solutions,
there are very well defined capabilities that are essential to enable these types of
solutions in the enterprise. Correctly assembling and combining these capabilities
represents a robust foundation to build enterprise-ready microservices solutions.
From the large sets of features attributed to microservices architecture, we believe
the following group is essential in any enterprise microservices solution:
 Service Discovery
 Service Description
 Lightweight Middleware
 API Gateway
 Containerization
 Data Source Partition
 Verb Partition
Service Discovery and Service Registry
Dynamically discovering services and capabilities is an essential element of
enterprise microservices architecture. Traditional SOA solutions typically rely on
centralized service registries for cataloging the services in an enterprise.
Unfortunately, the centralized service registry pattern is completely inapplicable for
environments in which tens or hundreds of microservices are constantly being
deployed across different environments.
In microservices architecture, service discovery requires decentralized, dynamic
and highly scalable models that can be adapted to different runtime topologies. In
this sense, microservices discovery should play a very similar role to DNS in
networking solutions. The following diagram illustrates this concept:

In the microservices world, the role of a service registry changes from a centralized
to a completely federated entity. The evolution of microservices architecture has
caused the evolution of different technologies that can enable service discovery at
an enterprise level.
Technologies to Enable Microservices Discovery
 Consul (https://consul.io/): Consul is a peer to peer, strongly consistent
data store that uses a gossip protocol to communicate and form dynamic
clusters. It provides a hierarchical key-value store that you can place data in
and register watches against to be notified when something changes within a
particular key space. Consul implements a full service discovery system in
the library, so you don’t need to implement your own or use a third-party
library. This includes health checks on both nodes and services. It
implements a DNS server interface, allowing you to perform service lookups
using the DNS protocol. It also allows “clients” to run as independent
processes and register/monitor services on their behalf. This removes the
need to add explicit Consul support into your applications.

 Eureka (https://github.com/Netflix/eureka): Eureka is a “mid-tier load
balancer” built by Netflix and released as open source. It is designed to allow
services to be able to register with a Eureka server and then locate each
other via that server. Eureka contains a built in load balancer which extends
its discovery capabilities to highly distributed environments. Eureka is
currently only practical in AWS environments.
 Zookeeper (https://zookeeper.apache.org/): ZooKeeper is an Apache
project providing a distributed, eventually consistent hierarchical
configuration store. ZooKeeper originated out of the world of Hadoop, where
it was built to help in the maintenance of the various components in a
Hadoop cluster. It is not a service discovery system per se, but is instead a
distributed configuration store that provides notifications to registered
clients. With this, it is possible to build a service discovery infrastructure;
however, every service must explicitly register with ZooKeeper, and the
clients must then check on the configuration.
 etcd (https://github.com/coreos/etcd): etcd is an HTTP accessible key-value
store. In this, it is similar in concept to ZooKeeper and the K/V portion of
Consul. It functions as a distributed, hierarchical configuration system, and
can be used to build a Service Discovery system. It originally grew out of the
CoreOS project, is maintained by them, and recently achieved a stable major
release. From the functional standpoint, etcd is dependent on HTTP and,
consequently, is only practical is environments in which all services are
leveraging that protocol.
Microservices Description
Understanding the capabilities of microservices is essential to streamline its
adoption in the enterprise. Like many of its distributed programming predecessors,
microservices architecture relies on description languages that illustrate the
capabilities of microservices so that they can be used by client applications. In the
case of microservices, the usage of description languages goes beyond modeling

the features of a specific microservice and includes contextual elements, such as
dependencies on other microservices, SLAs, etc.
Description languages have been the subject of passionate debates during the
evolution of movements like SOA and REST. While description languages are
undeniably effective for describing the capabilities of a service endpoint, they can
introduce unnecessary complexities when used as a proxy generation mechanism
as interoperability between different stacks becomes challenging. To avoid these
challenges, microservices architecture should leverage lightweight contracts that
describe the core capabilities of services. The following figure illustrates this
concept:

In microservices environments it is very common to have tens or hundreds of
services interacting between each other. In those scenarios, understanding which
features of a microservice are required by other microservices is essential to
guarantee the continuous evolution of a solution. To address that challenge,
microservices architecture can leverage techniques like consumer driven contracts
in which client applications describe which capabilities they require from a specific
microservice.
Technologies to Implement Microservices Description
 Swagger (http://swagger.io/): Swagger defines a standard, language-
agnostic interface to REST APIs which allows both humans and computers to
discover and understand the capabilities of the service without access to
source code, documentation, or through network traffic inspection. Swagger
has experienced a great level of adoption in the API platform space becoming
the standard of choice for describing RESTful endpoints.
 API Blueprint (https://apiblueprint.org/): API Blueprint is a documentation-
oriented API description language that can be considered the most popular
alternative to Swagger. API Blueprint relies on Markdown as the underlying
language which makes it semantically rich compared to alternatives. Even
though the project is mainly maintained by Apiary, API Blueprint enjoys a
very vibrant ecosystem of tools and extensions.
 gRPC IDL (https://thrift.apache.org/): gRPC is a next generation remote
procedure call (RPC) platform developed by Google. As part of its technology
stack, gRPC uses protocol buffers as Interface Definition Language (IDL) for
describing both the service interface and the structure of the payload
messages. It is possible to use other alternatives if desired. The gRPC IDL
provides seamless interoperability between services and clients created in
many programming languages including Java, Python, C#, Node.js, Go, etc.
Lightweight Middleware

Microservices are not exempted from the middleware requirements so common in
the enterprise. SOAs produced an entire generation of enterprise service bus (ESB)
platforms designed to broker the interaction between different service endpoints.
From the practical standpoint, ESBs aren’t only adopted to expand the
infrastructure capabilities (routing, persistence, transformation, etc) of SOA
solutions, but they also implement significant levels of logic related to specific SOA
processes. From this perspective, ESBs can be seen as the antithesis of
microservices as they become a centralized business logic broker to many services.
However, many of the middleware capabilities of traditional ESBs are still required
in microservices infrastructures and the trick becomes how to leverage these
capabilities without crossing the line into a monolithic architecture.
As an architecture style, microservices promotes the notion of “smart endpoints and
dump pipes,” or, as we preferred to call it, lightweight middleware. This type of
middleware expands the capabilities of microservices with infrastructure
components such as message persistence, message transformation, message
routing, or publish-subscribe communication, etc., while, at the same time,
maintains the business process logic in the microservices. This model keeps the
middleware infrastructure relatively lightweight and flexible enough to scale to
complex topologies. The following figure illustrates the lightweight middleware
patter in the context of microservices:

Technologies to Implement a Lightweight Middleware
From a practical standpoint, there are several technologies that can be used to
implement a lightweight microservices middleware. In our experience, the second
generation of enterprise messaging platforms, such as RabbitMQ, Kafka, or
ZeroMQ, seem to be the preferred options by most of our clients. Let’s explore
some of these options:
 RabbitMQ (https://www.rabbitmq.com/): RabbitMQ is a messaging broker
that serves as an intermediary for messaging. It gives your applications a
common platform to send and receive messages, and your messages a safe
place to live until received. Emerging as the de facto standard for cloud
messaging, RabbitMQ is used for efficient communication between servers,
applications, and devices.
 ZeroMQ (http://zeromq.org/): ZeroMQ is a high-performance asynchronous
messaging library, aimed at use in distributed or concurrent applications. It
provides a message queue, but, unlike message-oriented middleware, a

ZeroMQ system can run without a dedicated message broker. The library's
API is designed to resemble that of Berkeley sockets.
 Kafka (http://kafka.apache.org/): Created by LinkedIn, Apache Kafka is a
high performance publish-subscribe messaging platform. Kafka is designed to
allow a single cluster to serve as the central data backbone for a large
organization. It can be elastically and transparently expanded without
downtime.
Containerization of Microservices
The rapid evolution of container platforms like Docker have been one of the main
catalysts to the evolution of microservices solutions. Being able to package
microservices in portable containers simplifies the management and
operationalization requirements of microservices infrastructures. From the
functional standpoint, containers enable isolation of the infrastructure of different
microservices allowing these to evolve relatively independently. The following
diagram illustrates this concept:

The infrastructure isolation provided by containers also enables other essential
capabilities of microservices architecture such as continuous deployment and
seamless scalability. From the deployment perspective, containers allow individual
microservices to be deployed and tested without affecting other microservices.
Additionally, the isolated infrastructure provided by containers allows microservices
to be scaled independently.
Technologies for Containerizing Microservices
 Docker (https://www.docker.com ): Docker is the lead platform in the
market providing a model that enables the deployment and management of
applications inside containers. Docker enjoys a very robust ecosystem of
tools and solutions and is supported by a large number of enterprise
platforms.

 rkt (https://github.com/coreos/rkt): rkt is an alternative to the Docker
runtime, designed for server environments with the most rigorous security
and production requirements. rkt is oriented around the App Container
specification, a new set of simple and open specifications for a portable
container format.
 Kubernetes (http://kubernetes.io/): Created by Google, Kubernetes is an
open-source system for managing containerized applications across multiple
hosts in a cluster. Kubernetes is intended to make deploying
containerized/microservice-based applications easy but powerful.
API Gateway
The small granularity of microservices introduces a high degree of latency and
chattiness for client applications. For instance, a simple web or mobile application
could end up calling dozens of microservices to access the information required by a
single screen. As microservices evolve and new versions are created, the large
number of dependencies becomes incredibly fragile and challenging to maintain.
An API gateway is a server-side technology pattern that aggregates multiple
microservices and coarse level services tailored to specific client applications. From
this perspective, an API gateway can expose abstract services which reveal the
capabilities required by consumer applications. In addition to the aggregation of
microservices, the API gateway extends microservices with infrastructure
capabilities, such as data caching or instrumentation, so they can be consistently
applied across all endpoints. We can see the API Gateway pattern in the following
diagram:

Technologies to Implement a Microservices API Gateway
 Mashape’s Kong (https://getkong.org/): Kong is an open source
management platform for APIs and microservices. Kong is the engine behind
Mashape’s popular API Gateway.
 Apigee (http://apigee.com): Apigee can be considered the market leader in
API management. The current version of the Apigee Edge platform provides
many enterprise-ready capabilities relevant in microservices scenarios.
 Azure API Gateway (https://azure.microsoft.com/en-us/services/api-
management/): The Azure API Gateway is a native service in the Azure
platform to enable the publishing, security, and management of APIs and
microservices both on-premise and in the cloud.
 AWS API Gateway (https://aws.amazon.com/api-gateway/): AWS API
Gateway is a native service for API management on the AWS platform. The
service is tightly integrated with other services on the AWS platform making
it a great solution for managing microservices powered by AWS.
Inter-Service Communication
Microservices architecture exponentially increases the levels of inter-process
communication (IPC) required to accomplish specific business tasks. While REST-

based models are the most popular mechanisms for enabling microservices
communication, they are often impractical overall for internal IPC communications.
As a result, microservices architecture leverages next generation remote procedure
call (RPC) models to enable internal IPC communications. The following diagram
illustrates an example of IPC microservices communication.
While there are very well known challenges with traditional RPC architecture,
modern RPC models have made tremendous progress to avoid the pitfalls. The
complexity of IPC communication in microservices architecture expands beyond the
protocol of choice. IPC patterns such as synchronous, asynchronous, streaming,
etc., are common in large scale enterprise microservices solutions and should be
served under the same architecture.

Technologies to Enable IPC Communications
 gRPC (http://grpc.io ): Created by Google, gRPC is a high performance RPC
platform. In gRPC a client application can directly call methods on
a server application on a different machine as if it were a local object,
making it easier for you to create distributed applications and services. As in
many RPC systems, gRPC is based around the idea of defining a service,
specifying the methods that can be called remotely with their parameters and
return types. On the server side, the server implements this interface and
runs a gRPC server to handle client calls.
 Akka (http://akka.io): Akka is an open-source toolkit and runtime
simplifying the construction of concurrent and distributed applications on the
JVM. Akka supports multiple programming models for concurrency, but it
emphasizes actor-based concurrency, with inspiration drawn from Erlang.
 Apache Thrift (https://thrift.apache.org/): Thrift is an interface definition
language and binary communication protocol used to define and create
services for numerous languages. It is used as a remote procedure call (RPC)
framework and was developed at Facebook for "scalable cross-language
services development.” It combines a software stack with a code generation
engine to build services that work efficiently across a large number of
languages.
One Microservice per Data Source Strategy
Data access is one of the fundamental capabilities of microservices in the
enterprise. From this perspective, determining the right granularity of data access
capabilities of a microservice is a permanent debate when designing this type of
architecture. Typically, data access operations in a microservice are linked to a
specific data source with some relevant business context, such as contacts or
accounts. Using the data source entity as the partitioning unit for data access
microservices is a recommended practice in enterprise architecture. The following
diagram illustrates this strategy:

Architecting data access microservices around isolated data sources guarantees a
level of independence between the different services in enterprise solutions. This
model allows microservices to evolve independently around contextually bounded
concepts such as business data sources. Microservice purists will argue that each
microservice should use an independent database. While this principle is impractical
in many enterprise architectures, partitioning at the data source level offers a
simple and practical model to enable large scale data access in microservices
architecture.

Technologies to Enable the One Microservice per Data Source Strategy
 GraphQL (http://graphql.org/): Designed by Facebook, GraphQL is a query
language designed to build client applications by providing an intuitive and
flexible syntax and system for describing their data requirements and
interactions.
 OData (http://www.odata.org/): Open Data Protocol (OData) is an open
protocol which allows the creation and consumption of queryable and
interoperable RESTful APIs in a simple and standard way. OData is widely
implemented by many enterprise software platforms and is the default data
access model used by many Microsoft products.
 Falcor (http://netflix.github.io/): Created by Netflix, Falcor is a framework
for data fetching JSON resources. Falcor allows you to model all your
backend data as a single Virtual JSON object on your Node server. On the
client you work with your remote JSON object using familiar JavaScript
operations like get, set, and call. If you know your data, you know your API
for any JSON resource.
One Microservice per Use Case Strategy
In addition to data access, microservices architecture needs to enable functional
capabilities in the form of service endpoints. By functional we refer to microservices
that execute business logic as part of its operations. Typically, these types of
microservices are associated with functional use cases relevant to specific business
scenarios. From this perspective, partitioning per specific use case provides a very
pragmatic model to associate microservices with atomic business capabilities. This
concept is shown in the following figure:

Building microservices around individual use cases is an intuitive methodology for
organizing a microservices topology. Additionally, having microservices that
abstract atomic business use cases facilitates the composition of microservices to
enable more sophisticated business scenarios. Other capabilities like functional and
integration testing clearly benefit from this partitioning strategy.
Technologies to Enable the One Microservice per Use Case Strategy
 gRPC (http://grpc.io): Created by Google, gRPC is a high performance RPC
platform. In gRPC a client application can directly call methods on
a server application on a different machine as if it were a local object,
making it easier for you to create distributed applications and services. As in
many RPC systems, gRPC is based around the idea of defining a service,
specifying the methods that can be called remotely with their parameters and
return types. On the server side, the server implements this interface and
runs a gRPC server to handle client calls.

 Akka (http://akka.io): Akka is an open-source toolkit and runtime
simplifying the construction of concurrent and distributed applications on the
JVM. Akka supports multiple programming models for concurrency, but it
emphasizes actor-based concurrency, with inspiration drawn from Erlang.
 Apache Thrift (https://thrift.apache.org/): Thrift is an interface definition
language and binary communication protocol used to define and create
services for numerous languages. It is used as a remote procedure call (RPC)
framework and was developed at Facebook for "scalable cross-language
services development.” It combines a software stack with a code generation
engine to build services that work efficiently across a large number of
languages.
Microservices Monitoring
Instrumenting and monitoring microservices is an essential capability to
operationalize these solutions in the enterprise. While application performance
monitoring (APM) platforms provide the required capabilities to instrument
individual microservices, they missed some important elements needed to monitor
complete microservices architecture.
The complexity of microservices topologies can become an interesting challenge
from the observability and instrumentation perspective. Efficiently monitoring
microservices architecture requires providing some sophisticated capabilities, such
as tracing requests across microservices, and mapping requests to microservices
topologies, among others. Like other enterprise monitoring platforms, microservices
instrumentation requires a centralized endpoint that collects the runtime
information from the different microservices endpoints. The following figure
illustrates this concept:

Technologies to Enable Microservices Monitoring
 Netflix’s Atlas (https://github.com/Netflix/atlas/wiki): Atlas was
developed by Netflix to manage dimensional time series data for near real-
time operational insight. Atlas features in-memory data storage, allowing it
to gather and report very large numbers of metrics, very quickly.
 Netflix’s Hystrix (https://github.com/Netflix/Hystrix): Hystrix is a latency
and fault tolerance library designed to isolate points of access to remote
systems, services, and third-party libraries, stop cascading failure, and
enable resilience in complex distributed systems where failure is inevitable.
 Twitter’s Zipkin (https://twitter.github.io/zipkin): Created by Twitter,
Zipkin is a distributed tracing system. It helps gather timing data needed to
troubleshoot latency problems in microservice architecture. The front end is
a "waterfall" style graph of service calls showing call durations as horizontal
bars.
 Trace (http://trace.risingstack.com/): Trace is a microservice monitoring
and debugging tool that empowers you to get all the metrics you need
when operating microservices. Trace comes as both a free, open source
tool and as a hosted service.

Other Relevant Capabilities of Enterprise Microservices Architecture
Enterprise microservices architecture is relatively complex compared to some of its
predecessors in the distributed systems space. In this sense, there are many other
key capabilities that could be considered relevant to enable microservices at an
enterprise scale. In addition to the capabilities listed in the previous sections,
enterprises should consider some of the following features:
 Design for Failure: Assume that microservices solutions are going to fail all
the time and architect for an extreme level of resiliency.
 Failure Isolation: Prevent individual failures from cascading through a
microservices solution.
 Microservices Testing: Provide models to enable the functional and
integration test of microservices.
 Configuration Management: Enable highly available models to manage
configuration for microservices.
 Security: Data privacy, authentication, and access control are always
relevant capabilities of microservices.
Summary
Microservices is becoming one of the most important trends in modern enterprise
software solutions. Conceptually, microservices extend SOA with more efficient
architecture models. Implementing microservices require a cultural change in the
way that most enterprises approach software development.
This paper covered some of the best practices, technologies and patters of
enterprise microservices architectures. The paper in the fundamental building
blocks that should be considered by organizations to efficiently leverage
microservices models. The patterns and technology recommendations included in
this paper are based on our experience implementing this type of solutions for our
customers and not on any commercial affiliation with the vendors.

Microservices in the Enterprise: A Research Study and Reference Architecture

More Related Content

What's hot

Viewers also liked

Similar to Microservices in the Enterprise: A Research Study and Reference Architecture

More from Jesus Rodriguez

Recently uploaded

Microservices in the Enterprise: A Research Study and Reference Architecture