Building Microservice Architectures (Neal Ford)

BUILDING MICROSERVICE
ARCHITECTURES
@neal4d
nealford.com
what problem
denitions
characteristics
AGENDA
engineering
Conways Law
organizations which design systems ... are
constrained to produce designs which are
copies of the communication structures of
these organizations
Melvin Conway
Organized Around Business Capabilities

The Inverse Conway Maneuver
Domain/Architecture Isomorphism
Coupling Metrics
code
artifact
afferent
efferent
x
i
t
X-Ray
xray.inf.usi.ch/xray.php
Class Dependency
Package Dependency
Azureus Packages
Azureus Packages Filtered
Attempting to
generate class
diagram crashed x-ray.
From a Real Monolith
Package level coupling

from a real monolith
Name withheld by request
Software architecture
represents the
tension between
coupling & cohesion.
ACID versus BASE
BASE
ACID
Atomic
Consistent
Isolated
Durable
Basic Availability
Soft-state
Eventual Consistency
As your system becomes more distributed,

prefer BASE to ACID
because CAP Theorem

www.julianbrowne.com/article/viewer/brewers-cap-theorem
Formal proof: http://lpd.ep.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
# of users
http://highscalability.com/blog/2013/5/1/mytheric-brewer-on-why-banks-are-base-not-acidavailability.html
http://www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf
what problem
denitions
characteristics
AGENDA
engineering
What Traditional SOA Got Right

Breaking monoliths into services
Focus on integration over internal coupling
Prefer BASE to ACID
What Traditional SOA Missed

Architecture is abstract until operationalized.
Impact of Conways Law
The folly of trying to build Uber services (Customer)
Didnt support easy change (ESB pattern)
support
Microservice is the rst
architectural style developed
post-Continuous Delivery.
what problem
denitions
characteristics
AGENDA
engineering
Monoliths vs. Microservices
user interface
server-side
DBA
Orders
Shipping
Catalog
Products, not Projects

projects:
products:
s You build it, you run it
Smart Endpoints, Dumb Pipes
as decoupled & cohesive as possible

inspired by Unix lters/pipes
transport:
HTTP
messaging over lightweight bus
Prefer Choreography to Orchestration
pack of
enterprise architects
Consumer Driven Contracts
Because Conways Law!

traditional SOA /
ESB pattern
Consumer Driven Contracts

http://martinfowler.com/articles/consumerDrivenContracts.html
Prefer REST over SOAP
SOAP = RPC
REST is less brittle at integration points
Standardize on integration, not platform

embrace polyglot solutions
where sensible
too few
languages/platforms
Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS
Standardize in the gaps between

services - be exible about what
happens inside the boxes
Sam Newman
too many
languages/platforms

but dont go crazy
Building
Microservices
Have one, two or maybe three

ways of integrating, not 20.
Sam Newman
Building
Microservices
Pick some sensible conventions,

and stick with them.
Sam Newman
explicit about
coupling
engineering
safety nets
forces coarserundisciplined coupling = mess

grained coupling
coupling dynamics become integration issues
Microservice architectures promote coupling from

application to integration architecture.
Decentralized Data Management

Building
Microservices
Avoid distributed transactions if

at all possible
Sam Newman
ACID versus BASE
Decentralized Governance
Enterprise architects suer from less

pressure to make the correct choice(s)
in microservice architectures.
Small, Single Responsibility

small enough to t in your head
rewrite over maintain
(101000 LOC)-ish / service
single responsibility
How Big?

partition along natural boundaries
domain
organizational
transactional
nd a balance between standardization and freeforall
Partitioning by Existing Coupling
God Object: an object that

knows too much or does too much
Asynchronicity
return optimized for
ranking/aggregation,
not display
Prefer timely partial

over slow complete
Traditional Monolith
Model
User Interface
CQRS
Query Model
User Interface
Command Model
http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/
Reporting
Query Model
User Interface
Command Model
. . .
what problem
denitions
characteristics
AGENDA
engineering
Design For Failure

clients must respond gracefully to
provider failure
aggressive monitoring:
- business relevant
- architectural
- semantic
Monitoring
Building
Microservices
You have to get much better at

monitoring.
Sam Newman
Building
Microservices
You are not a badass if you use

an SSH Multiplexer!
Sam Newman
Aggregating Monitors
Response Time
Response Time
Response Time
Aggregating Monitors
Building
Microservices
Capture metrics, and logs, for

each node, and aggregate them
to get a rolled up picture.
Sam Newman
Synthetic Transactions
Building
Microservices
Use synthetic transactions to test

production systems.
Sam Newman
Correlation IDs
ID: 123
ID: 123
ID: 123
Building
Microservices
Use correlation IDs to track

down nasty bugs
Sam Newman
Engineering Consistency
integration
metrics
Building
Microservices
Consider Service Templates to

make it easy to do the right
thing!
Sam Newman
service behavior
downstream
SCM Repositories
Prefer repository per
service to monolithic
repository
Integrate via
continuous
integration
Testing Microservices
http://martinfowler.com/articles/microservice-testing/
Inside the Box
Unit Testing
Sociable
Solitary
Integration Testing
Integration Testing
Component Testing
Component Testing
shims:
inproctester
github.com/aharin/inproctester
Plasma
github.com/jennifersmith/plasma
Component Testing
Contract Testing
Pact
github.com/realestate-com-au/pact
Pacto
github.com/thoughtworks/pacto
Janus
github.com/gga/janus
End-to-End Testing
Test Pyramid for Microservices
Deployment
engineering
Building
Microservices
Abstract out underlying

platform dierences to provide a
uniform deployment
mechanism.
Sam Newman
Dont Let Changes Build Up

staging
production
Dont Let Changes Build Up

staging
production
Building
Microservices
Dont let changes build up release as soon as you can, and

preferably one at a time!
Sam Newman
Integration & Disintegration
Reducing Risk of Release

Components are
deployed.
Features are released.
Applications consist
of routing.
production
Blue/Green Deployments
1.1
1.1
1.1
1.2
1.2
1.2
Web server
Application
server
Database
server
Message Router
Blue/Green for Services

Deploy
Release
Route
Re-route upon failure
production
release risk
How Big?
# services
Dis-integrate
services that
monitoring shows
are no longer used
production
Building
Microservices
Use timeouts, circuit breakers

and bulk-heads to avoid
cascading failure.
Sam Newman
what problem
denitions
characteristics
SUMMARY
engineering
You must be
this tall to use
microservices
(Micro)service architectures provide unique

benets at the cost of increased (essential)
complexity.
Inverse Conway Maneuver
Build teams that look like

the architecture you want
(and it will follow).
Efferent Coupling
efferent
Strive for low efferent
coupling for your team.
Continuous Delivery
Teams with low eerent coupling
deliver relatively independently
into a common integration
pipeline (without fearing breaking
each others builds).
?S
@neal4d
nealford.com
bit.ly/nf_ftvideo
Functional Thinking
Clojure (inside out)

Stuart Halloway, Neal Ford
bit.ly/clojureinsideout
Functional Thinking
http://shop.oreilly.com/product/0636920029687.do
Understanding the Basics

Neal Ford, Mark Richards
http://oreil.ly/1kM7IuV
Presentation Patterns
Neal Ford, Matthew McCullough, Nathaniel Schutta
http://presentationpatterns.com
Taking a Deeper Dive

Neal Ford, Mark Richards
http://oreil.ly/RfKUqh

Building Microservice Architectures (Neal Ford)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Building Microservice Architectures (Neal Ford)

Uploaded by

Copyright:

Available Formats

BUILDING MICROSERVICE

Organized Around Business Capabilities

Azureus Packages Filtered

From a Real Monolith

Package level coupling

Name withheld by request

ACID versus BASE

As your system becomes more distributed,

because CAP Theorem

What Traditional SOA Got Right

What Traditional SOA Missed

Monoliths vs. Microservices

Products, not Projects

Smart Endpoints, Dumb Pipes

as decoupled & cohesive as possible

Prefer Choreography to Orchestration

Consumer Driven Contracts

Because Conways Law!

Consumer Driven Contracts

Prefer REST over SOAP

Standardize on integration, not platform

Standardize in the gaps between

Standardize on integration, not platform

Have one, two or maybe three

Pick some sensible conventions,

forces coarserundisciplined coupling = mess

Microservice architectures promote coupling from

Decentralized Data Management

Avoid distributed transactions if

ACID versus BASE

Enterprise architects suer from less

Small, Single Responsibility

Standardize on integration, not platform

nd a balance between standardization and freeforall

Partitioning by Existing Coupling

God Object: an object that

Prefer timely partial

Design For Failure

You have to get much better at

You are not a badass if you use

Capture metrics, and logs, for

Use synthetic transactions to test

Use correlation IDs to track

Consider Service Templates to

Inside the Box

Test Pyramid for Microservices

Abstract out underlying

Dont Let Changes Build Up

Dont Let Changes Build Up

Dont let changes build up release as soon as you can, and

Integration & Disintegration

Reducing Risk of Release

Features are released.

Blue/Green for Services

Use timeouts, circuit breakers

(Micro)service architectures provide unique

Inverse Conway Maneuver

Build teams that look like

Clojure (inside out)

Understanding the Basics

Taking a Deeper Dive

You might also like