Microservices Design
In microservices design, adopting high cohesion and autonomous approach is crucial. High cohesion emphasizes identifying a single focus in business functions and splitting them into finer-grained services to achieve better organization and maintainability. On the other hand, the autonomous approach focuses on loosely coupled services, clear communication by network, and the use of technology-agnostic APIs to promote flexibility and scalability. By following these principles, a robust and efficient microservices architecture can be developed.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Module Overview Microservices Design Principles Approach
Microservices Design Principles | Approach
Approach: High Cohesion Identify a single focus Business function AccountsUI Business domain Split into finer grained services Avoid Iskind of the same ? Gen? erate Invoice CRUD Don't get lazy! Accounts Service ?? ?? Don t be afraid to create many services Question in code\peer reviews Accounts Database Can this change for more than one reason
Approach: High Cohesion Identify a single focus Business function Business domain AccountsUI Split into finer grained services Avoid Iskind of the same Don't get lazy! Accounts Invoicing Service Don t be afraid to create many services Accounts Service Accounts Database Invoicing Database Question in code\peer reviews Can this change for more than one reason
Approach: High Cohesion Identify a single focus Business function Business domain AccountsUI Split into finer grained services Avoid Iskind of the same Accounts EDIInvoicing Service Accounts Invoicing Service Don't get lazy! Accounts Service EDI Accounts Database Invoicing Database Don t be afraid to create many services Invoicing Database Question in code\peer reviews Can this change for more than one reason
Approach: Autonomous Loosely coupled Accounts EDIInvoicing Service Communication by network Synchronous EDI Asynchronous Invoicing Database Publish events Subscribe to events Technology agnostic API Network Avoid client libraries Contracts between services Fixed and agreed interfaces Shared models Clear input and output Accounts Service Avoid chatty exchanges between services Avoid sharing between services Accounts Database Databases Shared libraries
Approach: Autonomous Loosely coupled Communication by network Order Service Synchronous Asynchronous Order Database Publish events 1 Subscribe to events Technology agnostic API Avoid client libraries Network Contracts between services Fixed and agreed interfaces 2 Shared models Clear input and output Avoid chatty exchanges between services Accounts Service Avoid sharing between services Accounts Database Databases Shared libraries
Approach: Autonomous Loosely coupled Communication by network Order Service Synchronous Asynchronous Order Database Publish events Subscribe to events Technology agnostic API Network Message Broker Avoid client libraries Contracts between services Fixed and agreed interfaces Shared models Clear input and output Avoid chatty exchanges between services Accounts Service Avoid sharing between services Accounts Database Databases Shared libraries
Approach: Autonomous Loosely coupled Communication by network Synchronous OrderService Asynchronous Order Publish events InternalModel Subscribe to events Fixed contract Technology agnostic API Avoid client libraries Order Shared Model Contracts between services Fixed and agreed interfaces Fixed contract Shared models Clear input and output Avoid chatty exchanges between services Accounts Service Avoid sharing between services Databases Shared libraries
Approach: Autonomous Loosely coupled Communication by network Synchronous Asynchronous Order Service Publish events Accounts ClientLibrary Subscribe to events Technology agnostic API Avoid client libraries Contracts between services Fixed and agreed interfaces Shared models Accounts Service Clear input and output Avoid chatty exchanges between services Avoid sharing between services Databases Shared libraries
Approach: Autonomous Loosely coupled Communication by network Synchronous OrderService Asynchronous Publish events Subscribe to events Technology agnostic API Avoid client libraries Contracts between services Fixed and agreed interfaces Shared models Clear input and output Accounts Service Avoid chatty exchanges between services Avoid sharing between services Databases Shared libraries
Approach: Autonomous Loosely coupled Communication by network OrderService Synchronous Asynchronous Publish events Subscribe to events Technology agnostic API Avoid client libraries Network Shared Database Contracts between services Fixed and agreed interfaces Shared models Clear input and output Avoid chatty exchanges between services AccountsService Avoid sharing between services Databases Shared libraries
Approach: Autonomous Loosely coupled .Netbased Service Communication by network Synchronous SQL Server Database Asynchronous Publish events Subscribe to events Technology agnostic API REST over HTTP and data inJSON Avoid client libraries Contracts between services Fixed and agreed interfaces Shared models Clear input and output Avoid chatty exchanges between services Javabased service Avoid sharing between services Databases mySQL Database Shared libraries
Approach: Autonomous Microservice ownership by team Responsibility to make autonomous GreenTeam Agreeing contracts between teams Responsible for long-term maintenance Accounts Service Collaborative development RedTeam Communicate contract requirements Communicate data requirements Postage Service Concurrent development Versioning Avoid breaking changes Orders Service Backwards compatibility Integration tests Have a versioning strategy Stock Service Concurrent versions PinkTeam Old and new Semantic versioning Major.Minor.Patch (e.g.15.1.2) Coexisting endpoints /V2/customer/ PurpleTeam
Approach: Autonomous Microservice ownership by team Responsibility to make autonomous Agreeing contracts between teams Responsible for long-term maintenance OrderService Collaborative development New OrderModel Communicate contract requirements Communicate data requirements Contract Change Concurrent development Versioning Avoid breaking changes OrderModel Backwards compatibility Integration tests Have a versioning strategy Concurrent versions Old and new Accounts Service Semantic versioning Major.Minor.Patch (e.g.15.1.2) Coexisting endpoints /V2/customer/
Approach: Business DomainCentric Business function or business domain Approach Identifybusiness domains in a coarse manner Accounts Domain Marketing Domain Review sub groups of business functions or areas Review benefits of splitting further Agree a common language Microservices for data (CRUD)or functions Fix incorrect boundaries Merge or split Sales Domain Sales Domain Explicit interfaces for outside world Splitting using technical boundaries Service to access archive data For performance tuning
Approach: Business DomainCentric Business function or business domain Approach Identifybusiness domains in a coarse manner Review sub groups of business functions or areas Review benefits of splitting further Agree a common language Accounts Domain Microservices for data (CRUD)or functions Fix incorrect boundaries Merge or split Explicit interfaces for outside world Splitting using technical boundaries Service to access archive data For performance tuning
Approach: Business DomainCentric Business function or business domain Approach Identifybusiness domains in a coarse manner Accounts CRUD Service EDIInvoice Service Review sub groups of business functions or areas Review benefits of splitting further Agree a common language Accounts Domain Microservices for data (CRUD)or functions Fix incorrect boundaries Invoice Generation Service Expenses Service Merge or split Explicit interfaces for outside world Splitting using technical boundaries Service to access archive data For performance tuning
Approach: Resilience Design for known failures Failure of downstream systems Accounts Service Otherservices internal orexternal ! Degrade functionality on failure detection Default functionality on failure detection Postage Service Design system to fail fast Use timeouts Orders Service Use forconnected systems Timeout our requests aftera threshold Service to service Stock Service Service to othersystems Standard timeout length Adjust length on a case by case basis Products Service Network outages and latency Monitor timeouts Log timeouts
Approach: Observable Centralized monitoring Real-time monitoring Monitor the host CPU,memory,disk usage,etc. Central Monitoring Expose metrics within the services Response times Timeouts Exceptions and errors Business data related metrics Number of orders Average time from basket to checkout Collect and aggregate monitoring data Monitoring tools thatprovide aggregation Monitoring tools thatprovide drill down options Monitoring tool that can help visualise trends Monitoring tool that can compare data across servers Monitoring tool that can trigger alerts
Approach: Observable Centralized Logging When to log Startup or shutdown Code path milestones Requests,responses and decisions Timeouts,exceptions and errors Structured logging Level Information Error Debug Statistic Date and time Correlation ID Host name Service name and service instance Message Central Logging Traceable distributed transactions Correlation ID Passed service to service
Approach: Automation Continuous IntegrationTools Work with source control systems Automatic after check-in Unit tests and integration tests required X Ensure quality of check-in Code compiles Tests pass Changes integrate Quick feedback Urgency to fix quickly X Creation of build Build ready for test team Build ready for deployment
Approach: Automation Continuous DeploymentTools Accounts Service Automate software deployment Server1 Configure once GO Works with CI tools Orders Service Deployable aftercheck in Reliably released atanytime Continous Deployment Tool Server2 Benefits Products Service Quick to market Reliable deployment Server3 Bettercustomer experience
