Download to read offline
More Related Content
Similar to Migrating from a monolith to microservices – is it worth it?
More from Katherine Golovinova
Migrating from a monolith to microservices – is it worth it?
- 1. From a monolith tomicroservices Is it worth it?
- 2. About me IuriiIvon SolutionArchitect 14+ yearsin Software Development (8 years @ EPAM) Has been working on lead positions on different projects since 2007. Experienced in various areas and technologies including WEB and desktop applications, WEB services, solutions with mixed technology stack (.NET + Java). Main Focus: Solution Architecture mainly based on Microsoft technologies, performance analysis and improvement, identity and access management Expert Areas: .NET, relational and non-relational databases, identity and access management
- 3. Introduction Ordering Notification Common Misc codeUsers Monolith ? ?
- 4. Motivation Among the reasonsto move from a monolith to microservice architecture developers may consider the following: • To scale some parts of the solution independently • To reuse some pieces of the functionality by other systems • To split release cycles of some parts of the solution • To implement different parts in a different technology stack • The existing code is not well-structured and is difficult to maintain • It is just how software market leaders do ☺ • …
- 5. YOU SHOU LDB E REA DY F OR … 5
- 6. Service contract management Whatto consider: • Tools to define and document API contracts • Generate service clients based on API specification Ordering Service Users Service ?
- 7.
- 8. Service contract management Whatto consider: • Tools to define and document API contracts • Generate service clients based on API specification • Follow REST API recommendations • Versioning • Backward compatibility testing • Consumer-driven contracts Ordering Service Users Service ?
- 9. Service contract management Expectedrequest Minimal expected response Interaction Consumer Provider Mock Consumer Mock Provider Real request Minimal expected response Match with expected request Expected request Real response Match with minimal expected response
- 10. Service contract management Whatto consider: • Tools to define and document API contracts • Generate service clients based on API specification • Follow REST API recommendations • Versioning • Backward compatibility testing • Consumer-driven contracts • How to manage service bus contracts Ordering Service Users Service ?
- 11. Service contract management Tools: -Swagger - NSwag - Pact – consumer-driven contracts - openapi.tools – a catalog of various tools related to OpenAPI standard Ordering Service Users Service ?
- 12. Exception handling What toconsider: • In case of an exception service should return a payload containing at least: • Exception type • Exception message • (optional) Exceptiondata • HTTP response status codes should be assigned according to common recommendations • Exception information must be passed along service invocation chain to avoid losing the original error • Do not expose low-level details such as exception stack in the response payload Client Users Service Ordering Service Exception Exception
- 13. Exception handling HTTP/1.1 400Bad Request { type: "ValidationError", message: "Product count is out of range", data: { property: "ProductCount", allowedRange: { from: 1, to: 25 } } } Client Users Service Ordering Service Exception Exception
- 14. Fault tolerance What toconsider: • Configurable timeouts on all service calls • Retries • Circuit breaker on caller side • Resilience testing Ordering Service Notification Service Users Service Overload Broken Connection
- 15. Fault tolerance Tools: • Polly– .NET resilience library • Simmy – fault-injection tool • Chaosmonkey • Wiremock – simulator for HTTP-base APIs, supports fault injection • … Ordering Service Notification Service Users Service Overload Broken Connection
- 16. Service-to-service call security Whatto consider: • Authentication • Authorization • Isolate non-public services in private networks • Transport-level encryption (HTTPS) Ordering Service Notification Service Users Service
- 17. Service-to-service call security Ordering Service Notification Service ClientSTS John Smith John Smith Ordering Service Notification Service Client STS John Smith Ordering System User Impersonation System user
- 18. VM1 VM2 Improved logging Whatto consider: • Log aggregation • Correlation identifier passed with every service-to-service interaction • Host/service information • Ability to increase logging level for a service or even for a single class on-the-fly Ordering Service Notification Service LogAgent LogAgent Log Aggregator HDD HDD
- 19. VM1 VM2 Improved logging Tools: •Splunk • ELK (Elasticsearch, Logstash, Kibana) • Azure Log Analytics • Amazon CloudWatch Logs Ordering Service Notification Service LogAgent LogAgent Log Aggregator HDD HDD
- 20. Configuration management What toconsider: • Common configuration service OR common configuration storage OR configuration variables substitution during deployment • Secrets encryption • Configuration change process Ordering Service Notification Service Configuration Service
- 21. Configuration management What toconsider: • Common configuration service OR common configuration storage OR configuration variables substitution during deployment • Secrets encryption • Configuration change process Ordering Service Notification Service Configuration files Deployment tool Configuration variables
- 22. Configuration management Tools: • AzureApp Configuration • Azure Key Vault • Etcd (used by Kubernetes) • HashiCorp Consul • HashiCorp Vault • … Ordering Service Notification Service Configuration Service
- 23. Monitoring What to consider: •Performance monitoring • Health-check for all services • Physical resources monitoring (CPU, memory, HDD, network) VM1 VM2 Ordering Service Notification Service Monitoring System Health-checkendpoint Performancemetrics Physicalmetrics
- 24. Monitoring Tools: • AppDynamics • NewRelic • Azure App Insights • Azure Monitor • Zabbix • … VM1 VM2 Ordering Service Notification Service Monitoring System Health-checkendpoint Performancemetrics Physicalmetrics
- 25. Data consistency What toconsider: • Eventual consistency: • Asynchronous reliable messaging • Polling for changes made by another service • Monitoring data consistency Ordering Service Notification Service Create order Create notification
- 26. Deployment What to consider: •Continuous deployment • Continuous delivery • Containerization • Container orchestrators • DevOps engineers Container Container Ordering Service Notification Service Container Tax Calculation Service Container Ordering Service VM1 VM2 Orchestrated
- 27. Deployment Tools: • Docker • Kubernetes •Azure Service Fabric Container Container Ordering Service Notification Service Container Tax Calculation Service Container Ordering Service VM1 VM2 Orchestrated
- 28. Development environment What toconsider: • Running all services locally, containers can significantly simplify this scenario • When working on a single service, connect to others running on a shared environment Tools: • Azure Dev Spaces – allows to share a Kubernetes cluster to debug individual services Notification Service Tax Calculation Service Ordering Service Shared Development Environment Development Machine
- 29. SO I SI T A LL WORTH I T? 29
- 30. Microservices are greatwhen 1. There is a need to share some capabilities with other products Notification Service Tax Calculation Service Product A Product B Product C
- 31. Microservices are greatwhen 2. The expected load is high(e.g. >100 users/sec) andthe solution can be broken down into several separately scalable units Notification Service Notification Service Loadbalancer Tax Calculation Service Tax Calculation Service Loadbalancer Tax Calculation Service
- 32. Microservices are greatwhen 3. There is a need to implement different parts of the solution in different technologies Real-time Service Machine Learning Reporting Service
- 33. Microservices are greatwhen 4. Business domain is too complex or even comprises several domains, hence a single monolithicsolution becomes too expensive to support
- 34. LET’S SU MMARI ZE 34
- 35. Summary • Microservices requireextracost: • Huge amount of extra effort to design, develop and setup common parts and processes • Dedicated DevOps engineers • Infrastructure costs • Organizational overhead • If designed and implemented properly, microservices improve several quality attributes: • Scalability • Supportability • Maintainability • Testability • Reusability
- 36. Summary • Thus, decisionwhether to go with microservices in general depends on analysis of cost, benefits, available resources andrequired time-to-market • Usually microservices are goodwhen: • There is a need to share some capabilities with other products • The expected load is high (e.g. >100 users/sec) and the solution can be broken down into several separately scalable units • There is a need to implement different parts of the solution in different technologies • Business domain is too complex or even comprises several domains, hence a single monolithic solution becomes too expensive to support • And not good when: • Building a prototype • The system is too small to break down into several services • The organization is not ready from resources and governance overhead standpoint
- 37.