The SeVEN DEADLY SINS OF MICRoservices
Daniel Bryant
@danielbryantuk
Container Solutions London
(WITH Credit to Tareq Abedrabbo, OPENCREDO)

The Seven Deadly Sins
• 1. LUST …
• 2. GLUTTONY
• 3. GREED…
• 4. SLOTH
• 5. WRATH
• 6. ENVY
• 7. PRIDE
19/06/15
@danielbryantuk

The Seven Deadly Sins (of Microservices)
• 1. LUST - Using the latest and greatest tech…
• 2. GLUTTONY - Excessive communication protocols
• 3. GREED - All your service are belong to us…
• 4. SLOTH - Creating a distributed monolith
• 5. WRATH - Blowing up when bad things happen
• 6. ENVY - The shared single domain fallacy
• 7. PRIDE - testing in the world of transience
19/06/15
@danielbryantuk

Who Am I?
• OpenCredo / Container Solutions
ü Agile, CI/CD, DevOps
ü Microservices and cloud
ü Docker, Mesos and Kubernetes
• London Java Community Associate
• Adopt OpenJDK and JSR
• InfoQ Editor and DZone MVB
19/06/15
@danielbryantuk

So, What is a microservice?
“Loosely coupled service oriented architecture
with bounded contexts”
Adrian Cockcroft
“Applications that fit in your head”
James Lewis
19/06/15
@danielbryantuk

1. Lust - Using THE LATEST and Greatest Tech…
19/06/15
@danielbryantuk

Microservices...
They solve all of our problems, Right?
19/06/15
@danielbryantuk

No... Not necessarily good for speed
19/06/15
@danielbryantuk
skillsma7er.com/skillscasts/6143-­‐microservices-­‐for-­‐speed
HOT
OFF
THE
PRESS!!
marJnfowler.com/bliki/
MonolithFirst.html

No... Check your architecture/design skills
“If you can't build a [well-structured] monolith,
what makes you think microservices are the answer?”
Simon Brown
(bit.ly/1n7D0vp)
19/06/15
@danielbryantuk

No... Check your architecture/design skills
19/06/15
@danielbryantuk

No... Operational maturity is vital
19/06/15
@danielbryantuk
marJnfowler.com/bliki/MicroservicePrerequisites.html

Microservices are very useful
But check your use case...
...Evaluation is a key skill
19/06/15
@danielbryantuk

Evaluation
“I will postpone using this shiny new framework until
my peers have validated the proposed benefits with
rigorous scientific experiments”
- Said by no programmer
…ever
19/06/15
@danielbryantuk

Pick Your (Technical) Battles...…
• As Dan McKinley says, “Choose Boring Technology”
– Optimize globally across organisation
• Java and Spring (Boot) are perfectly acceptable
• ... As are tomcat/jetty
19/06/15
@danielbryantuk

Matt Raible’s Comparison Framework
19/06/15
@danielbryantuk

2. GLUTTONY - Excessive Communication PROTOCOLS
19/06/15
@danielbryantuk

Standardize Across the Organization
• Choose one synchronous protocol
– e.g. JSON over HTTP
• Choose one asynchronous protocol
– e.g. RabbitMQ
Don’t gold-plate, but know your options: ProtoBuf, Thrift, ZeroMQ, MQTT
19/06/15
@danielbryantuk

Enterprise communication (Beam me up?)
19/06/15
@danielbryantuk
www.dzone.com/research/guide-­‐to-­‐enterprise-­‐integraJon

3. GREED - All your service are Belong to us…
19/06/15
@danielbryantuk

How Do Committees Invent?
“organizations which design systems ...
are constrained to produce designs which are copies of the
communication structures of these organizations”
- Melvin Conway, 1968
19/06/15
@danielbryantuk

19/06/15
@danielbryantuk
Dev
QA
Ops
Hand-­‐off
delays
Hand-­‐off
delays
Slow
feedback
Slow
feedback
Lack
of
cohesion,
shared
understanding
and
joint
accountability
Front-­‐end
Database
Middleware

19/06/15
@danielbryantuk

Cross-functional Teams
• Spotify (bit.ly/1C46ZKo)
– Culture
• Amazon (bit.ly/1F3Dgkm)
– Communication
• Gilt (gi.lt/1rgyWvO)
– Strategic alignment
19/06/15
@danielbryantuk

Conway was Telling the Truth... Deal with it!
19/06/15
@danielbryantuk

4. SLOTH - Creating a distributed monolith
19/06/15
@danielbryantuk

Can’t Deploy Services Independently?
Check your ‘bounded contexts’ and/or data ‘fault-lines’
(Also, check you have separated deploy and release)
19/06/15
@danielbryantuk

Can’t Deploy Services Independently?
• Schema-first design
– Michael Bryzek (Gilt): APIdoc
• Consumer-driven Contracts FTW
– Martin Fowler: CDC - A Service Evolution Pattern
“CDC is BDD for microservices”
19/06/15
@danielbryantuk

Architecture - not a Dirty Word
• Technical leadership (bit.ly/1EUwpLl)
• Communication (bit.ly/1Ia3u8o)
• Promote shared understanding
• ‘Just enough’ up front design
19/06/15
@danielbryantuk

5. WRATH - Blowing up when bad things happen
19/06/15
@danielbryantuk

Bring in Michael Nygard (Or some monkeys)
19/06/15
@danielbryantuk

OPERATIONAL Concerns: Technical
• Continuous delivery is a microservice prerequisite
– Rapid provisioning
– Basic monitoring
– Rapid application deployment
• I.E. Agile & DevOps
19/06/15
@danielbryantuk

Operational Concerns: Social
• Failure happens all the time... Get used to it!
• 'Gameday' or 'Disaster in recovery testing' (Real) Scenarios
• Failure injection testing (FIT):
– Building 'Failure as a Service' at Netflix without the Simian Army
19/06/15
@danielbryantuk

Share the pain...
19/06/15
@danielbryantuk

“Dev-on-call”
An occasional spike to the head
is a good thing...
...metaphorically speaking
• You write it, you run it
– Accountability
– Shared responsibility
– Communication
19/06/15
@danielbryantuk

6. ENVY - The shared SINGLE domain fallacy
19/06/15
@danielbryantuk

One Model to Rule Them All...
• One model…
– Breaks encapsulation
– Introduces coupling
• Know your DDD
– Entities
– Value Objects
– Aggregates and Roots
19/06/15
@danielbryantuk

But... how do I generate Reports?
• Aggregated reporting pattern
– Pull by service
• Data Pumps
– Push (Event sourcing?)
19/06/15
@danielbryantuk

7. PRIDE - testing in the world of transience
19/06/15
@danielbryantuk

People are surprisingly quiet about this...
19/06/15
@danielbryantuk
marJnfowler.com/arJcles/microservice-­‐tesJng/

Testing With Microservices is Difficult...
• Invest in your build pipeline testing
– Serenity BDD
– Wiremock / Saboteur
– Jenkins Performance plugin
19/06/15
@danielbryantuk

Testing With Microservices is Difficult...
• Do it in production(?)
– Netflix
– Hailo
– Gilt
• This is an advanced pattern!
– Automation is essential!
19/06/15
@danielbryantuk

Summary
• 1. LUST - Using the latest and greatest tech…
• 2. GLUTTONY - Excessive communication protocols
• 3. GREED - All your service are belong to us…
• 4. SLOTH - Creating a distributed monolith
• 5. WRATH - Blowing up when bad things happen
• 6. ENVY - The shared single domain fallacy
• 7. PRIDE - testing in the world of transience
19/06/15
@danielbryantuk

19/06/15
@danielbryantuk

THANKS...
@danielbryantuk
daniel.bryant@container-solutions.com
@containersoluti
www.container-solutions.com
(Credit to Tareq Abedrabbo for inspiration/guidance)
19/06/15
@danielbryantuk