Download as PDF, PPTX
Uploaded byUwe Friedrichsen
Microservices - stress-free and without increased heart attack risk
The document discusses the complexities and challenges associated with adopting microservices architecture, emphasizing that while they can enhance speed and team autonomy, they also introduce significant technical difficulties. It warns against the misconception that microservices are inherently easy, highlighting the need for sound design and operational practices to avoid 'microservice hell.' The author advocates for careful consideration of modularization, interface evolution, and resilience to effectively implement microservices in a production environment.
More Related Content
Similar to Microservices - stress-free and without increased heart attack risk
Microservices - stress-free and without increased heart attack risk
- 1. Microservices stress-free and withoutincreased heart-attack risk Uwe Friedrichsen, codecentric AG, 2015
- 2. @ufried Uwe Friedrichsen |uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
- 3. I must doµservices!
- 4.
- 5. µServices are anarchitectural choice
- 6. When do Ineed µservices?
- 7. The need forspeed
- 8. The need forspeed Autonomous teams µServices DevOps Continuous Delivery Cloud Craftsmanship …
- 9. The need forspeed Autonomous teams µServices DevOps Continuous Delivery Cloud Craftsmanship … Can’t I just go for µservices without all that other stuff?
- 10. Of course youcan, but you shouldn’t … … because you would pay the full price for µservices and hardly gain anything
- 11. What is theprice for µservices?
- 12. Well, ever heardabout µservice hell?
- 13. A single µserviceis 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
- 14. Consequences • Design ismore 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
- 15. How can weavoid µservice hell?
- 16.
- 17. Topic areas Design Interfaces User Interface Frameworks Datastores DeveloperRuntime Environment Deployment Production Resilience
- 18. "It seems asif 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
- 19. "In theory, programminglanguages 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
- 20. Design • Master modularizationfirst • Use bounded contexts as a modularization starting point • Forget about layered architecture • Rethink DRY – avoid deployment dependencies
- 21. ”If every serviceneeds 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
- 22. Interfaces • Plan forinterface evolution • Remember Postel’s law • Consider API gateways • Synchronous vs. asynchronous
- 23. µS Request/Response : Horizontalslicing Flow / Process µS µS µS µS µS µS Event-driven : Vertical slicing µS µS µS µS µS Flow / Process
- 24. User Interface • Thesingle UI application is history • Separate UI and services by default • Decouple via client centric API gateway • Including UI in service can make sense in special cases
- 25. Bounded Context Bounded Context Bounded Context µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS UI e.g., B2C-Portal UI e.g., embeddedin Partner-Portal UI e.g., Mobile App UI e.g., Clerk Desktop API Gateway API Gateway API Gateway
- 26. Frameworks • Not themost important issue of µservices • Should support at least uniform interfaces, observability, resilience • Nice if also support for uniform configuration and discoverability • Spring Boot/Cloud, Dropwizard, Netflix Karyon, …
- 27. Datastores • Avoid the“single, big database” • Avoid distributed transactions • Try to relax temporal constraints (and make actions idempotent) • Treat your storage as being “ephemeral”
- 28. Development Runtime Environment • Developers should be able to run the application locally • Provide automatically deployable “development runtime environment” • Containers are your friend • Make sure things build and deploy fast locally
- 29. Deployment • Continuous deploymentpipeline is a must • Unify deployment artifact format • Use either IaC tool deployment … • … or distributed infrastructure & scheduler
- 30. Production readiness • Youneed to solve at least the following issues • Configuration, Orchestration, Discovery, Routing, Observability, Resilience • No standard solution (yet) in sight • Container management infrastructures evolve quickly
- 31. Configuration • Netflix Archaius Orchestration • Apache Aurora on Apache Mesos • Marathon • Kubernetes • Fleet 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
- 32. A distributed systemis one in which the failure of a computer you didn't even know existed can render your own computer unusable. Leslie Lamport
- 33. Failures in complex,distributed, interconnected systems are not an exceptional case • They are the normal case • They are not predictable • They are not avoidable
- 34. µService systems are complex,distributed, interconnected systems
- 35. Failures in µservicesystems are not an exceptional case • They are the normal case • They are not predictable • They are not avoidable
- 36. Do not tryto avoid failures. Embrace them.
- 37. resilience (IT) the abilityof a system to handle unexpected situations - without the user noticing it (best case) - with a graceful degradation of service (worst case)
- 38. Resilience • Resilient softwaredesign is mandatory • Start with isolation and latency control • Add automated error recovery and mitigation • Separate control and data flow
- 39. Event/data flow Event/dataflow Resource access Error flow Control flow µS Isolation
- 40. Separation of control/error anddata/event flow W Flow / Process W W W W W W W S S S S S Escalation
- 41. Isolation Latency Control Fail Fast CircuitBreaker Timeouts Fan out & quickest reply Bounded Queues Shed Load Bulkheads Loose Coupling Asynchronous Communication Event-Driven Idempotency Self-Containment Relaxed Temporal Constraints Location Transparency Stateless Supervision Monitor Complete Parameter Checking Error Handler Escalation
- 42. Wrap-up • µServices areno free lunch • Use if responsiveness is crucial • Reduce stress by especially taking care of • Good functional design • Production readiness (incl. resilience) • New challenges for developers (& ops)
- 43. So, hope yourhell will be more like this …
- 44. @ufried Uwe Friedrichsen |uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com