Microservices have received some harsh headlines in recent years. Once billed as a one-stop solution for scalability after being adopted by Netflix, Amazon, and eBay, microservices embody the anything-could-happen, grow-as-you-go spirit of the digital 2010s, where even small startups and independent websites could become the next big thing. Microservices offer some of the same promises as the gig economy — the ability to reduce overhead and only pay for what you need when you need it.

Anyone who’s ever had to assemble a large team and get them up to speed in a hurry after experiencing an unexpected surge in business can tell you this often isn’t the case. Having to pay for massive spikes in traffic and demand can quickly become very expensive. It’s often cheaper to keep a well-structured team of well-trained and capable employees around, which is a decent metaphor for the “microservices vs. monolith” debate. It would be like hiring a bunch of temp workers every time you get busy rather than simply ensuring your existing team and structure are well-trained and set up properly.

There has been a fair deal of controversy regarding microservices in recent years. It seems every other week brings a new ‘Are Microservices Dead?’ article. While microservices might not be as trendy as they once were, reports of microservices’ demise are also wildly overstated. According to Statista, 85% of businesses with 5,000 or more employees were using microservices in 2021. 14% more had plans to adopt microservices in the future. Why is there such a discrepancy between these figures and the headlines?

To get to the bottom of the matter, we’re delving deep into the state of microservices in 2025.

Microservices: Not a Silver Bullet, But Far From Dead

Searching microservices trend is like reading a newspaper’s Front Page and obituary at the same time, full of 32-point headlines and mournful declarations like Why Microservices Aren’t Popular Anymore or the even more to the point and inflammatory question on Quora: are microservices dead? When you read through the articles and comments, it quickly becomes clear that the headlines are just as sensationalist as when microservices first started to trend.

We’ll start this discussion of the state of microservices in 2025 by stating outright that microservices aren’t dead. They’re also not the silver bullet that tech evangelists once made them out to be. The reality falls somewhere in the middle. Microservices are not right for every application, but they’re still highly useful in many different scenarios. As with most things dealing with tech, the answer lies in smart business decisions and clever adoption of the right architecture style for your product.

When Microservices Work

The majority of large organizations report using microservices in some capacity. Still, the gaps suggest that some businesses still use monolithic architecture alongside microservices. So, let’s first review the situations in which microservices tend to be worth it.

Microservices Work Best With Mature Products

According to author and analyst Martin Fowler, nearly all successful microservices started out as a monolith. He warns that nearly every system that starts as a microservice system quickly runs into problems. Fowler observes that the first few iterations of a product are mostly about determining what users actually need, so prioritizing agility, responsiveness, and the ability to redesign and refactor a product quickly. Unfortunately, this is much harder to implement with microservices than the monolith.

In light of this advice, it’s recommended that you start a product as a monolith and break it up into microservices later if you need to separate concerns. Transforming a feature into a microservice allows developers to use the same function across all of their apps and throughout the entire organization. Should you decide to go that route, some organizations recommend incrementally refactoring a monolithic application, where you replicate the existing monolithic software with one that uses microservices with the goal of gradually phasing out the monolith.

This approach is also sometimes referred to as the Strangler Fig pattern. This is a strategy that SoundCloud employed to migrate its monolithic public API into a microservices architecture.

Microservices Are Best For Complex Environments

Microservices first caught on when companies like Amazon, Uber, and Netflix adopted them in the mid-2000s to enhance speed and handle unexpected service demands. This flexibility helped all three go on to dominate their respective industries. Uber was able to reduce integration time from three days to three hours. They were also able to consolidate 2,200 microservices into 70 domains.

These examples illustrate the kind of products and services that best make use of microservices. Companies anticipating very complex business strategies or code implementation may do well to at least consider using microservices to deal with their demands. Should you decide to go that route, you may be better off designing your product as a monolith and breaking it down into microservices later on, as per our previous best practice.

Microservices Work Best For Distributed Teams

Distributed teams have their own needs. Adopting a microservice-based architecture makes sense for decentralized teams, as it allows teams to work on specific modules, projects, or products without disrupting the entire organization. They also make sense as they allow the entire team to use the same tools and resources regardless of their location. They can also help foster a greater sense of identity and belonging, which can be challenging to establish when a team is working entirely remotely, as they help each team better understand the big picture of your entire enterprise and how each individual piece fits into the greater whole.

When Microservices Might Not Work

In certain cases, microservices might not be the best fit for the situation at hand. Let’s explore a handful of these conditions.

Microservices Might Not Be The Best For On-Premise Solutions

Microservices require extensive automation to work properly. Some developers using microservices advocate for a “Culture of Automation” as an aspect of the DevOps philosophy, which encourages efficiency, reliability, and consistency. This means automating everything from code integration and deployment to installation and configuration.

Under most circumstances, developers can use continuous deployment pipelines to realize this goal. Developers publish the microservices, and users can use the product online. This approach is less practical for on-premises solutions, where users must set up and install an asset on their own server.

If you’re developing on-premises products or services, you might want to consider another architectural style. That said, some developers are creating native tools for on-premise microservices. Semaphore developed their own on-premise microservices solution, for example, called Semaphore On-Premise, which places an organization’s entire CI/CD pipeline behind the company’s firewall.

Yet, this still comes with some inherent challenges. Versioning is more difficult with microservices, for one thing, and more challenging for on-premises products or solutions. If you’re creating an on-premises solution, your best bet is extensive testing before releasing the product, as it won’t be able to be tested when it’s in production.

Monoliths Can Be Modular

Monolithic architecture tends to become large and unwieldy, which is one of the main reasons for microservices’ surge in popularity in the first place. This doesn’t necessarily have to be the case, though. Monolithic architecture can be broken up into modules and services, an approach that has come to be known as hybrid architecture, as well. When implemented properly, it can even have many of the same benefits, like the ability to work on individual components without disrupting the entire program. They just usually rely on internal APIs instead of microservices. Monoliths can even scale, just like microservices. You just have to deploy multiple instances of the monolith and then use load limiting to distribute the traffic.

Microservices Can Be EXPENSIVE

Let’s conclude with the most obvious — and most serious — reason for microservices falling out of favor. Microservices can be prohibitively expensive, even for large organizations. One developer on StackOverflow estimates how even a small microservices project ends up costing $500 a month once you factor in all of the components and each interaction. Microservices often require additional sidecars, service meshes, and additional tools for management and upkeep, for one thing. Microservices rely on data transfer to function, as well, which can drive up data transfer costs.

Using microservices can even drive up labor costs, as there’s no guarantee that each microservice uses the same stack. One might be written using Python, for example, while another might be created with Ruby on Rails. Moving a developer from the Python team to the Ruby on Rails team could require retraining the developer in the new stack.

Switching from microservices to monolithic architecture allowed Amazon to reduce their operating expenses by a staggering 90%, as reported in their ground-shaking article Scaling Up The Prime Audio/Video Monitoring Service and Reducing Costs by 90% from 2023. If one of the world’s biggest microservice providers thinks twice before using them, other organizations should be considering the same thing.

In accepted business wisdom, it’s generally not a good idea to incur high recurring debts, especially when income is uncertain. High overhead with an uneven income flow can be a recipe for disaster. And if microservices don’t always meet performance expectations, it defeats the purpose of using them to solve bottlenecks and increase scalability.

The State of Microservices in 2025

As we have seen, microservices are still a viable architectural style, even if they’re not generating as many buzzy headlines as they once were. Microservices can be great when implemented properly but are usually not the right choice for new products and startups. Furthermore, businesses with complex business models or codebases may do well to consider microservices instead of a monolith. Distributed and decentralized teams might also consider adopting a microservice-based architecture, as it allows each team to work independently without disrupting the whole organization while simultaneously improving their ability to conceptualize how each piece contributes to the whole. These may be a few of the reasons why 85% of very large organizations are adopting microservices, and even more are planning to do the same.

While microservices can be great, living up to their reputation for scalability and flexibility, they’re not the right solution for many applications. You can achieve many of the same results by designing and organizing your monolithic projects properly. Microservices can have their place, but make sure you spend plenty of time thinking about, planning, and designing your project if you’re considering them. There may be another more cost-effective way to get the same result.