Microservices are the new black?

So many of our customers have been eager to know more about microservices. They get to know about microservices from either their colleagues / friends or a tech conference that they had attended recently. Their questions will be in the lines of:

What exactly are microservices?

Will it help to speed up the development?

How much is it going to cost me?

Using our experience with microservices, we had identified where it helped our customers (and also where it didn't).

This article talks about the best ways a customer can take advantage of microservices and their pitfalls as well.

Advantages

First let's talk about their advantages. Microservices are immensely useful if the entire codebase is chunky and making changes to the code becomes very tedious. Also whenever the developers are not confident to make changes to the existing codebase, it becomes even more difficult to have a good velocity. Microservices in these cases help to decompose the big codebase into smaller chunks and also help to keep the concerns separated. This helps in two ways: to keep the complexity low and to keep the teams managing the microservices independent.

Team wise advantages

The team gets these advantages:

• Independent codebases to maintain and develop - so autonomy
• Speed of development increases for each separate team
• Complexity of code reduces for teams

Code wise advantages

• Test cases improve since each codebase will be smaller and easier to maintain
• API driven contracts will be the norm of communication between different services
• Each service could be independently deployed, tested and scaled

Dis-advantages

It's not always a rosy story for microservices. There are times when microservices could work in a not so good fashion. A startup choosing microservices with not enough people could de-rail the entire project. We have seen this happen multiple times and we don't recommend microservices for smaller companies with limited developers. We have also seen that there is an overhead for microservices in terms of logging, tracing. The organization should be educated enough to understand that there will be changes in the ways of communication between teams.

When to choose microservices?

We would suggest that you can choose a microservices oriented architecture when the following conditions are met. We would do this in a very detailed fashion during our consulting process.

• Large companies with different teams that have their respective leads and managers
• The code has become tougher to maintain and writing tests cuts across concerns
• Teams understand the implications of using microservices
  • Changes in communication
  • Changes in contracts between teams

We would suggest that if you are a small company, stay away from microservices. If you are a large company that can have many different teams with enough knowledge about the architecture, go for it.