Microservices are one of the hottest topics in software delivery today. Everywhere you look, you hear developers singing the praises of them. Yet, they are not a cure-all, and they’re not the right solution for all situations. This post explains reasons why you might not want to adopt microservices.

The Benefits of Microservices

Lest this article read as an attack on microservices, let’s start by spelling out why they are a good thing in many cases.

Applications that are written and deployed as microservices are more modular. In turn, the applications are easier to scale and manage because individual pieces—in other words, individual microservices—can be modified without having to revamp the entire application.

They also offer security advantages. A well-architected microservices application will isolate services in such a way that an attack against one service will not easily extend to other services.

Microservices applications often are easier to deploy, too. This is especially true thanks to infrastructure technologies such as containers, which make it easy to deploy each inside a portable, discrete environment.

Sponsorships Available

Sponsorships Available

Sponsorships Available

The Pitfalls of Microservices

Yet, the fact that they offer several advantages does not make them the perfect fit for all situations. Following are reasons why you might choose not to adopt microservices:

1. You have a legacy application. Migrating a monolithic legacy application to a microservices architecture requires time and effort. If you don’t expect to continue using the legacy app for a long time, the migration might not be worth it.
2. Microservices are more difficult to manage (in some ways). Although breaking monolithic applications into multiple discrete parts can simplify programming, it can also make the application more difficult to manage. Microservices mean there are multiple moving parts within your application. The parts often depend on each other in complex ways that are not immediately obvious. In short, there is more complexity to manage.
3. Microservices require a larger technology stack. This point is related to the preceding one. Managing the complexity of microservices applications often requires you to deploy additional tools, such as orchestrators, that you would not need with traditional monoliths. Having more tools is not necessarily a bad thing. But in some cases, keeping your technology stack lean can be an advantage. The fewer tools you have to learn, maintain and secure, the better.
4. Microservices make networking essential. Microservices applications typically rely on the network to enable communication between microservices. Without a network, they don’t work. This means managing and securing the network becomes more important, adding extra responsibility for developers and admins.
5. Microservices are slower to develop. In general, developing a microservices application requires more planning and coding. This is one of the reasons why these types of applications tend to perform and scale better; they force developers to work more carefully. In cases where you just want to get an application out the door as fast as possible, however, investing the time required for a microservices architecture may not be worth it.
6. Microservices are not actually that new. Interest in microservices has exploded over the past five years or so. For that reason, it’s easy to assume that they’re a new, innovative application design strategy. Yet, they and similar concepts have been around for years. In the 1980s, microkernels, which took a microservices-oriented approach to kernel design, were all the rage. Object-oriented programming, which is even older, is founded on the same type of thinking as microservices, too. More recently, service oriented architecture, or SOA, was a big deal; SOA is also more or less the same idea. The point: Microservices may seem cool and innovative, but they’re not necessarily as innovative as you think.

Again, I’m not here to knock microservices. They’re a useful application architecture in many cases. But like any technology trend, they can be used to maximum advantage only if you understand their limitations and shortcomings.