In this presentation, I describe the essential characteristics of the microservice architecture. You will learn about the benefits and drawbacks of the microservice architecture and when it makes sense to use it. I discuss how the microservice architecture is not a silver bullet. You will learn about the microservice pattern language, which is a collection of patterns that solve architecture and design issues that you will encounter when using microservices.

1. @crichardson
Microservices: decomposing
applications for testability and
deployability
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://learn.microservices.io
Copyright © 2018. Chris Richardson Consulting, Inc. All rights reserved

2. @crichardson
Presentation goal
Overview of the Microservice
architecture
Benefits and drawbacks

3. @crichardson
About Chris

4. @crichardson
About Chris
Microservices training and
consulting
(http://www.chrisrichardson.net/)

5. @crichardson
About Chris
Founder of a startup that is creating
an open-source/SaaS platform
that simplifies the development of
transactional microservices
(http://eventuate.io)

6. @crichardson
About Chris
https://www.manning.com/books/microservices-patterns

7. About Chris: microservices.io
Microservices pattern
language
Articles
Code examples
Microservices Assessment
Platform - coming soon

8. @crichardson
Agenda
From monolith to microservices
Microservices != silver bullet
The Microservices pattern language

9. @crichardson
Let’s imagine that you are
building a cool new food
delivery application….

10. @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

11. @crichardson
The monolithic architecture
is NOT
an anti-pattern

12. @crichardson
But successful applications
keep growing….
FTGO
Team
FTGO
Application

13. @crichardson
… and growing
Order Team
FTGO
ApplicationKitchen Team
Delivery Team

14. @crichardson
Eventually:
Testing and
deployment is
slow and painful
=
Monolithic hell

15. @crichardson
Technology stack becomes
increasingly obsolete
BUT
A rewrite is not feasible

16. @crichardson
Businesses must innovate faster
Software
Deliver software
rapidly, frequently
and reliably

17. @crichardson
FTGO
Application
Monolithic
Architecture
Order
Service
Kitchen
Service
Delivery
Service
…
Service
Microservice
Architecture
FTGO
Application
Loosely
coupled
Organized
around
business
capabilities

18. @crichardson
Application
Business capability Service
Food to Go
Order
Taking
Kitchen
management
Delivery
management
Business Capability = something a business does to deliver value
…
Order
Service
Kitchen
Service
Delivery
Service
…
Service

19. @crichardson
Browser
Mobile
Device
Content
Router
API
Gateway
Order
Service
Kitchen
Service
Delivery
Service
…
Service
Order
Database
Kitchen
Database
Delivery
Database
…
Database
HTTP
/HTML
REST
REST
Orders web
application
Kitchen Web
application
….
Inbound
Notification
Gateway
Notifications

20. @crichardson
Service = independently
deployable component
Command
Query
API
Event
Publisher
Event
Subscriber
API
Client
Consumer facing Implementation
Synchronous:
REST, gRPC, …
Asynchronous:
Command/Reply, Notification
Service database
Events
Events
Synchronous:
REST, gRPC, …
Asynchronous:
Command/Reply, Notification
Data owned by the service
Data replicated from elsewhere
SLA

21. Service size is secondary
microservice architecture

22. @crichardson
Loosely coupled teams and
services
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
Working independently > 80% of the time

23. @crichardson
Modern software development: moving
fast and not breaking things!
46x
440x
24x
5x lower
Amazon: ~0.001%
Netflix: 16 minutes
Amazon: every 11.6 seconds

24. @crichardson
Deliver software
rapidly, frequently
and reliably
Process: DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous teams
Architecture:
microservices
Testability
Deployability
Enables
Autonomy

25. @crichardson
Enables organization to scale
without impacting productivity

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

27. @crichardson
Agenda
From monolith to microservices
Microservices != silver bullet
The Microservices pattern language

28. @crichardson
No silver bullets
http://en.wikipedia.org/wiki/Fred_Brooks

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

30. @crichardson
Are microservices a good fit
for my application?

31. @crichardson
Do I have the skills/pre-requisites in place:
automated testing
automated provisioning
….. ?

32. @crichardson
When using microservices:
How to decompose an application into services?
How to deploy an application’s services?
How to handle cross cutting concerns?
Which communication mechanisms to use?
How do external clients communicate with the services?
How does a client discover the network location of a service instance?
How to prevent a network or service failure from cascading to other services?
How to maintain data consistency and implement queries?
How to make testing easier?
How to understand the behavior of an application and troubleshoot problems?
How to implement a UI screen or page that displays data from multiple services?

33. @crichardson
Agenda
From monolith to microservices
Microservices != silver bullet
The Microservices pattern language

34. @crichardson
Microservice pattern language
=
collection of patterns
that solve these
architecture, design, development and
operational problems

35. @crichardson
What’s a pattern?
Reusable solution
to a problem
occurring
in a particular context

36. @crichardson
The structure of a pattern
encourages objectivity

37. @crichardson
Without patterns
My favorite
technology rocks
Your favorite
technology sucks
http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html

38. @crichardson
With patterns:
Pattern
Benefits
Drawbacks
Issues
Alternative
Patterns
Patterns
that
address
issues

39. @crichardson
Microservices pattern language: http://microservices.io
Splitting Reassembling
Operations
Architecture
Microservice patterns
Data patterns
Communication patterns
Application
architecture
Cross-cutting concerns Security
Deployment
Maintaining data consistency
External API
Reliability
Discovery
Transactional
messaging
Testing
Observability
UI
Decomposition
Database architecture
Querying
Communication style
API gateway
Client-side discovery
Server-side
discovery
Service registry
Self registration
3rd party registration
Multiple Services
per host
Single Service per
Host
Service-per-
Container
Service-per-VM
Messaging
Remote Procedure
Invocation
Database per
Service
Saga
Shared
database
Microservice
Chassis
Backend for front end
Event
sourcing
Aggregate
Monolithic
architecture
Microservice
architecture
Motivating
Pattern
Solution
Pattern
Solution A Solution B
General Specific
Serverless
deployment
Circuit BreakerAccess Token
Domain-specific
Externalized
configuration
Consumer-driven
contract test
Service
Component Test
Exception
tracking
Distributed
tracing
Audit logging
Application
metrics
Log
aggregation
Health check
API
Service deployment
platform
Server-side page
fragment
composition
Client-side UI
composition
Decompose by
business capability
Decompose by
subdomain
CQRS
Transaction
log tailing
Transactional
Outbox
Polling
publisher
API
Composition
Domain event
Consumer-side
contract test
Sidecar
Service mesh
Application
patterns
Infrastructure patterns
Application Infrastructure patterns
Log deployments and changes

40. @crichardson
The pattern language guides you
when developing an architecture
What architectural decisions you must make
For each decision:
Available options
Trade-offs of each option

41. @crichardson
Key patterns

42. Issue: What’s the deployment
architecture?
Forces
Maintainability
Deployability
Testability
…
Monolithic
architecture
Microservice
architecture
Single deployable/
executable OR
Tightly coupled services
Multiple loosely coupled
services

43. Issue: How to decompose an
application into services?
Forces
Stability
Cohesive
Loosely coupled
Not too large
Decompose by
business capability
Decompose by
subdomain
Organize around
business capabilities
Organize around DDD
subdomains

44. @crichardson
Issue: how to maintain data
consistency?
Context
• Each service has its own
database
• Data is private to a service
Forces
Transactional data consistency
must be maintained across
multiple services
2PC is not an option

45. @crichardson
Issue: how to perform
queries?
CQRS
Context
Each service has its own
database
Forces
Queries must join data
from multiple services
Data is private to a service
Maintain query views by
subscribing to events
API
Composition

46. @crichardson
Issue: what external API to
expose?
Context
One or more clients access the
application’s API
Forces
Different clients need different data
Different clients use different networks
Mismatch between client’s needs and
fine-grained service APIs
Application architecture must evolve
without impacting clients
Services might use protocols that are
not web friendly
API gateway
Backend for front end

47. @crichardson
Issue: how to test that services
collaborate?
Context
Application consists of
multiple collaborating
services
Forces
Services collaborate and
must agree on APIs
End-to-end tests are slow,
brittle, and expensive and
best avoided
Client Service
Contract
defines
Consumer-
side contract
test
Tests
Uses
Consumer-
driven
contract test
Tests
Uses

48. @crichardson
The rest are generic technical
architecture patterns
=
Undifferentiated heavy lifting!

49. @crichardson
Issue: How do services
communicate?
Messaging
Remote Procedure
Invocation
Domain-specific
Forces
Services must
communicate
Usually processes on
different machines
…

50. @crichardson
Issue: How to handle cross
cutting concerns?
Microservice
Chassis
Forces
Every service must
implement logging;
externalize configuration;
health check endpoint;
metrics; …

51. Issue: How to deploy an
application’s services?
Multiple Services
per host
Single Service per
Host
Service-per-
Container
Service-per-VM
Serverless
deployment
Service deployment
platform
Forces
Multiple languages
Isolated
Constrained
Monitor-able
Reliable
Efficient

52. @crichardson
Issue: How to discover a service
instance’s network location?
Client-side discovery
Server-side
discovery
Service registry
Self registration
3rd party registration
Forces
Client needs IP address of
service instance
Dynamic IP addresses
Dynamically provisioned
instances

53. @crichardson
Issue: how to monitor the
behavior of your application?
Exception
tracking
Distributed
tracing
Audit logging
Application
metrics
Log
aggregation
Health check
API

54. @crichardson
Summary
The goal of architecture is to satisfy non-functional
requirements: deployability, testability, …
To enable DevOps/continuous delivery/deployment use the
appropriate architectural style
Small applications Monolithic architecture
Complex applications Microservice architecture
Use the pattern language to guide your decision making

55. @crichardson
@crichardson chris@chrisrichardson.net
http://bit.ly/kong_microservices
Thank you!