Downloaded 46 times
Uploaded byChris Richardson
SVCC Microservices: Decomposing Applications for Testability and Deployability
The document outlines the transition from monolithic to microservices architecture, highlighting its benefits in improving testability and deployability while also acknowledging potential complexities. It discusses essential patterns and considerations for successfully implementing microservices, such as service communication, data consistency, and cross-cutting concerns. The presentation emphasizes the importance of using a structured pattern language to guide architectural decisions and enhance software development processes.
More Related Content
Similar to SVCC Microservices: Decomposing Applications for Testability and Deployability
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
SVCC Microservices: Decomposing Applications for Testability and Deployability
- 1. @crichardson Microservices: decomposing applications fortestability and deployability Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net http://learn.microservices.io Copyright © 2018. Chris Richardson Consulting, Inc. All rights reserved
- 2. @crichardson Presentation goal Overview ofthe Microservice architecture Benefits and drawbacks
- 3.
- 4. @crichardson About Chris Microservices trainingand consulting (http://www.chrisrichardson.net/)
- 5. @crichardson About Chris Founder ofa startup that is creating an open-source/SaaS platform that simplifies the development of transactional microservices (http://eventuate.io)
- 6.
- 7. About Chris: microservices.io Microservicespattern language Articles Code examples Microservices Assessment Platform - coming soon
- 8. @crichardson Agenda From monolith tomicroservices Microservices != silver bullet The Microservices pattern language
- 9. @crichardson Let’s imagine thatyou are building a cool new food delivery application….
- 10. @crichardson Tomcat/App. Server Food ToGo: Monolithic architecture Browser/ Client WAR/EAR MySQL Database Delivery management Order Management Kitchen Management Web UI Restaurant Management HTML REST/JSON The application
- 11. @crichardson The monolithic architecture isNOT an anti-pattern
- 12. @crichardson But successful applications keepgrowing…. FTGO Team FTGO Application
- 13. @crichardson … and growing OrderTeam FTGO ApplicationKitchen Team Delivery Team
- 14. @crichardson Eventually: Testing and deployment is slowand painful Rapid, frequent and reliable delivery is impossible
- 15. @crichardson Technology stack becomes increasinglyobsolete BUT A rewrite is not feasible
- 16. @crichardson Monolithic hell By JohnMartin, Public Domain, https://commons.wikimedia.org/w/index.php?curid=3353638
- 17. @crichardson Businesses must innovatefaster Software Deliver software rapidly, frequently and reliably
- 18.
- 19. @crichardson Application Business capability Service Foodto Go Order Taking Kitchen management Delivery management Business Capability = something a business does to deliver value … Order Service Kitchen Service Delivery Service … Service
- 20.
- 21. @crichardson Service = independently deployablecomponent Command Query API Event Publisher Event Subscriber API Client Consumer facing Implementation Synchronous: REST, gRPC, … Asynchronous: Command/Reply, Notification Service database Events Events Synchronous: REST, gRPC, … Asynchronous: Command/Reply, Notification Data owned by the service Data replicated from elsewhere SLA
- 22. Service size issecondary microservice architecture
- 23. @crichardson Loosely coupled teamsand services Order Service Orders Team Automated deployment pipeline Source code repository Kitchen Service Kitchen Team Automated deployment pipeline Source code repository Delivery Service Delivery Team Automated deployment pipeline Source code repository Working independently > 80% of the time
- 24. @crichardson Modern software development:moving fast and not breaking things! 46x 440x 24x 5x lower Amazon: ~0.001% Netflix: 16 minutes Amazon: every 11.6 seconds
- 25. @crichardson Deliver software rapidly, frequently andreliably Process: DevOps/Continuous Delivery & Deployment Organization: Small, autonomous teams Architecture: microservices Testability Deployability Enables Autonomy
- 26. @crichardson Enables organization toscale without impacting productivity
- 27. @crichardson Microservices experiment safely andevolve the technology stack Java Java Java Java Java Golang “GoLang is cool!” Java Kotlin Java Java “Kotlin is better!” Java Kotlin
- 28. @crichardson Agenda From monolith tomicroservices Microservices != silver bullet The Microservices pattern language
- 29.
- 30. @crichardson Drawbacks of microservices Complexity Development:IPC, partial failure, distributed data Testing: Integration, end to end, … Deployment …
- 31. @crichardson Are microservices agood fit for my application?
- 32. @crichardson Do I havethe skills/pre-requisites in place: automated testing automated provisioning ….. ?
- 33. @crichardson When using microservices: Howto decompose an application into services? How to deploy an application’s services? How to handle cross cutting concerns? Which communication mechanisms to use? How do external clients communicate with the services? How does a client discover the network location of a service instance? How to prevent a network or service failure from cascading to other services? How to maintain data consistency and implement queries? How to make testing easier? How to understand the behavior of an application and troubleshoot problems? How to implement a UI screen or page that displays data from multiple services?
- 34. @crichardson Agenda From monolith tomicroservices Microservices != silver bullet The Microservices pattern language
- 35. @crichardson Microservice pattern language = collectionof patterns that solve these architecture, design, development and operational problems
- 36. @crichardson What’s a pattern? Reusablesolution to a problem occurring in a particular context
- 37. @crichardson The structure ofa pattern encourages objectivity
- 38. @crichardson Without patterns My favorite technologyrocks Your favorite technology sucks http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html
- 39.
- 40. @crichardson Microservices pattern language:http://microservices.io Splitting Reassembling Operations Architecture Microservice patterns Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backend for front end Event sourcing Aggregate Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit BreakerAccess Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Domain event Consumer-side contract test Sidecar Service mesh Application patterns Infrastructure patterns Application Infrastructure patterns Log deployments and changes
- 41. @crichardson The pattern languageguides you when developing an architecture What architectural decisions you must make For each decision: Available options Trade-offs of each option
- 42.
- 43. Issue: What’s thedeployment architecture? Forces Maintainability Deployability Testability … Monolithic architecture Microservice architecture Single deployable/ executable OR Tightly coupled services Multiple loosely coupled services
- 44. Issue: How todecompose an application into services? Forces Stability Cohesive Loosely coupled Not too large Decompose by business capability Decompose by subdomain Organize around business capabilities Organize around DDD subdomains
- 45. @crichardson Issue: how tomaintain data consistency? Context • Each service has its own database • Data is private to a service Forces Transactional data consistency must be maintained across multiple services 2PC is not an option
- 46. @crichardson Issue: how toperform queries? CQRS Context Each service has its own database Forces Queries must join data from multiple services Data is private to a service Maintain query views by subscribing to events API Composition
- 47. @crichardson Issue: what externalAPI to expose? Context One or more clients access the application’s API Forces Different clients need different data Different clients use different networks Mismatch between client’s needs and fine-grained service APIs Application architecture must evolve without impacting clients Services might use protocols that are not web friendly API gateway Backend for front end
- 48. @crichardson Issue: how totest that services collaborate? Context Application consists of multiple collaborating services Forces Services collaborate and must agree on APIs End-to-end tests are slow, brittle, and expensive and best avoided Client Service Contract defines Consumer- side contract test Tests Uses Consumer- driven contract test Tests Uses
- 49. @crichardson The rest aregeneric technical architecture patterns = Undifferentiated heavy lifting!
- 50. @crichardson Issue: How doservices communicate? Messaging Remote Procedure Invocation Domain-specific Forces Services must communicate Usually processes on different machines …
- 51. @crichardson Issue: How tohandle cross cutting concerns? Microservice Chassis Forces Every service must implement logging; externalize configuration; health check endpoint; metrics; …
- 52. Issue: How todeploy an application’s services? Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Serverless deployment Service deployment platform Forces Multiple languages Isolated Constrained Monitor-able Reliable Efficient
- 53. @crichardson Issue: How todiscover a service instance’s network location? Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Forces Client needs IP address of service instance Dynamic IP addresses Dynamically provisioned instances
- 54. @crichardson Issue: how tomonitor the behavior of your application? Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API
- 55. @crichardson Summary The goal ofarchitecture is to satisfy non-functional requirements: deployability, testability, … To enable DevOps/continuous delivery/deployment use the appropriate architectural style Small applications Monolithic architecture Complex applications Microservice architecture Use the pattern language to guide your decision making
- 56.