White Paper

Microservices—What an
Enterprise Architect needs to know

Contents INTRODUCTION
Rapidly accelerating digitalization is forcing many businesses to rethink their
Introduction
architectures. To meet the constantly growing expectations of technology-
A brief history savvy customers, companies must ensure that their products are available on
of microservices all digital channels and as quickly as possible.

Microservices One way to reduce throughput times in order to adapt to the ever-changing
and other trends needs of highly dynamic markets is to introduce a microservices architecture
in software development. Microservices allow rapid changes and short release
Transforming to a times along with high scalability and autonomous teams.
microservices architecture
One major use of microservices is to break down or avoid monoliths in order
Summary to avert the disadvantage that changes made to any part of the application
require the entire monolith to be rebuilt and redeployed. Over time, monoliths
develop very complex structures that make it increasingly difficult to perform
changes quickly. Moreover, scaling cannot be limited to individual parts, but
must be applied to the entire application.
 A BRIEF HISTORY OF
MICROSERVICES
How it all began
The term "micro web services" was first used by Dr.
Peter Rogers during a conference on cloud computing
in 2005. "Microservices" themselves premiered at
an event for software architects in 2011, where the
term was used to describe a style of architecture that
many attendees were experimenting with at the time.1
Netflix and Amazon were among the early pioneers
of microservices. The popularity of microservices
has recently been on the rise because they can solve
many current IT challenges such as increasing speed,
scalability of applications and rapid test processes.

Figure 1: Microservices as a search trend

Features of microservices
Services within a system are largely decoupled and can therefore be easily built,
Decoupling
altered and scaled.

Microservices are independent components that can easily be replaced or

Componentization
upgraded.

Business capabilities Microservices are very simple and focus on a single business capability.

Many developers and teams can work independently of each other and thus
Autonomy
significantly increase speed.

Allows frequent releases through systematic automation of software creation,

Continuous delivery
testing and approval.

Microservices do not focus on software projects; instead they treat applications

Responsibility
as products for which they are responsible.

The focus is on using the right tool for the job, not on standardizing technology
Decentralized governance platforms. Teams prefer to develop useful tools that other developers can use to
solve similar problems.2

Microservices support agile development. A new feature the customer does not
Agility yet quite believe will be successful cannot only be quickly developed—it can also
be quickly discarded again.3
Figure 2: Features of microservices

1, 2
Fowler, Martin: Microservices, a definition of this new architectural term. http://www.martinfowler.com/articles/microservices.html (11/02/2016)
3
Steinacker, Guido: Von Monolithen und Microservices. https://www.informatik-aktuell.de/entwicklung/methoden/von-monolithen-und-microservices.html
(11/02/2016)
Page 2 of 8
The philosophy behind microservices
The microservices style of architecture develops
complex application software from small, individual
applications that communicate with each other using
language-independent interfaces (APIs). Companies
run into trouble if they are unable to scale monolithic
architecture that has developed over time, if their
A monolithic application
puts all its functionalities
into a single process ...
... and scales by replicating the monolith
on multiple servers.
Figure 3: Monoliths and microservices, according to Martin Fowler
Microservices architecture
To create a sample microservices architecture we
first have to decide how we want to structure our
microservices. For example, we could divide them
vertically into levels:
Central services—Handle business data persistence and
apply business rules and other logic.
Composite services—Organize either a number of
central services in order to fulfill a common task, or
aggregate information from several central services.
architecture is difficult to upgrade or maintenance
becomes too complex. Microservices can be the answer
to this problem, as they break down complex tasks
into smaller processes that work independently of
each other.
A microservices architecture puts
every functionality element into a
separate service ...
... and scales by distributing these services
across servers and replicating them as
needed.
API services —Open up a functionality externally to
e.g. allow third parties to develop creative applications
that utilize the underlying functionality in the system
landscape.
Horizontally we would in this example apply a
structure based on domains in the sense of business
functionalities.
It is extremely important to define a target architecture
before beginning to scale microservices, otherwise
the IT landscape may end up devolving into chaos and
exhibit worse properties than the existing monolithic
applications.
Page 3 of 8
 C-1 C-2 C-1 C-2

API Services

API-1 API-2 API-3 API-4 API-5 API-6

Composite Services

MS-5 MS-6

Core Services

MS-1 MS-2 MS-3 MS-4

Domain A Domain B Domain C

Figure 4: A possible microservices target architecture

MICROSERVICES AND OTHER

TRENDS
Microservices & SOA
Service-oriented architecture (SOA) is a software
design style in which components deliver services over
a network via a communication protocol. SOA became
popular around 2005, but has fallen out of favor in
recent years while microservices have taken the IT
world by storm. When microservices became more
popular a few years ago, some people described them
as "fine-grained SOA". Others said that microservices
did what SOA was meant to do.
One problem with SOA was that it was too clumsy, too
complex and, due to its many processes, too slow. While
it initially reduced provider dependence, in the long
term SOA could not support the democratization of IT.
Ultimately, microservices were better able to integrate
web services and thus had a clear advantage over SOA.
Microservices & DevOps
DevOps and microservices are both trends that have
become more popular in companies in recent years.
Both were developed to increase companies' agility and
efficiency, and according to Netflix, DevOps excellence
is a key to excellence in microservices4.
Microservices increase the productivity of DevOps as
they include a common toolset that can also be used
for development and operations. This common toolset
creates a common terminology and processes for
requirements, dependencies and problems; that in turn
makes it easier for devs and ops to work together, as
the two units can work jointly on the same problem and
successfully repair a build configuration or a build script.
DevOps and microservices both work better when they
are used together.

4
Mauro, Tony: Adopting Microservices at Netflix: Lessons for Team and Process Design. Page 4 of 8
 Enterprise Architecture Management
& microservices
DevOps and microservices are core components of As a result, LeanIX can offer all employees up-to-date
a new form of IT. But there is another factor that is access to information on the IT landscape in their
necessary in order to support successful IT for the digital personal context—a basic requirement if a microservices
age: Enterprise Architecture Management (EAM). EAM architecture is to work. In day-to-day work and when
however also needs to evolve: Traditional approaches onboarding new employees, the increased transparency
based on complicated IT landscape modeling and can contribute significantly to sustainable, rapid further
planning for years in advance are no longer suitable for development of a company's IT landscape.
our extremely fast-moving digital times. In the worst
case scenario, EAM may even create a bottleneck and
block new developments.5 TRANSFORMATION TO A
MICROSERVICES ARCHITECTURE
In a microservices organization however, state-of-the-
Although it is not always easy for companies to
art EAM can create more added value than ever. Even
introduce microservices, there are very good reasons
independently working teams have to keep working
to do so. Allan Naim, Product Manager Container
towards a common goal, and the software they produce
Engine and Kubernetes at Google, predicts that in a
has to be able to work together. Online clothing
not-too-distant future every organization, no matter
retailer Zalando for example uses a team of enterprise
the industry or sector, will become a software company.
architects for this purpose.6 This team serves as the link
The reason for this is that customer data is becoming
between the various teams and programming languages
just as valuable as products and services.
and is responsible for filling the gaps that arise from
the different processes. It always has to know what is
Companies that want to survive in the digital world
happening where, says Eric Bowman, Vice President of
have to be aware that innovation, agility and speed
Engineering at Zalando.6
are the most important factors. Decoupling from
legacy systems by introducing microservices offers the
The developers at Zalando work in over 100 small, agile
opportunity to experiment with new approaches and
teams. Described as "radical agility", this model was
iterate more quickly.
introduced in early 2015 to make the ever-growing
tech company more efficient and more innovative.6 In a
Microservices not only change the way companies
microservices architecture with 200 microservices, the
write code, but also the companies themselves. While
teams are almost entirely autonomous and can choose
in a monolithic system the roles of team members are
the most suitable technology for each case themselves.
specialized, under microservices employees can work
Developers have full responsibility from DevOps
freely on different parts of the application without
through quality assurance to deployment.7
interruption. Introducing microservices can also change
business processes, products and customer services.
Many companies use an EAM tool to maintain an
And because microservices also give individuals more
overview of their IT landscape. Tools such as LeanIX
freedom to make decisions, they encourage innovation.
form the link between the individual teams and
technologies and provide a view of the overall system.

5
Friedrichsen, Uwe: The Need for Speed – eine Geschichte über DevOps, Microservices, Continuous Delivery und Cloud Computing.
https://blog.codecentric.de/2015/08/the-need-for-speed-eine-geschichte-ueber-devops-microservices-continuous-delivery-und-cloud-computing (11/02/2016)
6
t3n: Zalando: Wie der Mode-Konzern seine Tech-Bewerberzahlen vervierfachte. http://t3n.de/news/zalando-mode-konzern-739646/ (10/04/2016) Page 5 of 8
7
Giamas, Alex: From Monolith to Microservices, Zalando’s Journey. https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando (11/08/2016)
Best practices for introducing
microservices
No legacy system can be transformed into microservices
overnight. As Phil Calçado of SoundCloud describes in
his article on the company's transition to microservices,
there is still live monolith code at SoundCloud even
after several years. But the importance of this monolith
is decreasing every day.8
Companies that want to introduce microservices have
to decide where and how these microservices can be
integrated into their existing applications. The first
step is to define a microservices architecture. It has to
be established how the services will interact with each
other before a company attempts to optimize their
implementation. E-commerce company Zalando for
example uses the STUPS platform, which gives every
autonomous team a set of tools and components in
the form of a convenient and tamper-proof platform-
as-a-service on Amazon Web Services (AWS)9. STUPS
allows Zalando to iterate very quickly and at the same
time meet its high reporting requirements. Once your
microservices architecture gets going, you have to be
able to optimize the increase in speed.
Microservices evangelist Adrian Cockcroft, who was
responsible for introducing microservices at Netflix,
has introduced a number of best practices for designing
and implementing microservices10.
Business capability based design
Microservices architecture typically needs teams
that specialize in particular business capabilities
with different requirements, such as order approval,
shipping, delivery and returns management, which are
all part of order fulfillment. Companies should aim to
focus not on more projects, but on products. Services
should be developed as independent products that are
well documented and each only responsible for a single
business capability.
8
Calçado, Phil: How we ended up with microservices. http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html (10/28/2016)
9
Zalando STUPS. https://stups.io/ (10/25/2016)
10
Mauro, Tony: Adopting Microservices at Netflix: Lessons for Architectural Design.
https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/ (11/02/2016)
A separate data store for each microservice
Do not use the same data store for all your microservices.
Each microservices team should select the database
that is best suited to its service. A single data store also
holds a significant risk that microservices from different
teams share the same database structures, perhaps to
avoid duplicating work. When one team updates its
database structure, other services that use the same
structure may also have to be adapted.
Code should have a similar level of maturity
All code in a microservice should have a similar degree
of maturity and stability. If you have to add or rewrite
code that works well in a microservice, the best way
is usually to create a new microservice for the new or
altered code and leave the existing microservice where
it is. This allows you to iteratively release and test the
new code until it is error-free and maximally efficient.
Deployment in containers
Deploying microservices in containers is important, as
it means you only need one tool to deliver everything.
As long as the microservice is in a container, the tool
knows how to deliver it. Docker has currently become
the standard for containers.
Treat servers as stateless
Treat servers as replaceable members of a group. They
all have the same functionality, so you do not have to
worry about individual servers. Cockcroft says that you
should think of servers as "livestock", not as pets. If you
have a machine that has special functionalities, that you
know by name and where everyone is upset when it
fails, it's a pet. Instead you should think of your servers
like a herd of cows. What matters to you is how much
milk you get. If one day you find yourself with less milk,
you determine which cows are no longer producing
enough milk and replace them.
Page 6 of 8
Monitoring
Microservices consist of a large number of mobile parts;
it is therefore all the more important that you measure
everything efficiently and simply with mechanisms
such as response time notifications, service error
notifications and dashboards. Use logs such as Splunk
and monitoring tools like AppDynamics.
SUMMARY
Even if you choose not to introduce a pure microservices
architecture, and instead only apply some of its
principles, you can still benefit significantly—especially
in a traditional corporate IT landscape. Less redundant
code and data means lower risk, as fewer errors can
occur and your teams are better able to concentrate on
the main functions of their applications. Microservices
allow greater flexibility in deployment, release schedules
and processes, and enable you to pick up far more
speed in order to meet the needs of your customers
and the challenges of digitalization. The responsibility
for business capabilities gives your applications focus,
as they are developed as independent products that
deliver a single business capability, well documented
and easy to use.

Not every company is today at the technical level of

Netflix or Zalando, and it does not have to be in order to
follow the example of their IT architecture.

Copyright

© LeanIX GmbH. All rights reserved. LeanIX and the LeanIX logo are trademarks or registered trademarks of
LeanIX GmbH in Germany and/or other countries. All other products or services are trademarks of their respective
companies.

This document is current at the time of its initial publication. LeanIX GmbH reserves the right to alter it at any time.

THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED AS IS, WITH NO WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLICIT.

Document Version 1.1

Page 7 of 8
About LeanIX

LeanIX offers a Software-as-a-Service (SaaS) for Enterprise Architecture (EA), which enables organizations to take
faster, data-driven decisions for their IT landscape. More than 80 leading brands such as adidas, DHL, Merck,
Vodafone, and Zalando use the innovative solution worldwide. Users of LeanIX gain insights on how to organize and
leverage their IT landscape to increase competitiveness and enable innovation going forward. LeanIX addresses
the frequent problem that the required information about the IT landscape is missing, outdated, or difficult to
analyze. Use cases include application rationalization, technology risk management, and the shift from monolithic
architectures to microservices. LeanIX was founded in 2012 by Jörg Beyer and André Christ. The company’s
headquarter is in Bonn, Germany, with offices in Boston, Massachusetts, and Houston, Texas. A wide network of
partners provides support in America, Europe, and Australia.

LeanIX GmbH
Bonn
Germany

Tel: +49 (0) 228 2862992-0

Email: info@leanix.net
www.leanix.net

Page 8 of 8