Microservices have become somewhat of a panacea for all software development woes. Too often, the answer to a technical problem is “just make a microservice!” The reality is, however, that microservices development is not always the only, or even best, answer to a given problem.

Below, we’ll look at microservices and determine when the microservices architecture paradigm is worth it. We’ll consider monoliths and their relation to microservices and explore when it is more appropriate to apply one development style over the other.

Monolith vs. Microservice

Before answering this core question, we should refresh ourselves on the differences between monolithic development and microservice architecture.

Firstly, let’s look at the monolith. The idea of the monolith has been ubiquitous for quite some time. Put simply, a monolith is where everything is packaged together in a non-distributed solution akin to a giant monolithic tower. Imagine you are creating a service that has to do a hundred things. In the monolith, all those things, the resources they touch, the wrappers they use to communicate with other systems, and more, would all live in a single entity.

The problem with the monolith is that change comes with a hefty cost. You can’t simply remove a piece of the mighty Jenga-like monolith distribution. It all is dependent on itself, making changes costly to perform and maintain at scale. Changes with a ripple effect can easily tack on significant overhead, making even minor tweaks an absolute nightmare.

Whereas the monolith is a non-distributed solution, microservice architectures are the exact opposite. Each of the hundred functions would be grouped by form and function as its own API-driven microservice. The systems? Their own microservice. The resources? You guessed it, accessed and managed by its own microservice. With microservices, everything functions within its own domain, like an organism made of many cells.

The Promise of Microservices

The promise of microservices is appealing, especially the ability to easily switch out components. When everything is decoupled, extensibility, portability, and reusability are also more feasible. Replication of functions at multiple levels is erased, as a single microservice can be referenced by a hundred other microservices. As such, microservices are often sold as a cure-all. But is that really the whole story?

The Reality of Microservices

Microservices are powerful, and in the right situations, they can absolutely solve the plethora of issues brought on by a monolithic development approach. The reality is, however, that the microservice approach is just like any technical solution — appropriate in certain circumstances and not appropriate in others.

Microservice evangelism has been so fervent that its drawbacks are often not discussed with as much energy and specificity as its benefits. Namely, microservices bring significant additional complexity. Microservices add more complex interactions, especially in networking, as each element of the system must talk to each other element to accomplish an individual task.

Yes, microservices make each element independent. In this distribution of services, however, centralized control is tested, meaning deploying new frameworks or languages, updating to new versions of existing systems, or adopting new protocols means changing multiple microservice pieces rather than a single codebase.

To be clear, these drawbacks can be resolved quite handily — but doing so requires a management layer, which often introduces additional complexity and process demands. This is especially troublesome considering that microservices are often touted as highly efficient and lightweight, which is really only true when the implementation is of a certain size and complexity. Small-purpose APIs, for example, do not benefit from microservices in the same way a larger complex system would.

When Do Microservices Make Sense?

Microservices make sense when you have enough of a collection of services to justify it. In the microservice paradigm, each service is its own form and function and, accordingly, exists as a unit that works in combination with other units. In a mature product with hundreds of moving parts, each accessing other resources several times per call, a microservice framework doesn’t just make sense — it is perhaps the only approach to effectively handle such a complex system. The reduction over time in deployment and development cost alone justifies the adoption of the microservice architecture in this case, let alone the massive gains in efficiency and code size.

Notably, a considerable benefit of microservices is the need for extensibility. Microservices are a wonderful option when creating a system that faces rapid growth and extension. Yes, your software ecosystem runs fine today — but what about a year from now, when it needs 100 new functions across several different resource groups utilizing different authentication and authorization processes? Microservices can unlock extensibility by removing the development blockers of the monolithic approach.

When Do Microservices Not Make Sense?

The Infosys whitepaper Microservices, Not a Cake for Every Business states the following:

“The famous adage “one size doesn’t fit all” holds good for microservices as well, as they are not the right fit for every business/project. Just because everyone is jumping on the bandwagon cannot be the sole reason for its adoption. We must spend substantial amount of time to anaylze if the given application is fit for MSA or not.”

Yes, microservices deliver extensibility and scalability. But do you have a core product that needs to be extensible in the next 24 months? Do you anticipate millions of users across hundreds of functions in the next year? If the answer to that is a resounding “no,” then building microservices might not be right for you. Straightforward minimum viable products or experimentation do not justify the development overhead.

Another common situation is one in which you need tight control. Microservices and monoliths can be just as secure as either. Still, the reality is that the monolith represents one point of failure, one system to secure, and one system to monitor. Monitoring a microservice and all of its networked functions can be done expertly, but if you are trying to create a single secure service that runs on-premises, creating a microservices architecture does not make any sense.

4 Considerations to Find the Right Fit

As with any piece of technology, there will be situations that call for either a microservice or a monolith, and there will be plenty of situations in which the question is debatable. To determine when microservices are worth it, consider the practical outcome of adopting either solution. Here are several areas to consider, which should help weigh which is best for your software systems.

Consider the current scope. Will adopting a microservice architecture take something that is really only two core functions and turn it into a product requiring a team of ten to deploy, iterate, and monitor? This is probably not a good use of a microservice paradigm.

Consider future outlooks and scalability needs. Will adopting the monolith result in something we’re locked into for the next ten years despite the fact that we are on the cusp of Series A funding and a massive explosion of users? The monolith is probably a bad idea.

Consider real-world case studies. We can look to some real-world examples to validate this line of thinking. For instance, Nordic APIs has outlined SoundCloud’s multi-year breaking down the monolith and covered other case studies of microservices and API-first adoption at Uber, Netflix, Tinder, and elsewhere. We’ve also shared strategies other teams are using to avoid microservices disillusionment.

Consider company size and revenue. A study conducted by Qeunit found that only 1% of organizations need microservices. The findings suggest that $2 billion annual revenue is the scale at which companies have good reasons to adopt a microservices architecture. This data is not authoritative, as the sample size was just over 50 companies, but we can use it to draw inferences. Namely, that microservices and monoliths both have their place and should be considered within the context of their deployed reality.

Conclusion

As with anything in the tech space, monoliths and microservices have their time and place, and their use will depend highly on the specific use case and the benefits one wants to derive from their implementation. Microservices offer high extensibility and reusability but come with an increase in complexity. Monoliths represent a more straightforward option that carries a high cost of development and relatively difficult extensibility.

What do you think some good use cases for microservices and monoliths are? Let us know in the comments below!