The Pros and Cons of Microservices

Almost a precondition for using microservices, the enterprise should be looking at the big picture of its software offerings, not just the project du jour. Microservices make sense if the business intends to design individual microservices to use again and again in different ways. In these situations, the advantages of the microservices-oriented model will usually outweigh the downsides—and as with any technology, there are downsides.

Advantages of Modular Applications

So what do microservices bring to the table? Explore the topic even a little bit and you’ll see these benefits mentioned over and over again:

• Easy deployment
• Rapid scalability
• Less production time
• Reusability
• Cloud-friendly

Microservices result in modular applications, where one component can be changed without redeploying the entire app. This can allow organizations to evolve their applications with minimal internal and external customer disruption.

Many companies’ take on mobile apps—a constant work in progress, if you will—make them a natural fit for microservices. Plus, microservices can live all across the cloud, waiting to be called on whenever needed.

As they represent basic functions, such as order logging or credit card processing, they can be reused wherever the specific function comes up in the business process. This might include a retail website, the software used by telemarketers, and a customer-facing online app. Multiple uses, a single microservice. Microservices can thus limit production time for new applications because many of the building blocks already exist.

For companies that are invested in DevOps—the combination of development and operations functions into a more seamless unit—microservices have other benefits. The continuous integration and deployment (CI/CD) they’re seeking can come more easily with such modular architectures. A related features, changes can be safely rolled back to a previous version, which is better in the CI/CD-demanding sphere of DevOps.

Disadvantages of the ‘Little Cities’ of Code

All of these advantages do come at a cost, however. Among the downsides of microservices:

• They can be too small, dealing with functions that are too granular to be terribly useful.
• Latency can be an issue, especially during heavy use.
• Microservices can make testing more complex.
• Security risks exist, some of them quite serious.
• They add network and coordination overhead.

Not surprisingly—this is IT, where there are always a variety of opinions—some IT pros hate the idea of microservices, or at least consider them to have more limited applicability than the hype suggests. DZone, for example, underscores the overhead and risk involved in using microservices.

Even Martin Fowler—the same guy we keep mentioning as the definer of the microservices field—is cautionary. He warns not to even “consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.”

This article has more depth on the “monolith first” idea.

As we often say, the best course of action is not to take the advocates’ hype or the naysayers naying as the proverbial gospel. There are good reasons to use microservices and good reasons to stick with monolithic development. The choice will depend on the business case.