The promises and perils of microservices

2,223 views

Published on

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.

Published in: Software
1 Comment
7 Likes
Statistics
Notes
  • Awesome lonely girl looking for fun on webcam with the you now - www.xslideshare.usa.cc
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,223
On SlideShare
0
From Embeds
0
Number of Embeds
807
Actions
Shares
0
Downloads
51
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

The promises and perils of microservices

  1. 1. The promises and perils of microservices A map for the adventurous developer Uwe Friedrichsen – codecentric AG – 2015-2017
  2. 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
  3. 3. Why?
  4. 4. Must! … Do! … Microservices!
  5. 5. No, you don’t!
  6. 6. Microservices are an architectural choice
  7. 7. When do you need microservices?
  8. 8. If you need to go fast
  9. 9. Go fast? What do you mean with “fast”?
  10. 10. A bit of background …
  11. 11. Evolution of economy & markets
  12. 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. 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. 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. 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. 16. Key drivers Industrial era •  Cost-efficiency •  Scalability •  Repeatability •  Stability •  Efficiency & scale Post-industrial era •  Cycle times •  Adaptability •  Flexibility •  Resilience •  Effectiveness & speed
  17. 17. Evolution of IT
  18. 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. 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. 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. 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. 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. 23. Role of IT today
  24. 24. Business Market IT today is a … … Nervous System … Medium … Product … Differentiator Disruptive Technologies Business Support Systems Continuous Conversation Digitization
  25. 25. IT today is a key success factor to survive in a post-industrial market
  26. 26. The traditional IT “best practices” are counterproductive because they solve
 a completely different problem
  27. 27. We need to rethink IT!
  28. 28. Rethinking IT
  29. 29. What are the new drivers?
  30. 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. 31. What are the new goals?
  32. 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. 33. What are the building blocks?
  34. 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. 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. 36. Still, do I really need microservices?
  37. 37. Take the quick test
  38. 38. Take the real magic triangle …
  39. 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. 40. ... and pick the two properties
 that are most important for you
  41. 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. 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. 43. Of course you can, but you shouldn’t … … because you would pay the full price for µservices and hardly gain anything
  44. 44. What is the price for µservices?
  45. 45. Well, ever heard about µservice hell?
  46. 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. 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. 48. Only go for microservices if you holistically aim for shorter cycle times
  49. 49. What?
  50. 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. 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. 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. 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. 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. 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. 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. 57. Infrastructure automation •  “Make deployment boring” •  Automate tests •  Automate deployments •  Automate management of services in production
  58. 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. 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. 60. How?
  61. 61. How can we avoid µservice hell?
  62. 62. No silver bullet
  63. 63. Topic areas Design Interfaces User Interface Frameworks Datastores Developer Runtime Environment Deployment Production Resilience
  64. 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. 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. 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. 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. 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. 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. 70. Interfaces •  Plan for interface evolution •  Remember Postel’s law •  Consider BFF services (and API gateways) •  Synchronous vs. asynchronous
  71. 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. 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. 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. 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. 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. 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. 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. 78. Deployment •  Continuous deployment pipeline is a must •  Unify deployment artifact format •  Use either IaC tool deployment … •  … or distributed infrastructure & scheduler
  79. 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. 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. 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. 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. 83. Microservice-based systems are complex, distributed, interconnected systems
  84. 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. 85. Do not try to avoid failures. Embrace them.
  86. 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. 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. 88. Event/data flow Event/data flow Resource access Error flow Control flow µS Isolation
  89. 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. 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. 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. 92. So, hope your hell will be more like this …
  93. 93. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

×