Convert monolithic .Net Applications to microservices
- 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
- 11. 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
- 12. blogs.karthikeyanvk.in Enter Text Microservices Management • Defining Strategy • Implementing new projects • Migrating existing project
- 13. blogs.karthikeyanvk.in Enter Text How to start ?
- 14. blogs.karthikeyanvk.in Enter Text Pet Store Functionality Authentication Search Pet Order Pet
- 15. blogs.karthikeyanvk.in Enter TextWhat Makes a Good Service?
- 16. blogs.karthikeyanvk.in Enter Text Main Principles in Splitting Microservices Loose Coupling High Cohesion
- 17. blogs.karthikeyanvk.in Enter Text Loose Coupling • Loosely coupled service knows as little as it needs to about the services with which it collaborates.
- 18. blogs.karthikeyanvk.in Enter Text High Cohesion • Related behaviour to sit together, and unrelated behaviour to sit elsewhere. • Changing behaviour in lots of places to deliver a change, signals lack of high cohesion
- 19. blogs.karthikeyanvk.in Enter Text Practices Practices should underpin our principles Sometimes practices reflect constraints in your organization Coding guidelines Integration Style – HTTP/REST
- 20. blogs.karthikeyanvk.in Enter Text Combining Principles & Practices One person’s principles are another’s practices .NET Team practices and Java Team practises based on principles
- 21. blogs.karthikeyanvk.in Enter Text What is Bounded Context? • Specific responsibility enforced by explicit boundaries.
- 22. 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.
- 23. 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.
- 24. blogs.karthikeyanvk.in Enter Text Models & Shared Models
- 25. blogs.karthikeyanvk.in Enter Text Modules and Services • What models should be shared, and not shared • Identifying boundary within our domain. • Keep related code together and attempt to reduce the coupling to other modules in the system. • Microservices should cleanly align to bounded contexts. • Once proficient, skip the step of keeping the bounded context modelled as a module. Jump straight for a separate service
- 26. blogs.karthikeyanvk.in Enter Text Shared Libraries • Monolithic codebase into multiple libraries. • Libraries give you a way to share functionality between teams and services. • Too much leads You to lose true Technology heterogeneity. • Solution is to create common tasks that aren’t specific to your business domain that you want to reuse across the organization
- 27. blogs.karthikeyanvk.in Enter Text Premature Decomposition • Don’t start decomposition too quickly. • Initial Service boundary will not be right • CI/CD will break • Decompose into Microservices is much easier than trying to go to Microservices from the beginning.
- 28. 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
- 29. 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
- 30. blogs.karthikeyanvk.in Enter Text Interfacing with Customers • The Shared Database
- 31. blogs.karthikeyanvk.in Enter Text Orchestration Versus Choreography • Orchestration
- 32. blogs.karthikeyanvk.in Enter Text Orchestration Versus Choreography • Choreography
- 33. 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.
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
- #12: learn new runtimes, technologies, or frameworks In Search of Excellence - Tom Peters and Robert H. Waterman, Jr.. Published in 1982
- #15: Composability - a system design principle that deals with the inter-relationships of components. essential features - self-contained,Stateless
- #17: A loosely coupled service knows as little as it needs to about the services with which it collaborates. This also means we probably want to limit the number of different types of calls from one service to another, because beyond the potential performance problem, chatty communication can lead to tight coupling. We want related behavior to sit together, and unrelated behavior to sit elsewhere. System design is all about trade-offs
- #21: A loosely coupled service knows as little as it needs to about the services with which it collaborates. This also means we probably want to limit the number of different types of calls from one service to another, because beyond the potential performance problem, chatty communication can lead to tight coupling. We want related behaviour to sit together, and unrelated behaviour to sit elsewhere. System design is all about trade-offs,
- #23: Warehouse, finance, sales, front desk
- #27: Technology heterogeneity - The library typically has to be in the same language, or at the very least run on the same platform.
- #29: 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.
- #30: 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
- #31: Remember when we talked about the core principles behind good microservices? Strong cohesion and loose coupling — with database integration, we lose both things. Database integration makes it easy for services to share data, but does nothing about sharing behavior.
- #32: The downside to this orchestration approach is that the customer service can become too much of a central governing authority. It can become the hub in the middle of a web, and a central point where logic starts to live. I have seen this approach result in a small number of smart “god” services telling anemic CRUD-based services what to do.
- #33: Services should be dumb With a choreographed approach, we could instead just have the customer service emit an event in an asynchronous manner
- #34: 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