With popular poster children such as Netflix and Amazon, using microservices-based architectures seems to be the killer approach to twenty-first-century architecture. This session goes over the benefits, but more so the pitfalls, of using a microservices-based architecture. What impact does it have on your organization, your applications, and dealing with scale and failures, and how do you prevent your landscape from becoming an unmaintainable nightmare?

1. by Bert Ertman
Those who stand for nothing,
fall for anything - Alexander
Hamilton
Microservices
Gone Wrong!
@BertErtman

2. • Fellow, Director of Technology
Outreach at Luminis
• Background in all things Java
since 1995
• Java Champion, JavaOne
Rockstar Speaker, and a Duke’s
Choice Award Winner
• Involved in architecting and
implementing dozens of large
scale systems over the past 20
years or so
• Book author for O’Reilly, speaker
at many conferences

3. Cheaper
Better
Faster
Stronger{ Most problems in
Computer Science have
already been solved in
the 60/70s

5. Say what?
The term "Microservice Architecture" has sprung up over the last few
years to describe a particular way of designing software applications
as suites of independently deployable services. While there is no
precise definition of this architectural style, there are certain common
characteristics around organization around business capability,
automated deployment, intelligence in the endpoints, and
decentralized control of languages and data.
Source: http://martinfowler.com/articles/microservices.html

6. Where did it come from?
• Microservices-style architectures are a response to adjust software
architecture to an ever-evolving spectrum. It addresses Business
Agility through technology:
• Usage of cloud-based infrastructure and services
• DevOps
• The need to scale up the number of people/teams
• Client-side revolution both in technologies and devices

7. Microservices
are about
Business Agility

8. Modularization
• Divide and Conquer
• Break down complex
structures into smaller
chunks that can be solved
individually
• Cohesion over coupling

9. How small is micro?
• Small as in “single responsibility”
• Each service only does one thing, and one thing well
• Not about lines of code, but “small enough to fit in your head”
• Maybe even small enough that you can throw them away – Rewrite
over Maintain

10. Are Microservices a better SOA?

11. Services
• Provide a public, versioned contract for a component
• Have their own life cycle, so they can be
separately deployed
• Hide all implementation details

12. Comparing with SOA
• SOA: dumb endpoints, smart routes
• Endpoint is merely a remote procedure call
• Routing done through ESBs providing location transparency and
transformations

13. Comparing with SOA
• Microservices: Dumb pipes, smart endpoints
• Pipes: usually REST via HTTP(S)
• No intelligence in the route, or at least no more than simple
(persistent) queues

14. SOA is about Reuse
Microservices are
NOT about Reuse

15. What can we learn from Amazon/Netflix?
• They are not optimized for (saving) costs or overly structured
• Focus on opportunities ahead instead of cost savings
• Focus on speed to market (first mover advantage)
• Organized like nature to facilitate insane growth
• Cloud is their strategic advantage!

16. Why shouldn’t we pretend to be Amazon/Netflix?
• Most normal companies ARE looking for cost savings and
restructuring
• Most normal companies don’t have the scale of Amazon/Netflix
• Most normal companies see cloud still as a way to save costs
• If you pretend you are…you get all of their infrastructural problems
for free

17. Companies that have successfully adopted
Microservices have…
• …determined that they are an IT company which happen to offer
financial/healthcare/trading/shopping… services
• …embraced Cloud (technologies) as a strategic advantage
• …established solid CI/CD practices, and deploy to production
multiple times per day

18. Microservices require DevOps

19. *correction*

20. Microservices require
BizDevOpsSec

21. Conway’s Law
“Organizations which design systems ... are
constrained to produce designs which are copies of
the communication structures of these organizations"
—M. Conway 1968

22. What it actually means…
• Make sure the organization is compatible with the software architecture
• If your (microservices) architecture does not reflect the way your
organization is structured, don’t even bother going that way!
• It also means that your teams should be cross-functional. Everyone you
need to build, maintain and get it into production must be part of the
team

23. This is hard!

24. SOAAdoptionModel

25. So what should you do?
• Transform the organization along with the landscape
• Microservices boundaries must be drawn around organizational
capabilities
• Alternatively, they could be drawn around particular development
teams / features

26. There is no single way to do
microservices right!

27. There are many ways to do
microservices wrong!

28. Many wrong ways to do
microservices there are!

29. Struggles
• Data Strategy
• Orchestration vs Choreography
• Re-use Traps
• Test Strategy
• Dealing with Failure

30. Resilience
• The ability of a system to handle unexpected situations
• without the user noticing it (best case)
• with graceful degradation of service (worst case)

31. Anti-fragility
Isolation
Loose-coupling
Latency

32. Isolation
• Avoid cascading failures by
applying bulkheads:
• In shipping: partition the load into
sections allowing you to seal them
off if there is a breach
• In software: isolate services to
prevent cascading failures to
cripple the entire system
Web Application
thread
pool
•
•
•
•
Service
bulkhead
(size=3)

33. Loose-coupling
• Reduce coupling between failure units through:
• asynchronous communication
• location transparency
• relaxed temporal constraints
• idempotency
• self-containment

34. Latency control
• Detect and handle non-timely responses to avoid cascading failures
through:
• Timeouts
• CircuitBreaker
• Fan-out & quickest reply
• Bounded queues
• Shed load
InitiatingService
CircuitBreaker
TargetService
try 1
try 2
try 3
try 83
exception
exception
exception
exception
try 1
try 2
try 3
exception
exception
exception
circuit is CLOSED
circuit trips
and is OPEN
circuit is
HALF-OPEN

35. Anti-fragility
• Try to make code less breakable by correctly applying:
- Encapsulation (OOP)
- Open/Closed principle
- Test Driven Development (TDD)

36. summary

37. Microservices are NOT the logical
next step for enterprise architecture
in every organization

38. Microservices
• ..are suites of independently deployable services, organized around business
capabilities
• ..are small enough so they can ‘fit in your head’ and you can throw them away
• ..are all about promoting modularity at the system level
• ..are thriving on continuous deployment, DevOps, and infrastructure automation
• ..are a legitimate way of achieving business agility in some organizations
• ..will cause nightmares forever, when applied for the wrong reasons!

39. Microservices Gone
Wrong!
Thank you!
@BertErtman