Moving Forwards with Microservices Module Overview Brownfield Microservices

Moving Forwards with Microservices

Module Overview Brownfield. Microservices Greenfield Microservices Provisos

Brownfield Microservices Approach |Migration |Database Migration |Transactions |Reporting

Brownfield Microservices: Approach Existing system • Monolithic system Organically grown Seems to large to split • • • Shopping website Lacks microservices design principles • Identify seams • Service Customer Business Data Access Separation that reflects domains Identify bounded contexts Database • • Start modularising the bounded contexts • Internal Support website Move code incrementally Tidy up a section per release Take your time Existing functionality needs to remain intact Run unit tests and integration tests to validate change Keep reviewing • • Internet • • Seams are future microservice boundaries •

Brownfield Microservices: Approach Existing system • Monolithic system Organically grown Seems to large to split • Accounts Service • • Lacks microservices design principles Accounts Department • Identify seams • Separation that reflects domains Identify bounded contexts Orders Service Orders Department • • Start modularising the bounded contexts • Move code incrementally Tidy up a section per release Take your time Existing functionality needs to remain intact Run unit tests and integration tests to validate change Keep reviewing • Products Service • • Stock Department • • • Seams are future microservice boundaries •

Brownfield Microservices: Migration Code is organised into bounded contexts • Code related to a business domain or function is in one place Clear boundaries with clear interfaces between each • • Convert bounded contexts into microservices Accounts Shopping website • Start off with one Use to get comfortable Make it switchable Maintain two versions of the code • • Orders • • Service Customer Promotions Data Access Database How to prioritise what to split? • By risk By technology By dependencies • • Internal Support website Inventory • Incremental approach • Products Integrating with the monolithic • Monitor both for impact Monitor operations that talk to microservices Review and improve infrastructure Incrementally the monolithic will be converted • • Internet • •

Brownfield Microservices: Migration Code is organised into bounded contexts • Code related to a business domain or function is in one place Clear boundaries with clear interfaces between each • Message Broker Accounts Service Central Monitoring • Convert bounded contexts into microservices • Start of with one Use to get comfortable Make it switchable Maintain two versions of the code • Accounts Shopping website Data Access Accounts Central Logging • • • Orders How to prioritise what to split? • Service Customer Promotions By risk By technology By dependencies Database • Data Access • • Internal Support website Inventory Incremental approach • Products Integrating with the monolithic • Monitor both for impact Monitor operations that talk to microservices Review and improve infrastructure Incrementally the monolithic will be converted • • Internet • •

Brownfield Microservices: Migration Central Monitoring Code is organised into bounded contexts Central Logging • Code related to a business domain or function is in one place Clear boundaries with clear interfaces between each • • Convert bounded contexts into microservices Accounts Service Shopping website • Start of with one • Use to get comfortable Make it switchable Maintain two versions of the code • Promotions Service • • How to prioritise what to split? • Orders Service By risk By technology By dependencies • • Customer Internal Support website • Inventory Service Incremental approach • Integrating with the monolithic • Products Service Monitor both for impact Monitor operations that talk to microservices Review and improve infrastructure Incrementally the monolithic will be converted • • • Internet API Gateway Message Broker •

Brownfield Microservices: Database Migration Avoid shared databases • Message Broker Accounts Service Central Monitoring Split databases using seams • Relate tables to code seams • Supporting the existing application • Accounts Data Access Accounts Central Logging Data layer that connects to multiple database • Tables that link across seams • Orders API calls that can fetch that data for a relationship • Refactor database into multiple databases • Service Promotions Database Data Access Inventory Data referential integrity • Static data tables • Shared data • Products

Brownfield Microservices: Database Migration Central Monitoring Avoid shared databases • Central Logging Split databases using seams • Relate tables to code seams • Accounts Service Shopping website Supporting the existing application • Data layer that connects to multiple database Promotions Service • Tables that link across seams • API calls that can fetch that data for a relationship Orders Service • Refactor database into multiple databases • Customer Internal Support website Data referential integrity Inventory Service • Static data tables • Products Service Internet API Gateway Shared data • Message Broker

Brownfield Microservices: Transactions ensure data integrity • Accounts Service Shopping website Transactions are simple in monolithic applications 3 • Transactions spanning microservices are complex • Complex to observe Complex to problem solve Complex to rollback • Promotions Service 2 • • Options for failed transactions Transaction Manager • Try again later Abort entire transaction Use a transaction manager Two phase commit Disadvantage of transaction manager Reliance on transaction manager Delay in processing Potential bottleneck Complex to implement • • Place Order Internal Support website Orders Service 1 • • • Client Products Service 4 • • Internet API Gateway Message Broker Distributed transaction compatibility • Completed message for the monolith •

Brownfield Microservices: Transactions ensure data integrity • Message Broker Accounts Service Central Monitoring Transactions are simple in monolithic applications • Transactions spanning microservices are complex • Complex to observe Complex to problem solve Complex to rollback • Accounts Data Access Accounts Central Logging • • Options for failed transactions • Try again later Abort entire transaction Use a transaction manager Two phase commit Disadvantage of transaction manager Reliance on transaction manager Delay in processing Potential bottleneck Complex to implement Orders • • • Service Promotions Database • Data Access • • Inventory • • • Products Distributed transaction compatibility • Completed message for the monolith •

Brownfield Microservices: Reporting Microservices complicate reporting • Data split across microservices No central database Joining data across databases Slower reporting Complicate report development • Accounts Service Orders Service Products Service • • —— —— — — ——— Report Possible solutions • Service calls for report data Data dumps Consolidation environment • • •

Brownfield Microservices: Reporting Microservices complicate reporting • Data split across microservices No central database Joining data across databases Slower reporting Complicate report development • Accounts Service Orders Service Products Service • • Reporting Service Possible solutions • Service calls for report data Data dumps Consolidation environment • —— —— — — ——— Report • •

Brownfield Microservices: Reporting Microservices complicate reporting • Data split across microservices No central database Joining data across databases Slower reporting Complicate report development • Accounts Service Orders Service Products Service • • • Reporting Database • Possible solutions • Reporting Service calls for report data Data dumps Consolidation environment • —— —— — — ——— Report • •

Greenfield Microservices Introduction |Approach

Greenfield Microservices: Introduction New project • Evolving requirements • Domain Experts Business domain • Not fully understood Getting domain experts involved System boundaries will evolve • • • New System Teams experience • First microservice Experienced with microservices • • Existing system integration • Monolithic system Established microservices architecture • • Push for change • Dev Team Changes to apply microservice principles •

Greenfield Microservices: Approach Start off with monolithic design • High level Evolving seams Develop areas into modules Boundaries start to become clearer Refine and refactor design Split further when required • Accounts • • Orders • • • Promotions Modules become services • Inventory Shareable code libraries promote to service • Review microservice principles at each stage • Products Prioritise by • Minimal viable product Customer needs and demand • •

Microservices Provisos

Microservices Provisos Accepting initial expense • Longer development times Cost and training for tools and new skills Improved Inrastructure Skilling up Staff • • Skilling up for distributed systems Accounts Service • Handling distributed transactions Handling reporting • • Culture change Postage Service Orders Service Additional testing resource • Longer development time Latency and performance testing Testing for resilience • • Improving infrastructure • Security Performance Reliance • Stock Service • • Overhead to mange microservices Products Service • Cloud technologies • Culture change • Continued monitoring and logging Tools to test and manage

Module Summary Brownfield. Microservices Greenfield Microservices Provisos