This slide deck is basically an extended and updated version of the "Microservices - stress-free and without increased heart-attack risk" slide deck - yet quite a lot of extensions and updates. The deck is organized in three parts: Why, What and How. The first part addresses the question if and when you should use microservices at all. It tries to create a bigger picture by explaining changing (business) markets and a changing role of IT and fits microservices into that picture. When looking at this picture it also becomes clear that microservices always should accompanied by other measures like DevOps, Cloud and some more if you really want to leverage its benefits. Otherwise you usually only get the downsides of microservices with harvesting their benefits. The second part revisits the famous blog post from James Lewis and Martin Fowler, using it to explain what characteristics the microservice architecural style has. It turns out that this post contains quite a lot of information and that quite often only a subset of the characteristics get implemented. The third part, the "How" dives deeper into the challenges and pitfalls that you usually encounter if you decide to adopt microservices. While of course not being complete and not being a perfect guide that makes everything easy, it should at least help you tho avoid the most common problems and pitfalls. As always the voice track is missing which contains most of the information (it is a 90 min talk after all), but hopefully also the slides alone contain some helpful information.

1. The promises and perils of microservices
A map for the adventurous developer
Uwe Friedrichsen – codecentric AG – 2015-2017

2. @ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

3. Why?

4. Must! … Do! … Microservices!

5. No, you don’t!

6. Microservices are an architectural choice

7. When do you need microservices?

8. If you need to go fast

9. Go fast? What do you mean with “fast”?

10. A bit of background …

11. Evolution of economy & markets

12. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
The “bathtub” curve
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13

13. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Pre-industrial era
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
Tailor-made
solutions
“Mastery
is key to success”

14. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Industrial era
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
Cost-efficiently
scale production
“Get more done with less people
is key to success”

15. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Post-industrial era
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
Continuously respond
to changing demands
“Continuous
customer communication
is key to success”

16. Key drivers
Industrial era
• Cost-efficiency
• Scalability
• Repeatability
• Stability
• Efficiency & scale
Post-industrial era
• Cycle times
• Adaptability
• Flexibility
• Resilience
• Effectiveness & speed

17. Evolution of IT

18. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(Business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT

19. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT
We are
here …

20. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT
… but we still base most of
our decisions on that
We are
here …

21. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Remember the bathtub curve?
This adds an additional twist …

22. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT
… but we still base most of
our decisions on that
We are
here …
Business is very different today …
… than it was back then

23. Role of IT today

24. Business
Market
IT today is a …
… Nervous System
… Medium
… Product
… Differentiator
Disruptive
Technologies
Business
Support
Systems
Continuous
Conversation
Digitization

25. IT today is a key success factor to survive
in a post-industrial market

26. The traditional IT “best practices” are
counterproductive because they solve
a completely different problem

27. We need to rethink IT!

28. Rethinking IT

29. What are the new drivers?

30. IT
Post-Industrialism
Highly dynamic markets
Economic Darwinism
Lean startup/lean enterprise
Continuous design
Digitization
IT as a product
Digital conversation
Social media
Contextual computing
Disruption
Innovation through disruption
Cloud, mobile, IoT, serverless
Big data analytics
Data-driven enterprise
force
change
on

31. What are the new goals?

32. IT
… be quick
Short response times
Holistic IT value chain consideration
… be effective
Focus on outcome, not output
… improve continuously
Improvement as planned activity
needs
to …
… be efficient
Provide required throughput
… be robust
High availability and adaptability
… be flexible
Flexible response to changing needs

33. What are the building blocks?

34. Adaption
DevOps
Systemic optimization
Inspect and adapt
Quick feedback loops
Continuous improvement
…
Process
DevOps
Agile
Lean
Feature Flow (no projects)
Design Thinking
…
Governance
Beyond Budgeting
Decentralized control
Outcome-driven
Lean EAM
…
Organization
DevOps
Autonomous teams
Cross-functional teams
End-2-end responsibility
Routine task automation
…
People
Craftsmanship
T-shaped
Responsibility
Curiosity
Empathy
…
Technology
Cloud
Automation
Microservice
Heterogeneity
Resilience
…
(Some) Building Blocks

35. µService
• “Microservices are the mapping
of organizational autonomy
to software architecture”
• Limited in scope
• Self-dependent
• Loosely coupled
• Improves
• Autonomy
• Response time (if done right)
• Elasticity
• Trade-offs
• Higher design effort
• Harder to operate
• Distributed by default
• Shared nothing
• No shared data
• No cross-service coordination

36. Still, do I really need microservices?

37. Take the quick test

38. Take the real magic triangle …

39. You may pick
two
Good
Fast
Cheap
Optimizing for quality and cycle times
will result in higher costs
Optimizing for quality and costs
will result in long cycle times
Optimizing for cycle times and costs
will result in reduced quality

40. ... and pick the two properties
that are most important for you

41. You may pick
two
Good
Fast
Cheap
Industrial IT
Deliver large batches at minimized costs
towards slow markets
Post-industrial IT
Quickly adapt to ever-changing needs
of dynamic, fast-moving markets
Startup IT
Test hypotheses and pivot as fast as possible
to discover a product-market fit
This is the domain
of microservices

42. Adaption
DevOps
Systemic optimization
Inspect and adapt
Quick feedback loops
Continuous improvement
…
Process
DevOps
Agile
Lean
Feature Flow (no projects)
Design Thinking
…
Governance
Beyond Budgeting
Decentralized control
Outcome-driven
Lean EAM
…
Organization
DevOps
Autonomous teams
Cross-functional teams
End-2-end responsibility
Routine task automation
…
People
Craftsmanship
T-shaped
Responsibility
Curiosity
Empathy
…
Technology
Cloud
Automation
Microservice
Heterogeneity
Resilience
…
(Some) Building Blocks
Can’t I just go for microservices
without all that other stuff?

43. Of course you can, but you shouldn’t …
… because you would pay the full price for µservices and hardly gain anything

44. What is the price for µservices?

45. Well, ever heard about µservice hell?

46. A single µservice is easy …
… but the complexity of the business functionality remains the same
☛ Complexity is shifted from single µservices to µservice collaboration
µServices are usually self-contained …
… i.e., µservices are independent runtime processes
☛ This results in a highly interconnected, distributed system landscape

47. Consequences
• Design is (a lot!) more challenging
• Implementation is more challenging
• Distributed systems are challenging
• Lookup
• Liveness
• Partitioning
• Latency
• Consistency
• …
• New challenges for “monolith developers”
à µServices are not easy at all

48. Only go for microservices if you
holistically aim for shorter cycle times

49. What?

50. Characteristics
1. Componentization via services
2. Organized around business capabilities
3. Products not projects
4. Smart endpoints and dumb pipes
5. Decentralized governance
6. Decentralized data management
7. Infrastructure automation
8. Design for failure
9. Evolutionary design
J. Lewis, M. Fowler, https://www.martinfowler.com/articles/microservices.html

51. Componentization via services
• Out-of-process separation of functionality (in contrast to libraries)
• Independently deployable, replaceable and upgradeable
• Explicit published service interface
• Usually coarse-grained service interface due to remote call costs

52. Organized around business capabilities
• Not organized around technology layers, but business capabilities
• Broad-stack implementation for a business area
• Leads to cross-functional teams (Conway’s law)
• Also possible for monolithic applications, but not the common case

53. Products not projects
• Avoid the project team/maintenance team responsibility separation
• Team should own a product over its full lifecycle
• “You build it, you run it” – full responsibility for the software
• Ties in with organization around business capabilities

54. Smart endpoints and dumb pipes
• Avoid centralized business logic in smart communication mechanisms
• Maximize decoupling by keeping all business logic in services
• Minimize smartness of communication mechanisms
• HTTP (& REST) and lightweight messaging are most commonly used

55. Decentralized governance
• Empower autonomous teams (and give them the responsibility)
• Enable heterogeneous language and technology choices
• Use an OSS-inspired approach for shared assets
• Use consumer-driven contracts

56. Decentralized data management
• Allow different conceptual data models between services
• Allow different storage choices per service (“polyglot persistence”)
• Strive for transactionless coordination between services
• Embrace eventual consistency

57. Infrastructure automation
• “Make deployment boring”
• Automate tests
• Automate deployments
• Automate management of services in production

58. Design for failure
• Design services that they can tolerate the failure of other services
• Constantly reflect on how service failures affect the user experience
• Be able to detect failures quickly
• If possible, restore service automatically

59. Evolutionary design
• Evolutionary evolve the service landscape
• Can be used as transition path from a monolith
• Emphasis on replaceability and upgradeability
• Make sure service changes don’t break its consumers

60. How?

61. How can we avoid µservice hell?

62. No silver bullet

63. Topic areas
Design
Interfaces
User Interface
Frameworks
Datastores
Developer Runtime Environment
Deployment
Production
Resilience

64. "It seems as if teams are jumping on µservices because they're sexy, but the
design thinking and decomposition strategy required to create a good
µservices architecture are the same as those needed to create a well
structured monolith.
If teams find it hard to create a well structured monolith, I don't rate their
chances of creating a well structured µservices architecture.”
- Simon Brown
http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html

65. "In theory, programming languages give us all we need to encapsulate state
and environment - we just need to use them well.
Maybe we just don’t have the discipline? Maybe we had to explicitly advocate
the practice of writing services running in completely different environments
using different languages to trigger the sort of encapsulation that we want? If
that’s the case, we can either see it as a clever self-hack or something we were
forced into by the fact that we programmers are adept at overcoming any
sort of self-discipline we try to impose on ourselves.
Perhaps both are true.”
- Michael Feathers
https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton

66. Design
• Master modularization first
• Strive for low coupling and high cohesion
• Forget about functional decomposition and layered architecture
• Rethink DRY and resusability – avoid deployment dependencies

67. Foundations of design
• High cohesion, low coupling
• Separation of concerns
• Crucial across process boundaries
• Still poorly understood issue
• Start with
• Understanding organizational boundaries
• Understanding use cases and flows
• Identifying functional domains (à DDD)
• Finding areas that change independently
• Do not start with a data model!

68. Dismiss reusability
• Reusability increases coupling
• Reusability leads to bad service design
• Reusability compromises availability
• Reusability rarely pays
• Do not strive for reuse
• Strive for replaceability instead

69. ”If every service needs to be updated at the same
time it’s not loosely coupled”
- Adrian Cockcroft
http://de.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices

70. Interfaces
• Plan for interface evolution
• Remember Postel’s law
• Consider BFF services (and API gateways)
• Synchronous vs. asynchronous

71. µS
Request/Response : Horizontal slicing
Flow / Process
µS
µS
µS
µS
µS
µS
Event-driven : Vertical slicing
µS
µS
µS
µS
µS
Flow / Process

72. Order Fulfillment
Service
Online Shop
Payment
Service
Credit Card
Provider
Shipment
Service
Warehouse
System
<Foreign Service>
<Own Service>
Coupon
Management
Promotion
Campaign
Management
Loyalty
Account
Service
Payment
Provider
PayPal
Loyalty
Management
Accounts
Receivables
Music Library
E-Book
Library
Video Library
E-Mail Server
Coupon
Credit Card
Coordinate
Warehouse
Coordinate
Assets
Notify Cust.
PayPal
Coordinate

73. Order confirmed
Online Shop
Credit Card
Provider
Warehouse
System
<Foreign Service>
<Own Service>
Coupon
Management
Campaign
Management
Account
service
Credit Card
Service
Loyalty
Management
Accounts
Receivables
Music Library
E-Book
Library
Video Library
E-Mail Server
PayPal
PayPal
Service
Warehouse
Service
Promotion
Service
Bonus Card
Service
Coupon
Service
Music Library
Service
Video Library
Service
E-Book Library
Service
Notification
Service
Payment authorized
Digital asset provisioned
Payment failed
<Event>
Order fulfillment
supervisor
Track flow of events
Reschedule events
in case of failure
Services are responsible to eventually succeed
or fail for good, usually incorporating a
supervision/escalation hierarchy for that

74. User Interface
• Be prepared for multiple UIs for multiple devices, target groups, etc.
• Separate UI and service by change cohesion, not by dogma
• Decouple via client centric BFF service
• Take optimizations for slow and no connectivity into account

75. Frameworks
• Not the most important issue of µservices
• Should support at least uniform interfaces, observability, resilience
• Nice if also support for uniform configuration and discoverability
• Options are legion – choose the one that fits your needs best

76. Datastores
• Avoid the “single, big database” – embrace “polyglot persistence”
• Avoid distributed transactions – usually a sign for a poor design
• Try to relax temporal constraints (and make actions idempotent)
• Treat your storage as being “ephemeral”

77. Development Runtime Environment
• Developers should be able to run (parts of) the application locally
• Provide automatically deployable “development runtime environment”
• Containers and schedulers are your friends
• Make sure things build and deploy fast locally

78. Deployment
• Continuous deployment pipeline is a must
• Unify deployment artifact format
• Use either IaC tool deployment …
• … or distributed infrastructure & scheduler

79. Production readiness
• You need to solve at least the following issues
• Configuration, Orchestration/Choreography, Discovery, Routing, Observability, Resilience
• Bad news: No standard solution (yet) in sight
• Good news: Available solutions evolve quickly

80. Configuration
• Netflix Archaius
Orchestration/Choreography
• Mesosphere
• Nomad
• Kubernetes
• Swarm
Discovery
• Netflix Eureka
• Apache ZooKeeper
• Kubernetes
• Etcd
• Consul
Routing
• Netflix Zuul & Ribbon
• Twitter Finagle
Monitoring
• Hystrix
• Twitter Zipkin (Distributed Tracing)
Measuring
• Dropwizard Metrics
Logging
• ELK
• Graylog2
• Splunk
Slide is mostly obsolete due to
missing updates for some months

81. A distributed system is one in which the failure
of a computer you didn't even know existed
can render your own computer unusable.
Leslie Lamport

82. Failures in complex, distributed, interconnected
systems are not an exceptional case
• They are the normal case
• They are not predictable
• They are not avoidable

83. Microservice-based systems are
complex, distributed, interconnected systems

84. Failures in microservice-based systems
are not an exceptional case
• They are the normal case
• They are not predictable
• They are not avoidable

85. Do not try to avoid failures. Embrace them.

86. resilience (IT)
the ability of a system to handle unexpected situations
- without the user noticing it (best case)
- with a graceful degradation of service (worst case)

87. Resilience
• Resilient software design is mandatory
• Start with (functional & technical) isolation and latency control
• Add automated error recovery and mitigation
• Separate control and data flow

88. Event/data flow
Event/data flow
Resource access
Error flow
Control flow
µS
Isolation

89. Separation of control/error
and data/event flow
W
Flow / Process
W
W
W
W
W
W
W
S
S
S
S
S
Escalation

90. Core
Detect
Treat
Prevent
Recover
Mitigate
Complement
Supporting
patterns
Redundancy
Stateless
Idempotency
Escalation
Zero downtime
deployment
Location
transparency
Relaxed
temporal
constraints
Fallback
Shed load
Share load
Marked data
Queue for
resources
Bounded queue
Finish work
in progress
Fresh work
before stale
Deferrable work
Communication
paradigm
Isolation
Bulkhead
System level
Monitor
Watchdog
Heartbeat
Acknowledgement
Either level
Voting
Synthetic
transaction
Leaky
bucket
Routine
checks
Health
check
Fail fast
Let sleeping
dogs lie
Small
releases
Hot
deployments
Routine
maintenance
Backup
request
Anti-fragility
Diversity
Jitter
Error
injection
Spread
the news
Anti-entropy
Backpressure
Retry
Limit retries
Rollback
Roll-forward
Checkpoint
Safe point
Failover
Read repair
Error
handler
Reset
Restart
Reconnect
Fail silently
Default value
Node level
Timeout
Circuit
breaker
Complete
parameter
checking
Checksum
Statically
Dynamically
Confinement

91. Wrap-up
• Microservices are no free lunch
• Use if business responsiveness is crucial
• Complement with additional measures
• Know the “what” of microservices
• Reduce stress by especially taking care of
• Good functional design
• Production readiness (incl. resilience)
• New challenges for developers (& ops)

92. So, hope your hell will be more like this …

93. @ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com