What are the benefits of splitting a big monolithic application into 2 applications?

Question

We currently have a big monolithic J2EE application (weblogic / DB2). It is a typical OLTP application. We are considering to split this application into 2 applications where each application has its own database which is not directly accessible by the other application. This also means that each application need to expose an interface for the functionality that is needed by the other application.

So what are potentially the major benefits of splitting such an existing application into 2 applications ?

Answer 1

Most of applications using 10% of code during 90% of the time.

The core idea of the micro-services which is modern SOA. You are able to elastically scale the critical part of your application in the micro-service specific special cloud. Cloud is an elastic cluster, where each node is a virtual server (XEN or VMware etc.). Cloud can extend or shrink nodes count automatically according to the load factor, without manual attention.

With the classic monolithic applications, you need to scale a whole monolithic application. Usually such application use a large amount of RAM, as well as require strong hardware or strong and expensive virtual server. Another disadvantage of monolithic - if you need to release a new business feature, release cycle will be really long, since you've done a modification to the huge and complicated code-base with a code entropy. It will require time/budget expensive regression testing. But you have a benefit - different application parts (subsystems and modules) can be integrated much easier comparative to the SOA approach, off cause if you have good application design.

On another side - you can split your application logic to the set of small applications, such application called a micro-service. For instance you have one micro-service responsible for UI only - ie only Spring MVC with Angluar.js, another micro-service for business logic and persistence, and one more micro-service for obtaining data from social networks. All those services are interconnected with each other using some web-services usually RestFull, but can be SOAP or something like Google Protocol Buffers RPC etc. So now you are able to auto-scale only UI micro-service, which is expected to be performance critical, without touching business logic and social network micro-services. And you are able to update UI micro-service even once a weak, since UI only testing is not so expensive like business logic testing. But there is a disadvantage - cluster structure became more complicated, and require stronger team to maintain it (usually automate with some Chef or Docker based scripts). It is also hardly to implement subsystem integrations and you need to think about your system design more carefully.

So, if you have a huge and complicated system which is hi-loaded (like Amazon.com, Ebay, Facebook or stackoverflow). SOA approach gives you an opportunity to save some money on infrastructure and hardware. But it will be more expensive in development. And if you system is very simple, ie internet cafe site with a few pages - monolithic approach is preferred.

Answer 2

If scalability isn't your concern, then I'd be pointing at the following benefits:

• Increased change velocity - shorter time for a feature to get from the idea phase to production (lower complexity for developers)
• Lower cost of testing (smaller scope to test)
• Improved quality (again, smaller scope to test)

Answer 3

We can't weigh advantages and disadvantages without looking what that application is all about, what are business rules, how you are dividing application and how two applications share business rules. Dividing an application into two application is not just diving java classes into two groups. It require depth analysis from different perspective. Hope this helps.