Advanced Software Engineering

Microservices Architecture

1
What is happening?
• We now live in Microservices Era,
• Microservices (MicroS) is an architectural pattern
• MicroS is an architecture for distributed processing
• In the past, all architectures could be considered as Monolith
Architectures (traditional architecture patterns)
• Service Oriented Architectures (SOA) was introduced to
address issues of Monolith in 2001
• Many problems in 2010
• MicroS was introduced around 2011, became very popular
after 2015
• Now it could be implemented in any platform

2
Who are using?- Warning !
• Almost everyone (they say)
• Some interesting applications
• Netflix, facebook, amazon, uber, ebay
• It is not a silver bulet
• Will not solve all problems in the software problem
• If MicroS are implemented incorrectly, without addressing root flaws
in the system, a new product will be in crisis due to complexity
(Alexandra Noonan, SA, Segment)

3
Before Microservices
• Architectures didn’t directly support distributed processing
• Architecture segmented processing
• E.g. Client-Server Architecture
• High Coupling
• Monolith Architecture
• Doesn’t support modern requirements
• E.g Continuous Integration or Continuous Development (new version replaces the
current version)

4
Issues of Monolith Architecture
• Single Technology Platform
• All components should be in the same technology
• E.g. .net, nodejs, ….
• Due to centralization – one technology governs all components
• “Decentralization Governance” of Micro.Serv. Solves this issue
• Different components in different platforms (one module in .net, antoehr in Java,
another in nodeJS)
• Is this good approach?

5
History before 2010 in Software Arch.
• Two popular paradigms (Architecutre Styles)
• Monolith
• SOA
• What is Monolith Architecture?
[Single Family Culture]
• Single Process / No or Poor Distribution
• Strong coupling among classes
• Implemented in Silo/Stand Along culture [They live in their word]

6
Example

7
Good things about Monolith
• Easier to design
• Less problems in implementation
• All for one, one for all
• Internal communication for functionality
• Performance ?
•…

8
 Software Monolith

• One build and deployment unit.

• One code base.

• One technology stack (Linux, JVM, Tomcat, Libraries).

• Benefits
• Simple mental model for developers
• one unit of access for coding, building, and deploying

• Simple scaling model for operations

• just run multiple copies behind a load balancer

9
Monolith Architecture

Load Balancer

Monolithic App
Account Catalog
Component Component

Recommendation Customer Service Database

Component Component

Monolithic applications can be successful, but increasingly people are feeling

frustrations with them - especially as more applications are being deployed to
the cloud .
10
 Layered Systems

• A layered system decomposes a monolith into layers.

• Usually: presentation, logic, data access.

• At most one technology stack per layer

• Presentation: Linux, JVM, Tomcat, Libs, EJB client, JavaScript
• Logic: Linux, JVM, EJB container, Libs
• Data Access: Linux, JVM, EJB JPA, EJB container, Libs

• Benefits
• Simple mental model, simple dependencies
• Simple deployment and scaling model

11
Service Oriented Architecture (SOA)

12
What is SOA?
• Coined 1998, a kind of distributed architecuture
• Apps provide services to other application
(Integration of application)
• Services are described using metadata of their
functionality
• Implemented using SOAP or WSDL
• XML based API for services
• Implemented with ESB
• Chanel for communicating the services
• Validating, Routing, monitoring, authenticating,… (too
many things by one channel)

13
 Problems with Layered Systems

• Still huge codebases (one per layer).

• ... with the same impact on development, building, and deployment.

• Scaling works better, but still limited.

• Staff growth is limited: roughly speaking, one team per layer works
well
• Developers become specialists on their layer.
• Communication between teams is biased by layer experience (or lack
thereof).

14
Pros of SOA
• Sharing data and functionality

• Polyglot between services

[Multilingual]
• Java Service could communicate with .Net Service

15
Problems of Monolith
• Unique Technology for the platform
• If different components could benefit from different
technologies
• Some components – NodeJS, others .Net/Java
• Not possible
• Inflexible Deployment
• Monolith – deploy whole applications (new version replaces)
• Deploy only a part (update only one component)
• Changes in one component results testing whole app.

16
Problems …
• Resource Management
• With monolith, CPU/RAM cannot be allocated wrt components
• Increase performance, some components need more
resources
• Family concept & Round Robin (your turn)
• Large and Complex (codebase)
• Difficult to make change things (affect others)
• Testing cannot detect all issues
• Difficult to maintain-> obsolete (Don’t do new things)

17
Problems with Software Monolith

• Huge and intimidating code base for developers.

• Development tools get overburdened

• refactorings take minutes
• builds take hours
• testing in continuous integration takes days

• Scaling is limited
• Running a copy of the whole system is resource intense
• It doesn’t scale with the data volume out of the box

• Deployment frequency is limited

• Redeploying means halting the whole system
• Redeployments will fail and increase the perceived risk of deployment
18
 Problems …

• Area of consideration
• Web systems
• Built collaboratively by several development teams
• With traffic load that requires horizontal scaling (i.e. load
balancing across multiple copies of the system)

• Observation
• Such systems are often built as monoliths or layered systems

19
Problems of SOA
• Complicated and Expensive ESB
• ESB is doing everything, implementation is hard
• Expensive and complicated
• Difficult to maintain

• Inadequate tools for quick testing/manual (forced to

manual way)

20
Problems with Service Oriented Architecture

• Incremental change [BAD]

• Operationally complex [BAD] 21
Lot of Services!!!

22
 History

Requirement of architecture with modular and simple API

identified before 2011

• 2011: First discussions using this term at a software

architecture workshop near Venice

• May 2012: microservices settled as the most appropriate term

Martin Fowler

• Martin Fowler and James Lewis published

“Microservices” article
• De-facto standard
• https://martinfowler.com/articles/microservices.
html
James Lewis
23
 What is Microservices Architecture?

• Definition:
• In short, the microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies [martinfowler.com]

• On the logical level, microservice architectures are defined by a

• functional system decomposition into manageable and independently
deployable components

24
9 Guidelines for Microservices
1. Componentization Vs Services
2. Organized around business capabilities
3. Products not Projects
4. Smart Endpoints and Dump Pipes
5. Decentralized Governance
6. Decentralized Data management
7. Infrastructure Automation
8. Design for Failures
9. Evolutionary Design

25
Monolith vs Microservices
Monolith VS Microservices
(1) Componentization via Services
● Modular Design – a good for SW Design
● Software is a collection of components (modules)
● Component is independently replaceable and
upgradeable
● Modularity is implemented
○ Libraries - #include, import ..*, within the process
○ Services – Web API, RPC – out of process of mechanism
● In MicroS, Modularity as the service
○ A library could be inside the service
Towards Microservice implementation

29
Pros of Service - Components
● Independent Deployment
● Well defined interface

30
(2) Organized Around Business Capabilities
● In traditional projects, teams have horizontal responsibilities
○ Slow, cumbersome intergroup communication

31
Organized Around Business
Capabilities (2)
Organized Around Business Capabilities (3)
● One team handles a well-defined business capability/function
● Team has one goal
○ Full-stack team
○ Faster Development
● Well-defined boundaries of these business capabilities are required

33
(3) Products; not projects
What is the issue
● In SE Projects, we want to deliver working software/code (i.e.
products) but team doesn’t undertake the ownership
● No relationship between team and customers
● After delivering, the team moves to the next project

34
Products not projects ..
● In Microservices, the goal is to deliver a working
product which is more than working software
○ Requires good relationship with the customer
○ Have to provide the support
○ Team undertakes the ownership (responsible after the
delivery)
● You build it, you run it !
○ By Werner Vogels (CTO, AWS)
○ Corresponds to Agile Manifesto (promotes involvement
customer involvement/satisfaction, mindset of stakholders)

35
 (4) Smart End points and not dump pipe
lines
● Inter-service communication complicated and difficult to maintain
○ SOA uses ESB, WS-* protocol
● “dump pipes” – simple protocols
○ HTTP -> REST API

36
From ESB -> REST

37
Issues – of Service Communication
● Direct connections between services
○ Is it good? Why
○ What Alternatives
■ Discovery Service
■ Gateways
● Alternatives for REST ? GraphQL, gPRC – not simple
○ Make it Simple for development and maintence
○ Simple logic and easy code

38
(5) Decentralized Governance
● Standards for practices/decisions to be taken
○ Selecting database, dev platform, solving problems
● In Microservice, the team are granted permission to take
decisions
○ Take optimal technical decisions and take responsibility (right
tool for the job)
● Loosely coupled nature of services
○ No effect on other services
○ Implementing same thing using different platforms (Polyglot)

39
(6) Decentralized Data Management
● Traditional system, one database for all components in the system
● In microservices, each service has their database
○ Is it possible? What are issues?
■ Updating two databases for one transaction???

○ Why separate database

■ Each business capabilities want to manage
● Right tool for right task
○ SQL for Structured, NoSQL for unstructured data
● Consider case by cases (encouraging isolation)

40
(7) Infrastructure Automation
● Tools and Automation important for success of paradigm
○ Automated Testing/Deployment
● Short deployment cycles depend on automation (cannot done manually)
○ Lot of automation tools

41
(8) Design for Failure
● Complicated means more failures, then must protect
the reliability
● Lot of services/processes -> (high) communication
overhead/network traffic
○ Communication fails OR service goes down
● Codes must assume failures (exceptions)
● Logging events/exceptions
○ Investigate
● Independent monitoring
● Third party product for Monitoring

42
(9) Evolutionary Design
● Move to Microservice should be gradual
● No need to break everything/all parts into services
● Start small and expand to other parts

43
9 guidelines for Microservices
● Not mandatory instructions
● Adopt what works for you
● Some guidelines are problematics in some projects
● Things are changing – nothing permanent

44
Need of an Architectural Pattern

45
Problem with Architectural Patterns

Yesterday’s best practice is tomorrow’s

anti-pattern.

We inadvertently build architectures to

solve outdated problems.

46
Valued Business Drivers

Better Cheaper Faster

• Resilient • Test effort • Change
• Technology • Cost of • Deployment
choice maintaining • Execution

47
Trends in Software Development

Platform as Autonomous Continuous Agile

a Service teams Delivery Organization

Reactive
manifesto

48
Availability

A single missing “;” brought down the Netflix website for many
hours (~2008)

49
Conway’s Law

“organizations which
design systems ... are
constrained to produce
designs which are copies
of the communication
structures of these
organizations”
—Melvin Conway
50
 Microservice Architecture (1)

• Features:
• Distributed architecture
• separately deployed components
• Service components
• Bounded context
• Service orchestration

51
Microservice Architecture (2)

Load Balancer

API Gateway

Account Service Catalog Catalog

Service DB

Recommendation Customer Service Customer

Service Service DB

52
Simple and Lightweight

53
Independent Processes

54
Language Agnostic APIs and Decoupled Services

"Language agnostic" describes a software development paradigm where a

particular language is chosen because of its appropriateness for a particular task
(taking into consideration all factors, including ecosystem, developer skill-sets,
performance, etc.), and not purely because of the skill-set available within a
development team.
55
Size matters (not)

• It’s not about

lines of code used
• Small enough to
– Be handled by a
single team
– Not feel “big”

56
Slicing

Change your approach to vertical partitions

• Modeled after organization’s domains

• Owned by team
• Top to bottom
• Isolated from each other as much as possible

57
From monolithic to microservices

58
Why use Microservices Architecture
• Faster and simpler deployments and rollbacks
• Independent Speed of Delivery (by different teams)

• Right framework/tool/language for each domain

• Greater Resiliency
• Fault Isolation

• Better Scaling
• A microservices architecture puts each element of functionality
into a separate service and scales by distributing these services
across servers, replicating as needed.

• Better Availability 59
• If architected right
Microservices Challenges

Can lead to chaos if not designed right …

60
61
When to use Microservices Architecture
• When you need to support Desktop, web , mobile, Smart TVs,
Wearable, etc... or you don't know in future which kind of devices
you need to support.

• You are developing a server-side enterprise application. It must

support a variety of different clients including desktop browsers,
mobile browsers and native mobile applications. The application
might also expose an API for 3rd parties to consume. It might also
integrate with other applications via either web services or a
message broker. The application handles requests (HTTP requests
and messages) by executing business logic; accessing a database;
exchanging messages with other systems; and returning a
HTML/JSON/XML response.
62
When to use Microservices Architecture

63
Complexity

• Distributed Systems are inherently Complex

• N/W Latency, Fault Tolerance, Retry storms ..

• Operational Overhead

• TIP: Embrace DevOps Model

64
Service Discovery (1)

• 100s of MicroServices
• Need a Service Metadata Registry (Discovery Service)

Account Service Catalog

Service Registry
Service
(e.g. Netflix Eureka)
Recommendation Customer Service
Service Service

X
Service Y Z
Service Service

65
Service Discovery (2)

66
Chattiness (and Fan Out)
2 Billion Requests per day on Edge Service
Results in ~20 Billion Fan out requests in ~100 MicroServices

1 Request 1 Request

Monolithic App MicroServices

67
Testing
• A single microservice isn‘t the whole system.

• A clear picture of upstream and downstream services

is needed for integration testing

68
Prerequisites

• Before you go into production with a

microservices system, you need to ensure
that you have key prerequisites in place
• Rapid Provisioning
• Dev teams should be able to automatically
provision new infrastructure
• Basic Monitoring
• Essential to detect problems in the complex
system landscape
• Rapid Application Deployment
• Devops Culture
69
Versioning
• Microservice architectures enable independent evolution
of services – but how is this done without breaking
existing clients?

• There are two answers

• Version service APIs on incompatible API changes
• Using JSON and REST limits versioning needs of service APIs

• Versioning is key
• Service interfaces are like programmer APIs – you need to know
which version you program is in.
• As service provider, you need to keep old versions of your
interface operational while delivering new versions.

70
API compatibility
• There are two types of compatibility

• Forward Compatibility
• Upgrading the service in the future will not break existing clients
• Requires some agreements on future design features, and the
design of new versions to respect old interfaces

• Backward Compatibility
• Newly created service is compatible with old clients
• Requires the design of new versions to respect old interfaces
The hard type of compatibility is forward compatibility!

71
Further Challenges
• Transactions
• Instead of distributed transactions, compensations are
used (as in SOA)

• Authentication
• Is often offloaded to reverse proxies making use of
authentication (micro)services

• Request logging
• Pass along request tokens
• Add them to the log
• Perform log aggregation

72
Benefits of Microservices
• Asynchronicity
• Integration & Disintegration
• Complected (intertwined)Deployments
• Evolutionary Architecture
• Reduction of release risk

• Backends for Frontend

73
Inverse Conway Maneuver
Build teams that look like the architecture you want
(and it will follow).

74
Efferent Coupling

• Strive for low efferent coupling for your team.

• Efferent Coupling (Ce) is also known as Outgoing Dependencies or the Number of

Types inside a Package that Depend on Types of other Packages. Ce is a metric for
packages. In short, this measure includes all the types within the source of the
measured package referring to the types not in the measured package.

• Teams with low efferent coupling deliver relatively independently into a common
integration pipeline (without fearing breaking each others builds.

75
Do choreography instead orchestration
• What is service orchestration? It's the process of
managing different services and the dependencies
between them such that we promote the principles of
loose coupling.

• What is choreography? Choreography is the process of

agreeing, between the dancers, how a dance will be
performed before it is performed.

• One thing with micro-services that people get caught up

on is how to do orchestration. The answer is don't.
Instead of doing orchestration, do choreography.

76
Low coupling and high cohesion
• Low coupling and high cohesion.

• Coupling: Measurement of dependency between

two components. Expressed as sensitivity towards
propagation of changes and errors.

• Cohesion: Degree to which parts of a module belong

together.
Coincidental Procedural Sequential Functional
Logical Temporal Informational
cohesion cohesion cohesion cohesion
cohesion cohesion cohesion
(worst) • part of fixed • Output of one is (best)
• executed at a • operating on the
• same in nature execution used as input by • contributing to a
• random particular time same data
sequence another single task

77
Advantages of Microservices
• Each micro service is small and focused on a specific feature / business
requirement.
• Microservice can be developed independently by small team of developers
(normally 2 to 5 developers).
• Microservice is loosely coupled, means services are independent, in terms
of development and deployment both.
• Microservice can be developed using different programming language.
• Microservice allows easy and flexible way to integrate automatic
deployment with Continuous Integration tools (for e.g: Jenkins, Hudson,
bamboo etc..).
• The productivity of a new team member will be quick enough.
• Microservice is easy to understand, modify and maintain for a developer
because separation of code,small team and focused work.

78
Disadvantages of Microservices
• Microservice architecture brings a lot of operations overhead.

• DevOps Skill required (http://en.wikipedia.org/wiki/DevOps).

• Duplication of Effort.

• Distributed System is complicated to manage .

• Default to trace problem because of distributed deployment.

• Complicated to manage whole products when number of services

increases.
79
Who uses Microservices?
• Most large scale web sites including Twitter, Netflix, Amazon
and eBay have evolved from a monolithic architecture to a
microservices architecture.

Microservices at Netflix
80
 Growing Beyond Limits

• Applications and teams need to grow beyond the limits imposed by

monoliths and layered systems, and they do in an uncontrolled way.

• Large companies end up with landscapes of layered systems that

often interoperate in undocumented ways.

• These landscapes then often break in unexpected ways.

• How can a company grow and still have a working IT architecture

and vision?
• Observing and documenting successful companies (e.g. Amazon, Netflix) lead
to the definition of microservice architecture principles.
81
 What is Microservices Architecture?

• The term “micro” refers to the sizing: a microservice must be

manageable by a single development team (5-9 developers).

• Functional system decomposition means vertical slicing (in contrast

to horizontal slicing through layers).

• Independent deployability implies no shared state and inter-process

communication (often via HTTP RESTish interfaces).

• Microservice is the first architectural style developed for post-

Continuous Delivery. 82
ACID vs BASE

83
 Other definitions

• Small and
focused on
doing one
thing well
• Autonomous
“Loosely coupled service
oriented architecture with “… services are independently deployable and
bounded contexts” scalable, each service also provides a firm
Adrian Cockcroft (Netflix) module boundary, even allowing for different
services to be written in different programming
“SOA done right” languages.”
Anonymous Martin Fowler (Thoughtworks)
84
Points about Microservices Architecture

• Each microservice is functionally complete with

• Resource representation
• Data management

• Each microservice handles one resource (or verb), e.g. Clients, Shop Items, Carts,
Checkout

• Microservices are fun-sized services, as in “still fun to develop and deploy”

• Independent Deployability is key

• It enables separation and independent evolution of

• code base
• technology stacks
• scaling 85
• and features, too
 Independent Codebase

• Each service has its own software repository.

• Codebase is maintainable for developers – it fits into their

brain.

• Tools work fast – building, testing, refactoring code takes

seconds.

• Service startup only takes seconds.

• No accidental cross-dependencies between code bases.

86
 Independent Technology Stack
• Each service is implemented on its own technology stacks.

• The technology stack can be selected to fit the task best.

• Teams can also experiment with new technologies within a single

microservice.

• No system-wide standardized technology stack also means

• No struggle to get your technology introduced to the canon
• No piggy-pack dependencies to unnecessary technologies or libraries
• It‘s only your own dependency hell you need to struggle with

• Selected technology stacks are often very lightweight

• A microservice is often just a single process that is started via command line,
and not code and configuration that is deployed to a container. 87
 Independent Scaling

• Each microservice can be scaled independently

• Identified bottlenecks can be addressed directly

• Data sharding can be applied to microservices as needed

• Parts of the system that do not represent bottlenecks can

remain simple and un-scaled

• Microservices can be extended without affecting other services

• For example, you can deploy a new version of (a part of) the UI
without re-deploying the whole system
• You can also go so far as to replace the service by a complete rewrite
• But you have to ensure that the service interface remains stable 88
 Inter-communication

• Communication between microservices is often standardized

using
• HTTP(S) – battle-tested and broadly available transport
protocol
• REST – uniform interfaces on data as resources with known
manipulation means
• JSON – simple data representation format

REST and JSON are convenient because they simplify interface

evolution
89
 Bounded Context
• Bounded Context is a central pattern in Domain-Driven Design.

• It is the focus of DDD's strategic design section which is all about dealing with
large models and teams.

• DDD deals with large models by dividing them into different Bounded Contexts
and being explicit about their interrelationships.

90
 Polyglot Persistence
• In computing, a polyglot is a computer program or script written in a valid form of multiple
programming languages, which performs the same operations or output independent of
the programming language used to compile or interpret it

• Generally polyglots are written in a combination of C (which allows redefinition of tokens

with a preprocessor) and a scripting language such as Lisp, Perl or sh.

• Complex applications combine different types of problems, so picking the right language
for the job may be more productive than trying to fit all aspects into a single language.

• One of the interesting consequences of this is that we are gearing up for a shift to polyglot
persistence- where any decent sized enterprise will have a variety of different data storage
technologies for different kinds of data.

• This polyglot affect will be apparent even within a single application, a complex enterprise
application uses different kinds of data, and already usually integrates information from
different sources. 91
SOA vs Microservices
• What “Traditional” SOA Got Right
• Breaking monoliths into services
• Focus on integration over internal coupling
• Prefer BASE to ACID

• What “Traditional” SOA Missed

• Architecture is abstract until operationalized.
• Impact of Conway’s Law
• Didn’t support easy change (ESB pattern)

• It is often thought as decomposition within tiers, and introducing another

tier – the service orchestration tier
92
 SOA vs Microservices
Public APIs: SOA:
Better Customer Better Apps +
Experience Integration

API Management
“Here is
The API is “This is WSDL is Backend
…And the what I
the what I the App is the
product have to
contract need…” Contract Product
offer…”

Microservices:
Improved Developer
Experience
Microservices Focus on Change 93
Characteristics
• Componentization via Services
• Organized around Business Capabilities
• Products not Projects
• Smart endpoints and dumb pipes
• Decentralized Governance
• Decentralized Data Management
• Infrastructure Automation
• Design for failure
• Evolutionary Design
94
Componentization via Services
• Interaction mode: share-nothing, cross-process
communication

• Independently deployable (with all the benefits)

• Explicit, REST-based public interface

• Sized and designed for replaceability

• Upgrading technologies should not happen big-bang, all-or-
nothing-style

• Downsides
• Communication is more expensive than in-process
• Interfaces need to be coarser-grained
95
Organized around Business Capabilities (1)
• The microservice approach to division is different, splitting
up into services organized around business capability.

• Such services take a broad-stack implementation of

software for that business area, including user-interface,
persistant storage, and any external collaborations.

• Consequently the teams are cross-functional, including the

full range of skills required for the development: user-
experience, database, and project management.

• Line of separation is along functional boundaries, not along

tiers. 96
Organized around Business Capabilities (2)

97
Products not Projects
• Most application development efforts that we see use a project model:
where the aim is to deliver some piece of software which is then
considered to be completed.

• On completion the software is handed over to a maintenance

organization and the project team that built it is disbanded.

• Microservice proponents tend to avoid this model, preferring instead

the notion that a team should own a product over its full lifetime.

• A common inspiration for this is Amazon's notion of "you build, you

run it" where a development team takes full responsibility for the
software in production.

• This brings developers into day-to-day contact with how their software
behaves in production and increases contact with their users, as they
have to take on at least some of the support burden. 98
Smart endpoints and dumb pipes

• Applications built from microservices aim to be as decoupled and as cohesive as

possible - they own their own domain logic and act more as filters in the classical Unix
sense - receiving a request, applying logic as appropriate and producing a response.
• These are choreographed using simple RESTish protocols rather than complex
protocols such as WS-Choreography or BPEL or orchestration by a central tool.
• Microservice teams use the principles and protocols that the world wide web (and to
a large extent, Unix) is built on.
• Often used resources can be cached with very little effort on the part of developers or
operations folk.
• Uses HTTP request-response with resource API.
• Messaging over a lightweight message bus. The infrastructure chosen is typically
dumb (dumb as in acts as a message router only) - simple implementations such as
RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric
- the smarts still live in the end points that are producing and consuming messages; in
the services.

99
Decentralized Governance
• Principle: focus on standardizing the relevant parts, and leverage battle-
tested standards and infrastructure
• Rather than use a set of defined standards written down somewhere on
paper, prefer the idea of producing useful tools that other developers can use
to solve similar problems to the ones they are facing.
• These tools are usually harvested from implementations and shared with a
wider group, sometimes, but not exclusively using an internal open source
model.
• What needs to be standardized
• Communication protocol (HTTP)
• Message format (JSON)
• What should be standardized
• Communication patterns (REST)
• What doesn‘t need to be standardized
• Application technology stack
100
Decentralized Data Management
• Each service can choose the persistence solution that
fits best its
• Data access patterns
• Scaling and data sharding requirements

• Only few services really need enterprisey persistence

• Microservices prefer letting each service manage its own database, either different instances of
the same database technology, or entirely different database systems - an approach called
Polyglot Persistence. You can use polyglot persistence in a monolith, but it appears more
frequently with microservices.

101
Infrastructure Automation
• Having to deploy significant number of services
forces operations to automate the infrastructure for
• Deployment (Continuous Delivery)
• Monitoring (Automated failure detection)
• Managing (Automated failure recovery)
• Consider that:
• Amazon AWS is primarily an internal service
• Netflix uses Chaos Monkey to further enforce
infrastructure resilience

102
Design for Failure
• A consequence of using services as components, is that applications need to be
designed so that they can tolerate the failure of services.

• Since services can fail at any time, it's important to be able to detect the failures
quickly and, if possible, automatically restore service.

• Microservice applications put a lot of emphasis on real-time monitoring of the

application, checking both architectural elements (how many requests per second is
the database getting) and business relevant metrics (such as how many orders per
minute are received).

• Semantic monitoring can provide an early warning system of something going wrong
that triggers development teams to follow up and investigate.

• Microservice teams would expect to see sophisticated monitoring and logging setups
for each individual service such as dashboards showing up/down status and a variety 103
of operational and business relevant metrics
Evolutionary Design
• The key property of a component is the notion of independent replacement
and upgradeability - which implies we look for points where we can imagine
rewriting a component without affecting its collaborators.
• Indeed many microservice groups take this further by explicitly expecting
many services to be scrapped rather than evolved in the longer term.
• The Guardian website is a good example of an application that was designed
and built as a monolith, but has been evolving in a microservice direction.
• The monolith still is the core of the website, but they prefer to add new
features by building microservices that use the monolith's API.
• This approach is particularly handy for features that are inherently temporary,
such as specialized pages to handle a sporting event.
• Such a part of the website can quickly be put together using rapid
development languages, and removed once the event is over.
• We've seen similar approaches at a financial institution where new services
are added for a market opportunity and discarded after a few months or even 104
weeks.