Skip to main content

So whats wrong with Classic Applications a.k.a Monoliths?

A real life story

In my previous post introducing microservices, I wrote about this insurance product I was working on at the beginning of my IT career. It started off very simple as a layered application. Well it was not simple, the learning curve with J2EE of that time was indeed high. Just like microservices, it was all shiny new thing. The application started with just a couple of us. Then we started adding features. The product was sold. I was happy, I went to install and implement it at customer sites. It was fun.

Then customers demanded more and more features. New features were also required to address new business challenges and compete with established players. So we kept adding more bricks and mortar on that same structure. 2+ years flew by and I realized that we have about 20 odd modules, 500+ tables, and nearly a team of 100+. We had several customers in the US and elsewhere using this product. It was really a big success in such a short span of time.

But I also realized that I don't fully understand the system anymore. I had no clue about for example what the product module was doing, neither I understood the re-insurance module. Also, I could observe that new team members struggled to get on board. If learning EJB was not overwhelming enough, the size of the code base scared them. Changes were now difficult and time-consuming affair. For example making a change in the product module, you also needed to ensure nothing break in other modules.This meant several long meetings. Even if we ensure everything was all right and put several features together for next release, something or the other would break. This would lead to slow deployment and longer deployment times. I have already described the challenges in scaling this application in my previous post.  

In short, as the application created based on classic architecture makes it extremely difficult to maintain, change and operate as it grows big over a period of time.

I have many such stories and experiences of large classical applications becoming obese and fatigued over time.

A short summary of issues with large classic applications.

Figure 1 - Monolith Challenge Balls

Comprehension paralysis

It is extremely difficult to comprehend each and every aspect of a large application codebase. This is true even if you are working on it from Day 0 on that application. As the application grows bigger and bigger it becomes next to impossible for one developer/designer to know everything.  

High Ramp up time

This is a fall out of the comprehension paralysis. New developers would take months instead of a couple of days/weeks to come out to speed. Even if they did come up to speed, they would never feel assured, barring a few exceptions though.

Design Decay

New developers joining the team find it extremely difficult to understand the design, they resort to quick and dirty changes. The result is degradation in the overall design and code quality. I have seen developers found it so difficult that they at times wrote JDBC code in JSP (Amazing stuff !!!!)

Tight coupling
Since all the modules are seating together in one code base they are very tightly coupled. Some or the other concern would sneak in across module boundaries.

Snail paced changes

Due to the tight coupling, the team would spend hours in figuring out how to ensure that a change in one module is not going to break another. This can be a sign of collaboration, but a big impediment to progress. Team members, designers, and architects would then argue for hours and days to conclude on the best way forward to implement a change.

Continuous "SLOW" delivery 

CI/CD did not exist in 2001. Assume it did for a minute. Even in that case, the slow changes and gigantic code base would make it extremely difficult. The development was slow (Visual Age, Bea IDEs ran slowly with the large code base and it was the time of costly memory, we had only 512MB/1GB on developer workstations), there were several tests so it was not possible to get quick feedback. This also meant loss of developer productivity.

Long downtime

Since changes were difficult several features would be clubbed in a release, instead of short focused release. As a result lot of testing was required before and after pushing to production to ensure everything worked fine. Also, you had to follow a long manual to deploy and cannot afford to miss a line. This meant long downtime maintenance windows. This would not make the customers/end users happy. This was done after working long hours late in the night as this system was mainly accessed during day time and batch processes ran after 6 pm. Since the whole code base was being redeployed, with so many EJB components, the application itself took a long time to come up. I remember people going for coffee and cigarette break after restarting the server 😁

Scaling challenges

It is an absolute nightmare to do capacity planning for such large systems.As I explained before, even if you know which parts to scale more than the others, but due to the tight coupling, you cannot do anything about it i.e scale selectively with optimal hardware.
The product

Technology lockdown

In such tightly coupled or "monoliths" you could be forever locked with some specific technology and server and some vendors. Over a period of time, new and better technologies, languages come up. Even if you know they are better, even if you know you can or should make the switch two things will prevent you from doing so. First is the inertia especially from management and development group both. It's working and running let it run. Second is the cost of such a switch can be very very expensive and there is no sponsor for that.

Non-technical challenges

Some people would know the system and code better than others. They would take management by the gun point when it came to appraisal, raise and bonus. I am not joking it's true.


Popular posts from this blog

Why do you need Spring Cloud Config server?

Last month I wrote a primer on concepts around 12 factor app. Before getting into the details of the Spring Cloud Config Server, I must refresh on the principle #3 from the list presented in that post.

3 – ConfigurationStore config in the environments
Configuration information must be separate from the source code. This may seem so obvious, but often we are guilty of leaving critical configuration parameters in the scattered in the code. Instead, applications should have environment specific configuration files. The sensitive information like database password or API key should be stored in these environment configuration files in encrypted format.
 The key takeaways from this postulate for a cloud-native microservices application are:
Do not store configuration as part of the deployable unit (in the case of lead microservice - inside the jar or war if you are still deploying war like the good old days). Instead, store it in an external location and make it easily accessible during run-…

Upgrading Lead Microservice - Use MariaDB and Flyway with Spring Boot

So far I have been using an in-memory H2 database or Mockito for testing the lead microservice. To make the transition towards using the Spring Cloud Config server, I need to upgrade the micro-application to use MariaDB. I will be adding the configuration in the application.yml  the file which in the subsequent post will move over to the config server store. I will also be using Flyway to make it easy to maintain the database schema changes in future. I will use this post to introduce Flyway in the mix. Spring Boot also provides first class integration with Flyway. I am using Flyway as its really quick and easy to get started, minimal learning curve (no DSL) and I am comfortable with it having used it in the past.


MariaDB 10 is installedBasic familiarity with FlywayHeidi SQL client is installed.
Step 1 - Update build.gradle to include the MariaDB JDBC and Flyway dependencies.
Do not forget to do a Gradle refresh on your IDE (I am using STS 3.8.4 on Java 8)

Step 2 - Rename the…

How to implement Cache Aside Pattern with Spring?

ProblemYou want to boost application performance by loading data from a cache and prevent the network trip to the persistent store (and also the query execution). This can be achieved by loading data from a cache. However, you want to load data on demand or lazily. Also, you want the application to control the cache data management – loading, eviction, and retrieval. Forces Improve performance by loading data from cache lazily.Application code controls cache data management.The underlying caching system does not provide read-through, write-through/write-behind strategies (strange really ??).
Solution Use cache aside design pattern to solve the problems outlined above. This is also one of many caching patterns/strategies. I believe it is named in this because aside from managing the data store, application code is responsible for managing the cache also.
Let's now try to understand how this caching technique works and then explore how it solves the problems.
ReadCache MissThe applic…