TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development

@crichardson
The microservice architecture:
enabling rapid, reliable, frequent
and sustainable development
Chris Richardson
Founder of Eventuate.io
Founder of the original CloudFoundry.com
Author of POJOs in Action and Microservices Patterns
@crichardson
chris@chrisrichardson.net
http://adopt.microservices.io
Copyright © 2020. Chris Richardson Consulting, Inc. All rights reserved

Presentation goal
Microservice architecture:
• Trends driving adoption
• Essential characteristics
• Beneﬁts and drawbacks

@crichardson
About Chris
http://adopt.microservices.io

@crichardson
For slides, more information, raffle,
discounts, …
Raffle: 5 ebooks
+
40% discount
Raffle: 2 free spots
+
20% discount
https://bit.ly/tdc-2020-msa

Agenda
The need to deliver software rapidly, frequently and reliably
Developing long-lived applications
The monolithic architecture is not an anti-pattern
Overview of the microservice architecture
Architecting loosely coupled services

@crichardson
Software
https://www.wsj.com/articles/SB10001424053111903480904576512250915629460

@crichardson
The Marketplace is
Volatile
Uncertain
Complex
Ambiguous

@crichardson
https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2
https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4
https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/
O
VID
-19

@crichardson
Businesses must be nimble,
agile, and innovate faster
IT must deliver software
rapidly, frequently and reliably

@crichardson
Quantifying rapid, frequent
and reliable delivery
Velocity
Lead time - time from commit to deploy
Deployment frequency - deploys per
developer per day
Reliability
Mean time to recover from a
deployment failure (MTTR)
Change failure rate - % of deployments
that cause an outage
Key Lean*
principles
* Inspired by the Toyota Production System

@crichardson
Modern software development: rapid and
reliable
Faster
More reliable

The research shows…
Software Delivery
Performance
Lead time, Deployment
frequency, Mean Time To
Restore, Change Fail %
Organizational
Performance
Proﬁtability, Productivity,
Market share
$
Impacts

@crichardson
Process: Lean/DevOps/Continuous Delivery & Deployment
Organization: Small, long-
lived, product-centric,
autonomous teams
Architecture: ???
Deliver changes to
long-lived
applications rapidly,
frequently and reliably

What is DevOps?
Set of practices where
developers, testers
(dev) and IT operations
(ops) collaborate and
communicate to deliver
software rapidly,
frequently, and reliably
http://itrevolution.com/devops-handbook

Key DevOps practices
ApplicationAutomated deployment pipeline
Repository
Production
Frequent
Commits
Code and
conﬁguration
Reliable and frequent
deployments
Fast and reliable
automated tests

DevOps practices: hypothesis
driven development and A/B testing
A requirement is a
hypothesis that’s often
wrong
Validate by quickly getting
feedback for real users
Eric Ries. The Lean Startup (p. 75).
increase in revenue = frequency of experiments x
idea success rate x idea impact

High performance
organization: team of teams
5-9 people - promotes trust
Long-lived - enables trust and high
performance
Cross functional/autonomous -
eliminates time consuming hand-offs
Owns suitably sized software
“component”
Promotes long-term sustainable
development
Prevents cognitive overload

@crichardson
Case study: amazon.com
Amazon reorganized itself into long-
lived, product-centric, loosely coupled,
autonomous, two pizza teams that
developed microservices.
By 2015, they were deploying 130,000
times/day!
This ability to delivery software rapidly
frequently and reliably enables them to
dominate retail as well as cloud
computing.
Rossman, John. Think Like Amazon: 50 1/2 Ideas to Become a
Digital Leader
DevOps Handbook, Kim et all

Development in high performing
organizations
“Complete their work without communicating and
coordinating with people outside their team”
“Make large-scale changes to the design of their system
without depending on other teams to make changes in
their systems or creating signiﬁcant work for other teams”
“We can do most of our testing without requiring an
integrated environment.”
“We can and do deploy or release our application
independently of other applications/services it depends
on.”

Required architectural quality
attributes (a.k.a. -ilities)
“Complete their work without
communicating and coordinating with
people outside their team”
“Make large-scale changes to the design
of their system without depending on
other teams to make changes in their
systems or creating signiﬁcant work for
other teams”
“We can do most of our testing without
requiring an integrated environment.”
“We can and do deploy or release our
application independently of other
applications/services it depends on.”
Loosely coupled
(Conway’s law)
Modular
Testable
Deployable
API encapsulates design decisions

@crichardson
Successful applications live for a long time, e.g. 10 years,
20 years, …
BUT
Technology changes: Programming languages,
frameworks, …
Time
Technology A Technology B
V1 V2 V3 V…
Importance
The importance of a technology changes over time

@crichardson
An organization’s technology must
be aligned with the marketplace
Murer, Stephan,Bruno Bonati Consulting, Bruno Bonati. Managed Evolution: A Strategy for
Very Large Information Systems
Relying on technology that is unimportant to market
Not using technology that is important to the market

@crichardson
Must be able to upgrade the
technology stack

@crichardson
Required architectural quality
attributes (a.k.a. -ilities)
Long-lived applications
Modularity
Incrementally upgrade the technology
stack
API encapsulates the
technology stack

@crichardson
Architecting for rapid, frequent,
reliable and sustainable development
Loosely coupled
(Conway’s law) Modular
Testable
Deployable
API encapsulates
• design decisions
• technology stack

@crichardson
Tomcat/App. Server
Food To Go: Monolithic
architecture
Browser/
Client
WAR/EAR
MySQL
Database
Delivery
management
Order
Management
Kitchen
Management
Web UI
Restaurant
Management
HTML
REST/JSON
The application
The monolithic architecture
is an architectural style
that structures the
application
as a single executable/
deployable component

-ilities of small monoliths
Testability
Deployability
Maintainability
Modularity
Evolvability
✅
✅
✅
✅
✅

@crichardson
Rapid, frequent and reliable delivery
eventually becomes impossible
Time
Maintainability
Testability
Deployability
Modularity
Evolvability
Size/
Complexity
-ilities required to be competitive
Risk of
disruption

@crichardson
MyApp.war
Modular monolith = single classpath
No guarantee of composability
Orders.jar Customers.jar
Orders.jar Customers.jar
Test
independently
Still work?
+ dependencies + dependencies

@crichardson
Technology stack becomes
increasingly obsolete
BUT a rewrite is not feasible

@crichardson
Many decisions are global and can’t be
changed incrementally Don’t change
Programming language
Application framework
Library and framework version
…

@crichardson
Monolithic hell
By John Martin, Public Domain, https://commons.wikimedia.org/w/index.php?curid=3353638

The microservice architecture is
an architectural style
that structures an application as a
set of services that are
Highly maintainable and testable
Minimal lead time
Loosely coupled
Independently deployable
Implements a business capability
Owned/developed/tested/deployed by a small team

@crichardson
Food to Go: Microservice
architecture
Browser
Mobile
Application
Content
Router
API
Gateway
Order
Service
Restaurant
Service
Delivery
Service
…
Service
Order
Database
Restaurant
Database
Delivery
Database
…
Database
HTTP
/HTML
REST
REST
Browse &
Search WebApp
Restaurant
Detail WebApp
….
JavaScript
Message
Broker

@crichardson
API
The structure of a service
Operations
Event
Publisher
Commands
Queries
Synchronous
REST/gRPC
Asynchronous
Messaging
Events
Event
Subscriber
API
Client
Invokes
Operations
Events
Service
Database
Private!

@crichardson
Service architecture “mirrors”
the business
FTGO business
Kitchen Service
Delivery Service
Order Taking
Kitchen
Delivery
Accounting
….
….
Service
Order Service
Accounting Service
Maps to
Maps to
Maps to
Maps to
Maps to
Area of the business,
a.k.a.
Subdomain or Business Capability

@crichardson
Goal is team autonomy one
service per team
Service
https://microservices.io/patterns/decomposition/service-per-team.html
Owned by a
team
Owns one
service
Not to exceed
cognitive capacity of
team

@crichardson
Split service only to solve a
problem
Team become two large split team, split service
Deployment pipeline takes too long split into two services
that can be developed/tested independently
Polyglot development: e.g. Python ML model in a Java
application
Split for fault tolerance - isolate HA parts of the application
…

Benefits of microservices
Improved maintainability
Each service fits in the heads of the
development team = Easier to
understand and change
Preserves modularity since a service is a
well-defined module with an
impermeable API
Improved testability:
Each service is easier to test and faster
to test
Improved evolvability - evolve each service’s
technology stack independently
Improved deployability
Each service can be deployed
independently
Easier to scale application
Each service can be scaled
independently
Improves availability/fault isolation and
latency
Critical services are isolated from less
critical services: separate processes and
infrastructure
Separate deployments reduces risk of
change based failure

@crichardson
Process: Lean + DevOps/Continuous Delivery & Deployment
Architecture:
microservices
Testability
Deployability
Modularity
Deliver changes to
long-lived
frequently and reliably
autonomous teams

@crichardson
Loosely coupled teams and
services
Order
Service
Orders
Team
Automated deployment pipeline
Source code repository
Kitchen
Service
Kitchen
Team
Delivery
Service
Delivery
Team
Working independently > 80% of the time

@crichardson
Microservices experiment safely
and evolve the technology stack
Java
Java
Java
Java
Java
Golang
“GoLang
is cool!”
Java
Java
Java
“Kotlin
is better!”
Java
Kotlin

@crichardson
Drawbacks of microservices
Complexity
Development: IPC, partial failure, distributed data
Testing: Integration, end to end, …
Deployment
…

@crichardson
…Drawbacks of microservices
Correctly identifying service boundaries and avoiding the
distributed monolith anti-pattern
Refactoring a monolithic application to a microservice
architecture

@crichardson
If you are
developing a long-lived, large/complex
application
AND
you need to deliver it rapidly, frequently
and reliably
THEN
the Microservice Architecture is often a
good choice

@crichardson
About Conway’s Law
“organizations which design
systems ... are constrained to
produce designs which are
copies of the communication
structures of these
organizations.”
http://melconway.com/Home/Home.html
Loosely coupled teams require a
loosely coupled architecture

@crichardson
Loose coupling is essential
Services collaborate, e.g. Order Service must
reserve customer credit
Coupling is inevitable
BUT
Services must be loosely coupled
API
Order
Service
Customer
Service
reserveCredit()

Runtime coupling
Order Service cannot respond to a synchronous request
(e.g. HTTP POST) until Customer Service responds
VS
Design time coupling
Change Customer Service change Order Service

@crichardson
Loose coupling - design time
Design-time coupling requires coordination between teams:
e.g. Meetings to discuss API changes
Slows down development
Essential to minimize design time coupling:
Use well-designed, stable APIs
Be careful with shared libraries - best for utilities

Design iceberg services
Implementation
DB
API
Small, stable
API
Large, complex
implementation Change
What’s hidden can
easily be changed

Avoid shared libraries containing
business logic
Shared utility libraries ✅
Shared libraries containing
business logic that changes
requires multiple services
to change in lock step ❌
Service A
Library
Service B
Library
Service …
Library
Change

Avoid shared database tables
Order
Service
Customer
Service
Database
Customer
table
Tight design-
time/runtime
coupling
Order
Service
Customer
Service
Order database
Order
table
Customer database
Customer
table
APIs
only

@crichardson
Loose runtime coupling

@crichardson
The trouble with synchronous IPC :
runtime coupling => reduced availability
Order
Service
Customer
Service
PUT /customer/id/credit
availability(createOrder) =
availability(OrderService) x
availability(CustomerService)
POST /order
😢
Order Customer
creditLimit
availableCredit

Problem:
Developers treat services as if they are programming
language-level modules (that communicate via HTTP)
Consequences:
IPC is relatively expensive high latency
Synchronous communication temporal coupling
reduced availability - serviceAvailabilitynumber of services
Anti-pattern: Distribution is
free

@crichardson
Self-contained service:
Can handle a synchronous
request without waiting for a
response from another service
https://microservices.io/patterns/decomposition/self-contained-service.html

@crichardson
Order
Service
Order Management
Customer Management
Improving availability: replace
service with module
POST /order
Order
Customer
creditLimit
availableCredit
availability(OrderService)
More available 😄
Larger service/
team 😢
Response =
validation
outcome 😄

@crichardson
messaging system
Use asynchronous messaging
Sender Recipient
Message
Channel
Payload
Header
http://bit.ly/books-eip
Channel types:
• Point-to-point
• Publish/Subscribe

@crichardson
Improving availability: sagas
Order
Service
Customer
Service
POST /order
Credit Reserved
More available 😄
Complexity of sagas 😢
Order created
Response =! Validation
outcome 😢
Order events
Customer events
https://microservices.io/patterns/data/saga.html

@crichardson
Improving availability: CQRS
Order
Service Customer
Service
POST /order
Customer
Created
More available 😄
Complex/Costly 😢
Response =
validation
outcome 😄
Customer
creditLimit
availableCredit
Replicated
Owned
Customer
creditLimit
availableCredit
Credit Limit
Changed
https://microservices.io/patterns/data/cqrs.html

@crichardson
Summary: What is the microservice
architecture?
The microservice architecture is
an architectural style
that structures an application as a
set of services that are
• Highly maintainable and testable
• Minimal lead time
• High deployment frequency
• Loosely coupled
• Independently deployable
• Implements a business capability
• Owned/developed/tested/deployed by a small team

@crichardson
Summary: Why should you care
about the microservice architecture?
Process: Lean + DevOps/Continuous Delivery & Deployment
Architecture:
microservices
Testability
Deployability
Modularity
Modularity
Evolvability
Maintainability
Availability
Deliver changes to
long-lived
frequently and
reliably
autonomous teams
Organizational
Performance

@crichardson
@crichardson chris@chrisrichardson.net
https://bit.ly/tdc-2020-msa
Questions?

TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development

Similar to TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development (20)

More from Chris Richardson

More from Chris Richardson (11)

Recently uploaded

Recently uploaded (20)

TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development