Architecture Vision
SAP Industry Cloud Solution
SAP Excise Tax Management
Monolith to Micro services
Objective – This document intends to share technical vision of driving the architecture of Excise Tax Management solution to micro service path. It intends to share how we are approaching the task of converting our monolith to microservices in a pragmatic and reasonable & feasible approach. The Document provides high level view on possible iterative variants where every variant represents the progress on top of previous version with respect to micro service behavior.
Objective is also to collect suggestions and point of views of the experts who took time to read this paper and may have gone through similar journey.
Disclaimer –This is the technical architectural vision and needs to be proved based on business requirements, costs and benefits. This document does not promise compliance to the mentioned factors.
We started with a quick research on what are the general guidance and statements from reliable source
Martin Fowler statements - I am sharing following statements from Martin Fowler to start.
1.Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2.Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble
Reference - https://martinfowler.com/bliki/MonolithFirst.html
From this perspective, The Excise Tax architecture has started well with a monolith and it is time to consider starting journey towards micro service-based architecture slowly keeping a good balance with continuous delivery of functional features to customers.
Micro Service Tradeoffs –
Microservices provide benefits…
- Strong Module Boundaries: Microservices reinforce modular structure, which is particularly important for larger teams.
- Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong.
- Technology Diversity: With microservices you can mix multiple languages, development frameworks and data-storage technologies.
…but come with costs
- Distribution: Distributed systems are harder to program, since remote calls are slow and are always at risk of failure.
- Eventual Consistency: Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency.
- Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly.
Reference - https://martinfowler.com/articles/microservice-trade-offs.html
SAP Excise Tax Management Product -
SAP Excise Tax Management is a carve out solution running on SAP Cloud Platform Cloud Foundry.
It serves the customers who handle Excise Tax relevant products and need to manage Excise Tax related business and legal requirements.
It is one of the first Cloud Native Carve out solution integrated with SAP Digital Core (S4HANA).
Main challenges to focus on-
- It is difficult to divide the database artefacts among micro services so micro services have their own independent database
- Sometimes same reused service instance to be used by many micro services
- Most of the times micro services are expected to use independent service instances. This increases the cost to the solution
- Multitenant solution onboarding and subscribing mechanisms with SaaS Registry requires different handling.
- Direct database call vs Http call to micro service may bring performance challenge
Journey Milestone by Milestone – The people who have experienced this journey, recommend starting and progressing on this journey in iterations. This document follows the same philosophy and presents milestone variants of the architecture.
Excise Tax Functional Building Blocks - Following are the identified probable functions which can be base for dividing the current monolith to micro service. Colour codes are used to depict footprint of individual functions on different variants.
Please note that this is a representative list of the modules and can be enhanced as and when required.
Building Blocks have dependencies to reused service -
EMCS functions- RabbitMQ, Audit Log, HANA service
Stock Ledger Functions- RabbitMQ, Audit Log, HANA service
Master Data Functions- Audit Log, HANA service
Job Scheduling Function- Job Scheduler, HANA service
Subscription to the solution - In all variants mentioned in this document subscriptions are handled via one app router app. The App router app is responsible to collect dependencies from all java applications and giving it to SAAS Registry during call-backs triggered during subscription.
Let’s Start with Milestone Variants –
We start with current Monolith of Excise Tax Management Solution, which runs on 1 java service app and 1 database
Fig. Milestone 0- Monolith
Next milestone is to take out EMCS (Excise Movement Control System) application as a separate java application which still uses the common database. EMCS app uses app to app communication to interact with main java app
*same color for reuse services represents same service instance
Fig. Milestone 1-Variant A
Next milestone is to take out EMCS related database artefacts in a separate database container, which makes EMCS piece as true micro service.
*same colour for reuse services represents same service instance
Fig. Milestone 2-B
Next milestone is to introduce a new service broker for the EMCS related service inside EMCS micro service. This service broker will be visible as s separate service in marketplace
*same color for reuse services represents same service instance
Fig. Milestone 3-Variant C
Next milestone is to take out Job management related functionality and its database artefacts as a separate micro service. We can do this in one bigger milestone considering the critically of the Job Management functionality is relatively low and very minimal data is persisted in Excise Tax Management database about jobs.
*same color for reuse services represents same service instance
Fig. Milestone 4-Variant D
Next milestone is to take out Master Data Management and Synchronization related functionality as a separate java app. We still use the common data base for Master Data related persistence. This will reduce the risk of losing any data by mistake especially considering that solution is already live
*same color for reuse services represents same service instance
Fig. Milestone 5-Variant E
Next milestone is introducing Master Data Management service broker inside the Master Data Management App. This is a smaller milestone to bring all Master data related OData and rest services under a specific service broker
*same color for reuse services represents same service instance
Fig. Milestone 6-Variant F
Next milestone is to take out Master Data Management related database artefacts in a separate database container, which makes this piece as true micro service.
*same color for reuse services represents same service instance
Fig. Milestone 7-Variant G
Conclusion – The above-mentioned architecture vision helps to lay a realistic roadmap for the product to become more flexible and modular to take good advantage of the micro service Architecture and help Product Managers to plan for this adaption in iterative and feasible way.
Disclaimer – “This is purely a technical article and does not share any official view for the mentioned product”
- SAP Managed Tags:
1 Comment
