Monolithic to Microservices - Handson
- 1. blogs.karthikeyanvk.in How to your Convert Monolithic to Microservices Karthikeyan VK https://blogs.karthikeyanvk.in @karthik3030
- 2. blogs.karthikeyanvk.in Enter Text Why Microservices ? Resilience Scaling Removing Rewriting barrier Ease of Deployment
- 3. blogs.karthikeyanvk.in Enter Text Why Microservices ? Organization Alignment Composability Technology Heterogeneity
- 4. blogs.karthikeyanvk.in Enter Text Organization Alignment • Microservices allows to align our architecture our organization, by helping us minimizing the number of people working on one codebase • Smaller codebases tend to be more productive. • Support Devops
- 5. blogs.karthikeyanvk.in Enter Text Composability • Removing thinking in terms of narrow channel to more holistic concepts of customer engagement such as web/native/mobile/tablet/Wearable device and exposing API as service
- 7. blogs.karthikeyanvk.in Enter Text What are Microservices ? Microservices are small, autonomous services that work together.
- 8. blogs.karthikeyanvk.in Enter Text How Small is Small ? • Lines of Code ? • Who has a system that is too big and that you’d like to break down?
- 9. blogs.karthikeyanvk.in Enter Text How to define being small ? • Smaller the service, the more you maximize the benefits and downsides of Microservices architecture. • When you get smaller, the benefits around interdependence increase • When you get too smaller, the complexity emerges from having more and more moving parts
- 10. blogs.karthikeyanvk.in Enter Text Corporate Culture • Open to technology • Think of Task Force • Leave behind process and procedures • Culture of Automation • Expect failure • Autonomous
- 11. blogs.karthikeyanvk.in Enter Text How to start ?
- 12. blogs.karthikeyanvk.in Enter Text Pet Store Functionality Authentication Search Pet Order Pet
- 13. blogs.karthikeyanvk.in Enter Text What is Bounded Context? • Specific responsibility enforced by explicit boundaries.
- 14. blogs.karthikeyanvk.in Enter Text What is Bounded Context? • A Domain consists of multiple bounded contexts, and residing within each are models that do not need to be communicated outside as well as things that are shared externally with other bounded contexts.
- 15. blogs.karthikeyanvk.in Enter Text What is Bounded Context? • Each bounded context has an explicit interface, where it decides what models to share with other contexts.
- 16. blogs.karthikeyanvk.in Enter Text Business Capabilities • Don’t think in terms of data that is shared • Think in terms of bounded context capabilities that is provided in the rest of the domain. • Communication in Terms of Business Concepts
- 17. blogs.karthikeyanvk.in Enter Text Integration between Microservices • Avoid Breaking Changes • Keep Your APIs Technology-Agnostic • Make Your Service Simple for Consumers • Hide Internal Implementation Detail
- 18. blogs.karthikeyanvk.in Enter Text Conway's law and System Design • Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.
- 20. blogs.karthikeyanvk.in Enter Text Modelled around Business Domain
- 21. blogs.karthikeyanvk.in Enter Text Modelled around Business Domain
- 23. blogs.karthikeyanvk.in Enter Text Hide DB Service 1 Service 2 Service 3 Never !!!!
- 24. blogs.karthikeyanvk.in Enter Text Hide DB Service 1 Service 2
- 25. blogs.karthikeyanvk.in Enter Text Hide Implementation - Client libraries BE Careful on how you use
- 26. blogs.karthikeyanvk.in Enter Text Decentralize all the things
- 27. blogs.karthikeyanvk.in Enter Text Decentralize all the things Orchestration vs Chreography
- 28. blogs.karthikeyanvk.in Enter Text Decentralize all the things Chreography – Semantic Monitoring
- 33. blogs.karthikeyanvk.in Enter Text Culture of automation
- 34. blogs.karthikeyanvk.in Enter Text Do I need microservices ?
- 36. blogs.karthikeyanvk.in Enter Text References @karthik3030 • https://middlewareblog.redhat.com/2017/12/05/the-state-of-microservices-survey-2017- eight-trends-you-need-to-know/ • https://samnewman.io/talks/principles-of-microservices/
Editor's Notes
- #3: Resilience – One part of the service fails and whole application fails, so running application in spite of failures Scaling – One part of application needs more resources and scalling is easy when Microservices Removing Rewriting Barrier – Technology can be changed easily if it is small for specific needs
- #4: Composability - a system design principle that deals with the inter-relationships of components. essential features - self-contained,Stateless
- #6: Composability - a system design principle that deals with the inter-relationships of components. essential features - self-contained, Stateless
- #8: Gather together those things that change for the same reason, and separate those things that change for different reasons
- #9: Gather together those things that change for the same reason, and separate those things that change for different reasons
- #11: learn new runtimes, technologies, or frameworks In Search of Excellence - Tom Peters and Robert H. Waterman, Jr.. Published in 1982
- #13: Composability - a system design principle that deals with the inter-relationships of components. essential features - self-contained,Stateless
- #15: Warehouse, finance, sales, front desk
- #17: These capabilities may require the interchange of information — shared models — but I have seen too often that thinking about data leads to anemic, CRUD-based (create, read, update, delete) services. So ask first “What does this context do?”, and then “So what data does it need to do that?” When modeled as services, these capabilities become the key operations that will be exposed over the wire to other collaborators. Communication in Terms of Business Concepts - It’s also important to think of the communication between these microservices in terms of the same business concepts.
- #18: Technology Agnostic - Avoiding integration technology that dictates what technology stacks we can use to implement our Microservices. Ready shift to java or databases based on requirement
- #19: Organizational issues to consider as well Explain moore’s law two-pizza teams owning the whole lifecycle of their services Explain how about three tier architecture and Microservices fits here wrt to teams
- #22: Domain entities – Data oriented – Collection of capabilities
- #23: Bounded context Think about what can be shared in the model Exposing the hidden is easier than hiding the exposed properties.
- #27: ARM Template Autonomy Owner operator model Own the microservices Internal Open source – submit PR, still proper gate keeper. No service bus – keeping it dumb Proper technical boundary
- #28: GOD Class Use events Talk in queue
- #29: GOD Class Use events Talk in queue
- #31: Swagger Consumer driven contracts Define api standards API Documentation API Gateway – Service Discovery
- #32: Microservices are not reliable by default Kubernetes helps Polly No single point of failure Search for product but cannot order atleast Strangler pattern Circuit breaker
- #33: Logs Monitoring Elastic search Log analytics Dashboards
- #34: Time to market CI/CD Build once and deploy everywhere. Build piplelines
- #35: Organisation alignment Release faster Scaling Adopt Technology faster Embrace uncertainty in digital world