Remember how, in the mid-2010s, companies rushed to migrate their monolithic applications to microservices en masse? That shift marked the beginning of the DevOps era, as this architectural style demanded specialized orchestration tools and a new approach to software delivery.
Why did this boom actually happen? All because such loud names as Netflix, Spotify, and Amazon, having risked re-architecting their systems, publicly shared the impressive results of the endeavor. Therefore, many companies followed the example, hoping to repeat the success and believing that this move would help them improve application performance a hundredfold.
However, time has shown that in the majority of cases, migration was an unnecessary and, what is more, economically destructive decision. Why designing a microservices solution is “not for everybody”, in which scenarios it’s a panacea, and in which it’s better not even to think about re-architecting — read in our new blog post.
When It’s Time to Split the Monolith. The Real-Life Example of Our Client
Let’s start with reviewing the example of our client, a financial service provider who is now in process of their microservices migration endeavor. Their project is a vivid illustration of the case when there is no other way than to opt for re-architecting.
Having started their business more than a decade ago, they have adopted a CRM system that had been used until the present day. Sure thing, throughout all these years, the platform hadn’t been left “as is” — it had been expanded, and new modules had been added. All these improvements severely affected the application performance, and the client started seeking a solution.
Explore How We Conducted Microservices Migration for a Financial Service Provider
In theory, they could have simply upgraded to more powerful hardware to avoid the complexity of a migration. However, there’s an important caveat to consider.
Upgrading hardware doesn’t guarantee that the performance of the specific services in need of optimization will actually improve. That’s because computing resources — CPU and memory — are often distributed in unpredictable ways within a monolithic architecture.
Our client needed to boost the performance of a few critical services, while was fine with leaving less important ones unchanged. A hardware upgrade might have only partially addressed the issue, with no certainty that the right components would benefit. That’s why this kind of solution had to be abandoned.
It’s an entirely different scenario when we talk about microservices. In this architecture, each service is isolated, making it easy to define clear performance metrics and run targeted, effective tests. In contrast, trying to achieve the same within a monolithic system is far more challenging — because alongside your specific component, the processor is also handling numerous unrelated operations.
This makes tracking processor load an uphill battle, as it becomes nearly impossible to accurately measure the efficiency of a specific piece of functionality.
On the contrary, when that functionality is isolated within a dedicated microservice, you can conduct clean, focused testing and reliably monitor fluctuations in CPU usage. This enables more strategic resource planning and helps improve system performance with reduced effort and cost.
Another risk of simply upgrading hardware is eventually hitting a performance ceiling — where no available equipment can meet the system’s growing capacity demands. Acknowledging this limitation and recognizing the impracticality of repeatedly migrating to ever more powerful hardware, the client concluded that transitioning to a microservice-based architecture was the most reasonable and cost-effective strategy for scaling the application.
Find out everything about the Difference Between Microservices vs. Web Services
Easy Infrastructure Management — the Good and the Bad at the Same Time
The main pro of a monolithic architecture worth mentioning is the ease of its management. Put simply, you deploy it as a single application, and if there appears a necessity to proceed with alterations, it’s possible to do it in one fell swoop.
For instance, you want to upgrade your database or a backend framework version. You can easily make all necessary updates with one endeavor (depending on upgrades and code specifics, of course).
With a microservices-based architecture, however, this trick will not work. Each service operates independently, meaning alterations must be made individually across multiple components — often requiring careful coordination and more complex deployment strategies.
However, there is good about it. Imagine we’ve modified the database structure by adding or removing a column, for example. In a monolith, the same database table is often used across various parts of the application.
As a result, you’ll need to review every component that relies on that table to ensure the changes haven’t broken anything. The real challenge is scale: the number of dependent components can be overwhelming, and missing even one can lead to bugs that require additional time and effort to fix.
In contrast, with a microservices architecture, this process is significantly simpler and less time-consuming. Since the application is split into isolated, self-contained services, you only need to update the microservice that directly depends on the modified database schema. Other services remain untouched, reducing the risk of unintended side effects and streamlining maintenance.
Swinging Only Between Microservices and Monolith? There’s One More Option to Consider
In our client’s case, it quickly became clear that decoupling the monolith was the most efficient path forward. However, this doesn’t mean that such a solution is universally applicable or the best fit for every application.
Their CRM system was a heavy, high-load platform with deeply intertwined dependencies that had evolved over more than a decade. But does that mean every project should adopt a microservices architecture from the outset, just to avoid future re-architecture efforts? The answer is disappointing yet predictable: it depends.
If your application isn’t expected to undergo rapid development or significant functional scaling, adopting microservices too early may amount to premature optimization, and it’s more reasonable to opt for a monolith. In such cases, the complexity and associated costs of building and maintenance may outweigh the benefits of microservices architecture.
Modular Monolith as a Compromise Solution
Yes, both monolithic and microservices architectures come with their own sets of complexities and trade-offs. But what if you’re cautiously optimistic about your application’s growth — you know that a traditional monolith won’t scale in the long run, yet adopting a full microservices architecture feels overly complex and costly at this stage? In such cases, there’s a middle-ground solution worth considering: the modular monolith.
This means building your application as a set of logically separated modules that are conditionally independent of each other. Like a traditional monolith, it can still be deployed as a single unit, with a centralized configuration and a shared database. However, each module maintains its own domain logic and interacts with its own set of database tables, minimizing interdependencies.
This structure allows teams to work on individual modules with fewer risks of breaking unrelated functionality. More importantly, it lays the groundwork for a future transition to microservices — should the need arise — since many of the architectural boundaries are already in place.
Rewrite, not Migrate. When Migration Seems to Be an Uphill Battle
Sure, every situation is unique — but if you choose a monolithic architecture early on, it’s crucial to avoid letting your application grow to a point where migration becomes nearly impossible.
That’s exactly what happened with one of our clients. Their CRM system had scaled so much over time that some services became too tightly intertwined to isolate.
Take their transaction service, for example. All payment logic was deeply embedded in the database, entangled with countless dependencies and a mountain of legacy code. In this case, a standard migration approach simply wasn’t feasible.
So, what was the solution? For this service, they skipped the idea of migrating the service with others — and opted to rewrite it from scratch. Sure thing, it’s not an easy and cheap task to tackle, but it’s still the lesser of two evils.
However, it’s better not to perceive functionality rewriting as a silver bullet. Things might be quite complex and intricate, and there’s a serious reason for that.
If you’ve been using your application for decades, the probability that the same engineers have been working on the system and developing it in breadth and upwards is extremely low. Most likely, your project witnessed not one change in engineering generation, which means that knowledge of the application’s business logic had been partially lost.
The absence of knowledge of app nuances might significantly hinder the rewriting process, turning it into a real adventure where you can easily stumble. And some pieces might be impossible to rewrite due to the high risk of doing something wrong.
From here stems another challenge you’ll most probably have to make up with. This is forced maintenance of a monolithic application besides the new platform you conduct migration to. Yes, it’s expensive and effort-consuming, but there’s no other option to follow if you have a large-scale lucrative business closely tied to software functioning and performance.
Of course, the best solution is not to bring your system to such a deplorable state and start thinking over the optimization beforehand, when you see the first signs of maintenance issues. Acting thoughtfully, you’ll cushion the blow at least a little bit and won’t have to spend a fortune on migration endeavors.
Monetary Side of the Issue. Why Microservices Is an Expensive Adventure
When businesses, inspired by the success stories of Netflix and other tech giants, jumped on the microservices bandwagon, many overlooked a critical factor: the complexities of ongoing maintenance.
What often gets missed is that the microservice infrastructure is a completely different beast compared to monolithic systems. This applies to everything — from technical architecture to the long-term costs of support.
With a monolith, you’re typically dealing with a single application instance and one database, relatively straightforward to maintain.
But with microservices, every new service adds to your resource consumption, especially in the cloud environment. And that’s just the beginning. You’ll also need robust orchestration, monitoring, and management to keep it all running smoothly.
Read about Cloud Cost Optimization and Best Practices to Cut Your Spending
This is precisely why the role of DevOps engineers has become indispensable in organizations adopting microservices architectures. Unlike monolithic architecture, microservices demand a high degree of automation, scalability, and resilience. Managing such a complex, distributed system requires specialized skills and tools, far beyond the scope of traditional system administration.
Microservices Migration Speed and Factors It Depends On
If you have firmly decided that the time has come and microservices migration is inevitable, it’s better to know the main factors that might affect the speed of transition. Most frequently, the main stumbling stone is the system age, which entails the following issues:
Data Irrelevance
As systems age, so does the data they contain — and often, the methods of data entry become outdated as well. A simple example is date formatting. In the past, certain databases like MySQL allowed storing dates in formats such as YY/MM/DD. Today, this practice is no longer supported or recommended, leading to compatibility issues during migration.
These discrepancies might seem minor at first glance but can cause significant headaches when attempting to move legacy data into a modern microservice software architecture. Each inconsistency requires careful handling, data transformation, and validation to ensure smooth integration into the new system, which requires extra time.
Obsolete Technologies
Technologies also age, which becomes a serious obstacle when it comes to migration. In the project we discussed earlier, the client’s system was built with PHP5 — a technology that is now considered obsolete and no longer maintained.
The real challenge here lies in the fact that outdated source code often becomes untouchable. Without proper support or updates, even basic modifications can be impossible. In some cases, it goes beyond simple refactoring — you might not even have access to critical parts of the codebase anymore.
When direct alterations are off the table, reverse engineering becomes the only viable solution. This involves carefully analyzing how the legacy system works, reconstructing its logic, and rebuilding necessary components from scratch using modern technologies. As you may have guessed, the approach takes extra time and resources, which also affects the migration speed and overall costs.
Explore Digital Transformation Challenges to Overcome
Wrapping Up
If you’re just beginning your tech journey, it’s essential to avoid rushed decisions. Microservices are a powerful solution — but they’re best suited for large-scale, high-load systems that have outgrown the capabilities of monolithic architecture.
However, if you don’t have immediate plans for rapid scaling or your growth roadmap is still uncertain, alternatives like a modular monolith might be a smarter choice. This approach offers a balanced middle ground, sparing you from unnecessary complexity and costs that can arise from premature microservices adoption.
Making the right architectural choice early on can save you from major headaches down the road.
If you’re looking for expert guidance on software architecture or need a partner experienced in the intricacies of microservices, we are here to help. Reach out to us — we’ll be happy to support your journey!
Get the conversation started!
About the author
