This research note is restricted to the personal use of bdole@nets.eu.

Assessing Microservices for Agile Application

Architecture and Delivery
Published: 20 March 2018 ID: G00346861

Analyst(s): Gary Olliffe

Microservices architecture is an approach for building distributed

applications that support agile and scalable delivery. Technical professionals
defining application architectures must assess the benefits and complexities
of MSA and apply it cautiously to the systems they determine need it.

Key Findings
■ Microservices architecture (MSA) is misnamed. It is not solely about architecture but also
processes, organization, culture and platforms for delivering application functionality. Adopting
MSA is a journey that starts with embracing agile development principles and practices.
■ MSA can improve development agility with deployment flexibility and feature-level scalability.
However, it is more costly and complex than delivering a more coarse-grained architecture.
Beware of vendor hype and "microservices washing" of products and services.
■ MSA combines service-oriented architecture (SOA) best practices with modern organizational
disciplines and leverages cloud-native application platforms and tooling.
■ Microservices are not your only option. Organizations that have successfully adopted
microservices are also using miniservices, macroservices and monolithic deployment
architecture. Organizations using only microservices are like unicorns — they do not exist.

Recommendations
Technical professionals responsible for application architecture should:

■ Build maturity in agile development, continuous delivery and DevOps practices before
committing to business-critical use of microservices.
■ Don't start your journey with the goal of adopting microservices. Identify measurable business
goals tied to agility, release cadence and scalability, and assess how MSA helps to meet them.
■ Apply MSA principles incrementally and pragmatically to improve application delivery by
implementing smaller, more loosely coupled services where distinct system capabilities need to
develop and evolve rapidly and independently.

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ Avoid MSA if your software will not be updated frequently over the long term. MSA has very
limited value if there is no continuous change to manage, or need for dynamic scalability.

Table of Contents

Analysis.................................................................................................................................................. 3
What Is Microservices Architecture?................................................................................................. 6
Not Just Architecture.................................................................................................................. 8
Good SOA Practices and More.................................................................................................10
What a Microservice Is Not............................................................................................................. 11
Benefits of Microservices................................................................................................................ 15
Moving Toward Microservices................................................................................................... 15
Dynamic Deployment Strategies............................................................................................... 17
Horizontal Scalability With Precision..........................................................................................19
The Challenges of Adopting MSA................................................................................................... 21
Managing Complexity............................................................................................................... 21
Two Architecture Viewpoints..................................................................................................... 23
Organizing Teams to Deliver Microservices................................................................................34
Strengths........................................................................................................................................36
Delivers Cloud-Native Applications............................................................................................37
Supports Incremental Adoption, Evolution and Coexistence..................................................... 37
Empowers Development Teams to Become Delivery Teams..................................................... 37
Supports Technology Optimization............................................................................................38
Realizes SOA Best Practices.................................................................................................... 38
Weaknesses................................................................................................................................... 38
Microservices Architecture Is Misnamed................................................................................... 39
Complexity Is Moved and Expanded, Not Removed................................................................. 39
Maturity of Microservices Technology Varies............................................................................. 40
Modernization of Application Infrastructure Is Required............................................................. 40
Microservices Have Become an Aspirational Rather Than a Rational Choice.............................40
Culture Change Is Required...................................................................................................... 41
Guidance..............................................................................................................................................42
Gartner Recommended Reading.......................................................................................................... 44

List of Figures

Page 2 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 1. Microservices Interest Continues to Rise.................................................................................. 4

Figure 2. The Diverse Marketplace for Microservices Technology............................................................ 5
Figure 3. Example of UNIX Command Composition................................................................................7
Figure 4. A Simplified View of MSA......................................................................................................... 8
Figure 5. Microservices Team Organization Should Be Aligned With Business Rather Than Technology
Capability............................................................................................................................................... 9
Figure 6. APIs Insulate Their Clients From Service Implementation Details.............................................14
Figure 7. Comparing Scalability With Monolithic and Microservices.......................................................20
Figure 8. Inner and Outer MSA............................................................................................................. 24
Figure 9. Examples of the Inner Architecture of a Microservice..............................................................26
Figure 10. Components of an Outer Architecture for MSA.................................................................... 30
Figure 11. Microservices Teams Still Need to Coordinate on Cross-Cutting Concerns.......................... 36

Analysis
Microservices architecture (MSA) is an approach for building and delivering service-oriented
applications with three primary objectives: agility of delivery, flexibility of deployment and precision
of scalability. A supplemental benefit is the ability to choose and update implementation technology
on a per-service basis.

This research helps application architects and solution architects answer the following question:

What are the benefits and challenges of adopting MSA to help

an organization improve software delivery agility?
1
The term "microservice" emerged a few years ago and gained traction in the latter half of 2013 to
describe an approach to delivering cloud-ready or cloud-native applications. The early case studies
and examples pointed to the work of Netflix, Amazon, eBay and others that had taken a radically
different approach to building and supporting their cloud-based applications. These applications
were the antithesis of monolithic applications, where entire application scopes are developed, built,
tested and deployed together.

Since then, the terms "microservice" (or "micro service") and "microservices architecture" have built
momentum and mind share among architects. This has driven improved support for microservices
use cases in both commercial and open-source tools and platforms. However, at the same time, the
hype has been fueled by vendors adopting and frequently misappropriating the term microservices
to describe their APIs, services and products. The rise of microservices has been rapid, and their
impact on application architecture and the technology market continues to grow based on Gartner's
metrics for client interactions, readership and Google Trends data, as shown in Figure 1.

Gartner, Inc. | G00346861 Page 3 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 1. Microservices Interest Continues to Rise

Source: Gartner (March 2018)

MSA has caught the attention of application architects looking to address the challenges of
improving delivery cadence and scaling their applications in cloud-based environments. As a
cautionary note, interest in microservices has also grown among organizations without these explicit
challenges. This increases the risk that this pattern is adopted for inappropriate reasons, not least
because it is heavily hyped, fashionable and will look good on an architect's or developer's
resume/CV. Understanding exactly why and how your organization will benefit from an MSA is an
important first step to adoption and shouldn't be left as an afterthought.

Along the way, a number of design practices, patterns and frameworks have been adopted by or
affiliated with this upsurge in interest around microservices. Practices such as domain-driven
2 3
design and the "twelve-factor app," along with design patterns including bounded context,
Command Query Responsibility Segregation (CQRS) and event sourcing, have helped practitioners
define the first generation of MSA. Frameworks such as Spring Boot/Cloud, Node.js, .NET Core,
Seneca, Akka and many others have been used to build and deploy microservices. The number of
frameworks available for popular application runtimes also continues to grow rapidly.

Beyond the frameworks, there are tools, platforms and services all providing capabilities to support
the development, testing, deployment and operation of MSAs. Figure 2 shows a sample of these
tools and platforms. MSA was created through an amalgamation of proven frameworks, architecture
patterns and practices, but its momentum is now driving new technologies and patterns.

Page 4 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 2. The Diverse Marketplace for Microservices Technology

Note: Representative sample of technologies

Source: Gartner (March 2018)

Gartner, Inc. | G00346861 Page 5 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

What Is Microservices Architecture?

Successfully adopting MSA relies on aligning your organization, culture and processes with the
design and architecture of your application (see "How to Succeed With Microservices Architecture
Using DevOps Practices"). At its core, MSA is a software architecture pattern in which applications
are composed of small, independently deployable processes communicating with each other using
language-agnostic APIs and protocols. Microservices have the following attributes that distinguish
them from monolithic applications and traditional SOA services:

■ Tightly scoped: Microservices should implement a single functional responsibility with the goal
of reducing development and maintenance complexity for each individual service. This makes
microservices more fine-grained than their traditional SOA predecessors.
■ Tightly encapsulated behind concrete programmatic interfaces: Microservices
implementations should be fully encapsulated behind well-defined and concrete APIs, whether
they are based on request response, message or event-based patterns. Implementations using
HTTP/REST are common due to their simplicity and ubiquity, but interfaces can also be
exposed over other protocols such as Advanced Message Queuing Protocol (AMQP), Apache
Thrift, gRPC, Protocol Buffers or Apache Avro. Monolithic SOA applications often break
encapsulation between services because it is easy to do so when multiple services are
delivered in a single codebase.
■ Highly cohesive: The capabilities provided by a single microservice should be closely related
and should share a common purpose and common data on which they act. The goal of this
cohesion is to prevent ripple effects as changes are made to a system. Cohesion is often simply
described using the phrase "things that change together, stay together." Service boundaries
should be defined to minimize the chances of any given feature change requiring coordination
between service implementation teams. This contrasts with coarse-grained services that
aggregate a number of loosely related or disparate functions and actions on multiple data
entities.
■ Responsible for managing their own data: A microservice should manage its own data
models and persistence. This helps microservices maintain encapsulation and independence
from other services and supports cohesion (code and data structures often change together).
Monolithic applications commonly have multiple services that share a single data model, which
breaks encapsulation and creates coupling of services at the data layer. This trait is one of the
most challenging for teams trying to transition from monolithic architectures to microservices.
There can be cultural and operational challenges for organizations with consolidated data
management teams, and it is a huge technical undertaking for teams decomposing monolithic
applications. Additionally, this aspect of MSA creates new challenges for aggregation of data to
support analytics and reporting at a systemwide or enterprisewide level.
■ Highly decoupled: Microservices should be very loosely coupled with each other. When they
interact, they should discover each other through configuration of the service or the runtime
environment and then only interact through the published APIs (whether request-response,
event-based or message-based). Event-driven, publish-subscribe models of interaction can be
valuable for implementing extensible decoupled interactions between services because an
event source does not need to be aware of the specific event sinks listening for its event

Page 6 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

messages. Monolithic applications tend to be highly coupled, making localized changes prone
to side effects and increased complexity.
■ Independently deployable, self-contained and autonomous: Microservices should be
deployable individually with as few external dependencies as possible, and they should be able
to function independently of other services. It should also be possible to start and stop
instances of individual services independently of all others. To be independently deployable,
microservices are often self-hosting executables, packages or container images, bundling their
own lightweight web and/or application server frameworks, rather than relying on server
application platforms preinstalled on their host environments. Traditional SOA services tend to
be deployed in large numbers in monolithic bundles of services deployed to shared application
server environments.

In addition to these properties, proponents of MSA often draw an analogy between microservices
and UNIX commands. Both are single-purpose executables that can be composed through
standard interfaces. For example, the command in Figure 3 composes three independent
executables to convert, modify and post data to a web service.

Figure 3. Example of UNIX Command Composition

JSON = JavaScript Object Notation

CSV = comma-separated values

Source: Gartner (March 2018)

In the case of UNIX commands, the standard interfaces are stdin, stdout and stderr. For
microservices, the standard interfaces can include HTTP, AMQP and other open protocols
supported by the outer architecture (that is, the architecture of the environment in which your
microservices are executed and operated).

Figure 4 shows a simplified representation of a microservices architecture environment where

services are accessed and interact through both synchronous and asynchronous APIs and where

Gartner, Inc. | G00346861 Page 7 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

each has its own data store. The structure of a typical MSA is explained in more detail in the Two
Architecture Viewpoints section.

Figure 4. A Simplified View of MSA

RDBMS = relational database management system

Source: Gartner (March 2018)

Not Just Architecture

In addition to introducing a new structural pattern for applications, adopting MSA will impact how
you organize to develop and deploy software. Traditional application architectures can be observed
4
to embody Conway's Law, which states:

Page 8 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

"Organizations which design systems ... are constrained to

produce designs which are copies of the communication
structures of these organizations."

In Figure 5, the technology-siloed teams on the left of the diagram tend to build systems with
layered architectures that represent the delivery handoffs between teams. Each team owns a layer
in the architecture rather than delivery of the business capability. MSA allows and encourages
applications to be developed and supported by cross-functional teams organized around service
capability rather than architectural tier, as shown on the right of Figure 5.

Figure 5. Microservices Team Organization Should Be Aligned With Business Rather Than Technology
Capability

Source: Gartner (March 2018)

In this model, each team typically has responsibility for the full life cycle of a service, including
operations and ongoing maintenance and enhancement. This delivery model requires process
discipline and automation to be efficient and agile. Hence, experience with continuous integration,
continuous delivery and DevOps is a prerequisite for scaling up your use of MSA successfully.

In addition to aligning teams to the functional services, the distributed and dynamic nature of MSA
is based upon those teams leveraging a platform with cloud characteristics: on-demand self-

Gartner, Inc. | G00346861 Page 9 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

service, resource elasticity, resource pooling and metered consumption. This platform may leverage
public or private cloud services but it needs to be managed by a platform ops team. The platform
ops team is responsible for deploying and operating the delivery platform used by development
teams to build and operate their services. For more details on platform ops and the platform
choices for MSA, see "Selecting a Cloud Platform for DevOps Delivery With Microservices
Architecture."

In the "2018 Planning Guide for Application Platform Strategies," Gartner describes how synergies
in platforms, processes, architectures and people lead to optimal application delivery. When the way
that you deliver and operate a solution is as important as the function of the solution, then defining
solutions involves defining architectures, processes, platforms and organization structures that
remove constraints rather than tolerate them.

Delivering and sustaining a highly dynamic distributed application environment based on

microservices requires investment. It is more costly and complex than delivering a well-structured
nondistributed application. This means that your stakeholders must see measurable value in being
able to deliver continuously and that you need to invest the investment in the necessary automation
tools and processes. In addition, this state of change should be long-term, without a foreseeable
stable state when the solution is "finished" (i.e., change is continual while the system and the
business are operational).

It is critical to note that achieving continuous delivery at scale alone does not require MSAs. Internet
giants like Facebook, Etsy and Stack Overflow, as well as more traditional enterprises like Standard
5
Bank of South Africa, have been able to create high-velocity, continuous delivery with monolithic
architecture and diligent process automation. They have also been able to scale these applications
effectively without adopting MSAs.

The organizational impact of microservices will also affect teams that are already agile (see
"Solution Path for Achieving Continuous Delivery With Agile and DevOps"). The key organizational
principle of microservices is to make teams independent — to make them the owners of their
services and accountable for the delivery and operation of those services. This runs counter to the
"shared ownership" found in frameworks for scaling agile delivery (see "Implementing Enterprise
Agile Using the Scaled Agile Framework (SAFe)"). In such cases, efficiency and productivity are
driven by being able to assign any resource to any task anywhere in the organization. In an MSA,
resources might move teams and become productive quicker due to the simplicity of individual
services. However, the service itself has a clear owner because it is not just a source code or binary
asset but an operational business capability that should be managed as a product rather than a
project.

Good SOA Practices and More

While MSA is not the same as SOA, the architecture principles of SOA are critical to the delivery of
MSA. To illustrate this, the following SOA design principles are taken from "A Guidance Framework
for Applying SOA Design Principles," first published by Gartner in 2009:

■ Service orientation: Encapsulating discrete system capabilities into IT assets that multiple
consumers can use

Page 10 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ Separation of concerns: Separating different aspects of a software system so they may

change at different rates
■ Loose coupling: Reducing dependencies between system components so that changes to one
don't adversely impact others

The MSA takes these principles and applies them with renewed vigor to meet the goals of agility
and scalability:

■ Service orientation should be applied at a granular level and is combined with the single
6
responsibility principle from object-oriented design.
■ Separation of concerns should be applied to isolate services "all the way down," including
service development, data management and runtime isolation.
■ Loose coupling is applied through well-designed APIs and interfaces. REST and event-driven
patterns are commonly used to help maintain decoupling.

These three SOA principles combine to enable a fourth principle that is critical to MSAs:
independence. Microservices must be independently developed, tested, deployed, operated and
scaled. The internal architecture of a given microservice (the "inner architectures"; see the Two
Architecture Viewpoints section for more detail) and its data model can be independently designed
and changed.

MSA is not just about "doing SOA right." Its objectives are more specific. By revisiting these core
principles and understanding how MSA applies and refines them, you can gain some of the benefits
of MSA in your traditional SOA environments without the disruption and change required to fully
embrace MSA.

What a Microservice Is Not

In the early days of MSA adoption, there was some misunderstanding of and ambiguity surrounding
the term "microservice." As the hype around the term has grown, so has the level of
misunderstanding and misuse. In some cases, this is vendors "microservice washing" their
marketing for visibility. In others, it is a reflection of the fact that microservices overlap with service-
oriented design practices and API-centric application development.

During the course of this research, we encountered the following implementations wrongly
described as microservices:

■ A simple API to a more complex service implemented as part of a monolithic application.

The design or scope of an API should be distinct from its implementation. In this case, we
would call the service a "macroservice."
■ A service implemented with a small amount of code. The amount of code is irrelevant if the
service cannot be independently deployed and operated.

Gartner, Inc. | G00346861 Page 11 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ A service built and delivered without automation of testing, deployment and operations.
MSA is an approach to optimize delivery of code to production, and operation at scale. Without
automation, the risk of human error is amplified.
■ A service built on mutable compute instances that are updated and patched separately
from software deployment. Deployment and operational predictability are key to microservices
operations. Changes to your underlying OS or runtime that do not go through the same
disciplined and automated testing and deployment processes as code changes are both hard to
repeat and introduce high risk of failure.
■ A service that has dependencies on its peers that prevent it from being changed and
updated independently. Coupling between services that cause them to require synchronized
change creates a "distributed monolith." Microservices should only have dependencies on well-
defined interfaces to other services and allow the service implementations to change
independently.
■ A large, coarse-grained service or monolithic set of services packaged in a Docker
container. Containerization does not create a microservice. It is just a software packaging and
deployment mechanism. Docker and other container models are useful tools for defining the
unit of deployment (e.g., your code and its dependencies) for a microservice, but they are not
the only approach.
■ A service exposed via API by another party. No matter how that service is implemented, if
you don't control the implementation, this is just a service as far as your application is
concerned.
■ A component, module, service or capability, labeled as a "microservice" by a vendor, over
which you do not have deployment and management control consistent with your other
microservices. Microservices washing is a common ploy to get attention from customers;
however, the benefits of MSA come from the processes and organization models it supports.
You cannot buy these benefits in a product, but you can seek out products that fit with your
approach to microservices.
■ An API published for use internally or externally to an organization. MSA is an
implementation detail that should be separated from the published interface specification. API
consumers should not know or care whether the implementation architecture uses
microservices, a more traditional application architecture or an integration platform. See
"Decision Point for Application Services Implementation Architecture" for more details.

While confusing, these abuses of the name "microservice" do not mean that these are bad
functional implementations or poor choices of architecture for the requirements. Microservices are
not a goal in themselves. They are an architecture that helps you organize for development agility
and leverage cloud capabilities for deployment automation and scalability. If you have simpler
requirements, a simpler architecture is the right choice. Start with a well-structured monolithic
application and break it down as you identify demand for increased agility and more flexible
deployment. You will be much more likely to end up with the right number of services of the right
granularity (see "How to Design Microservices for Agile Architecture").

Page 12 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

It is important not to conflate simple services that have published interfaces with MSA. It is also
important not to confuse the granularity of the API you expose to your consumers outside the
microservices implementation domain with the granularity of your services. The consumer of a
published API should be insulated from the implementation architecture of the service, as shown in
Figure 6. The client should be unaware whether the API connects to cooperating microservices,
coarse-grained miniservices or an integration platform connected to other systems.

Gartner, Inc. | G00346861 Page 13 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 6. APIs Insulate Their Clients From Service Implementation Details

Source: Gartner (March 2018)

Page 14 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

We have seen "cloud washing" of products and services that were not especially "cloudy." Similarly,
the broad interest in microservices among architects and IT leaders has driven many vendors and
teams to use "microservices washing" to generate interest and raise awareness of products,
services and tools. You should use the attributes described in the What Is Microservices
Architecture? section to determine whether a product or service is a microservice or will help you
implement MSA. Also, you must recognize that microservices are not a requirement or goal. Other
approaches can be simpler and more appropriate.

Although we can identify anti-patterns for MSA in the list above, it is important to remember that
there may be good reasons to make architectural trade-offs and relax some of the architectural
constraints of MSA. If those trade-offs are made consciously, an implementation that does not have
all the attributes of a true or pure MSA is the right choice. Analysis of your requirements may
determine that the complexities of full-blown MSA do not have a clear return on investment, or that
the process and cultural changes are not feasible within your broader organizational environment. In
these scenarios, pragmatic application of microservices principles to the delivery of APIs and
services will be the right answer for many teams.

Benefits of Microservices
The principal benefits that should lead you to pay attention to microservices are:

■ Faster delivery cadence: Microservices make your delivery life cycles more flexible by
decoupling the development and deployment of individual services, enabling agile teams to
practice continuous delivery.
■ Increased deployment flexibility: Microservices support development team organization and
deployment strategies that allow applications to evolve more dynamically, with more agility and
reduced risk.
■ More precise scalability: Microservices make your applications more scalable by allowing you
to deploy additional service instances to add capacity for specific features and by allowing you
to choose specific technologies for each microservice when necessary.

Achieving all of these benefits requires a disruptive change in organization, processes and
technology, and it will increase the overall complexity of delivering applications. But if those benefits
are critical to the success of your business, they can far outweigh the costs.

There is a further benefit accessible to all, even if you don't embrace MSA. Understanding how and
why MSA adopts certain practices and patterns can help you build and manage better service-
oriented applications and identify services that might benefit from a full-fledged microservice
approach in the future.

Moving Toward Microservices

78
Microservices have been described as the first "post-DevOps" architecture. , This means it is the
first significant new architecture paradigm to be defined since the emergence of DevOps as an
approach to IT system delivery. This term neatly sums up the fact that MSA is structured to

Gartner, Inc. | G00346861 Page 15 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

empower DevOps teams, rather than requiring that DevOps practices are retrofitted and constrained
by delivery using a pre-existing technology architecture.

As noted above, it may be possible to go "fast enough" without MSA. If your business requirement
is for faster releases to production, optimizing your monolithic deployment practices will initially give
a much better return on investment and can, with discipline, be used to support continuous delivery.

If your teams have release cadences measured in weeks or months, this should be your priority.
Release cycles measured in days are achievable with the right engineering and automation focus
(see "Solution Path for Achieving Continuous Delivery With Agile and DevOps"). Once you have your
development, automation and operations processes to the point where the architecture is holding
you back, then consider decomposing it (see "Refactor Monolithic Software to Maximize
Architectural and Delivery Agility"). Additionally, as you add more functionality, evaluate whether it
will need to change independently of the existing codebase and whether it is then a candidate for
implementation as an independently deployable service.

Aside from enabling more continuous delivery, some benefits of MSA are much harder or impossible
to achieve by "accelerating the monolith," notably:

■ Flexibility and granularity in deployment and update of technology.

■ Heterogeneous technology adoption. A monolith runs on one app platform/runtime, so there
may be some framework freedom.
■ Precision of scale. Monoliths scale in monolithic chunks, so deploying more capacity means
deploying more chunks, along with the resources to support them.

We will explore each of these in detail in the following sections.

9
The originators and early practitioners of MSA identified that monolithic applications — in which the
components and dependencies were built, integrated and tested as a monolithic unit, even when
componentized at the code/framework level — were inhibiting development agility and productivity.

These issues manifested themselves in a number of ways:

■ Development and build environments became overloaded as the monolith expanded, leading to
lower developer productivity.
■ Deployment had to be coordinated across multiple teams because the monolith was deployed
as a whole. No one could deploy any changes without the entire team being ready to deploy.
■ "Big bang" deployments increased risk and complicated rollback when issues in new code were
detected after release.
■ Development and support teams had to know the whole system. Encapsulation of logic was
technical, not organizational, and service components within monolithic applications are often
tightly coupled as a result of a shared platform.
■ Shared data and code-level object dependencies often left the door open for lazy design
shortcuts.

Page 16 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ Regression test suites for the entire system often needed to be executed for each release to
mitigate the risk of unforeseen dependencies between application components.

Organizations intent on deploying enhancements and fixes to production on a very rapid basis
(often multiple times per day) need a way to address these issues. DevOps practices described in
the following research can help with coordination and automation of the build-and-release life cycle:

■ "DevOps — Eight Simple Steps to Get It Right"

■ "Choose the Right Metrics to Drive Your Agile, DevOps and Continuous Delivery Initiatives"
■ "Using DevOps Tools for Infrastructure Automation"

However, these documents do not address the dependencies and complexities intrinsic to the
architecture of monolithic applications. Also, ensuring that application services are fully
encapsulated behind concrete interface contracts (be that RESTful, message-based or otherwise)
can help manage dependencies. But more granularity is required to provide true agility, and MSA
provides this granularity.

Adopting MSA allows various components of the system to be implemented as microservices and
delivered by independent teams working on independent life cycles, and it addresses the risks of
system dependencies. Adopting MSA can also reduce the internal complexity of each microservice.
This makes individual microservices easier to comprehend, design, build, test, and for new team
members, learn.

However, the complexity removed from service implementations is replaced by the complexities of
designing and managing a more distributed system. This distributed system will have new failure
modes that are harder to detect and diagnose. It will also be harder, if not impossible, to fully
regression-test before each update, requiring dynamic deployment practices to mitigate release risk
and allow for quality assurance in the live environment. These practices are described in more detail
in the following section.

For details on how microservices and DevOps practices must be combined, see "How to Succeed
With Microservices Architecture Using DevOps Practices." However, organizations that have
successfully adopted microservices are not using them exclusively. They have multigrained services
environments including microservices, miniservices and monolithic macroservices. The applications
that compose these services follow a pattern we call Mesh App and Service Architecture (MASA).
For more details on MASA, see "Adopt a Multigrained Mesh App and Service Architecture to Enable
Your Digital Business Technology Platform" and "Solution Path for Using Microservices Architecture
Principles to Deliver Applications."

Dynamic Deployment Strategies

Big-bang application deployments are painful because they are complex and risky. Adopting MSA
supports strategies to address both the risk and complexity.

Microservices are independently deployable. As long as interface contracts are not changed, an
individual microservice can be updated without significant coordination with its consumers.

Gartner, Inc. | G00346861 Page 17 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

However, a clear interface versioning strategy must be in place for when breaking changes are
necessary. (For more details on API versioning, see "A Guidance Framework for Designing a Great
API" and "A Guidance Framework for Creating Usable REST API Specifications.") The ability to
deploy services independently makes it easier to run different versions of a service in parallel and
adopt new strategies to mitigate risks and ensure quality of service. For example:

■ Validating a release with production traffic by routing requests to a microservice to both new
and existing implementations in parallel. This allows development teams to validate new
behavior with real requests before a new version is used to respond to production requests.
■ Minimizing impact on consumers using "canary testing" (named for miners' use of canaries to
monitor for noxious gas in the mine). This involves routing a small proportion of requests to a
new service implementation to validate that its behavior is acceptable before fully migrating.
■ Reducing deployment impact using blue-green deployment to eliminate in-place upgrades is
done by deploying a parallel instance of a microservice and redirecting requests from the old
service to the new once it is stable.
■ Rollback is implemented by redirecting requests back to the original service implementation.
However, there are issues of data consistency and compatibility that the team owning the
microservice will need to address. Although potentially complex, the encapsulation principle
and limited scope of a microservice will make this less challenging than addressing these
concerns for monolithic applications.
■ Using feature flags to control the behavior of services in the running environment. This allows
new code to be deployed before it needs to be enabled. Development teams can deploy related
code changes in an uncoordinated fashion but then enable them together.
■ Because microservices encapsulate most, if not all, of their dependencies within a single
deployable unit, they are much more easily portable to other environments. This portability is of
growing concern as the era of cloud application platforms begins in earnest (see "A Guidance
Framework for Architecting Portable Cloud and Multicloud Applications").
■ Encapsulated dependencies and externalized configuration, combined with automation, mean
that services and the compute resources, whether processes, containers or virtual machines
(VMs), can be immutable and simply be recreated or replaced when needed.

These strategies are enabled not solely by the creation of smaller, encapsulated, independently
deployable services. These flexible strategies are enabled by deploying microservices within a
capable and predictable operational environment (outer architecture). Key capabilities of this
operational environment include deployment automation, flexible routing of requests,
instrumentation, monitoring and alerting to detect issues with a level of robustness and efficiency
that make it practical to include within your deployment processes.

Your deployment platform for application services can make these dynamic deployment strategies
easier to manage. These capabilities are part of the "outer architecture" (see the Two Architecture
Viewpoints section) that supports your microservices. The platform options for implementing this
outer architecture are analyzed in detail in "Selecting a Cloud Platform for DevOps Delivery With
Microservices Architecture."

Page 18 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

The options include cloud services (platform as a service [PaaS], container infrastructure as a
service [CIaaS] and function platform as a service [fPaaS]) as well as self-managed software. Cloud
service options include PaaS offerings, such as:

■ AWS Elastic Beanstalk

■ Google App Engine
■ Heroku
■ Microsoft Azure App Service

CIaaS offerings include:

■ AWS Elastic Container Service

■ Google Kubernetes Engine (GKE)
■ Joyent's Triton Compute
■ Microsoft Azure Container Service

Self-managed software options include cloud-native applications platforms like Pivotal Cloud
Foundry and Red Hat OpenShift, and container management software like Apache Mesos,
Apprenda Cloud Platform, Docker Swarm and Kubernetes.

Horizontal Scalability With Precision

Scaling monolithic applications is hard, coarse-grained and often inefficient. Vertical scalability is
limited by the specification, availability and cost of more powerful physical infrastructure and the
ability of your application to make use of it. Horizontal scaling of monolithic applications typically
involves deploying multiple instances of your entire application or large subcomponents of it (see
Figure 7).

Gartner, Inc. | G00346861 Page 19 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 7. Comparing Scalability With Monolithic and Microservices

Source: Gartner (March 2018)

Page 20 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Horizontally scaling microservice applications happens at the service level. To scale the application,
you start additional instances of the microservices that require additional capacity, allowing you to
precisely target additional resources to the system capabilities that require it. When scaling
horizontally, instances of a microservice can be distributed across multiple hosts.

Due to their independently deployable, self-contained and autonomous nature, microservices are
easier to deploy and faster to instantiate. These attributes also allow microservices deployments to
leverage the intrinsic elasticity of cloud-based platforms (whether public or private, SaaS, PaaS, or
infrastructure as a service [IaaS]) to better use resources and react to changes on demand. Cloud-
native applications should take full advantage of cloud characteristics (e.g., elasticity, on-demand
provisioning, network accessibility and resource pooling), and MSA is reliant on these capabilities to
deliver its benefits.

Of course, we can scale traditional applications, but adding capacity typically involves multiple
steps: provisioning infrastructure, deploying and configuring application platforms, deploying
application code, and reconfiguring the application infrastructure to recognize the new capacity.
Automation can help streamline this, but new capacity is typically added in coarse-grained chunks,
even when only a small proportion of the application is actually driving the need for more resources.
This approach to scaling applications is slow and imprecise, and even with automation and
virtualization, adding capacity can take many minutes, and often much longer.

The Challenges of Adopting MSA

Adopting the basics of MSA is simple. Almost any developer can use the frameworks and platforms
available to build and deploy simple, single-purpose services that manage their own data and
encapsulate their logic behind a REST API.

However, to gain the benefits of MSA for your organization, you need to industrialize your adoption
across the software development life cycle (SDLC) and into operations. You need to be able to
coordinate multiple teams delivering multiple services, and they need to be able to efficiently and
robustly deploy and scale the services they are responsible for. You need new platform
infrastructure for your outer architecture because your legacy application servers don't fit the MSA
operating model. And this new infrastructure is part of a public or private cloud. This is the hard
part.

Managing Complexity
Individual microservices implementations are intended to be simple, self-contained executables that
are easy for developers to comprehend, develop and support. But the complexity that is removed
from your monolithic codebase has not disappeared. The complexity has just moved and, in some
cases, grown. To deliver a robust MSA with all of the benefits described in the Benefits of
Microservices section, you must:

■ Coordinate the work of multiple teams to ensure alignment around cross-cutting concerns such
as outer architecture dependencies, service interfaces, and identity management and
communications patterns.

Gartner, Inc. | G00346861 Page 21 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ Deliver, sustain and evolve a microservices infrastructure platform using a cloud service or self-
managed software and separate platform ops from service DevOps. (For more details on the
relationship between platform ops and service DevOps, see "Selecting a Cloud Platform for
DevOps Delivery With Microservices Architecture.")
■ Automate the building, testing and deployment of (potentially) many microservices.
■ Manage dependencies between services through well-defined, documented and internally
published interfaces to ensure loose coupling.
■ Manage the discovery of services and the routing of requests to different versions of a service,
often dynamically, to support seamless version transitions and rollback.
■ Dynamically manage the scaling and load balancing of each service by configuring platform
capacity, setting load-balancing rules and running more instances of the microservice.
■ Support the sharing of data between services in a way that enforces service contracts, reduces
service coupling, and maintains performance and scalability.
■ Manage heavily partitioned data that helps maintain decoupling and isolation of services but
creates the need to manage data relationships, consistency and integrity outside of the data
persistence layer.
■ Ensure observability of the environment through instrumentation, monitoring and log
aggregation to help identify bottlenecks and support diagnostics. This includes supporting
tracing of distributed transactions that may span multiple microservices using both request-
response APIs and asynchronous message-based or event-driven communications.
■ Prevent cascading failures from affecting the overall system.
■ Manage configuration across the environment.
■ Secure access to the services within your microservice application environment and from
applications consuming the published APIs that encapsulate the functionality of your
microservices. For more details, see "Building Identity Into Microservices."
■ Be acutely aware of disaster recovery (DR) and failover requirements. Resilience should be built
in and tested continuously because you cannot take a "snapshot" of the system that will be
valid for any useful period of time.
■ Embrace new approaches pragmatically. For example, event-driven design paradigms and
patterns drive looser coupling but require new developer mindsets and infrastructure to adopt
successfully. For more discussion of event-driven architecture in the context of microservices,
see "Assessing Event-Driven Middleware Technology for Modern Application Architecture" and
"How to Design Microservices for Agile Architecture."

An MSA implementation cannot ignore these complexities. For small deployments of MSA, some of
these complexities might be managed manually, but as your MSA grows, you will need an operating
environment that allows you to manage them more efficiently. So, while your inner architecture for
any given microservice is simpler than that of your monolithic application, you must be prepared for

Page 22 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

the additional complexity of distributed application services by planning the outer architecture of
your MSA.

Two Architecture Viewpoints

The reorganization of complexity that comes with MSA can be understood by viewing the
architecture from two perspectives:

■ The inner architecture: The software architecture of an individual microservice and what it
exposes to the outside world. Defined by DevOps teams building and running services.
■ The outer architecture: The architecture of the microservices infrastructure that provides an
operating environment and distributed management platform on which your microservices will
be built, deployed and executed. Delivered and operated by platform ops to support the work of
DevOps teams.

Conceptually, your choice or definition of inner architecture and outer architecture is independent.
But practically, there is a close relationship between the two, and you should not define them in
isolation.

Figure 8 shows the relationship between the inner and outer architecture viewpoints.

Gartner, Inc. | G00346861 Page 23 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 8. Inner and Outer MSA

AuthN/AuthZ = authentication/authorization

Source: Gartner (March 2018)

Inner Architecture

The inner architecture defines the implementation structure of each microservice. This inner
architecture implements services that follow the single responsibility principle and supports the
delivery of the service as a loosely coupled, self-contained unit of deployment.

The technical decoupling of services means that each can adopt a unique internal architecture best
suited to the capability it delivers. This can be taken to the extreme of choosing specific
implementation technology for each microservice because all interactions with the service use
standardized communication protocols and interfaces. For instance, one microservice might be
written with Java using the Spring Boot framework, while others may be implemented using
Node.js, Go or Scala. Because the inner architecture of each microservice is encapsulated,

Page 24 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

implementation knowledge isn't required for one microservice to use another. This encourages
development teams to use the optimal technology stack for each implementation. The
microservices share interface contracts based on network-based protocols and formats, not code.

However, this does not mean that every microservice should be conceived independently without an
architectural baseline. If you adopt MSA, you should adopt or define a strongly opinionated inner
architecture stack that will drive consistency for common requirements but not constrain developers
to it when there is good justification for evaluating and adopting alternatives. For example, a
nonblocking runtime may prove significantly more efficient for certain tasks. A functional
programming language may be much more productive for implementing certain classes of
algorithm.

Remember that any diversity you introduce could add complexity to the outer architecture, for
example, demanding service mesh or build automation features that work across all of your inner
architecture stacks and runtimes. Figure 9 shows four common examples of inner architecture.

Gartner, Inc. | G00346861 Page 25 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 9. Examples of the Inner Architecture of a Microservice

Source: Gartner (March 2018)

Page 26 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

The examples of different inner architectures shown in Figure 9 are not exhaustive, but show some
of the most common patterns:

■ Basic persistence: This microservice has its own encapsulated data persistence. When that
persisted data changes, it emits events to notify other services. Note that the persistence
mechanism is scoped within the service and is shared by service instances to allow the service
implementation to be stateless.
■ Externalized persistence: This microservice uses an external service to provide persistence.
This could be another business service with persistence capabilities or a dedicated data
persistence service available in the deployment environment (e.g., a NoSQL data store). When a
dedicated data persistence service is used, it is critical that the data persisted is scoped and
isolated to the microservice that owns it.
■ Command Query Responsibility Segregation: This microservice uses the CQRS pattern to
optimize the implementation of a service that has different nonfunctional requirements for read
and write behavior. The interface to the service is split between commands that trigger
modifications or changes in state and queries that provide read access to the state of resources
managed by the service. This model is typically used to support services with significantly
higher performance and capacity requirements for reading data than for writing data. Because
the service implementation is split, the design, data model and number of instances of the
implementation supporting queries are independent of the implementation supporting
commands.
■ Event handler: This microservice is only triggered through subscription to a topic on the
messaging channel. Scalability is implemented using the "competing consumers" pattern
against a shared subscription. The microservice may also emit new events to the messaging
channel to notify other services of changes in state, such as completion of processing.

In addition to the CQRS pattern described above, the inner architecture of microservices will often
leverage one or more of the following patterns associated with managing communications and data
in distributed systems:

■ Bounded context: Used to define service/domain boundaries and the explicit relationships with
other domains. Bounded context is often implemented along with the publish/subscribe pattern
to help microservices that need to share data maintain replicas of the necessary data as it is
modified. Bounded context is a fundamental design pattern for microservices that helps to
ensure loose coupling and independence through encapsulated data and explicit data
relationships.
■ Publish/subscribe: Used to support distribution of microservice-level events among services to
choreograph processes that span service boundaries and to support loosely coupled
extensibility.
■ Event sourcing: Used to manage application state by storing it as a complete history of events
associated with the resources managed by a given microservice. This allows the state to be
reconstituted to provide different views of a resource. It also allows for replay of events to

Gartner, Inc. | G00346861 Page 27 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

rebuild the state of the microservice, such as when deploying a new version whose data
persistence store needs to be reconstituted.
■ 10 11
Tolerant reader: Used to implement Postel's Law (also known as the robustness principle). It
encourages consumers to use only the elements of a message or record that they need, and to
be tolerant of changes to the elements and structure they don't use.
■ Asynchronous request response: Used to prevent a requesting client from blocking while a
request is processed. The response is received and processed independently. "Fire and forget"
is a specialization of this pattern where a response is not required.

In addition to these common patterns, it is also important to recognize that MSA is not set in stone.
There is a distinction between dogmatic application of complex, best-practice technical patterns
and pragmatic execution that trades some agility and scalability for simplicity or fit with the skills
and tools available. For example, adopting event-driven asynchronous patterns to allow loose
coupling, improved responsiveness and scalability is the commonly agreed best practice and best
fit for communication between microservices.
12 13 14 15 16 17 18
However, evidence in the public domain , , , , , , and in Gartner interactions with clients and
vendors indicates that a significant majority of existing microservices implementations make an
architectural trade-off and use synchronous request/response communication patterns extensively.
These implementations often use REST over HTTP and are occasionally optimized using more
efficient protocols like gRPC and Thrift. Event-driven patterns are still increasing in awareness,
relevance and adoption. The trade-off is that they introduce new challenges for designers and
developers who must learn and apply less widely understood patterns and practices (for more
discussion of event-driven architecture [EDA], see "Assessing Event-Driven Middleware Technology
for Modern Application Architecture").

Units of Deployment

The most important technical decision for the inner architecture of your microservices is defining
your preferred unit of deployment because it defines how microservices are packaged, deployed
and executed. Of course, one of the benefits of microservices is that each microservice is
encapsulated behind a concrete interface. Different services can use different technologies; but
starting with a consistent technology for your unit of deployment is strongly recommended.

These units of deployment should support the scaling out of a microservice by executing more
units/instances. In most cases, you will need to host multiple microservices instances per
underlying OS instance and support deployment across multiple OS instances.

Currently, most common examples of units of deployment are self-hosting packages, which include
the "server" container for HTTP APIs, any frameworks required for asynchronous messaging, and
other runtime dependencies. This could be bundled into an executable or a single executable
"package" for execution using a runtime engine. Common technologies used to create these units
of deployment for microservices include Java Archive (JAR) files built using the Dropwizard or
Spring Boot framework stacks, self-hosting .NET Core executables or Node.js bundles.

Page 28 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Although an OS-level process is a convenient unit of deployment and isolation, the ability to
individually manage and isolate service instances is the fundamental requirement. This can be
supported using alternative approaches, such as:

■ Packaging and deploying the application to a public or private application platform as a service
(aPaaS) environment
■ Packaging the service as a stand-alone server application with an embedded web or app server
■ Packaging as an OS container image (e.g., using Docker)
■ Packaging as a lightweight OS image that bundles your service and its application
dependencies

These choices will be influenced by your target deployment platform and by your choice of outer
architecture. However, in all cases, it is important that you consider your units of deployment
immutable. That is, to change the implementation or patch the runtime, you create a new version
rather than updating existing packages. This change in approach also impacts configuration
management in infrastructure and operations (I&O) teams, where compute capacity becomes a
fungible commodity and deployment of patches involves rolling redeployments.

Outer Architecture

As we decompose our application functionality into simpler, self-contained microservices, the

complexity that once lived in monolithic service and application implementations does not
disappear. The distribution of functionality inherent in MSA and the need to support rapid
development, delivery and scalability mean that overall complexity is actually likely to increase.

This complexity moves to what we call the "outer architecture." As you adopt MSA, you will need to
define the components of your own outer architecture to help you manage the development,
testing, deployment, operations and interactions with (and between) your microservices. Figure 10
shows components of an outer architecture for MSA.

Gartner, Inc. | G00346861 Page 29 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 10. Components of an Outer Architecture for MSA

Source: Gartner (March 2018)

As shown in Figure 10, this outer architecture has a number of responsibilities that can be used to
deliver successful systems using MSA. The more complex your use of MSA becomes, the more
critical these capabilities will be to the ongoing stability and smooth running of the microservices.
For example:

■ Managed containers: Your individual service instances need a context in which to operate. The
managed containers, whether implemented as virtual machines, Docker containers or
orchestrated processes, provide this capability. This component provides instance management
and orchestration, spinning up new instances as needed and managing the life cycle of
individual instances.

Page 30 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ External gateway: Your MSA implementation is likely to expose its capabilities in the form of
APIs to be consumed by business apps and applications. The service external gateway
manages access to these services and helps to protect the microservices environment by
enforcing traffic management and security policy. The external gateway functionality is often
implemented using API management products (see "Guidance Framework for Evaluating API
Management Solutions" for more details on API management). The service gateway also
supports the use of the software-defined application services (SDAS) architecture design
pattern to separate service consumption from service implementation. The external API
gateway may also be supplemented by internal microgateways to control service to service
communication. These microgateways provide some of the service mesh capabilities.
■ Service mesh capabilities: The service mesh consists of capabilities to help keep
communications between services loosely coupled, reliable and flexible. These capabilities help
decouple services, support versioning strategies and manage elastic scalability under load.
■ Service routing: Requests, whether from a client application or between microservices,
need to be routed to the right microservice, based on configuration and policy.
■ Load balancing: Instances of each microservice need to be load-balanced to support
scalability, and the granularity and configuration of load balancing need to be controlled by
the teams managing each service.
■ Service discovery: Services need to be discoverable in a loosely coupled manner. Service
discovery is typically implemented using a service registry, within which microservices
owners can register and configure the information needed by other services to locate and
invoke them at runtime. You can think of this as analogous to DNS at the network level.
Service discovery also helps to manage the dependencies that will exist between
microservices, and it becomes critical when managing change in the environment.
■ Configuration store: Service instances will need to share configurations associated with
both the microservice and the overall environment. For example, a microservice deployed
into an environment needs a way to learn where the service discovery registry is and where
it should emit log events to. Note that, due to the distributed nature of a microservice
environment, this is often implemented using a distributed key-value store.
■ Identity provider: Service instances should communicate using trusted identities (see
"Building Identity Into Microservices"). The service mesh will enable the provision and
validation of these identities. This may include integration with an external identity provider
or directory.
■ Service image registry: Somewhere within your environment will be a registry to store the
immutable images of your built and tested services. The technology used for this store will
depend on the unit of deployment you use. It could be a code repository (for dynamically
generated services), a Docker image registry, a binary artifact repository or binary large object
(BLOB)-based storage for VM images.
■ Message-oriented middleware: The simplest MSA implementation might be sustainable using
synchronous protocols like HTTP or more efficient protocols like gRPC or Thrift. However, most

Gartner, Inc. | G00346861 Page 31 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

MSAs will also need an asynchronous messaging channel to support event- and message-
driven patterns, such as publish/subscribe and fire-and-forget.
■ Build and test automation: The development agility benefits of MSA require a high degree of
build and test automation in the development cycle to maximize the quality of development
output and to streamline its delivery.
■ Deployment automation: For development agility benefits to be fully realized, deployment
needs to be automated. You must not only automate the deployment of new or enhanced
microservices, but also support automation of changes in the outer architecture itself (e.g.,
updating service routing, load balancing, service discovery and service configuration data as
part of the deployment).
■ Platform automation: To realize the runtime scalability and adaptability benefits of
microservices, the outer architecture must include support for automation associated with the
underlying platform. This includes provisioning of VMs or containers, as well as managing the
running instances of each microservice.
■ Monitoring and alerting: A distributed environment increases the complexity of monitoring and
alerting when issues occur within the environment. The outer architecture should provide the
capabilities to do this consistently and efficiently.
■ Logging and diagnostics: When an issue occurs in a distributed environment, it can be difficult
to identify and isolate the root cause. By supporting detailed instrumentation and diagnostic
analysis, including tracing of distributed processes, the outer architecture can help
microservices teams triage and resolve issues more quickly.
■ Identity provision: Externalizing authentication and authorization using a token-based service
is strongly advised to ensure secure consumer-to-service and service-to-service interactions.

Choosing a Platform for Your Outer Architecture

Your microservices need an environment to execute in and to provide these supporting capabilities.
Gartner recommends you begin by using an aPaaS to implement microservice outer architecture.
However, there are a number of ways to deliver this environment, which represent a trade-off
between simplicity with the risk of lock-in and complexity with the burden of support. They include:

■ Application platform as a service: aPaaS platforms provide the most commercialized set of
"outer architecture" capabilities today. However, this varies by provider and platform.
Capabilities supported typically include provisioning and operations automation, service
repository, monitoring, service routing, load balancing, service configuration and service
discovery. Although an aPaaS can help you speed up initial adoption of MSA, you should be
aware of the risk of lock-in, particularly as you build the outer architecture and integrate it into
your development, deployment, testing and operational processes. Examples include platforms
like AWS Elastic Beanstalk, Google App Engine, IBM Cloud Foundry, Microsoft Azure App
Service, and Red Hat OpenShift Online and Dedicated.
■ Cloud-native application platforms: These platforms deliver PaaS-like capabilities on
infrastructure that you manage, whether in your own data center or using IaaS. The same

Page 32 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

cautions apply no matter how you gain portability of the platform between cloud and hosting
providers. Examples include Pivotal Cloud Foundry, Red Hat OpenShift Container Platform and
Apprenda. For more details, see "Comparing Leading Cloud-Native Application Platforms:
Pivotal Cloud Foundry and Red Hat OpenShift."
■ Container infrastructure as a service (CIaaS): Sitting between full-featured aPaaS and self-
hosted container management software are a growing number of container-centric, lightweight
container hosting services. These provide more service- and application-centric management
and operations tools than the container management frameworks, but they do not include many
of the platform services for developers offered by a full-featured aPaaS. Examples of this
include Docker Cloud, Joyent's Triton, Amazon Web Services (AWS) Elastic Container Service
(ECS), Google Kubernetes Engine and Microsoft Azure Container Service.
■ Container management software: Using containers (e.g., containers created and managed
using Docker) as the unit of deployment is popular because they provide a lightweight and
flexible mechanism for packaging executables and their dependencies. Container management
software also provides support for deployment automation and some platform management
and monitoring capabilities. Container management software, such as Google's open-source
19
Kubernetes project, Apache Mesos, Apcera and Docker Swarm, add features like simplified
port mapping and scaling, but for many capabilities, you will need to add other tools and
frameworks to your outer architecture. For more detailed analysis, see the following Gartner
research:
■ "Orchestrating Container-Based Cloud and Microservice Applications"
■ "Assessing Container Management Frameworks Running On-Premises and in the Cloud"
■ "Using Kubernetes to Orchestrate Docker Container-Based Cloud and Microservices
Applications"
■ Function Paas (fPaaS) and fPaaS frameworks: When Amazon Web Services launched its
Lambda service, it created a new category of PaaS, which we now refer to as "function PaaS"
(fPaaS), in which there are no running instances of services. A service is defined as a single
function that is provisioned and executed on demand in a completely stateless and, from the
point of view of the developer, serverless architecture. Similar capabilities from Microsoft (Azure
Functions), IBM (Apache OpenWhisk) and Google (Google Cloud Functions) have been
launched to compete for this market of on-demand compute capacity. Although appealing as a
lightweight model of service hosting, these services are still maturing, and best practices for
deploying and managing them at scale are evolving, so they should be evaluated with caution.
fPaaS frameworks provide the tools to self-host similar capabilities. The adoption of these in the
enterprise is even less mature than fPaaS. Examples include OpenWhisk (on which the IBM
Cloud Functions service is based), Fission, Galactic Fog Gestalt, Iron-io IronFunctionsand
OpenFaaS.
■ Microservices application frameworks: The rise of microservices and the ensuing demand
from developers for tools to make the creation of these architectures easier have led to the
emergence of a number of frameworks. These are targeted at developers and provide not just
runtime capabilities but also the libraries and templates to support development of fine-grained

Gartner, Inc. | G00346861 Page 33 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

services using MSA patterns. Examples of this include Microsoft's frameworks for Azure Service
Fabric, Lightbend's Lagom, and Spring Cloud (which integrates many of the Netflix OSS tools).
Although these frameworks provide some outer architecture capabilities, they still need to be
combined with an appropriate deployment infrastructure such as IaaS, aPaaS or container
management to complete an outer architecture implementation. For more details, see
"Assessing Microsoft Azure Service Fabric for DevOps and Microservice Architecture."

At present, the market for microservices tools and platforms is fragmented. A few vendors aspire to
provide a full, opinionated platform stack that covers a majority of the outer architecture
capabilities. However, most platform and framework providers focus on a subset of features, and
legions of open-source projects and startup vendors are providing niche solutions for independent
capabilities. As a result of this state of the market, teams adopting MSA must plan to compose their
overall outer architecture and evolve it over time as the market and available capabilities mature. For
a comparison of their advantages and disadvantages, see "Selecting a Cloud Platform for DevOps
Delivery With Microservice Architecture."

Concrete demand (as opposed to wishful thinking by bored architects) for microservices in the
enterprise is growing based on adoption of digital business practices. Thus, the need for
microservices platforms or stacks that are cohesive and easier to adopt and support will also grow.
Gartner believes there will be consolidation and convergence in the market to support this.

Organizing Teams to Deliver Microservices

20
Conway's Law is often cited by microservices advocates when describing the drawbacks of
traditional application delivery organizations and the "monolithic" applications that they have
historically delivered and supported. Conway's Law postulates that an organization will design
systems that have a structure that approximates the organization's own communications structure.

For example, a team organized around the platform tiers in a traditional architecture will inevitably
produce a system structured in such a way. In distributed, cloud-ready applications, aligning teams
around the UI, application logic, application middleware, data and infrastructure layers becomes an
inhibitor to scalability of the teams. It gets harder to manage each tier and its relationship to the
other tiers as the system gets bigger and more complex.

Even more mature agile delivery teams will find some challenges with the model of delivery for
microservices. Frameworks for scaling agile development like SAFe (see "Implementing Enterprise
Agile Using the Scaled Agile Framework (SAFe)") and Large Scale Scrum (LeSS) advocate shared
ownership of code assets for optimal deployment of resources across a large application delivery
organization. That is, they advocate standardization and consistency to enable resources to be
deployed where there is work to be done. Productivity is the goal.

By contrast, microservices delivery teams are organized for speed of delivery (see Figure 11). They
are:

■ Organized around the services they deliver: Teams are structured to reflect the service
boundaries of the system, rather than arbitrary vertical or horizontal delineation of capabilities
on an architecture diagram.

Page 34 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

■ Coordinated with teams delivering other microservices: Although their release cycles are no
longer coupled, there is still a need to manage dependencies between services and to
coordinate on the evolution of the interfaces and contracts each service exposes. In essence,
the teams become both providers and consumers to each other.
■ Collaborating across teams: Although independently responsible for "their" microservices,
teams must not work in isolation. There should be established communities around the "outer
architecture" features.
■ Focused on delivering products, not projects: Teams adopting microservices need to change
their delivery focus and treat the services they implement as products rather than treating each
tranche of work as a discrete project with a beginning and end. See "A Guidance Framework for
Designing a Great Web API" for further discussion on how to take a product-centric approach to
delivering application services.
■ Responsible for the full delivery life cycle of the service: The term "carry the pager" is often
used to emphasize that microservices delivery teams are independently responsible for the
services they deliver. Microservices concepts were born from a desire for an architectural model
that supports DevOps. If your microservice teams know that any failures will impact them
directly, it will encourage team discipline and robust implementation.

Gartner, Inc. | G00346861 Page 35 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Figure 11. Microservices Teams Still Need to Coordinate on Cross-Cutting Concerns

Source: Gartner (March 2018)

Strengths
The strengths of the MSA relate back to the two primary objectives of the architecture: agility of
delivery and flexibility of deployment. New benefits (and strengths) may emerge as the tooling,
frameworks and platforms evolve to more fully support the requirements described in the Inner
Architecture and Outer Architecture sections. But for now, the strengths of MSA can be summarized
as follows:

■ Delivers applications that truly leverage cloud platform capabilities

■ Supports incremental adoption, evolution and coexistence
■ Empowers development teams to become delivery teams
■ Improves agility beyond what is possible through process alone
■ Supports technology optimization
■ Realizes SOA best practices

Page 36 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Delivers Cloud-Native Applications

By applying MSA, you can build distributable application services that can be scaled in a granular,
flexible and dynamic manner that realizes the full benefits of cloud elasticity when deployed into an
appropriate environment.

As more application workloads migrate to public- or private-cloud-based platforms, the

opportunities to benefit from MSA will increase accordingly. This will drive broader relevance and
adoption of the pattern in enterprise IT environments. When assessing your existing application's
ability to leverage cloud platform capabilities, use the guidance provided by "How to Assess Your
Application to Adopt Cloud-Native Architecture."

Supports Incremental Adoption, Evolution and Coexistence

MSA is not an all-or-nothing approach. Not everything has to be a microservice. Capabilities
developed and deployed as microservices can be consumed by applications and services with
more traditional architectures. In fact, you should choose the implementation architecture for all
services based on their functional and nonfunctional requirements. For more details, see "Solution
Path for Using Microservices Architecture Principles to Deliver Applications" and "Decision Point for
Application Services Implementation Architecture."

MSA also allows microservices to evolve independently and incrementally, thus reducing the need
for risky "big bang" platform upgrades and product releases. For further information on this
incremental approach, see "How to Design Microservices for Agile Architecture."

Adopting microservices successfully affects your architecture (including data, identity, security and
integration architecture). It also impacts your application platform selection, development methods,
operational processes, organization structure and culture. It is a major undertaking and should not
be taken lightly. For details of this overall transformation required to embrace MSA, see "How to
Succeed With Microservice Architecture Using DevOps Practices."

Extracting the business value from MSA requires a commitment from multiple stakeholders in your
IT organization as well as alignment with business objectives and outcomes. It is not a decision that
only affects your application development organization. Given this need for broad buy-in, it is better
to start small and demonstrate the benefits of the model rather than seeking broad consensus first.

Empowers Development Teams to Become Delivery Teams

DevOps teams need to support service delivery, including development and operations. By
decomposing systems into more granular capabilities to deploy and operate, MSA decouples
development life cycles and empowers development teams to take responsibility for the
deployment and operations of the individual services they deliver and accountability for the services
provided.

This approach enables DevOps and development activity to scale out. Some teams will gladly
accept this new responsibility, but it is essential that they are empowered to make the
implementation decisions needed for success and understand that they are accountable for

Gartner, Inc. | G00346861 Page 37 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

providing the services they own. This responsibility includes making the right choice of technologies
for service implementation, and it may include justified exceptions from the preferred approach. For
organizations considering MSA, the readiness to change the organizations, resources and culture is
a critical factor in success. See "How to Succeed With Microservice Architecture Using DevOps
Practices" and "How to Build Effective Microservices Teams."

Supports Technology Optimization

Adopting MSA allows you to choose the right technology and tooling to support specific services.
You should aim for as much consistency as possible across services. However, microservices
attributes mean that if you have a capability that is limited by your standard stack, you can adopt an
alternative programming language, use an event-driven server or use an in-memory data grid. The
limited scope of each service limits the impact of the change. The dynamic deployment capabilities
can also let you validate that your new service implementation is both functionally equivalent to and
better-performing than the original (see "How to Design Microservices for Agile Architecture").

Realizes SOA Best Practices

Microservices principles and practices can be applied to traditional SOA implementation activities,
even if your requirements are not a good fit for microservices or you are not ready to commit to
MSA. There is very little that is brand new or unproven under the microservices banner, and much
that represents best practice, whether your teams are building microservices or "macroservices."
For example, adopting the principles of "single responsibility" and "independent deployability"
promoted by MSA can help improve delivery in your SOA environment. MSA will continue to mature,
and the natural evolutionary cycle is likely to bring more robust tooling, frameworks and standards
to MSA, some of which will have similarities to existing SOA standards. Do not ignore the evolution
of MSA, even if you do not yet see a need to apply it.

Weaknesses
MSA is not a panacea. It is not suitable for all teams or applications — far from it. Despite the
growing hype and interest in microservices, their suitability and applicability remain quite
specialized, and adopting them should be approached with some caution. The weaknesses of MSA
can be summarized as follows:

■ Microservices architecture is misnamed

■ Complexity is moved, not removed
■ Maturity of microservices technology varies
■ Modernization of application infrastructure is required
■ Microservices have become an aspirational rather than rational choice
■ Culture change is required

Page 38 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Microservices Architecture Is Misnamed

There is such a thing as "microservice technical architecture." It is the decomposition of
functionality into independently deployable, loosely coupled services and the technology to support
them. But adopting MSA impacts so much more than "the architecture" of your applications that it
should be called "microservices methodology" or "microservices practice."

Embracing MSA should be just part of your journey toward continuous delivery of business
capabilities. We recommend you follow the "Solution Path for Achieving Continuous Delivery With
Agile and DevOps" to ensure that you have the prerequisites in place before focusing on the
specifics of microservice delivery. These are explained in "How to Succeed With Microservice
Architecture Using DevOps Practices."

In addition to these broad challenges of optimally aligning architecture, platform, processes and
people, the "micro" of microservices is also misnamed. The services each will only represent a
fraction of a system's functionality, and some may be "micro" relative to what you might previously
have built and deployed. However, many of your services will still have complex implementations
and operational requirements to deal with. You (and all the "unicorn" organizations using
microservices that preceded you) will, in reality, have a fleet of multigrained services, with different
paces of change.

The good news is that the term microservices has given us critical mass of interest in and
understanding of a set of very powerful patterns and practices that might otherwise have remained
the trade secret of a few. You just need to wield that power wisely and pragmatically for it to be
beneficial to your organization.

Complexity Is Moved and Expanded, Not Removed

As we have seen, the outer architecture required to fully realize the development, deployment and
operational scalability and agility that MSA can support is highly complex. The complexity of our
monolithic applications has not been eliminated. Instead, it has moved, and new complexities of
building and managing highly distributed application services have been introduced.

To manage this complexity, extensive component management, orchestration and automation

capabilities are needed throughout the service life cycle and across hosting and application
platforms. The application data also becomes harder to manage because it is fragmented between
microservices and transactions that cross service boundaries. These must be coordinated, often
without the help of protocols that support two-phase commit.

Thus, complexity is now moved to a place where most teams understand it less and must use new
tools and technologies to build expertise and experience. Additionally, as the number of
microservices in the environment increases, the complexity of governing those services and
controlling proliferation and duplication of microservices will increase significantly.

These new complexities will translate into costs in the form of effort, tools and platforms to manage
the complexity. This is the investment required to reap MSA's agility, scalability and flexibility
benefits.

Gartner, Inc. | G00346861 Page 39 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Behind the hype and excitement, MSA is still unproven across a spectrum of scenarios in the long
term. We still have much to learn about the factors that make microservices a suitable approach
and about the point at which the complexity has a negative impact that outweighs the benefits. It is
clear that not every organization delivering application services is a Netflix, eBay, Amazon or
SoundCloud.

Maturity of Microservices Technology Varies

The MSA pattern is still maturing. Some of the tools and frameworks that directly or indirectly
support it are relatively mature, but many are still evolving (and emerging). Although aPaaS
platforms come close, they are still general-purpose platforms to which capabilities like service
discovery, telemetry and an API gateway must be added. There is currently no holistic, commercially
supported "microservices platform" that brings together all of the necessary outer architecture
capabilities. Tools like IBM Microservice Builder, Lightbend's Lagom, Macaw.io and Microsoft Azure
Service Fabric come close but are strongly opinionated about inner architecture or lack some outer
architecture features. Service mesh frameworks like Conduit, Istio and Linkerd also continue to
evolve and mature, providing even more choice in how service discovery, routing, load balancing,
tracing, security and identity are implemented.

This means that you will need to complete your own outer architecture, and it will likely be unique to
your organization. You should plan for it to change and mature rapidly as you deploy and update
platform components and capabilities. For more details, see "Selecting a Cloud Platform for
DevOps Delivery With Microservice Architecture."

How this situation evolves will depend heavily on the patterns of adoption among enterprise
organizations and on whether a market for microservices technology and tooling fully emerges.

Modernization of Application Infrastructure Is Required

You should not try to run an MSA on your existing Java Platform, Enterprise Edition (Java EE)
application server or Internet Information Services (IIS) for Windows Server infrastructure. MSA
requires an embedded server to achieve autonomy of service instances and to support cloud
deployment. You also need "outer architecture" capabilities to drive automation and management of
services, and the tools you need to modernize toward have "mixed maturity" and a good deal of
diversity.

This diversity is driven by the variety of options for how to package your microservices and at what
level to isolate and manage them. Fortunately, much of the technology is open-source, and as such,
requires limited financial commitment as organizations explore the different options as the
technology matures.

Microservices Have Become an Aspirational Rather Than a Rational Choice

The hype surrounding microservices has driven it to the point where it is hard to find guidance on
the alternatives. It may also be hard to find application architects who will recommend anything
else. This is because microservices have become aspirational. Individuals, teams and whole
organizations are aspiring to be "like Netflix" (or Uber, SoundCloud, or any one of the organizations

Page 40 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

that have publicized their successes). For now, it is like a brand with credibility and prestige,
something that consumers are willing to pay a premium for to emulate their heroes.

This does not make MSA a bad architecture. It simply raises the risk of it being promoted and
chosen over more suitable and pragmatic approaches. For example, as you learn more about MSA,
you may realize you have already been adhering to some of the microservice principles, and you
might have been applying some of the patterns. There are two paths open to you. One is continued,
pragmatic adoption of the patterns and principles associated with microservices to deliver more
coarse-grained and less rapidly changing services. The other is more dogmatic adoption of fine-
grained microservices in line with business objectives and demand for continuous delivery of new
features to your application domains.

The latter path requires significant (and for many enterprises, new) engineering skills and resources
along with the process and culture change required to support a highly dynamic development and
operation environment. But the reward is that MSA can be a "force multiplier" for agile delivery and
deployment flexibility.

In our research to date, most examples of dogmatic fine-grained MSA found outside of startups and
technology-led organizations were either supported by professional services expertise or were led
by very competent, persuasive and trusted technology evangelists. These individuals were able to
garner resources and financial commitment from IT leadership. This evangelist/leadership role is
critical to driving such an initiative. Pragmatic and more gradual adoption of microservice principles
and practices is much more accessible and much more likely to lead to success for teams with a
good foundation in SOA, APIs and agile development.

MSA has been a bottom-up, grassroots-driven trend, now embraced by a whole marketplace. As a
result, the definitions of "microservices" among technical professionals and vendors are myriad. If
you are sourcing MSA expertise or technology, make sure your definition of and goals for MSA align
with the experience of potential resources. Be prepared to invest in learning microservices through
training, research and experimentation. Consider getting help from an experienced third party to
mitigate risk and accelerate your learning if you see a short-term opportunity that is a strong fit for
the benefits and strengths of MSA. See "Solution Path for Using Microservices Architecture
Principles to Deliver Applications" for additional guidance on adopting MSA in a pragmatic way.

Culture Change Is Required

MSA advocates a dedicated team responsible for each microservice. With this responsibility comes
accountability for the day-to-day operations and ongoing support of that microservice. This is
frequently articulated by saying that development teams must be ready to "carry the pager," that is,
be continually on call for issues with their service.

However, this is not solely about being on call. It is also a motivator for development teams to
ensure that the quality and robustness of their microservices avoid being woken up at 3 a.m. by an
alert. In addition to culture change for developers, there is impact on I&O's role, especially where
MSA is deployed internally or where I&O acts as a broker for cloud services used within an MSA.

Gartner, Inc. | G00346861 Page 41 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

MSA also requires a very mature delivery team. Adoption of continuous delivery should come before
microservices. Discipline is still required to adhere to design patterns and SOA principles. MSA is
commonly a grassroots concept that ripples through the organization, much like agile development
did. For teams that are already self-organizing through agile and DevOps, adoption of the
nontechnical changes might not be too hard, but for traditional application development teams,
adoption of MSA will require significant cultural change. See "How to Succeed With Microservice
Architecture Using DevOps Practices" and "How to Build Effective Microservices Teams."

Guidance
Microservices and MSA are no longer new terminologies, and they continue to evolve and mature
into more broadly applicable practices for efficiently delivering flexible, scalable, distributed
applications. They are still subject to a great deal of hype and excitement in the architecture
community. However, at their core, they are an approach based on proven principles and best
practices, combined to address a set of emerging needs for cloud-ready applications, DevOps and
continuous delivery. As a result, there is a spectrum of scenarios where you can benefit from
understanding MSA, from adopting best practices into your existing SOA delivery to fully embracing
MSA to transform your delivery life cycles and application architecture.

Gartner's guidance is as follows:

■ Assess the full potential and impact of MSA: It's not just about architecture and runtime
scalability. It's about delivery life cycle cadence and adaptability. Adopting MSA will have an
impact on your processes and organization structure if you intend to fully embrace it to achieve
all the potential benefits. Delivering those benefits with a robust MSA requires a deep
understanding of and commitment to delivering both the inner and outer architecture aspects.

You must also assess how the MSA will affect your software delivery life cycle and how your
organization, processes, responsibilities and culture will need to change to realize the benefits.
MSA is not always the right choice. Applications composed of services and components
deployed as a monolithic codebase, or more macroservices, are lower-risk where you do not
have explicit demand for the benefits of microservices and the discipline in development and
operations to deliver them. Adopting MSA is not a "no brainer" or an all-or-nothing endeavor.
You need to educate developers, ops, leadership and stakeholders and get buy-in for the
changes, benefits and complexities. See "How to Succeed With Microservice Architecture
Using DevOps Practices" for more details.
■ Eat the monolith one bite at a time, and start with a nibble: To identify MSA opportunities,
look for subsets of your monolithic applications that will benefit both from the ability to rapidly
and independently evolve the functionality through continuous delivery and from the flexible and
scalable deployment model. The key indicator that microservice patterns and practices will help
is that you have areas of functionality that demand continual change. The same application
microservices can help if the pace of that change is limited by the need to coordinate releases
across multiple groups of developers.

Page 42 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

Exploding a monolith directly to a set of fine-grained microservices creates significant risk by

introducing complexity to your development, deployment and operations processes. Your first
step toward MSA should also be a low-risk opportunity that will help validate understanding of
the technical and organizational impact. For example, you might add a notification service to an
existing application using a microservice built using Spring Boot, .NET Core (see
"Assessing .NET Core for Modernizing .NET Applications") or Node.js (see "Assessing Node.js
and JavaScript to Build APIs, Microservices, and Event-Driven Web and Mobile Apps").

It is important that these first steps don't ignore the outer architecture. Putting these
foundations in place early will prevent a "false dawn," where small-scale success leads to
operational and productivity issues as you increase adoption and hence complexity. You must
also measure the benefits that MSA is delivering. Use metrics, both for development life cycle
and for runtime environment, to show benefits (or negative impact) and to provide insight into
where to invest to improve services, processes, skill sets, or tooling and platforms. See "How to
Design Microservices for Agile Architecture" and "Refactor Monolithic Software to Maximize
Architectural and Delivery Agility" for more explanation of how to migrate from monolithic
architectures.
■ Use aPaaS or CaaS as a way to get access to some of the "outer architecture": aPaaS or
CaaS platforms and frameworks provide some of the outer architecture capabilities you will
need to be successful. A detailed assessment of the options is provided in "Selecting a Cloud
Platform for DevOps Delivery With Microservice Architecture."

If your workload is suitable for the public cloud, an aPaaS platform will deliver a sizable
proportion of the outer architecture you will need to get started. However, beware of vendor
lock-in (see "A Guidance Framework for Architecting Portable Cloud and Multicloud
Applications").

For on-premises or IaaS-based microservices deployments, your platform choices come with
an additional burden: You need to build, compose or deploy an outer architecture. If you have
the appropriate engineering and operational resources available, using a lighter-weight
container orchestration framework can provide an alternate to a full-featured aPaaS framework.
But you must plan to select and integrate more supplemental outer-architecture features (see
"Orchestrating Docker Container-Based Cloud and Microservices Applications" and "Assessing
Container Management Frameworks Running On-Premises and in the Cloud").
■ Keep your inner architecture as simple and consistent as possible until you hit
constraints: "Polyglot" is the ability to use different languages, frameworks, data persistence
and even platforms on a per-microservice basis. This is a major benefit espoused by
microservice advocates. However, for enterprise teams, the benefits of consistency must still be
recognized. Define a preferred stack for your MSA and treat the polyglot opportunities as an
"exception case." Use alternate application platforms, languages and data persistence only
when you have a specific need, such as a performance or capacity demand for a specific
service that is better met by a different technology.
■ Manage microservices, too: Interface contracts for microservices, be they RESTful web APIs
or asynchronous message definitions, must be defined and managed through their life cycles. If

Gartner, Inc. | G00346861 Page 43 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

successful, microservices will proliferate, and the need to manage the contracts and access to
the services will become critical. Use the mediated APIs' design pattern to mediate and manage
access to services. See "Choosing an Architecture for Managing APIs and Services" and
"Mediated APIs: An Essential Application Architecture for Digital Business" for more information
on managing and mediating APIs to decouple them from service implementation.

Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

"How to Design Microservices for Agile Architecture"

"Orchestrating Container-Based Cloud and Microservice Applications"

"How to Succeed With Microservice Architecture Using DevOps Practices"

"Building Identity Into Microservices"

"Selecting a Cloud Platform for DevOps Delivery With Microservice Architecture"

"Refactor Monolithic Software to Maximize Architectural and Delivery Agility"

"10 Essential Skills of the Modern Software Architect"

"How to Build Effective Microservices Teams"

"Innovation Insight for Microservices"

"Innovation Insight for Miniservices"

"Use These Three Best Practices to Power Your Microservice Adoption"

Evidence
1 "Microservices." MartinFowler.com.

2 E.
Evans, "Domain-Driven Design: Tackling Complexity in the Heart of Software." Addison Wesley,
2003.

3 "The Twelve-Factor App." 12Factor.net.

4 "Conway's Law." Wikipedia.

5 "Standard Bank: Our DevOps Journey." Chef Software.

6 "Single Responsibility Principle." Wikipedia.

7 "Conference Presentation Abstracts and Slides." Nealford.com.

Page 44 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

8 "Made for Each Other: Microservices + PaaS." Pivotal.

9 "Microservices." MartinFowler.com.

10 "Tolerant Reader." Service Design Patterns.

11 "Robustness Principle." Wikipedia.

12 "Conway's Law." Wikipedia.

13 "Michael Bryzek on Handling Microservices in the Real World." InfoQ.

14 "Moving to Microservices — a Technology and Organisation Transformational Journey."

15 "How We Ended Up With Microservices." SoundCloud.

16 "How Runscope Overcame Microservices Challenges." Runscope.

17 "How We Build Microservices at Karma." Karma.

18 "Microservices: A Real World Story." WatirMelon.

19 "Container Cluster Manager From Google." GitHub.

20 "Conway's Law." Wikipedia.

Gartner, Inc. | G00346861 Page 45 of 46

This research note is restricted to the personal use of bdole@nets.eu.

This research note is restricted to the personal use of bdole@nets.eu.

GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

© 2018 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access
this publication, your use of it is subject to the Gartner Usage Policy posted on gartner.com. The information contained in this publication
has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of
such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the
opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions expressed herein are subject
to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal
advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may
include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of Directors may include
senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or
influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see
“Guiding Principles on Independence and Objectivity.”

Page 46 of 46 Gartner, Inc. | G00346861

This research note is restricted to the personal use of bdole@nets.eu.