BSc(Honours) in Software Engineering

PRO210130 - Software Architecture & Design

Micro Services Architecture

©Lanka Nippon BizTech Institute

ACKNOWLEDGEMENT

Presented by: Ms.C.D.Padmaperuma

Lecturer in Information Technology
BSc.in CS(UCSC), MCS, MCSSL

Reviewed by: Prof.K.P.Hewagamage

Software Architecture & Design | Microservices Architecture 2

Microservices Architecture
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
Software Architecture & Design | Microservices
4
Architecture
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)

Software Architecture & Design | Microservices

5
Architecture
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)

Software Architecture & Design | Microservices

6
Architecture
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?

Software Architecture & Design | Microservices

7
Architecture
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]

Software Architecture & Design | Microservices

8
Architecture
Example

Software Architecture & Design | Microservices

9
Architecture
Good things about Monolith

• Easier to design
• Less problems in implementation
• All for one, one for all
• Internal communication for functionality
• Performance ?
• …

Software Architecture & Design | Microservices

10
Architecture
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

Software Architecture & Design | Microservices

11
Architecture
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 .

Software Architecture & Design | Microservices

12
Architecture
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

Software Architecture & Design | Microservices

13
Architecture
Service Oriented Architecture (SOA)

Software Architecture & Design | Microservices

14
Architecture
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)

Software Architecture & Design | Microservices

15
Architecture
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).

Software Architecture & Design | Microservices

16
Architecture
Pros of SOA

• Sharing data and functionality

• Polyglot between services

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

Software Architecture & Design | Microservices

17
Architecture
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.

Software Architecture & Design | Microservices

18
Architecture
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)

Software Architecture & Design | Microservices

19
Architecture
Problems with Software Monolith
• Huge and intimidating code base for developers.

• Development tools get overburdened

• refactoring 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

Software Architecture & Design | Microservices

20
Architecture
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

Software Architecture & Design | Microservices

21
Architecture
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)

Software Architecture & Design | Microservices

22
Architecture
Problems with Service Oriented Architecture

• Incremental change [BAD]

• Operationally complex
[BAD]

Software Architecture & Design | Microservices

23
Architecture
Lot of Services!!!

Software Architecture & Design | Microservices

24
Architecture
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/microservi
ces.html
Software Architecture & Design | Microservices James Lewis
25
Architecture
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
Software Architecture & Design | Microservices
26
Architecture
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

Software Architecture & Design | Microservices

27
Architecture
Monolith vs Microservices

28
Monolith VS Microservices

29
(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

30
Towards Microservice implementation

31
Pros of Service - Components

● Independent Deployment
● Well defined interface

32
(2) Organized Around Business Capabilities

● In traditional projects, teams have horizontal responsibilities

○ Slow, cumbersome intergroup communication

33
Organized Around Business Capabilities (2)

34
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

35
(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

36
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)

37
(4) Smart End points and not dumb pipe lines

● Inter-service communication complicated and difficult to maintain

○ SOA uses ESB, WS-* protocol
● “dumb pipes” – simple protocols
○ HTTP -> REST API

38
From ESB -> REST

39
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

40
(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)

41
(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)

42
(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

43
(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

44
(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

45
9 guidelines for Microservices

● Not mandatory instructions

● Adopt what works for you
● Some guidelines are problematics in some projects
● Things are changing – nothing permanent

46
Need of an Architectural Pattern

Software Architecture & Design | Microservices

47
Architecture
Problem with Architectural Patterns

Yesterday’s best practice is

tomorrow’s
anti-pattern.

We inadvertently build architectures to

solve outdated problems.
Software Architecture & Design | Microservices
48
Architecture
Valued Business Drivers

Better Cheaper Faster

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

Software Architecture & Design | Microservices

49
Architecture
Trends in Software Development

Platform as Autonomous Continuous Agile

a Service teams Delivery Organization

Reactive
manifesto

Software Architecture & Design | Microservices

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

Software Architecture & Design | Microservices

51
Architecture
Conway’s Law

“organizations which
design systems ... are
constrained to
produce designs
which are copies of
the communication
structures of these
organizations”
—Melvin Conway
Software Architecture & Design | Microservices
52
Architecture
Microservice Architecture (1)
• Features:
• Distributed architecture
• separately deployed components
• Service components
• Bounded context
• Service choreography

Software Architecture & Design | Microservices

53
Architecture
Microservice Architecture (2)

Load Balancer

API Gateway

Account Catalog Catalog

Service Service DB

Recommendation Customer Service Customer

Service Service DB

Software Architecture & Design | Microservices

54
Architecture
Simple and Lightweight

Software Architecture & Design | Microservices

55
Architecture
Independent Processes

Software Architecture & Design | Microservices

56
Architecture
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.

Software Architecture & Design | Microservices

57
Architecture
Size matters (not)

• It’s not about

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

Software Architecture & Design | Microservices

58
Architecture
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

Software Architecture & Design | Microservices

59
Architecture
From monolithic to microservices

Software Architecture & Design | Microservices

60
Architecture
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
• If architected right
Software Architecture & Design | Microservices
61
Architecture
Microservices Challenges

Can lead to chaos if not designed right …

Software Architecture & Design | Microservices

62
Architecture
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.
Software Architecture & Design | Microservices
63
Architecture
When to use Microservices Architecture

Software Architecture & Design | Microservices

64
Architecture
Complexity

• Distributed Systems are inherently Complex

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

• Operational Overhead

• TIP: Embrace DevOps Model

Software Architecture & Design | Microservices

65
Architecture
Service Discovery (1)

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

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

X
Service Y Z
Service Service

Software Architecture & Design | Microservices

66
Architecture
Service Discovery (2)

Software Architecture & Design | Microservices

67
Architecture
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

Software Architecture & Design | Microservices

68
Architecture
Testing

• A single microservice isn‘t the whole system.

• A clear picture of upstream and downstream

services is needed for integration testing

Software Architecture & Design | Microservices

69
Architecture
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
Software Architecture & Design | Microservices
70
Architecture
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.

Software Architecture & Design | Microservices

71
Architecture
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!

Software Architecture & Design | Microservices

72
Architecture
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
Software Architecture & Design | Microservices
73
Architecture
Benefits of Microservices

• Asynchronicity
• Integration & Disintegration
• Intertwined Deployments
• Evolutionary Architecture
• Reduction of release risk

• Backends for Frontend

Software Architecture & Design | Microservices
74
Architecture
Inverse Conway Maneuver

Build teams that look like the architecture you want

(and it will follow).

Software Architecture & Design | Microservices

75
Architecture
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.
Software Architecture & Design | Microservices
76
Architecture
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.
Software Architecture & Design | Microservices
77
Architecture
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.

Procedural Sequential Functional

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

Software Architecture & Design | Microservices

78
Architecture
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.
Software Architecture & Design | Microservices
79
Architecture
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.

Software Architecture & Design | Microservices

80
Architecture
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
Software Architecture & Design | Microservices
81
Architecture
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.
Software Architecture & Design | Microservices
82
Architecture
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.

Software Architecture & Design | Microservices

83
Architecture
ACID vs BASE

Software Architecture & Design | Microservices

84
Architecture
Other definitions

• Small and
focused on doing
one thing well
• Autonomous

“Loosely coupled
service oriented “… services are independently deployable
architecture with and scalable, each service also provides a
bounded contexts” firm module boundary, even allowing for
Adrian Cockcroft different services to be written in different
(Netflix) programming languages.”
“SOA done right”
Anonymous Martin Fowler (Thoughtworks)
Software Architecture & Design | Microservices
Architecture 85
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
• and features, too
Software Architecture & Design | Microservices
86
Architecture
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.
Software Architecture & Design | Microservices
87
Architecture
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.
Software Architecture & Design | Microservices Architecture 88
Independent Scaling
• Each microservice can be scaled independently

• Identified bottlenecks can be addressed directly

• Data sharing 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
Software Architecture & Design | Microservices
89
Architecture
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
Software Architecture & Design | Microservices
90
Architecture
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.

Software Architecture & Design | Microservices

91
Architecture
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.
Software Architecture & Design | Microservices
92
Architecture
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

Software Architecture & Design | Microservices

93
Architecture
SOA vs Microservices

Public APIs: SOA:

Better Customer Better Apps +
Experience Integration

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

Microservices: Improved
Developer Experience

Software Architecture & Design | Microservices

94
Architecture
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

Software Architecture & Design | Microservices

95
Architecture
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
• Re-allocation of responsibilities between services is harder

Software Architecture & Design | Microservices

96
Architecture
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.
Software Architecture & Design | Microservices
97
Architecture
Organized around Business Capabilities (2)

Software Architecture & Design | Microservices

98
Architecture
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.
Software Architecture & Design | Microservices
99
Architecture
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.

Software Architecture & Design | Microservices

100
Architecture
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

Software Architecture & Design | Microservices

101
Architecture
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.

Software Architecture & Design | Microservices

102
Architecture
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

Software Architecture & Design | Microservices

103
Architecture
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
of operational and business relevant metrics

Software Architecture & Design | Microservices

104
Architecture
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
weeks.

Software Architecture & Design | Microservices

105
Architecture