Convert monolithic .Net Applications to microservices With Principles

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
• #14: Composability - a system design principle that deals with the inter-relationships of components. essential features - self-contained,Stateless
• #16: 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
• #20: 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,
• #22: Warehouse, finance, sales, front desk
• #25: 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.
• #27: Consumer first – expose API
• #29: Consumer first – expose API , API Standards, Swagger, Service discovery, zookeeper, Humane registry
• #30: Consumer first – expose API , API Standards, Swagger
• #35: 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.
• #36: Services should be dumb With a choreographed approach, we could instead just have the customer service emit an event in an asynchronous manner
• #37: 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