Following topics will be addressed into presentation: Motivation and goals of splitting monolith application Criteria and markers to start splitting process. Is it necessary at all? Optimal order of extracting microservices How organize the whole process in closed iterative steps? What can be done with common libraries and shared code? Options for technology and deployment of target microservices How organize and motivate the teams and convince management? Speaker Bio Andrei is a Software Architect in VMWare Tanzu Labs. The areas of his interest are REST API design, Microservices, Cloud, resilient distributed systems, security and agile development. Andrei is PMC and committer of Apache CXF and committer of Syncope projects.

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?