Silicon Valley CodeCamp 2019 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.

1. @crichardson
Cubes, Hexagons, Triangles, and
More: Understanding the Microservice
Architecture Through Shapes
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 © 2019. Chris Richardson Consulting, Inc. All rights reserved

2. @crichardson
Presentation goal
The essential characteristics
of the Microservice
Architecture

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

4. @crichardson
About Chris
https://microservices.io/book
40% discount with code
ctwsvcc19

5. About Chris: microservices.io
Microservices pattern
language
Articles
Example code
Microservices Assessment
Platform

6. @crichardson
Agenda
Process
Organization 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

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

9. @crichardson
Successful applications often live a very long time
Technology changes
Need to be able to easily modernize applications
+

10. @crichardson
Success Triangle
Process
Organization Architecture
Deliver changes to
long-lived
applications
rapidly, frequently
and reliably

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

12. @crichardson
Agenda
Process
Organization 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

13. Required architectural quality
attributes (.a.k.a. -ilities)
https://en.wikipedia.org/wiki/Non-functional_requirement
DevOps
Autonomous Teams
Long-lived applications
Testability
Deployability
Maintainability
Modularity
Evolvability

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
✅
✅
✅
✅
✅

16. @crichardson
But successful applications
keep growing….
Development
Team
Application

17. @crichardson
… and growing
Development
Team A
ApplicationDevelopment
Team B
Development
Team C

18. @crichardson
… and modularity breaks down…
http://www.laputan.org/mud/
“haphazardly
structured,
sprawling,
sloppy, duct-
tape and bailing
wire, spaghetti
code jungle.”

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

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
Testability - small service easier/faster to test
Deployability - each service is independently deployable
Maintainability - small service easier to understand and
change
Modularity - a service API is impermeable enforces modularity
Evolvability - evolve each service’s technology stack
independently
*Improved scalability and fault tolerance too

26. @crichardson
Process: Lean + DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous,
product teams
Architecture:
microservices
Testability
Deployability
Modularity
Modularity
Evolvability
Maintainability
Deliver changes to
long-lived
applications rapidly,
frequently and reliably

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

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

29. @crichardson
Agenda
Process
Organization 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

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
DB
adapter,
e.g. DAO
Business logic
HTTP
Inbound port,
e.g. interface
Inbound
adapter
Outbound port,
e.g. interface
Outbound
adapter
HTTP

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

33. @crichardson
Order Service example
Order
Service
REST
API
POST /orders
Event
Publisher
Order Created
Consumer
Service
…
API
Client
Restaurant
Service
Event
Subscriber
API
API
Event
Publisher
Restaurant Created
Async

34. @crichardson
… The structure of a service
SLA
Telemetry
API
Telemetry: Metrics, exceptions
Externalized
configuration
Logging
Distributed
tracing
Heath Check
endpoint

35. @crichardson
Agenda
Process
Organization 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

36. @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()

37. 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

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

39. Design iceberg services
Implementation
DB
API
Small, stable
API
Large, complex
implementation Change

40. Avoid CRUD service anti-
pattern: database wrapper
DB
API
Large,
unstable API
Minimal
implementation

41. 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

42. @crichardson
Agenda
Process
Organization 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

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

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

45. @crichardson
messaging system
Use asynchronous messaging
Sender Recipient
Message
Channel
Payload
Header
http://bit.ly/books-eip

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

47. @crichardson
Improving availability: sagas
Order
Service
Customer
Service
availability(createOrder) =
availability(OrderService)
POST /order
Credit Reserved
More available 😄
Complexity of sagas 😢
Order created
Response =! Validation
outcome 😢
Order events
Customer events

48. @crichardson
Improving availability: CQRS
Order
Service Customer
Service
availability(createOrder) =
availability(OrderService)
POST /order
Customer
Created
More available 😄
Complex/Costly 😢
Response =
validation
outcome 😄
Customer
creditLimit
availableCredit
Replicated
Owned
Customer
creditLimit
availableCredit
Credit Limit
Changed

49. @crichardson
Agenda
Process
Organization 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

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

51. @crichardson
The state of automated testing
today: Oops!
https://cdn.agilitycms.com/sauce-labs/white-papers/sauce-labs-state-of-testing-2018.pdf
😢

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

53. 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

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

55. @crichardson
Consumer-driven contract
testing
Verify that
a service (a.k.a. provider)
and its clients (a.k.a. consumers)
can communicate while testing
them in isolation

56. @crichardson
Contract testing example
Api Gateway
Order
Service
Proxy
Order Service
Order
Controller
GET /orders/{id}
ProviderConsumer

57. @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
Consumer-side contract test
OrderService
Proxy
Order
ServiceProxy
Tests
Use
WireMock-
based
Order Service
Test Double
Configures
Verify that proxy makes
requests that match
contract and can consume
responses
“service virtualization”
GET /orders/{id}

59. @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
Assumption:
If consumer and provider are tested
independently with the same contracts
Consumer and provider can communicate

61. @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
https://blogs.msdn.microsoft.com/seliot/2011/04/25/i-dont-always-test-
my-code-but-when-i-do-i-do-it-in-production/

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

64. 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
https://medium.com/@copyconstruct/testing-in-production-
the-safe-way-18ca102d0ef1

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

67. @crichardson
@crichardson chris@chrisrichardson.net
http://adopt.microservices.io
Questions?
40% discount with code ctwsvcc19