BUILDING MICROSERVICE

ARCHITECTURES
@neal4d
nealford.com
 what problem

denitions

characteristics
engineering

AGENDA
 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
From a Real Monolith
Package level coupling
generate class
from a real monolith
diagram crashed x-ray.

Name withheld by request

Software architecture
represents the
tension between
coupling & cohesion.
ACID versus BASE
ACID BASE

Atomic Basic Availability

Consistent Soft-state
Isolated Eventual Consistency
Durable 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/myth-
eric-brewer-on-why-banks-are-base-not-acid-
http://www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf availability.html
 what problem

denitions

characteristics
engineering

AGENDA
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
engineering

AGENDA
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 too many

languages/platforms languages/platforms

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Standardize in the gaps between

services - be exible about what
happens inside the boxes
Sam Newman
 Standardize on integration, not platform

but dont go crazy

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Have one, two or maybe three

ways of integrating, not 20.
Sam Newman

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Pick some sensible conventions,

and stick with them.
Sam Newman
 explicit about
coupling

engineering
safety nets

forces coarser-
undisciplined coupling = mess grained coupling
coupling dynamics become integration issues

Microservice architectures promote coupling from

application to integration architecture.
Decentralized Data Management

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Avoid distributed transactions if

at all possible
Sam Newman

ACID versus BASE

Decentralized Governance
Decentralized Governance
 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?

Standardize on integration, not platform

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
engineering

AGENDA
 Design For Failure

clients must respond gracefully to

provider failure
aggressive monitoring:
- business relevant
- architectural
- semantic
 Monitoring

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

You have to get much better at

monitoring.
Sam Newman
Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

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
DESIGNING FINE-GRAINED SYSTEMS

Capture metrics, and logs, for

each node, and aggregate them
to get a rolled up picture.
Sam Newman
 Synthetic Transactions

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Use synthetic transactions to test

production systems.
Sam Newman
 Correlation IDs ID: 123

ID: 123

ID: 123
Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Use correlation IDs to track

down nasty bugs
Sam Newman
 Engineering Consistency
integration

metrics service behavior

Building downstream
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Consider Service Templates to

make it easy to do the right
thing!
Sam Newman
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
DESIGNING FINE-GRAINED SYSTEMS

platform dierences to provide a

uniform deployment
Sam Newman mechanism.
Dont Let Changes Build Up
staging production
Dont Let Changes Build Up
staging production

Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

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

Message Router

1.2 1.2 1.2

Application Database
Web server server server
 Blue/Green for Services

Deploy

Release

Route

Re-route upon failure

production
 How Big?

release risk

# services
 Dis-integrate
services that
monitoring shows
are no longer used
production
Building
Microservices
DESIGNING FINE-GRAINED SYSTEMS

Use timeouts, circuit breakers

and bulk-heads to avoid
cascading failure.
Sam Newman
 what problem

denitions

characteristics
engineering

SUMMARY
 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
bit.ly/nf_ftvideo

Functional Thinking
nealford.com
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 Taking a Deeper Dive

Neal Ford, Matthew McCullough, Nathaniel Schutta Neal Ford, Mark Richards
http://presentationpatterns.com http://oreil.ly/RfKUqh