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.
Comments
Post a Comment