Armedia Solution Engineering Team

• Vishal Deshpande
• Andrew Slade
• William Phillips
• Naga Krishna Sumanth Kovvuri

When Should I Use Microservices?

Microservices are a powerful and useful tool when used appropriately. However, they are not a magic bullet to solve all software design woes in comparison to monolithic architectural design. Like most issues, there are great benefits and serious downsides to both microservices and monolithic applications. It is imperative to review your use case carefully and determine which course is the best for your application.

What Are The Benefits Of Using Microservices?

There are a few big benefits to using microservices in comparison to monolithic applications.

Microservices are inherently separated from one another, which promotes a better focus on the scope as well as keeping code succinct which eases future maintenance. These services can be specially designed to accomplish one task very well, and changes to update or improve a service will not break interactions with other microservice so long as the existing API works as expected.

Unrelated services do not impact one another. For example, in a monolith application you have Service A and Service B. Now, let us say that Service B malfunctions and crashes. Because they are part of the same system, Service A will be brought down as well. However, with microservices, because services are separated from one another, Service A will not be impacted if Service B crashes. In addition, deployments of a service can happen while all other services are still live.

Another benefit is improved scalability. If only a few services are being hammered enough to require scaling, you only need to scale those services. In a monolith, you would have no choice but to use additional resources to scale all the other services, which would lead to wasting resources. This is especially useful in cloud-based hosting because careful control of resource use is more cost-effective.

Finally, you are able to use whichever language or software stack for your microservice as needed, so long as it can meet the requirements of your architecture. This can enable teams to explore new technologies and features without having to re-write an entire monolith. In fact, some languages have better developed open-source libraries for certain tasks, such as image processing or voice recognition.

What Are The Downsides Of Using Microservices?

Microservices don’t come without drawbacks, however.

The single biggest issue is the increased complexity of handling the microservice architecture. The system is a distributed application, so there will need to be additional work towards the discovery and coordination of each microservice. Because of this complexity, you will need to design your application more up front in comparison to a monolith.

There are additional headaches when it comes to synchronizing services and keeping your data consistent between microservices. When it comes to communication between microservices, you have no choice but to use remote calls, which have slower performance and the calls may get lost, delayed, or even fail. In addition, trying to keep calls transactional can be a nightmare when a transaction goes between multiple microservices.

Testing is also difficult with microservices. In order to test full functionality, you either need all dependent microservices running or you need appropriate mocking of values to simulate the environment.

In Summation

As stated earlier, there is no right or wrong answer. The common sense approach is if your application is small, won’t need to scale up very far, and you want it to be simple to deploy, a monolith is a right answer. A microservice solution for that problem would add too many layers of complexity to the benefits.

However, if your application will be very large, will constantly be expanding on features and offerings, and want extremely strong and fault-resistant system, then microservices may be the better solution.