The microservice architecture is becoming increasing important. But what is it exactly? Why should you care about microservices? And, what do you need to do to ensure that your organization uses the microservice architecture successfully? In this talk, I’ll answer these and other questions using shapes as visual metaphors. You will learn about the motivations for the microservice architecture and why simply adopting microservices is insufficient. I describe essential characteristics of microservices, You will learn how a successful microservice architecture consist of loosely coupled services with stable APIs that communicate asynchronous. I will cover strategies for effectively testing microservices.
7. @crichardson
+
Marketplace is volatile, uncertain, complex
and ambiguous
+
Businesses must innovate faster
Deliver software rapidly, frequently and reliably
Software
8. @crichardson
Quantifying rapid, frequent
and reliable delivery
Velocity
Lead time - time from commit to deploy
Deployment frequency - deploys per developer per day
Reliability
Change failure rate - % of deployments that cause an
outage
Mean time to recover from a deployment failure
14. @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
15. -ilities of small monoliths
Testability
Deployability
Maintainability
Modularity
Evolvability
✅
✅
✅
✅
✅
20. @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
21. @crichardson
The scale cube
X axis
- horizontal duplication
Z
axis
-data
partitioning
Y axis -
functional
decomposition
Scale
by
splitting
sim
ilar
things
Scale by
splitting
different things
22. The microservice architecture is
an architectural style
that structures an application as a
set of services
Each microservice is:
• highly maintainable and testable
• loosely coupled
• independently deployable
• organized around business capabilities
• owned by a small team
23. @crichardson
Start with one service per
team
Service
Small, autonomous
team
Split service only to solve a problem
e.g. accelerate development and testing
24. @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
25. @crichardson
Benefits of microservices
Maintainability - small service easier to understand and
change
Modularity - a service API is impermeable enforces modularity
Evolvability - evolve each service’s technology stack
independently
Testability - small service easier/faster to test
Deployability - each service is independently deployable
*Improved scalability and fault tolerance too
28. @crichardson
…Drawbacks of microservices
Correctly identifying service boundaries and avoiding the
distributed monolith anti-pattern
Refactoring a monolithic application to a microservice
architecture
30. @crichardson
Order Service
The traditional 3-tier/layered
architecture
Presentation
Business logic
Persistence
Order Controller
Order
OrderDAO
Only one?
Only one?
Depends on
persistence?!
Doesn’t reflect reality!
31. @crichardson
The Hexagonal architecture, a.k.a. ports and
adapters
Order
Controller
REST-
based
Proxy
Message
Subscriber
Messages
Order
DAO
Business logic
HTTP
Inbound port,
e.g. interface
Inbound
adapter
Outbound port,
e.g. interface
Outbound
adapter
HTTP
Order
implements
uses
32. @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
DB
adapter
Business
logic
34. @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()
35. 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
36. @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
38. Avoid CRUD service anti-
pattern: database wrapper
DB
API
Large,
unstable API
Minimal
implementation
39. 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
41. @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
42. 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
43. @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
45. @crichardson
About message channels
Abstraction of message broker capabilities, e.g.
Apache Kafka topics
JMS queues and topics
….
Channel types:
Point-to-point - deliver to one recipient
Publish-subscribe - deliver to all recipients
49. @crichardson
Microservices enable DevOps
DevOps requires automated testing
Complexity of microservices requires good
automated testing
Using the Microservice Architecture
without automated testing
is self-defeating AND risky
http://bit.ly/msa-antipattern-flying-before-walking
50. @crichardson
The state of automated testing
today: Oops!
https://cdn.agilitycms.com/sauce-labs/white-papers/sauce-labs-state-of-testing-2018.pdf
😢
51. @crichardson
The testing pyramid and
microservices
Unit
Integration
Includes consumer-driven contract tests
Component
End to End
Classes within
service
A services adapters
An entire service
Multiple services or application
Brittle, Slow,
Costly
Reliable, Fast,
Cheap
52. Pipeline
Deployment pipeline:
the path from laptop to production
Pre
commit
tests
Commit
stage
Tests
Integration
Tests
Performance
Tests
Release/
Deploy
Other non-
functional
tests….
Component
Tests
53. @crichardson
Deployment pipeline per service
Order
Service
Orders
Team
Automated deployment pipeline
Source code repository
Kitchen
Service
Kitchen
Team
Automated deployment pipeline
Source code repository
Delivery
Service
Delivery
Team
Automated deployment pipeline
Source code repository
56. @crichardson
Contract testing example
Request from consumer
Response from service
Describes
Written by
API Gateway
Team API definition
by example
Order
Service
Proxy
Order
Controller
GET /orders/{id}
ProviderConsumer
58. @crichardson
Provider-side contract test
Class BaseHttp {
}
class HttpTest
extends
BaseHttp {…
Spring Cloud
Contract
Code
generates
Reads
Configures
with mock
OrderRepository
Order
Controller
Tests
Order
Repository
Must be
consistent
Verify API
structure matches
contracts
GET /orders/{id}
60. @crichardson
Application
Deployment pipeline
End to end tests: a bottleneck
and best avoided
Order Service deployment
pipeline
Kitchen Service deployment
pipeline
Delivery Service deployment
pipeline
….
End to End
tests
Production
Brittle, Slow,
Costly
62. @crichardson
Testing in production*
Challenge:
End-to-end testing is brittle, slow, and costly
Your end-to-end test environment is a simulation of production
No matter how much you test issues will appear in production
Therefore:
Separate deployment (running in production) from release (available to
users)
Test deployed code before releasing
Automate for fast deployment, rollback and roll forward
* a.k.a. Validation in production
63. Order Service
V1
Order Service
V2
Test deployed code before
releasing: e.g. Canary release
1.Deploy V2 alongside V1
2.Test V2
3.Route test traffic to V2
4.Release V2 to a small % of production
users
5.Monitor/test (latency, errors) - undo
rollout if errors
6. Increase % of production traffic going
to V2
7.Repeat until 100% of traffic going to V2
8.Eventually undeploy V1
Intelligent
traffic router
Order Service
V1
Order Service
V2
Monitoring system
65. @crichardson
Summary
Process: Lean + DevOps
Organization:
Small, autonomous teams
Microservice
Architecture
Deliver changes to long-
lived applications rapidly,
frequently and reliably
Success Triangle Scale Cube Hexagonal Architecture
API
Iceberg services
Channel
Messaging
Unit
Integration
Component
End to End
Testing Pyramid
Microservice
architecture has
required -ilities
Loose design-time
coupling
Loose run-time
coupling
Foundation of modern
development
The structure of each
service
The goal