I am slightly hesitant to write this post, as it might attract some criticism. Nevertheless, I told myself there is nothing wrong with sharing my point of view (even though it might not be well accepted). I would like to share my personal experience regarding yesterday’s Monolithic and today’s Microservice architecture in this post.
Yesterday’s Monolithic application
20 years back, I was starting my career. At that point, I was working for a large financial corporation in N. America. This financial institution’s middleware platform was running in CORBA, C++ platform. Since CORBA was getting extinct around that time, the technology vendor decided not to support CORBA anymore. It was a huge risk for the enterprise to run its mission-critical middleware platform on unsupported technology. Thus, management decided to port their middleware application to platform-independent technology stack: ‘SOAP’ and ‘Java’, which was considered as the cool kid of the time. There were around 500+ services that were running on this C++, CORBA stack. They ported all those services into SOAP/Java technology. It was one of the biggest portings done in the industry of the time. Since then, any new services they developed to meet the growing business demand were also written on this new platform. So, what’s the relationship between this technology migration and this post? Have I gone too far? Not really…
Astonishingly, all those 500+ services were built from one single code base and deployed on one single JVM instance – perfectly meeting today’s definition of ‘Monolithic’ architecture. But interestingly, all those 500+ services were running on a JVM instance, which had only 2 GB memory size (-Xmx). When I tell this memory size to a few millennial engineers now, they aren’t able to believe it. They are asking “Are you sure? Have you grown too old? Is memory faded?” I am 100% sure, my memory hasn’t faded :-). However they had several 2 GB JVM instances to service the incoming traffic. Several of these services are business-critical and sensitive transactions like ‘List Transaction History’, ‘Funds Transfer’, ‘Get Account Details’, ‘Get Customer Details’…. This middleware platform was beautifully processing several millions of transactions/day that too with tight milliseconds level SLAs.
Today’s Microservice
Now let’s fast forward 20 years. We are now in the 2021 Microservices, containers, kubernetes world. In my personnel career, after an unbelievable amount of struggle and pain, I progressed to build a *small*, profitable technology business. Our company specializes in building performance engineering tools (GCeasy, HeapHero, fastThread, yCrash). Humbled to see the world’s premier enterprises use our toolsets. Because of this current role, I get the opportunity to see the architecture and deployments of large corporations, who use our products. I could see several enterprises are either talking about switching to ‘Microservices’ architecture or already in the process of switching to ‘Microservices’ architecture. We could also see a few enterprises already switched to Microservices architecture. But one sharp observation here is: several of these microservices applications’ memory sizes are pretty large. They are in the range of 10 GB, 20 GB, … 100 GB. It’s getting harder to see modern enterprise applications that run under 2 GB heap. Besides that, response times are also getting degraded, due to several network hops between Microservices and garbage collection.
Does that mean modern applications are consuming more memory than its predecessors? Here is a study we published earlier highlighting the inefficiencies of one of the world’s well celebrated modern frameworks.
So, I am asking myself: Do modern/Microservice applications consume more resources than yesterday’s monolithic applications? Is the road as the industry we are heading is in the right direction?
Conclusion
Please don’t interpret that I am lobbying against Microservice architecture. I very well see the benefits of Microservice architecture: rapid development, decoupled deployments, reduced test cycles, polyglot programming… Here I am only expressing concerns about growing memory size, response time and its associated computing cost, complexity. You are welcome to share your experiences/thoughts!
Published on Java Code Geeks with permission by Ram Lakshmanan, partner at our JCG program. See the original article here: Is today’s microservice bloated than yesterday’s monolithic? Opinions expressed by Java Code Geeks contributors are their own. |
you are simply right. Microservices solves some very ugly problem, but the undesirable effects are severe. Wouldn’t it be a good idea to have the problems, that Microservices fix? But it is fashion. Like many other hype technologies in the last decades the prerequisites are forgotten sooner or later. Sometimes in an weired amount (remember SOAP-calls were you had difficulties to find the payload?). I had a similar experience 2 years ago were a much younger engineer came up with an solution of 5 app servers and 10 network hops and a total of about 8 GB RAM were one… Read more »