Architecting for speed: how agile innovators accelerate growth through microservices

1
ARCHITECTING FOR SPEED
How agile innovators accelerate growth
through microservices
Jesper Nordström
Tomas Betzholtz

2
Cutthroat competition requires enterprises to transform
how they build and deliver software
In a world where software has become the key differentiator, enterprises are forced to transform
the way they build, ship and run software in order to stay in the game. Competitive pressure
requires applications to be rapidly and continuously upgraded with nonstop availability, and
companies that lack the capacity to experiment, innovate and get new features out quickly,
will be at disadvantage.
This is driving many IT organisations to adopt the software design model known as microservices
architecture, which quickly is gaining traction as a new way to think about structuring
applications, and is changing the fundamentals of enterprise application management.
Managing complex enterprise systems is a challenge and many enterprises still sit on large,
monolithic applications with huge unmanageable codebases that have become increasingly
difficult to maintain. Adopting a microservices architecture where applications instead are built
as suites of services enables them to not only become more agile but also to cut costs and
increase stability.
January 2016

3
“Many enterprises still sit on large, monolithic
applications with huge unmanageable codebases that
have become increasingly difficult to maintain.”
The problem with traditional software architecture and
monolithic applications
Enterprise applications have traditionally been built as monoliths with all functionality in
a single process. These monoliths cause increasing frustration, especially as more applica-
tions are being deployed to the cloud. Monolithic applications are fine for small scale teams
and projects but become problematic at larger scale when many teams are involved because
they don’t allow organisations to improve functionality rapidly enough.
• As developers write code to add new features, the codebase grows, and over time it
becomes hard to know where a change should be made because the codebase has
become so large. Code related to similar functions begin to proliferate, making fixing
bugs or implementations complicated. Doing continuous updates requires an exponen-
tially growing amount of coordination.
• New developers must often spend months learning the codebase before they can begin
to work because it requires an understanding of how any change will affect the entire
codebase, and a broken update can cause the entire application to crash. Even seasoned
teams worry about making changes or adding code that unexpectedly might disrupt
operation—why even simple changes can be debated endlessly.
• Change cycles are tied together and a change made to only a small part of the applica-
tion requires the entire monolith to be rebuilt and deployed. Updates therefore become
more painful and less frequent, contributing further to the fragility of the application.

4
This is why many enterprise IT organisations are spending weeks carefully coding and
testing before any updates can be rolled out to end users.
When things go wrong (which they often do), the blame game starts, and the business starts
to search for outsourcing alternatives because they’re losing trust in IT’s ability.
The rise of microservices
Microservices has emerged as a solution to many of the problems associated with large,
monolithic applications. It’s the first architectural style of the DevOps era and embraces the
engineering practices of Continuous Delivery. It’s also an example of evolutionary architec-
ture, which supports incremental change as a first principle.
“Microservices has emerged as a solution to many
of the problems associated with large, monolithic
applications.”
Successfully implemented, microservices can deliver substantial increases in the speed and
agility in which companies build and deploy software. The cost required to deliver an appli-
cation is typically much less and systems become more resilient. Development time can
go from months to weeks. Businesses such as Dropbox, GE and Goldman Sachs have seen
development lead times cut by 75% after transitioning to microservices.1
Microservices as an evolutionary architecture
Conventional wisdom asserts that architectural elements are difficult to change. However,
the world of software isn’t static but evolves continuously why a fixed view of architecture
will be short lived. Architecture is abstract until operationalised and it’s hard to determine
the long-term viability of any architecture until it’s been implemented and upgraded 2
.
Evolutionary architecture designs for incremental change as a first principle. Change is
difficult to anticipate and has traditionally been expensive to accommodate later on, but
when evolutionary change is built into the architecture, change becomes easier and less
costly—allowing changes to development practices, release practices and general agility.
A key benefit of evolutionary architectures is the ability to experiment. Several versions
of a service can exist within the ecosystem, which allows for experimentation and gradual
replacement of existing functionality. This means organisations can spend less time specu-
lating about story backlogs and instead engage in hypothesis driven development.
What are microservices?
The microservices architectural style is not an agreed architecture with a defined set of
frameworks. In short it can be described as a conceptual approach to developing applica-
tions as suites of small, loosely coupled and composable services working together, where

5
each microservice is a complete autonomous process that can be programmed in any lan-
guage and managed separately.
Each microservice is designed to perform a single function representing a small business
capability and talk to other microservices via language-agnostic APIs. The services are inde-
pendently deployable and scalable. In a conventional architecture, a single database sup-
ports one monolithic application. In microservices architecture, each service has its own
database. Together, these services and their databases deliver the user experience.
Let’s look at some of the characteristics of microservices in more detail:
Microservices are autonomous
The core idea of the microservice architecture is that any one service is autonomous and
can be changed and deployed independently, without needing to change any other part of
the system. Therefore, microservices must have minimal dependency on one another (loose
coupling). To prevent the applications that consume their data from binding too tightly to
them, and make it easier to roll out future changes, services should expose only necessary
information.3
A loosely coupled service knows as little as needed about the services with
which it collaborates. This means integration styles should be avoided that tightly binds one
service to another and cause changes inside the service to require a change to consumers
(the “calling” program). The number of different types of calls from one service to another
should also be limited.
Microservices communicate via language-agnostic APIs
Microservices communicate with each other through language and platform-agnostic appli-
cation programming interfaces (APIs), which means that they can be developed in any pro-
gramming language that is best suited for the task at hand.
Microservices perform a single business function
A key characteristic of microservices is that they focus on doing one thing well and have
clearly defined interfaces (bounded context). Keeping the service focused on an explicit
boundary, namely a specific product feature, makes it is clear where code lives for a given
piece of functionality, while avoiding that the service grows too large. Every component
of a microservice should be focused on the same task. This makes it easier to modify the
behaviour of a part of the system, since it reduces the number of places where code needs to
be updated to a single service, and the change can be released promptly. When a behaviour
requires changes in several places, many services must be released at once to deliver that
change, which takes more time and involves more risk.
Microservices are small
Codewise, microservices are usually around 100 lines, but can be up to 1000. However,
rather than count lines of code when identifying the scope of microservices, it’s better to
look at the functionality the service needs to provide, and how it relates to other services.
Microservices should be “minimal but complete”4
. A general rule is that a microservice
should be small enough to be managed by a small team, and its conceptual model should

6
be able to “fit in your head”. If the codebase feels too big, breaking it down makes sense. A
microservice should be the responsibility of exactly one team, but one team can be respon-
sible for several services.
Microservices are managed by decentralised, cross functional product
teams
The ideal organisation for microservices has small, empowered teams where each team is
responsible for a business function composed of a number of microservices which can be
independently deployed. Teams handle all aspects of software development for their micro-
services, from conception through deployment, and therefore feature all roles necessary
to deliver these services, such as product owners, architects, developers, quality engineers
and operational engineers. This organisation design is consistent with Conway’s law5
, which
says that the interface structure of a software system will reflect the social structure of the
organisation that produced it.
MICROSERVICES ARCHITECTURE
User
Interface
Business
Logic
Data Access
Layer
DB
User
Interface
Microservice
Microservice Microservice Microservice
DB DB DB
MONOLITHIC
ARCHITECTURE
Microservice
DB
The microservices premium (Image adapted from martinfowler.com)
The building blocks of microservices
The idea of microservices isn’t new. Google, Amazon and Facebook have been using micro-
services for more than ten years. Each time a search is performed on Google, about 70
microservices are called out before results are returned6
. Enterprises tried to achieve the
benefits of microservices through an approach called service-oriented-architecture (SOA),
which mainly failed due to poor governance, design and the lack of critical building blocks
required for large-scale adoption. However, with the rise of DevOps and the development
of the three key building blocks required, the benefits of microservices are now accessible
to everyone. These building blocks are:
• Containers
• Scalable cloud infrastructure
• APIs

7
DEVOPS
MICROSERVICES
AND API:S
CONTAINERS
THE BUILDING BLOCKS OF MICROSERVICES
SCALABLE CLOUD
INFRASTRUCTURE
The building blocks of microservices
Containers: the launchpad for microservices
Just like containers revolutionised the shipping business, software containers have formed a
standardised frame for all services, transforming how developers build and deploy applica-
tions. Containers reduce complexity and enable developers to scale applications both faster
and cheaper. Docker has today become synonymous with the container technology. In the
future, every large application will be a distributed system comprising dozens of microser-
vices running in their own containers.
Containers package a piece of software in a complete filesystem comprising everything it
requires to run, which ensures it will run the same every time, independent of the environ-
ment it is running in. By containerising the application platform and its dependencies, var-
iations in OS distributions and underlying infrastructure are abstracted away7
. This makes
it easier to move applications from the workstation where they are coded to the clusters of
computers that serve those applications to users. Compared with virtual machines, contain-
ers have a very small footprint, which means that a single server can host far more contain-
ers than VMs. They can also be launched in mere seconds, compared to several minutes for
virtual machines.
Scalable cloud infrastructure
Virtualisation as we have known it can no longer keep pace with the demands of microser-
vices and next-generation applications, delivering the necessary resources on demand to
effectively scale and operate services. With DevOps emerging as a new way of managing
development and operations, virtualisation is also losing one of its principal benefits: run-
ning different guest operating systems on the same physical server8
.
The fundamental principle of virtualisation: dividing a large and costly server into numer-
ous virtual machines, is making way for new cloud architectures that are reimagining how
data centres work. Rather than split the resources of individual servers, a software layer
aggregates all the servers in a data centre into one massively scaled virtual computer to run
highly distributed applications.
These emerging data centres are made up of inexpensive commodity parts with small, inex-
pensive servers. They lack the computing power of traditional state-of-the-art data centres
but due to their large number, the result is much more powerful. The new level of abstrac-
tion makes an entire data centre seem like one huge supercomputer9
but the system really

8
consists of millions of microservices inside their own Linux-based containers—bringing
the advantages of multitenancy, isolation and resource control throughout every container.
As scaling requirements grow and applications increase in complexity each day, every devel-
oper and IT organisation will soon be affected by these changes. Every data centre—public,
private or hybrid—will soon be adopting hyperscale cloud architectures10
. This is bringing
new cloud economics and cloud scale to enterprise computing, and enabling new kinds of
businesses previously not possible. The data centre operating system allows developers to
build distributed applications easier and safer without limiting themselves to the plumbing
or limitations of the machines, and without being obliged to desert their preferred tools.
This new intelligent software layer will relieve IT organisations, often seen as innovation bot-
tlenecks, from manually configuring and managing individual applications and machines,
and instead enable them to spend more efforts on agility and efficiency—becoming less of
maintainers and operators and more of strategic users.
3
App A
VM
Hypervisor
Server
TRADITIONAL SERVER VIRTUALIZATION
App B
VM
App A
VM
Hypervisor
Server
App B
VM
Microservice
Container
Datacenter OS
Server Server
HYPERSCALED CLOUD INFRASTRUCTURE
Server
Microservice
Container
Microservice
Container
Microservice
Container
Tradtional server virtualization vs hyperscaled cloud infrastructure
APIs: from technical need to business model driver
An application programming interface (API) is a toolset of protocols and routines expos-
ing the functionality of a service or application to others, allowing them to communicate.
APIs make it much simpler for developers to combine data from different sources to build
applications.
APIs are far from new, but have in recent years grown significantly both in number and
sophistication, as an increasing number of companies see how they can help companies
innovate faster and lead to new products and new customers. This fast adoption of APIs has
established a standardised format for communication, which has enabled microservices.
APIs started as an enabler for things companies wanted to do, but have today expanded from
a technical need to become a business priority. They are now a critical ingredient of running
a digital business and a key driver of business strategies, enabling businesses to acceler-
ate new service development and offerings. The number of public APIs are exploding with
businesses across industries embracing APIs and opening them up to outside developers.
APIs can expand the reach of a company’s key assets, letting them be shared, reused or
resold as a new revenue stream11
. From a business perspective, few software companies
can today grow without publishing an API of their service. This means that developers all

9
over the world can build new, interconnected technologies and services that augment the
software and take it in novel directions.
The benefits of microservices
As organisations scale both technology and staff it becomes much more difficult to manage
monolithic code bases. By decomposing applications into microservices, organisations will
see benefits such as faster development cycles, improved productivity, superior scalability
and supreme system availability.
“By decomposing applications into microservices,
organisations will see benefits such as faster
development cycles, improved productivity, superior
scalability and supreme system availability.”
Ease of deployment
The traditional software development approach of releasing an application every couple
of months is not fast enough for digital businesses that need to deploy new releases many
times per week or even per day. Due to their high change costs, monolithic applications
are not well suited for rapid release cycles. Releasing just a small change to a million-lines-
code monolithic application requires that the whole application is deployed, which means
these happen infrequently. As a result, changes usually build up between releases, leading
to more comprehensive releases. And the longer between releases, the higher the risk that
something goes wrong.
With microservices, developers can change the code in one service and deploy it separately
from the other parts of the system. This allows them to faster deploy code and get new func-
tionality out to customers sooner. If a problem should arise, it can swiftly be isolated to a
single service so a fast rollback easily can be made. This speed of deployment with reduced
risk is a main reason why organisations like Amazon and Netflix use microservices archi-
tectures, ensuring they remove as many barriers as possible to get software out the door12
.
Superior scalability
Enterprises that want to move fast and stay innovative in hypercompetitive markets require
an architecture that can scale. The scaling demands for various components within an appli-
cation normally differ13
. Scaling monolithic applications is highly inefficient as the only way
of doing this is often to clone the entire application, even though the various parts are not
equally load intensive. As this doesn’t represent the actual demands on the system, it leads
to wasted computing power and resources.
Microservices on the other hand, allow efficient selective scaling of application components
and can scale up or down independently, without affecting the rest of the system. Rather
than scaling up with bigger machines or more copies of the entire application, it’s possible
to scale out with duplicate copies of the heaviest-used parts. Consequently, a microservices

10
architecture means more efficient use of code and underlying infrastructure, resulting in
cost savings reducing the amount of infrastructure required to run a given application.
4
A microservices architecture has each piece of func�onality
in a separate service
A monolithic app has all func�onality in a single process
It scales by cloning the en�re applica�on on mul�ple servers
It scales by distribu�ng services across servers,
replica�ng as needed
TRADITIONAL SERVER VIRTUALIZATION SCALING WITH MICROSERVICES
Scaling monolithic applications and microservices (adapted from martinfowler.com)
Technology Diversity
Trying out new technologies always involves some risk. With a monolithic application, if
developers wish to test a new programming language, database or framework, every change
will affect a significant part of the entire system. Microservices allow organisations to take
advantage of new technology more quickly as it’s possible to embrace different technolo-
gies; mixing multiple languages, development frameworks and data-storage technologies
(polyglot).
As the system consists of multiple, collaborating services that communicate across lan-
guage-agnostic protocols, an application can consist of microservices running on distinctive
platforms (Java, Ruby, Node, Go etc.), thereby taking advantage of the specific advantages
of each platform14
. This means organisations can use different technologies inside each one
and pick the right tool for each job, rather than having to select a standardised one-size-
fits-all approach. This said, some organisations still choose to place constraints on language
choices. Netflix and Twitter, for example, mostly use the Java Virtual Machine as a platform
because they know the reliability and performance of that system15
.
Moreover, developers have many places where they can try out a new piece of technology.
They can pick a service that is lower risk and use the technology there, to limit potential
negative impact.
Resilience
When a monolithic application fails, everything stops working. But since microservices are
autonomous, there is much less risk that they cause a system failure if they break down16
.
Loose coupling with other services together with bounded context, limits its failure domain,
making the system more resilient to disruptions. The failure of a single instance of a micro-
service has minimal impact on the application. And if all instances of a microservice should
go down, it won’t cause the entire application to crash but only impacts the function of this

11
particular microservice, so users can continue to use the rest of the application. Apart from
a more stable system, increased resilience also facilitates experimentation and innovation
as it makes failing less risky.
“When a monolithic application fails, everything stops
working. But since microservices are autonomous,
there is much less risk that they cause a system failure
if they break down.”
Organisational agility
Almost every IT organisation with legacy is experiencing the problems associated with large
teams and codebases. The problems are often exacerbated when the team is distributed.
With conventional application architecture and monolithic code, one large team of engi-
neers works on one big piece of code and are grouped according to technical expertise. They
often step on each other’s feet and the speed of development slows exponentially with the
growth of the code in the monolith.
With microservices architecture, applications are built by small, decentralised and autono-
mous development teams. Every team is trusted to make their own decisions about the soft-
ware they produce and is dedicated to a single service that can be updated independently.
This encourages ownership of particular functions and makes changes both easier and
faster as there are fewer bottlenecks and less resistance to change so decisions can be made
quicker.
Moreover, small teams working on small codebases have a better overview of the code,
which makes it easier for new developers to understand the functionality of a service. And
because each piece of the application is independent of the rest of the stack, programmers
don’t have to understand how everything else works so there is no need for lengthy integra-
tion work across development teams.
5
Developers Monolith Delivery pipeline
MONOLITH DEVELOPMENT LIFECYCLE
Build Test Deploy
Developers Microservices Delivery pipelines
MICROSERVICE DEVELOPMENT LIFECYCLE
Build Test Deploy
Build Test Deploy
Build Test Deploy
Build Test Deploy
Monolith vs Microservice development lifecycle

12
Replaceability
The barriers to replacing a microservice or removing it are very low as the codebase seldom
is longer than a few hundred lines and the team managing the service has a good under-
standing of the code.
Reusability
As businesses shift from thinking in terms of narrow channels to holistic concepts of cus-
tomer engagement, they have to consider the multitude of ways they want to integrate capa-
bilities for the web and native applications on desktop, mobile and wearables—and they
need the right architectures for this. Microservices open opportunities for functionality
to be reused and consumed in different ways for different purposes, which is important
with regard to how consumers use the software. Each microservice acts like a Lego block
that can be plugged into an application stack so organisations can assemble them to build
applications catering to a variety of use cases. And as circumstances change, it’s possible to
rebuild things in new ways.
Challenges with microservices
While microservices provide many benefits, they also come with costs. Microservices is no
silver bullet and they have all the associated complexities of distributed systems. While the
services themselves are simple, there is a great deal of complexity at a higher level with
regard to managing these services and orchestrating business processes17
. Every organisa-
tion and system is different and a number of factors will determine whether or not micros-
ervices are right for yours. However, with the right automation and tools, most drawbacks
can be addressed.
Distribution
A microservices architecture necessitates a distributed system which can be complex and
hard to manage. Services interact using an inter-process communication mechanism18
.
Remote calls are slow and can fail at any moment why developers should design for failure19
.
So as not to lose performance, most microservice systems use asynchronous communica-
tion, which is difficult to get right, and is harder to debug20
. Also, with more components
exchanging information, it leads to increased network communication and risk for network
congestion, reinforcing the need for reliable and fast network connections.
Operational complexity
Microservices introduce additional operational complexity as there are many more moving
parts that have to be managed and monitored. You have a multitude of individual services
to build, test, deploy and run, possibly in polyglot languages and environments21
. This over-
head will increase exponentially as you add more microservices to your application.
While monitoring each individual service instance is easier (because they are doing less),
the cost to monitor the entire application is higher and it’s difficult to debug behaviour
that spans many services22
. Well defined service boundaries will improve this issue, while
ill-chosen boundaries will make it worse.

13
Testing within each service is straightforward as the test surface is smaller and developers
can test services locally, but testing the entire application as a whole and how services func-
tion with one another can be complicated.
Substantial DevOps Skills Required
Handling the complexity involved in maintaining a microservices based application with
lots of services that continuously are being redeployed requires many new skills and tools. It
reinforces the necessity of using Continuous Delivery and DevOps. Without the automation
and collaboration that Continuous Delivery promotes, controlling a swarm of services is
simply not possible23
. You’ll also need a DevOps culture24
with deep collaboration between
developers, operations and all others involved in software delivery. Experienced DevOps
teams with a high level of expertise that can keep the microservices up and available are
hard to find.
“Without the automation and collaboration that
Continuous Delivery promotes, controlling a swarm of
services is simply not possible.”
Eventual Consistency
Microservices introduce eventual consistency issues due to decentralised data management.
As microservices entails updating multiple resources, developers need to be aware of this
and work out how to identify when things become out of sync. Business logic risk acting
on inconsistent information, and when this occurs it can be difficult to identify where the
problem is as the inconsistency window will have closed by the time you try to diagnose the
issue25
.
API mismatch
Services rely on the interfaces between them to communicate and for this to work flawlessly,
messages must have a format and semantics that every interface can read26
. As all services
are interrelated, modifying one service’s interface can introduce errors such as message
format differences between API versions. To avoid this, you need to adjust all the other
interfaces as well so other services can understand that change. This requires many changes
that need to be released in a coordinated fashion, although some changes can be avoided
with backwards compatibility approaches.
Security
Security has been named one of the biggest barriers to container adoption27
and cloud-
hosted microservices present new security challenges28
that must be addressed to avoid
vulnerabilities, including:
• More attack surfaces: With more moving parts, there are more potential vulnerabilities
to exploit for attackers.

14
• Less internal consistency: Microservices allow developers to shift programming lan-
guages and frameworks. However, any time something changes, new vulnerabilities
may appear.
• Existing tools don’t address securing microservices: Most existing security tools were
created before microservices made their way to the enterprise. New alternatives are
emerging, but off-the-shelf security tools are still limited, which means companies have
to be particularly careful when securing their microservices based applications.
• New trust relationships: With containerised infrastructure, you can easily download
and deploy container images from public repositories at no cost. However, this means
you’re incorporating third-party software into your stack and you can never guarantee
the security of code that you’re not in control of.
These challenges mean architects have to rethink how to secure applications. But with the
proper strategies29
, security risks can be mitigated:
• Secure the internal environment: Make sure your hosting environment is as secure as it
can be. For a Docker cloud environment, this implies limiting access to the cloud host
and configuring Docker to prevent public internet connections except where needed.
• Use security scanners: Tools such as Docker Security Scanning helps finding and fixing
security vulnerabilities inside containers.
• Use access control: Apply access-control limitations at multiple levels of the software
stack to mitigate security risks.
• Assure communication: Make sure everyone involved in building and deploying soft-
ware doesn’t operate in silos but communicate continuously so they’re aware of poten-
tial security implications with changes.
As more and more enterprises start using microservices, security will eventually get easier to
manage. Microservices can actually also improve security through isolation between appli-
cation components—mitigating the risk that a breach in one component enables attackers
to compromise the whole stack. They also provide resilience against DDoS attacks as con-
tainers allow superior flexibility and scalability.
Should your business use microservices?
While many teams have found microservices to be a superior approach, others have found
them to be a burden that reduce productivity. Like any architectural style, microservices
have both advantages and downsides. To make a correct decision and determine if micro-
services is right for them, companies have to understand the trade-offs and apply them to
their specific context. Not every application is complicated enough to warrant being broken
into microservices and in many use cases the complexity of microservices may hamper the
team’s productivity.
“Not every application is complicated enough to
warrant being broken into microservices.”

15
The microservices premium30
is the cost organisations pay in reduced productivity to learn
and manage microservices, and this cost will only be justified for complex applications.
As a software system increases in complexity, the premium is outweighed by the fact that
microservices alleviate the productivity loss caused by mounting complexity.
There comes a point when an application becomes complex enough or the number of engi-
neers working on it grows past 50-75 that the benefits of a microservices architecture begin
to take off31
. Adopters like GE, Goldman Sachs and Airbnb say it’s been well worth the
tradeoff and that the benefits far outweigh the costs. As more organisations adopt the micro-
services model, improved tools will also emerge to manage the increasing complexity.
6
THE MICROSERVICES PREMIUM
For less complex systems,
the added effort required to
manage microservices
reduces productivity
As complexity rises, productivity falls
rapidly with monolithic applications
The benefits of microservices outweighs
the added effort to manage microservices
Productivity
Base Complexity
Microservices
Monolith
NB: The level of team skills is more important
than any monolith/microservices consideration
The microservices premium (Image adapted from martinfowler.com)
Adopting microservices
It can be dispiriting for DevOps advocates observing companies like Spotify and Sound-
Cloud that successfully have adopted microservices and want to implement them in their
own enterprise setting. If you’re not a startup or a born digital company, you won’t be
designing a microservice based system from scratch and likely have a legacy of culture,
organisation, processes, tools, services and architecture standing in the way. Applications
are likely too tightly coupled to the rest of the architecture to be independently developed,
deployed and qualified32
.
Embracing microservices requires significant planning, discipline and coordination with
new toolsets and a change in team dynamics that will affect all aspects of the organisation.
To execute successfully, the approach requires considerable organisational and cultural
adjustment.
Before you take a microservices system into production, you need to make sure you have
certain key prerequisites in place. If your organisation doesn’t have these capabilities, you
need to obtain them before you put a microservice application into production. The capa-
bilities are highly relevant for monolithic systems too. In fact, one can argue that DevOps,
Continuous Delivery and automation are more important than microservices.

16
Prerequisites
Rapid Provisioning: You need the capability to spin up a new server in a few hours33
.
This fits in with cloud computing, but can be accomplished without a complete cloud service.
Rapid provisioning requires automation. Being able to automate your systems and push
code updates regularly are critical to deal with the complexity you will incur with micros-
ervices architecture.
Monitoring: With many loosely-coupled services working together in production, things
will inevitably break in ways that are hard to notice in test environments34
. Microservices
require a far more comprehensive monitoring effort to uncover problems quickly than mon-
oliths do. If an unexpected problem appears, you need to ensure you can quickly rollback.
The microservices monitoring landscape is currently fragmented; there is no clear winner
and some companies are building their own products.
Rapid deployment: With many services to manage, you have to be able to deploy them
quickly—both to test environments and to production. This will typically comprise a deploy-
ment pipeline that can execute in a few hours at maximum35
. The objective should be to fully
automate it, although some manual intervention will probably be required at the first stage.
DevOps and Continuous Delivery: DevOps is a key enabler for microservices and pro-
vides the framework for developing, deploying, and managing the container ecosystem.
Close collaboration between developers and operations is a must to make sure that pro-
visioning and deployment can be done quickly36
. It’s also important to make sure you can
respond quickly when monitoring signals an issue. Any incident management has to involve
the development team and operations—both in resolving the immediate problem and the
root-cause analysis to make sure the underlying issues are fixed.
Culture: There is need for strong organisational support and an overall shift in the IT cul-
ture to succeed with microservices. Organisations have to increase their tolerance for risk
and learn to fail gracefully, fast and often to achieve success. The culture must also embrace
automation of deployment and testing. For developers, operations and testing engineers
with long experience in monoliths, a microservices-based system is a new reality and they
will need time to manage this shift.
Organisation: The most challenging aspects of moving from a monolith to microservices
are the organisational changes required, such as building services teams that own all aspects
of their microservices. Small, agile teams who can integrate their work frequently are an
important precursor to microservices. A cornerstone involves promoting collective code
ownership and fostering software craftsmanship.
You also need to shift towards product centred teams, and organising your development
environment so developers can effortlessly switch between multiple repositories, libraries
and languages.
Governance: As microservices involve a variety of technologies and platforms, centralised
governance isn’t optimal. The microservices community favours decentralised governance
as its developers strive to produce useful tools that can then be used by others to solve the

17
same problems37
. Netflix, for example, encourages developers to save time by using code
libraries established by others.
However, you must design and manage your evolution to microservices, or the result will be
an uncontrollable sprawl. It’s key to have a cross-functional team in charge of the develop-
ment, maintenance and operation of microservices that’s distinct from those managing the
monolithic application38
. This team should understand how the components fit together,
control architectural decisions, guide the creation of new services and ensure standards
adoption. To avoid creating duplicates of services, create a shared repository of all services
for teams to use in development.
Microservice architecture also favours decentralised data management. Monolithic systems
use one logical database across different applications. But in a microservice application,
every service normally manages its own database.
Security: More surfaces and complexity raise security requirements39
. You need to think
about how you’ll authenticate who can speak to whom and identify illicit traffic. It also
involves taking decisions on who has authority to work on certain services, if all services
are to be used for all tasks in the organisation, and how shared services will be billed and
managed.
Moving from monolith to microservices
With the above foundational capabilities in place, your organisation is ready for a first sys-
tem using a handful of microservices.
1. Before splitting out services, it’s key that you understand your system’s domain and
what it does, to be able to identify proper bounded contexts for services. Getting service
boundaries wrong can result in having to make costly changes in service-to-service col-
laboration later on40
.
2. Begin by identifying non-critical functionality in the monolithic application that is
rather loosely coupled with the rest of the system. Take one piece at a time and break it
off. Once the piece is working, move to the next. A more forceful approach can lead to
lost functionality and make it hard to diagnose problems. Another option is to dictate
that all new functionality is built as microservices.
3. Move gradually to develop an understanding of your organisation’s ability to change.
Allow the new paradigm to settle and give the organisation time to grow new capabili-
ties, build the tooling and processes necessary to manage microservices well, learn about
keeping the new system healthy and ensuring the DevOps collaboration is working well
before you ramp up your number of services.
4. Begin with some coarse-grained but self-contained services41
. You can fine-grain the ser-
vices as the implementation progresses. Coarse-grained services result in fewer network
calls between the monolith and the microservices.
5. Minimise changes being made to the monolith for supporting the transition in order to
lower maintenance cost and reducing the impact of the migration.
6. The monolithic application must be adapted to support feature toggling—enabling you
to switch between using the new service and the code in the monolithic application.

18
You need to have a fallback and prepare for a smooth load transfer to the new service.
Iteratively deprecate similar functionalities in the monolith.
7. To reduce the development and operational costs of the migration, the patterns
employed by the microservices should be appropriate to the monolith’s architecture.
8. A major challenge is to design and develop the integration between the current system
and the new microservices42
. When part of the application is redesigned with microser-
vices, it’s common to write glue code to support communication with the new services.
An API gateway can combine several individual service calls into one coarse-grained
service, to reduce the cost of integrating with the monolithic system.
9. The new microservices should be self-contained with their own runtime environment.
The services should also be deployed on infrastructure that is physically or logically
isolated from the monolith.
10. Create standardised service templates that form boilerplates for development and con-
tain common elements required to support the microservices-based application, such
as monitoring, log collection, metrics and safety mechanisms43
. The boilerplate should
account for polyglot technologies comprising application servers, database, program-
ming language etc. This will lower the ramp up time for development teams and create
standardisation for Operations.
11. Going further than a handful of services will require more effort, including tracing
business transactions through multiple services and automating your provisioning and
deployment by completely adopting Continuous Delivery.
When is the microservice transformation done?
Creating and maintaining an information system is never done and this is also valid for sys-
tems built with microservices. Architects and developers can sometimes spend a lot of time
attempting to identify the “ideal” solution or implementation model for their system design,
which rarely works44
. One advantage of microservices is that change over time isn’t as costly
or risky as it might be in tightly coupled large-scope release models. Perfecting the system is
unviable as it will always be a moving target, and the moment you reach a final state you’ll
start to accumulate technical debt—progressing towards an outdated system that will be dif-
ficult to change. Working according to the microservices model implies many small releases
over time and you’ll continuously be changing and improving something. This means there
will be many milestones along the way that together add up to major changes over time.
Greenfield Projects
For greenfield development, Martin Fowler45
and Sam Newman46
generally recommends
starting new products as monoliths and once you have a sense for how the product will be
used, you can decompose from there. This is because it’s hard to know how best to divide
up a monolith until its usage has been observed and it’s easier to chunk up something you
already have. However, some disagrees47
with this approach, while stressing that it’s abso-
lutely key to know the domain very well before starting.

19
Tools
This article will not go into the technical implementation details of microservices. However,
Matt Miller at Sequoia Capital has produced an excellent map of the Microservices Ecosys-
tem48
, containing both commercial and open source projects important to microservices
today. Toolsets that need to be added to the stack includes orchestration, monitoring, secu-
rity, inter-service communications, API Management etc. The most straightforward way
to get started is with Docker49
, which is an attractive platform for both startups and enter-
prises due to the available number of tools and the ecosystem around it. You can register
for a hosted container service such as Google Container Engine or Amazon EC2 Container
Service to obtain a sense of what it’s like to deploy and manage containerised applications.
About the authors
Jesper Nordström is Head of Insights at 3gamma and also leads the firm's digital acceler-
ation practice. With a cross-disciplinary background, he has extensive experience working
at the intersection between business, IT and design – helping companies gain competitive
edge by leveraging digital technologies. Areas of expertise include digital transformation,
innovation strategy and emerging technologies. Jesper holds dual degrees in engineering
and business management.
Tomas Betzholtz is an IT Management consultant within the Emerging Technology capa-
bility at 3gamma. He has over 20 years of experience from the IT industry focusing on IT
architecture and transformation. He has experience from a varying set of companies, from
manufacturing to finance and insurance where he has helped IT organisations improve their
architectural skills to enable business efficiency.

20
References
1. https://techcrunch.com/2016/01/23/get-small-to-get-big-through-microservices/
2. https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture
3. https://medium.freecodecamp.com/an-introduction-to-microservices-2705e7758f9#
4. http://www.nirmata.com/2015/02/microservices-five-architectural-constraints/
5. https://en.wikipedia.org/wiki/Conway%27s_law
6. http://blogs.wsj.com/cio/2015/10/05/innovate-or-die-the-rise-of-microservices/
7. http://www.cio.com/article/2924995/enterprise-software/what-are-containers-and-why-do-you-need-them.html
8. http://www.infoworld.com/article/2906362/data-center/dawn-of-the-data-center-operating-system.html
9. http://a16z.com/2015/04/08/aggregation-is-the-new-virtualization-how-microservices-are-taming-distributed-comput-
ing/
10. http://www.infoworld.com/article/2906362/data-center/dawn-of-the-data-center-operating-system.html
11. http://dupress.com/articles/tech-trends-2015-what-is-api-economy/
12. http://samnewman.io/books/building_microservices/
ing/
ing/
16. http://martinfowler.com/articles/microservice-trade-offs.html
17. http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
18. https://www.nginx.com/blog/building-microservices-inter-process-communication/
19. http://martinfowler.com/articles/microservices.html#DesignForFailure
20. http://blog.xebia.com/microservices-architecture-principle-4-asynchronous-communication-over-synchronous-communi-
cation/
27. http://www.infoworld.com/article/3029772/cloud-computing/how-to-secure-containers-and-microservices.html
28. http://searchcloudapplications.techtarget.com/tip/Everything-you-need-to-know-about-securing-microservices
29. http://searchcloudapplications.techtarget.com/tip/Everything-you-need-to-know-about-securing-microservices
30. http://martinfowler.com/bliki/MicroservicePremium.html
32. https://devops.com/2015/03/03/avoiding-common-executive-devops-mistakes/
33. http://martinfowler.com/bliki/MicroservicePrerequisites.html
37. https://smartbear.com/learn/api-design/what-are-microservices/
38. http://thenewstack.io/microservices-four-essential-checklists-getting-started/

21
42. http://thenewstack.io/from-monolith-to-microservices/
44. http://transform.ca.com/API-microservice-architecture-oreilly-book.html
45. http://martinfowler.com/bliki/MonolithFirst.html
46. http://samnewman.io/blog/2015/04/07/microservices-for-greenfield/
47. http://martinfowler.com/articles/dont-start-monolith.html
48. https://www.sequoiacap.com/article/build-us-microservices/
49. http://searchvirtualdesktop.techtarget.com/opinion/What-is-Docker-and-what-does-it-mean-for-virtualization
50. https://blog.risingstack.com/how-enterprises-benefit-from-microservices-architectures/
51. http://www.mckinsey.com/business-functions/business-technology/our-insights/beyond-agile-reorganizing-it-for-fast-
er-software-delivery

Architecting for speed: how agile innovators accelerate growth through microservices

24
ABOUT 3GAMMA
3gamma provides independent technology strategy consulting and IT advisory services to industry leading
companies across sectors. Operating from offices in Sweden, UK and Denmark, we work closely with senior
executives, strategists and technologists to accelerate growth and seize the opportunities of the digital age.
Through our six capabilities we help clients realise the maximum value of their technology investments and
ensure that their technology operations are agile, effective and support innovation:
• Strategy & Governance
• Emerging Technologies
• Sourcing & Legal
• Risk & Assurance
• Operational Excellence
• Transformation & Change
3gamma Insights brings leading-edge thinking at the intersection of IT and business, illuminating central topics
relevant to CIOs and decision makers.
STOCKHOLM
3gamma Sweden AB
Centralplan 15
SE-111 20 Stockholm
Sweden
Phone: +46 8 748 0330
GOTHENBURG
3gamma Sweden AB
Drottningtorget 5
SE-411 03 Göteborg
Sweden
Phone: +46 31 309 7910
DENMARK
3gamma ApS
Frederiksborggade 15
DK-1360 Copenhagen K
Phone: +45 53 700 400
MALMOE
Adelgatan 21
SE-211 22 Malmö
Sweden
Phone : +46 40 630 4610
UNITED KINGDOM
The News Building
3 London Bridge Street
London SE1 9SG
United Kingdom
Phone +44 (0) 203 743 6104

Architecting for speed: how agile innovators accelerate growth through microservices

More Related Content

What's hot (19)

Viewers also liked (11)

Similar to Architecting for speed: how agile innovators accelerate growth through microservices (20)

Recently uploaded (20)

Architecting for speed: how agile innovators accelerate growth through microservices