The latest articles on DEV Community by Deepanshu chhabda (@dpnshu_). https://dev.to/dpnshu_ https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F413608%2F5a3b040a-facd-49b6-9217-5f174572acb4.jpg https://dev.to/dpnshu_ en Deepanshu chhabda Tue, 27 Jul 2021 18:17:14 +0000 https://dev.to/dpnshu_/1-notes-on-building-microservices-4o8a https://dev.to/dpnshu_/1-notes-on-building-microservices-4o8a <p>Currently reading <a href="https://www.oreilly.com/library/view/building-microservices/9781491950340/"><strong>Building Microservices: Designing Fine-Grained Systems</strong></a> and trying to curate notes for myself and some greater good 😉. I'm trying to approach this in a minimalistic way keeping the essence of chapters intact.</p> <h2> Introduction </h2> <h3> Small, and Focused on Doing One Thing Well </h3> <ul> <li>Cohesion - To have related code grouped together.</li> <li>Enforcing SRP by Uncle BOB <ul> <li><strong>Gather together those things that change for the same reason, and separate those things that change for different reasons.</strong></li> <li> <strong>Key rules</strong> <ul> <li>Small enough and no smaller.</li> <li>Is it codebase too big to be managed by a small team?</li> </ul> </li> </ul> </li> </ul> <h3> Autonomous : Freedom to govern itself </h3> <ul> <li> <strong>Golden rule</strong>: Can you make a change to a service and deploy it by itself without changing anything else?</li> <li>Decoupling is an important aspect <ul> <li>Modelling the service right </li> <li>Choosing right good, decoupled APIs</li> </ul> </li> </ul> <h2> Key benefits </h2> <h3> Tech Heterogenity </h3> <ul> <li>Performance improvement can be done easily by consuming a new stack</li> <li>Adopting new tech is easy - Start with a service with limited potential impact.</li> </ul> <h3> Resilience : Capacity to recover quickly </h3> <ul> <li> <strong>Key</strong> : Bulkheads (Barriers between services)</li> <li>Service boundaries are obvious bulkheads</li> <li>In monolithic, everthing stops at once. We run it on multiple machines to handle this scenario.</li> <li>In microservices, building a system that handles total of failure of one service( and degrade functionality accordingly).</li> </ul> <h3> Scalability </h3> <ul> <li>Scaling is easier for micro than monolithic service. One aspect of complete service can be scaled individually.</li> <li>On-demand provisioning (like by AWS) on pieces that need it.</li> </ul> <h3> Easy of deployment </h3> <ul> <li> <strong>Key factors</strong> <ul> <li>Delta in subsequent releases</li> <li>Avoiding High Risk, Large Impact deployments </li> </ul> </li> <li>Microservices mitigates above factors' bad consequences</li> </ul> <h3> Organizational Alignment </h3> <ul> <li> Working on any one codebase to hit the sweet spot of team size and productivity.</li> </ul> <h3> Composability </h3> <ul> <li>Reuse of existing functionality</li> <li>Web, native application, mobile web, tablet app, or wearable device</li> </ul> <h3> Replacibility optimization </h3> <ul> <li>Scary Legacy code - vital and risky to replace</li> <li>Small service - Low cost to replace</li> </ul> microservices design systems