apidays LIVE Hong Kong 2021 - API Ecosystem & Data Interchange August 25 & 26, 2021 Modernizing Monolith Applications with API Architecture John Yeung, EASG Committee at Hong Kong Computer Society

1. H O N G KO N G
Modernizing Monolithic Applications
with API Architecture
John Yeung
EASG Committee at HK Computer Society
August 2021
S e s s i o n T o p i c

2. Agenda
• Introduction
• Monolithic vs Microservice Architecture
• Best Practices for Adopting Microservices
• Case Study

3. H O N G KO N G

4. The New Normal
Companies are increasingly global, and their products are completely digital.
Source: Gartner
47% 79% 67%

5. When the impact of change is small,
the release velocity can be increased.
Monolith Microservices

6. What is Monolith?
What is a monolithic application? There are
many definitions available, such as legacy
application or codebase that evolved
organically, or an application that does not
have clear domain and module boundaries.
In general, monolithic applications are those
application which grew over time, became
difficult to understand and manage, with
highly coupling designs.

7. What are Microservices?
Microservices are an architectural pattern
for software development where software
is composed of small independent services
that communicate over well-defined APIs.
These services are owned by small and self-
contained team.

8. H O N G KO N G
Monolithic vs Microservice Architecture

9. Monolithic vs Microservice Architectures
•
•
•
•
Monolithic
•
•
•
•
Microservice

10. Monolithic Architecture
Store Front UI
Account Service
Shopping Cart Service
Delivery Service
The Typical Issue:
As the business and user base grows,
customers expect newer user experiences,
and integration requirements increase,
the monolithic approach becomes a
bottleneck to growth. Typical issues with
monolithic applications include huge time
to market, a complex learning curve for
new developers, unusually large
dependencies, and longer deployment
time.

11. Microservice Architecture
Store Front UI
Account Service
Shopping Cart
Service
Delivery
Service
Micro-Gateway
MicroServices
Business Logic Database
API Calls
API Calls
API Calls

12. Benefits of Microservices
Agility Simple
Deployment
Lower
Cost
Flexible
Scaling
Each microservice has an independent lifecycle, which means that each one can be
developed, deployed, scaled and managed independently.

13. H O N G KO N G

14. I want to implement Microservice Architecture.
How can I start it?
The architecture team should consider the following aspects:
• Possible candidates that could represent a microservice.
• How to run the monolithic app in parallel while you develop the
microservices.
• How to tackle the database, which is also monolithic.
• How to tackle reporting in a distributed architecture.

15. I want to implement Microservice Architecture.
How can I start it?
Here are the key aspects:
I. Service Decomposition
II. Tackling a Monolithic Database
III. Reporting across Distributed Microservices

16. I. Service Decomposition
Guidelines for identifying which service goes first:
• The technical debt of the component should be lower to avoid taking those
debts along with the migrated microservices.
• Test coverage of the component should be good so that it would be easy to
test the components after the migration.
• The components should be of high value to the business unit, so the team
can see the benefits of the migration such as high scalability / computing
requirements.
• Components should have clean separation from the database.

17. I. Service Decomposition (Cont.)
Store Front UI
Delivery
Service
Account Service
Shopping Cart
Service
API Calls
Key Points:
• Develop old component from
monolithic as a Microservice.
• Both services will co-exist (with
load balancing).
• Microservice will take over the
older component.

18. II. Tackling a Monolithic Database
Typically, monolithic applications have their own monolithic databases. When
modernize a monolithic application to microservices, we need to split the
monolithic database apart.
1. Analyze the monolithic database mappings, with some tools such as
SchemaCrawler, SchemaSpy and ERBuilder.
2. This mapping helps us understand the coupling between database objects
that spans across potential microservice boundaries.
3. May need to tackle other issues like data synchronizations, transactional
integrity, joins and latency.

19. II. Tackling a Monolithic Database (Cont.)
Product Module Order Module
Products Orders
Database Calls
In this pattern, the function or module
accesses a table that belongs to another
function or module. The joins between a
module’s own table and another table are
used to retrieve the required data. This is
considered to be an anti-pattern in
microservice architecture.
But in a microservices architecture, the
Products table and Order Module become
separate microservices.
Here are two options:
• Option 1: Data as an API
• Option 2: Projection of Data

20. Option 1: Data as an API
Product Module
Products
Order Module
Orders
API Calls
Microservice 1 Microservice 2

21. Option 2: Projection of Data
Product Module
Products
Order Module
Orders
Data Replications
Products
Database Calls
Microservice 1 Microservice 2

22. III. Reporting across Distributed Microservices
An important aspect of all applications is Reporting.
For Monolithic Applications, there are two major approaches:
Approach 1: In-App Reporting
Use their own database for reporting purposes.
Approach 2: Centralized Reporting
ELT (Extract, Transform and Load) tools are used to transform and push
application data to a centralized data warehouse. Then, specialized reporting
tools are used to create and publish reports.

23. III. Reporting across Distributed Microservices (Cont.)
In a distributed Microservice Architecture, reporting across services is a
challenge. Each microservice owns its own database and the database level
relationships across microservice databases are broken. To build reporting
functionalities in such situation, the data from different microservice
databases need to be brought together. There are possible options:
Option 1: Aggregate via Service Calls
Option 2: Data Pump
Option 3: Event-Carried State

24. Option 1: Aggregate via Service Calls
User Shipping
Order
Payment
Reporting
API Calls
Individual microservices expose data
as APIs, which can be consumed by
the report engine. Simple reporting
can be easily implemented by using
this option.
The drawback is that microservices
must have the additional workloads to
build and expose APIs that respond
with large data sets. This induces
performance issues.

25. User Shipping
Order
Payment
Reporting
Option 2: Data Pump
Data
Pump
A data pump is a pattern by which
data that changes in one microservice
is captured and sent to the reporting
database. It is very similar to ETL, but
its scope is much smaller. It can be
built with logic to convert data format
into a reporting data format.
The drawback is that there are more
components to manage with this
option.

26. User Shipping
Order
Payment
Reporting
Event
Bus
Option 3: Event-Carried State
Produces
Subscribes
This option is very suitable for
microservice applications that follow
event-driven architecture. The data
state can be published as events
which many consumers can subscribe
to and one of them can be Reporting.
With techniques like event streaming,
the porting system can build a data
state of entities in an optimized
reporting database. (Near) real-time
reporting is possible with this option.

27. H O N G KO N G

28. Case Study
• Background: A global-branded retail enterprise is undergoing a digital transformation. They leveraged
mobile app technologies to interact with their customers and streamline the transactions like ordering,
payment and delivery.
• Key Challenges: As their retail business is scaling up, especially in Asia Pacific and they are opening more
retail shops in the region, their technologies face challenges of supporting more than million users and
transactions. Though they started using cloud services (in IaaS) for several years. The current architecture
hasn’t been optimized and it’s not good enough to support the future business development. Second, they
like to explore more advanced technologies like AI and ML to further improve the current features which are
not fast enough because of high computing requirements.
• Business Needs: (1) Leverage more cloud services, (2) optimizing the architecture design and (3) explore the
integration of new technologies on cloud, in order to support the future business development.

29. Key Ideas
• Our Vision: To transform from Monolithic Architecture to Microservices
Architecture in a Progressive Way.
• Explain the differences between these two architectures and the benefits.
• Improve the current architecture and propose target architecture.
• Introduce new technologies like cloud-based Machine Learning ML services and
how it can help us meet the high-compute requirements like Waiting Time
Calculation.

30. Technology Roadmap
Version 1.0 Version 3.0
Key Technology:
Key Benefits:
Re-host
(Lift and Shift)
IaaS
• VM Instances
1
• On-Demand Resources
Re-platform
(Lift and Reshape)
IaaS + PaaS
• Managed Database:
Relational Database
Services
• Better API Management:
API Gateway
2
• Agility, High Availability,
Scalability
Re-Architecting
PaaS Mainly
• Microservice Architecture
with serverless technology
• Machine Learning Model
Development
3
• Cost Optimization, Agility,
High Availability,
Scalability
Version 2.0 Version 2.1

31. Modernization Patterns
Discover/Assess/Prioritize
Applications
Determine
Migration Path
Re-host
(IaaS)
1
Automate Use Migration
Tools
Validation Transition Production
Manual Install Manual Config
Manual Deploy
Determine New
Platform
Modify Underlying
Infrastructure
Re-platform
(IaaS + PaaS)
R
e
-
A
r
c
h
i
t
e
c
t
Purchase COTS /
SaaS & Licensing
Manual Install &
Setup
Re-design
Application / Infra
Architecture
Retain / Revisit
Retire /
Decommission
App Code
Development
Full ALM /
SDLC
Integration
2
3

32. Version 1.0: Re-host (Lift and Shift)
Discover/Assess/Prioritize
Applications
Determine
Migration Path
Re-host
(Lift and
Shift)
1
Automate Use Migration
Tools
Validation Transition Production
Manual Install Manual Config
Manual Deploy
V1.0
Migration to Cloud
On-demand Resources

33. Version 1.0
MongoDB
Server
RDS DB
(Master)
RDS DB
(Standby)
Multi-AZ
Internet
Web + Application Tier
Database Tier
RDS SQL Server as the main database, in
Master and Standby design;
MongoDB for storing transaction logs.
Load Balancers
V1.0

34. Version 2.0: Re-platform (Lift and Reshape)
Discover/Assess/Prioritize
Applications
Determine
Migration Path
Re-host
(Lift and
Shift)
1
Automate Use Migration
Tools
Validation Transition Production
Manual Install Manual Config
Manual Deploy
Determine New
Platform
Modify Underlying
Infrastructure
Re-platform
(Lift and Reshape) 2
V2.0
Auto-scaling Mechanism
+
Caching Services
Migration to Cloud
On-demand Resources
V1.0

35. Version 2.0
Public
Users
MongoDB
Server
RDS DB
(Master)
RDS DB
(Standby)
Multi-AZ
Internet
#1: Auto-Scaling Mechanism:
It enables us to scale up and down the cloud
resources horizontally, for meeting the actual
needs.
#2: Leverage Caching Services:
Use caching services (Redis) to handle session
data and offload some workloads from the
database.
Redis
Cluster
#3: Use Managed NoSQL Database Services
V2.0

36. Modernization Patterns
Discover/Assess/Prioritize
Applications
Determine
Migration Path
Re-host
(Lift and
Shift)
1
Automate Use Migration
Tools
Validation Transition Production
Manual Install Manual Config
Manual Deploy
Determine New
Platform
Modify Underlying
Infrastructure
Re-platform
(Lift and Reshape) 2
V2.1
API platform for better
management and
integration
V1.0
Migration to Cloud
On-demand Resources
V2.0
Auto-scaling Mechanism
+
Caching Services

37. Version 2.0
Public
Users
MongoDB
Server
RDS DB
(Master)
RDS DB
(Standby)
Multi-AZ
Internet
Payment GW
Delivery System
CRM
POS
API Calls

38. Version 2.1
Public
Users
MongoDB
Server
RDS DB
(Master)
RDS DB
(Standby)
Multi-AZ
Internet
#3: Building Better API Management:
API Gateway handles all the tasks involved in
accepting and processing up to hundreds of
thousands of concurrent API calls, including traffic
management, authorization and access control,
throttling, monitoring, and API version
management etc.
Payment GW
Delivery System
CRM
POS
APIM
Platform
API Calls

39. Modernization Patterns
Discover/Assess/Prioritize
Applications
Determine
Migration Path
Validation Transition Production
Re-design
Application / Infra
Architecture
App Code
Development
Full ALM /
SDLC
Integration
3
V3.0
Microservices with
Serverless and ML Services
R
e
-
A
r
c
h
i
t
e
c
t

40. Version 3.0: Re-Architecting in a Progressive Way
1
Original Monolithic
Application
1
Original Monolithic
Application
New Module
Dispatcher
1st Stage (As-Is) 2nd Stage 3rd Stage
1
Original Monolithic
Application
New Module
New Module
Dispatcher

41. Version 3.0: Integrating with ML
1
Original Monolithic
Application
Waiting Time
Calculation
Dispatcher
2nd Stage
#2: Using NoSQL Database:
Store historical data and achieve better Read IO
throughput.
#1: Build Waiting Time Calculation Micro-services:
API Endpoints with Serverless (AWS Lambda or Azure
Function) technologies

42. Version 3.0: Integrating with ML (Cont.)
1
Original Monolithic
Application
Waiting Time
Calculation
Dispatcher
2nd Stage
#3: Leveraging the Power of Cloud-based
Machine Learning services:
• Develop some algorithms, e.g. linear
regression for calculating the historical
data and predict the waiting time;
• Leverage SageMaker or ML Studio to
develop and deploy ML models;
• Extract testing data from the NoSQL
database (historical data);
• Invoke the ML model with the Wait Time
Calculation logic.
Machine Learning
ML Models
ML Model
Developments
Machine Learning
Algorithms
Testing
Data
ML Model
Deployment

43. Closing Note
• Microservice architecture promises to solve the shortcomings of monolithic
applications. The migration is a worthwhile journey, but not an easy one!
• This architecture model can help enterprises pick up the pace of digitalization.
• Three key aspects for architecture team need to consider: Service Decomposition,
Tackling Monolithic Databases and Reporting.
• This session suggests several options and the rationale to tackle these aspects.

44. Thank you!
H O N G KO N G
John Yeung
arhitectyeung@gmail.com