DCEU 18: From Monolith to Microservices
1 like•285 views
The document discusses the challenges of transitioning from monolithic architectures to microservices, emphasizing release engineering, independent component lifecycles, and the impact of organizational structures on design. It outlines various tools and strategies for achieving operational excellence and managing complexity in microservices, including contract validation, dependency management, and continuous integration testing. Additionally, it highlights the significance of monitoring and health checks in distinguishing between single service and multiple service environments.
DCEU 18: From Monolith to Microservices
- 1. JEFF NICKOLOFF Founder, Topple From Monoliths to Microservices
- 2. 1. Release engineering for monoliths becomes challenging as groups and codebases scale. 2. Changing technological context is difficult to integrate in monolithic projects. 3. Side effects, leaky abstractions, resource isolation. 4. Security? But why migrate?
- 3. 1. How and why microservice architectures and ownership end up falling along organizational lines. 2. How we can learn from monolith tooling to inform our tooling in a microservice environment. 3. How you can achieve operational excellence at scale taking a logistical approach with Docker. What do we hope to learn?
- 4. • Building, shipping, and running… • Same challenges, but different context. • How will the context change? Challenges
- 5. • More, smaller focused components • Components have independent lifecycles • Network vs memory component addressing • Distributed and localized state • Unreliable wall clocks • Independent component runtime state (health) • Independent component “experiences” Distributed and Independent
- 6. Silos and Cognitive Limits
- 7. • The number is about 150 • What is it? • Relationships in constant flux. So is code. Dunbar's Number
- 8. “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.” Why should we embrace it? Conway's Law
- 9. • Focused development • Focused on-call rotations • Integration on interface reduces dev risk • Ops specialization reduces “time to root cause” • Change impact has “perspective” Isolation in Management and Operation
- 10. • More than “names and numbers… ” • Versioning contracts can be extremely painful • Validate contract changes early, and prefer backwards compatibility • Track contract dependencies • Anticipate long adoption cycles Contract (API) Versioning
- 11. Tools
- 12. • Monoliths - Shared libraries - Code weaving with Aspect Oriented Programming • Microservices - Middleware - Sidecar processes - Orchestrators Tool Forms
- 13. • Not simple function calls • Inter-component: - Authentication - Authorization - Channel encryption - Maintenance • Tool? Service Mesh; API gateways; Netflix Hystrix Trustworthy Communication
- 14. • No more in-process singletons: - Distributed locking - Leadership election • Tools? Orchestrators; DIY with storage locks and fencing Distributed Coordination
- 15. • Linearizing log/event streams without clocks • Log aggregation and centralization • Tools? ELK; Fluent, Syslog Disjoint Event Streams
- 16. • Tracing the causal relationships between a set of inter-component requests • Tools: Zipkin, Jaeger, Service Mesh Multi-Process Debugging
- 17. • Monoliths - Tests versioned with code - Tests consistent snapshots of code - Unit, Functional, and Integration Testing - Loose contract between components - Fails before deployment Evolution of Testability
- 18. • … do the same things, just continuously at runtime. • Microservices - No runtime consistency -> snapshot testing is less useful - Need continuous or edge integration testing - Contract validation becomes critical - Tests define the service contracts Evolution of Testability
- 19. • Names and versions identify contracts - Interfaces, structures, data. Not just code. • Process vs Code Dependencies - Must code to interface - Runtime dependency modeling • Tool? Getting into logistics… Dependency Management
- 21. • More artifacts - Release artifacts: binaries, and images - Runtime artifacts: processes, names, and containers - Configuration: config, secret material • Securing supply chain • Tools: Docker registry, pipelines (CI/CD) Artifact Management
- 22. • “Release Engineering” vs. “Distribute Change Management” • More processes • Declarative desired state - Don’t describe changes - Describe processes, configuration, and state • - Version control it • Tools: Orchestrators Controlling Change
- 23. • Monitoring 1 service vs N services • How do you define health? • How often do you test? • How many missing or out of threshold points trigger alarms? • What actions? • Tools: Orchestrators, Nagios, Visibility/Monitoring platforms Monitoring and Health
- 24. • Monoliths integrate on memory addresses - At build-time with static linking (once during build) - At run-time with dynamic linking (once at startup) • Microservices integrate on network addresses - Runtime only - Distributed and continuous linking Need a distributed linker (we already have a few) Build-time vs Run-time Integration
- 25. • Linking is all about name to address resolution • On a network we call that service registration and discovery (SD) - Bootstrap addresses (static) - DNS (built-in) - VIP (load balancing, reverse-proxies, etc.) - Native SD (proprietary interfaces) - Service Mesh (woven sidecars – configuration, not code) “Distributed Linking”
- 26. If you experience a new problem, look for equivalent tools from your monolith stack. Remember
- 27. Take A Breakout Survey Access your session and/or workshop surveys for the conference at any time by tapping the Sessions link on the navigation menu or block on the home screen. Find the session/workshop you attended and tap on it to view the session details. On this page, you will find a link to the survey.
- 28. Jeff Nickoloff - @allingeek gotopple.com Ciao