Microservices Architecture Introduction Overview Microservice Second Module First























- Slides: 23
Microservices Architecture Introduction
Overview Microservice Second Module First Module Design Approach Introduction VM VM VM Host Third Module Technology Fourth Module Moving Forwards
Module Overview Microservices Emergence of Microservices Design Principles
Microservices What is a Service? |Introduction |The Monolithic
Microservices: What is a Service? Account Orders Offers Basket Shopping website Website Account Service Mobile App Desktop App Network Database
Microservices: What is a Service? Account Orders Offers Basket Website Server 1 Account Load Balancer Mobile App Server 2 Server 3 Desktop App Network Database Server
Microservices: Introduction SOA done well • Knowing how to size a service Traditional SOA resulted in monolithic services • • Micro sized services provide • UI Service Efficiently scalable applications Flexible applications High performance applications • • Client • Application(s) powered by multiple services • Small service with a single focus • Service Lightweight communication mechanism • Both client to service and service to service • Technology agnostic API • Independent data storage • Service Independently changeable • Independently deployable • Distributed transactions • Centralized tooling for management •
Microservices: Introduction Accounts Service Shopping website Promotions Service Account Offers Orders Service Orders Internal Support website Basket Inventory Service Products Service Client Internet API Gateway
Microservices What is a Service? |Introduction |The Monolithic
Microservices: The Monolithic Typical enterprise application • No restriction on size • Large codebase • Longer development times Account Offers Challenging deployment Shopping website Orders • • Orders Inaccessible features • Basket Fixed technology stack • Service Promotions Customer Data Access Database High levels of coupling • Between modules • Internal Support website Inventory Between services • Failure could affect whole system • Products Scaling requires duplication of the whole • Single service on server • Internet Minor change could result in complete rebuild • Easy to replicate environment •
Microservices: The Monolithic Accounts Account Orders Offers Basket Shopping website Customer Promotions Data Access Inventory Products Internet UI Layer Business Layer Database
Emergence of Microservices Why Now? |Benefits
Emergence of Microservices : Why Now? Need to respond to change quickly • Need for reliability • Business domain-driven design Accounts Service Shopping website • Automated test tools • Promotions Service Release and deployment tools • Account Offers Orders Service Orders Internal Support website Basket On-demand hosting technology • Inventory Service Products Service Client On-line cloud services • Need to embrace new technology • Asynchronous communication technology • Internet API Gateway Simpler server side and client side technology •
Emergence of Microservices : Benefits Shorter development times • Reliable and faster deployment • Enables frequent updates • Accounts Service Shopping website Decouple the changeable parts • Promotions Service Account Offers Increased uptime Orders Service Orders Internal Support website Basket Security • • Fast issue resolution • Inventory Service Highly scalable and better performance • Products Service Client Internet API Gateway Better ownership and knowledge • Right technology • Enables distributed teams •
Microservices Design Principles Introduction |Principles |Summary
Microservices Design Principles: Introduction High Cohesion Autonomous Business Domain Centric Resilience Observable Automation
Microservices Design Principles: High Cohesion Single focus • Single responsibility Accounts Service • SOLID principle Only change for one reason • • Postage Service Reason represents • A business function A business domain • Orders Service • Encapsulation principle • OOP principle • Stock Service Products Service Easily rewritable code • Why • Scalability Flexibility Reliability • • •
Microservices Design Principles: Autonomous Loose coupling • Accounts Service V 1 Honor contracts and interfaces • Postage Service V 6 Orders Service V 3 Independently changeable Independently deployable Stock Service V 4 Products Service V 2 Stateless • Backwards compatible Concurrent development
Design Principles: Business Domain Centric Service represents business function • Accounts Department Postage calculator • Accounts Service • Scope of service Accounts Department • Bounded context from DDD • Orders Service Identify boundariesseams • Orders Department Shuffle code if required • Group related code into a service Aim for high cohesion Products Service • • Stock Department Responsive to business change •
Microservices Design Principles: Resilience Embrace failure • Another service Specific connection Third-party system • Accounts Service • • Postage Service ! Degrade functionality • Default functionality • Multiple instances • Register on startup Deregister on failure • Orders Service • Types of failure • ExceptionsErrors Delays Unavailability • Stock Service • • Network issues • Products Service Delay Unavailability • • Validate input • Service to service Client to service • •
Microservices Design Principles: Observable System Health • Status Logs Errors • • Central Monitoring • Centralized monitoring • Centralized logging • Why • Distributed transactions Quick problem solving Quick deployment requires feedback Data used for capacity planning Data used for scaling Whats actually used Monitor business data • • • Central Logging • •
Microservices Design Principles: Automation Tools to reduce testing • Manual regression testing Time taken on testing integration Environment setup for testing • • • ✓ Tools to provide quick feedback • Integration feedback on check in Continous Integration • X ✓ • Tools to provide quick deployment • Pipeline to deployment Deployment ready status Automated deployment • • ✓ • Reliable deployment Continuous Deployment Why • X • Distributed system Multiple instances of services Manual integration testing too time consuming Manual deployment time consuming and unreliable • •