Microservices.pdf
- 1. Andrei Shakirin, VMware Tanzu Labs Splitting Monolith Application to Microservices: gains and challenges
- 2. Agenda • Monolith vs Microservices architecture • Introduction into eCommerce use case • Overview of monolith architecture • What were good with monolith? • What were the pain points in monolith? • Iterative way to microservices world • Challenges in microservice architecture and possible solutions • Conclusions and recommendations
- 3. About Me • Senior Engineer by VMWare Tanzu • PMC in Apache CXF • Contributions in Apache Syncope, Apache Aries and Apache Karaf • Speaker in technological and methodological conferences
- 4. 4 Monolith vs Microservices Architecture Styles Monolith Microservices System design Build as single system Build as set of independent subsystems based on business subdomain (binding context) Codebase Normally single code repository Multiple code repositories per subsystem (microservice) Deployment Whole system deployed as single deployment unit Subsystems are deployed independently Datastore Normally single shared datastore Every subsystem owns it’s database Communication Local inside the application modules Remote sync or async communication between subsystems Technology Build on single homogenues technology Can use different technolgies in subsystems
- 5. E-Commerce Project Setup for Monolith • Backend for E-Commerce system (provide Rest APIs and functionality to manage users, carts, checkouts, products, orders, fulfilments) • 3 Teams, each about 7-8 persons • Technologies: Java, OSGi, Hibernate, PostgreSQL, Apache Karaf, ActiveMQ, Apache CXF • Methodology: scrum
- 6. eCommerce Platform Architecture Middleware Web Browser Frontend PostgreSQL Mobile App Credit-Worthiness Check System Active MQ SAP Online Finance System External consumers REST API Mongo DB
- 7. Core Middleware Design Customer Domain Article Domain Order Domain Core User Service Core Cart Service Core Article Service Core Order Service SAP Messaging REST REST REST REST Core Domain DAOs DB DB DB OSGi Container (Karaf) SAP Connector JMS Connector
- 8. What is Good With Monolith? • Quick start and first achievement • Homogenous approaches to design APIs, GUIs, architecture • Simple build and deployment pipelines • Easy communicate between system components (Java Interfaces) • Easy monitoring • Teams have single development and deployment guideline (not always optimal) • Less complexity in administration by DevOps
- 9. What Hurts the Teams with Monolith? Issue Description Prio Keeping up to date Upgrade of JDK or third parties is possible only for all services and all teams: all or nothing high Resilience l Services share a common HTTP thread pool l DB connections share DB connection pool high Shared deployment One vertical team can easily break the environment shared by three other teams high Development cycle Long development cycle: implement → deploy → test high Innovations New technologies applied by one team as third party dependencies can affect other teams medium Scalability All services and components can be scaled only together medium Learning curve New developers have long learning curve, often are scared to refactor the system, because of complex interrelations medium
- 10. Step 0: Decouple consumers using Gateway Gateway Old Service1 inside Monolith New Microservice1 Container Consumer 1 Consumer 2 Consumer 3 Routing / Canary release 90% 10% Old Service2 inside Monolith Old Service3 inside Monolith
- 11. Step 1: Extract Services with Minimum Dependencies on Monolith Gateway Old Service2 inside Monolith Address Microservice Monolith container Consumer 1 Consumer 2 Consumer 3 Routing / Canary release 90% 10% Old Service1 inside Monolith Old Service3 inside Monolith • Minimum dependendencies from rest monolit • Independent data store • Low complexity
- 12. Step 2: Extract Services with High Availability Requirements Gateway Old Service2 inside Monolith Price&Availability Microservice Monolith container Consumer 1 Consumer 2 Consumer 3 Routing / Canary release 90% 10% Old Service1 inside Monolith Old Service3 inside Mnolith • Request load is essentially higher (or lower) as rest monolith components
- 13. Step 3: Split Code Base due domain duplication User Customer Domain Checkout Article Domain Order Domain User Service Cart Service Checkout Service Order Service SAP Messaging REST REST REST REST User Core Domain DAOs DB OSGi Container (Karaf) Cart Customer Domain Cart Core Domain Core Order Domain Cart Article Domain Checkout Core Domain Core framework as thridparty
- 14. Step 4: Extract core services with shared Database and Connectors Docker Order Service REST R E S T Docker Checkout Service REST R E S T Docker Cart Service REST R E S T DB Docker User Service REST R E S T SAP Messaging DB
- 15. Step 5: Decentralize Data Management Docker Order Service REST R E S T Docker Checkout Service REST R E S T Docker Cart Service REST R E S T Docker User Service REST R E S T SAP Messaging DB DB DB DB
- 16. K8S Cluster Target View PODs Order Service REST R E S T PODs Checkout Service REST R E S T PODs User Service REST R E S T PODs Cart Service REST R E S T DB DB DB DB Messaging
- 17. Microservice Architecture Challenges Technical l CI/CD pipelines l Monitoring solution l Central logs with elastic search functionality l Messages Tracing and debugging Organizational l Teams use heterogeneous style in APIs, GUIs, architecture l Features required changes in multiple services l Release cycles and central QA l Mistakes in subdomains split and teams responsibilities
- 18. 1. CI/CD Pipeline Jenkins mvn compile jib:build SpringBoot Application Google Docker Registry JIB Plugin <plugin> <groupId>com.google.cloud.tools</groupId> <artifactId>jib-maven-plugin</artifactId> <version>${jib-maven-plugin.version}</version> <configuration> <from> <image>openjdk:11</image> </from> <to> <image>${jib-maven-plugin.image}</image> <tags> <tag>${project.version}</tag> </tags> </to> </configuration> </plugin> K8S Cluster Helm chart
- 19. 2. Monitoring Solution With Instana
- 20. K8S Cluster 3. Logging Solution PODs Order Service REST R E S T PODs Checkout Service REST R E S T PODs User Service REST R E S T PODs Cart Service REST R E S T L o g s Fluentbit parser Fluentbit parser Fluentbit parser Fluentbit parser Graylog server
- 21. 3. Logging and Tracing Solution
- 22. 4. Tracing: proprietary solution Service MDC Logs JAX-RS Filter Client Generate SpanID Log SpanID with every statement Propagate SpanID
- 23. 4. Tracing: alternative l SpringBoot Sleuth l Zipkin/Brave
- 24. Organizational Challenges Issue Solution Heterogenous design style: APIs, GUIs, architecture Explain best practices, show success stories, organize common workshops, but avoid to force and press teams decisions Features span multiple services Well defined contracts between microservices. Compatible changes, especially in APIs Communication between teams If too match dependencies → rethink splitting of microservices Release cycles and central QA Prolong teams responsibility to production deployment and maintenance
- 25. Wrong Split of Subdomains These mistakes can be very expensive, especially if organisation is not flexible enough Recommendations: l Train on Monolith: l Isolate subdomains in packages l Decouple through the interfaces and dependency injection l Use consistent names for contexts across application l Move and split classes around until boundaries are clear l Use pair reviews to ensure the architecture design l Clearly communicate with managers and/or business to plan time for split l Constantly review the boundaries and update them by project evolving
- 26. Conclusions l There is not single silver bullet architecture: the right choice depends on your requirements, business domain and development perspective l Often starting from monolith is faster and pragmatic l Split monolith to microservices only because of good reasons l Prefer iterative splitting process to Big Bang, use Strangler and Gateway patterns l Start splitting from more simple and critical services l Be aware of technical and organisational challenges after the split and provide solutions (CI/CD, logging, tracing, monitoring, async communication) l Mistakes in microservices boundaries definition are expensive: train on monolith and check and rethink the boundaries by system evolving
- 27. Thank You!
- 28. Step 2: Add Helm Chart and Terraform Project
- 29. Old Solution with ActiveMQ Marketplace Mirakl Seller1 Seller2 Seller3 SellerN ActiveMQ Topic Consumer Group Product Consumer Group Price & Availabilty Consumer Consumer
- 30. Scaling asynchronous processing using Kafka Marketplace Mirakl Seller1 Seller2 Seller3 SellerN Kafka Topic Partition 1 Partition 2 Partition 3 Partition 4 Consumer Group Product Consumer Group Price & Availabilty Consumer 1 Consumer 2 Consumer 1 Consumer 2 Consumer 3 Consumer 4
- 32. Spring Rest Docs
- 33. Spring Rest Docs
- 34. Questions to Tanzu Labs • Are the Pivotal principles like TDD & Pair Programming still applied by the customer engagements? • Are there any principle structural changes on Pivotal after acqusition? • Are most of engagements related to CloudFoundry product? • Describe typical phases of engagement • Do the customers use Quarkus Graal VM / Micronaut as alternative to SpringBoot? • Which Cloud Providers customers typicaly used: Amazon, Azure, GCP? • VMware: internal conferences, presentation, team events?