Designing loosely coupled services

@crichardson
Designing loosely coupled
microservices
Chris Richardson
Microservice architecture consultant and trainer
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

@crichardson
What you will learn
The different types of coupling
Their drawbacks
How to design loosely coupled services

@crichardson
About Chris

@crichardson
Discounts
35% discount
ctwcloudnativev20
$120 discount coupon
YKXQSOXG

@crichardson
Agenda
• Microservices and coupling
• Minimizing design time coupling
• Reducing runtime coupling
• Avoiding infrastructure coupling

Pattern: microservice
architecture
Highly maintainable and
testable
Minimal lead time (time from
commit to deploy)
Loosely coupled
Independently deployable
Implements a business
capability
Owned/developed/tested/
deployed by a small team
An architectural
style
that structures an
application as a
set of deployable/
executable units,
a.k.a. services
A service is:

@crichardson
Food to Go: Microservice
architecture
Browser
Mobile
Application
API
Gateway
Order
Service
Restaurant
Service
Delivery
Service
…
Service
Order
Database
Restaurant
Database
Delivery
Database
…
Database
REST
REST
JavaScript
Message
Broker

@crichardson
Why microservices: success triangle
Process: Lean + DevOps/Continuous Delivery & Deployment
Organization:
Network of small,
loosely coupled, teams
Architecture:
Microservices
(sometimes)
IT must deliver software
rapidly, frequently, reliably and
sustainably
Enables:
Loose
coupling
Enables:
Testability
DeployabilityBusinesses must be
nimble, agile and
innovate faster
S/W VUCA

@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
Reduces availability
VS
Design time coupling
Change Customer Service change Order Service
Reduces development velocity
Neither is guaranteed: you must design your
services to be loosely coupled

@crichardson
Degree of coupling
=
f( )
Service boundaries
Service responsibilities
Service APIs
Service collaborations

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”
….
Loose design-time coupling/modularity
=

Need to avoid lock step
changes
Design-time coupling requires
coordination between teams:
e.g. Meetings to discuss API
changes
Slows down development
Worst case is a distributed
monolith: multiple services
frequently changing in lock step
Essential to minimize design time
coupling
API
Order
Service
Customer
Service
reserveCredit()
Change
Requires change here
Order team
Customer team

@crichardson
Example change: adding a
COVID delivery surcharge
interface OrderService {
Order getOrder()
…
}
class Order
…
Money tax
Money serviceFee
Money deliveryFee
…
}
No explicit
total
Money covidSurchargeNew!
Order
Service
Accounting
Service
…
Service
…
Service
Update
Calculate Calculate Calculate
Calculate

@crichardson
DRY (Don't repeat yourself)
services
"Every piece of
knowledge must have
a single, unambiguous,
authoritative
representation within a
system"
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
For example:
Order Total

Shared library that calculates Order
Total != DRY
Shared libraries containing
business logic that changes
requires multiple services
to change/rebuild/
redeployed in lock step ❌
Shared utility libraries ✅
Service A
Library
Service B
Library
Service …
Library
Change

@crichardson
DRY: calculate Order Total in
the Order Service
interface OrderService {
Order getOrder()
…
}
class Order
…
Money tax
Money serviceFee
Money deliveryFee
…
}
Money total
Order
Service
Accounting
Service
…
Service
…
Service
Update
Calculate

@crichardson
Icebergs: expose as little as possible
Implementation
API
Small, stable
API
Large, complex
implementation
Change
What’s hidden can be
changed without
impacting client
Twilio: sendSms(from, to, message)

Consumer
Consume as little as possible
Postel’s Robustness
principle: https://
en.wikipedia.org/wiki/
Robustness_principle
Consumer-driven contract
tests verify compliance
Swagger/Protobuf-
generated stubs parse
everything!
{
…
"tax": …
"serviceFee": …
"deliveryFee": …
"total": "12.34"
…
}
class Order {
Money total;
}
What you ignore can’t affect you

The downside of sharing
database tables
Schema changes require
Coordination across teams
Overhead of maintaining
backwards compatibility
Duplication of data access logic
Updates require duplication of
consistency enforcement
business logic
Order
Service
Customer
Service
Database
Customer
table
Tight design-
time/runtime
coupling
Duplicated
code
Duplicated
code

Use a database-per-service
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
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
Essential: Use resilience patterns for
synchronous communication
https://github.com/resilience4j/resilience4j#resilience-patterns

@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: move
responsibility + 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
Stale data? 😢
Confusing? 😢

@crichardson
Indirect coupling via infrastructure
Virtual infrastructure:
compute, storage, network
Kubernetes
Service Mesh
Infrastructure services:
databases, message,
brokers, …
Service
A
Service
B
Service
…
Static
Dynamic
Susceptible to
operator
misconﬁguration
global impact
Services compete for
limited resources
Loosely coupled
BUT

The trouble with shared
infrastructure: resource contention
Order
Service
Customer
Service
Database Server
Order
Database
Customer
Database
Runaway
scenario
High resource
utilization
Unavailable

The trouble with shared
infrastructure: misconﬁguration
Order
Service
Customer
Service
Database Server
Order
Database
Customer
Database
Unavailable
Risk of
misconﬁguration
Unavailable

Clustering doesn’t help with
misconfiguration
Monzo bank, July 29th, 2019
Single large Cassandra
cluster that was
misconfigured
Adding capacity outage
https://monzo.com/blog/
2019/09/08/why-monzo-
wasnt-working-on-
july-29th
AWS Kinesis, Nov 25th,
2020
Attempted to expand
Kinesis “front-end fleet”
# threads (one-per-peer)
exceeded max OS limit
https://aws.amazon.com/
message/11201/

Database Server
Use private infrastructure: minimizes
resource contention and blast radius
Order
Service
Customer
Service
Database Server
Order
Database
Customer
Database

@crichardson
Message broker
Message brokers need to be
shared!
Broker
Node
Order
Service
Customer
Service
Broker
Node
Control plane What about
misconﬁguration?

@crichardson
Message
broker
cluster
Use “Private” message brokers
Order
Service
Customer
Service
Message
broker
cluster
Control plane Control plane
Bridge
Critical Less Critical

@crichardson
Shared infrastructure: Service
mesh
What about
misconﬁguration?
Synchronous communication =
runtime coupling!

Fault isolated swim lanes
Partition/Route by
“value”, e.g.
CustomerID
And/Or
function, e.g.
User
management,
Order
Management
Virtual Infra.
Kubernetes
Service Mesh
Infra. services
Service
A
Service
B
Service
…
Routing
Async
Swim lane 1 Swim lane 2
Virtual Infra.
Kubernetes
Service Mesh
Infra. services
Service
A
Service
B
Service
…

@crichardson
Summary
Rapid and frequent development requires loose design-time
coupling
Loose runtime coupling is important for availability
Avoid synchronous communication but use resilience patterns
when you do
Strive for self-contained services
Avoid coupling at the infrastructure level: avoid shared
services, use swim lanes, ….

@crichardson
@crichardson chris@chrisrichardson.net
Questions?
ctwcloudnativev20 YKXQSOXG

Designing loosely coupled services

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Designing loosely coupled services

Similaire à Designing loosely coupled services (20)

Plus de Chris Richardson

Plus de Chris Richardson (14)

Dernier

Dernier (20)

Designing loosely coupled services