Should you change to Microservices?

In this new era, monoliths are viewed as primitive but are they really?

Welcome, thank you for clicking on this article, I hope you’ll enjoy it, and most of all that it will be helpful. So before we get started let me introduce you to the topics of this article:

• What are microservices?
• A case for/against microservices
• Pros/Cons of microservices
• How big a microservice should be?
• How to make the change to microservices?
• Conclusions

What are microservices?

You may have heard the term microservices, how great they are and you might have a vague idea of what it means, but what exactly are microservices? Well, it is an architectural pattern where you can structure your application as a collection of smaller components (services) that are loosely coupled, independently deployable, organized around business capabilities, highly maintainable and testable, and owned by a small team. Essentially, with microservices, you chop up for would-be monolith into independent business components, as shown in the image below.

A simplified view of monolith vs microservices

With the microservices architecture instead of maintaining one big application, you are splitting it into multiple applications that handle a particular task. In a very rudimentary case, you can imagine an e-commerce application: instead of having a monolith, you could split your application into 3 applications: Shopping service, orders service, and shipping service.

The client connects through his browser to your shopping service and purchases an item. The shopping service will then tell the orders service about the order, the latter then stores all the details of the purchase into the customer profile and then tell the shipping service that there is a new order that needs to be shipped.

Now you might be asking yourself: “OK, I’ve just split my application into 3 different applications and now I have to deal with a distributed system and a lot more complexity because of the very likely asynchronous tasks I have to do between applications”. And you would be absolutely correct and that is a point that is important to figure out right out of the get-go. Not every project should follow the microservices path, there are particular cases where it is necessary to go that path but in most cases, you will do just fine with a monolith. Microservices are not the silver bullet of development.

A case for Microservices

Back in 2008 Netflix which was servicing the whole world with a monolith realized that they needed a better solution, because each time they deployed some changes, they had to stay in what they called the “war room” checking if something went wrong and if it did, they had to figure out what part of the code was causing issues. At one point a single missing semicolon shut down their website for several hours. When you change to microservices you are dealing with smaller, more manageable codebases so it becomes easier to detect errors, and even if a bug manages to sneak into production only that service will fault.

A case against Microservices

Segment, a Customer Data Platform (CDP) broke up their monolith into microservices in the hopes of a brighter future but after a few years they end up going back to the monolithic architecture. Basically what happened was that an error in any one of the routed connections would cause requests to pile up as the microservices attempted to correct the issue. As more and more requests were piling up, the system would try to compensate with auto-scaling, resulting in an overload of ports being used which in turn would result in performance issues to the customer base. This was probably caused by a wrong implementation of the architecture but you can see how the microservices architecture became a bigger issue instead of helping.

Pros of Microservices

Before we get into the negatives of microservices, I would like to point out the great benefits of this architectural style.

• Microservices are independently deployable: each service is deployed independently, it allows you to continuously improve and deliver that service to your customers without redeploying everything else.
• Microservices are independently scalable: usually in a monolith, if you want to scale up, you are essentially cookie-cutter pasting the whole monolith into different machines which increases the workload quite significantly. With microservices, you only need to scale the most needed resources, making it easier and chapter to scale.
• Microservices reduce downtime through fault isolation: If a particular service fails, you can easily isolate the fault and prevent the failure to cascade down the rest of the pipeline. Effectively giving you extra time to fix the failure before your critical applications have any problems or the customer notices it.
• A smaller codebase allows teams to rapidly understand the code: microservices usually have small codebases, making them easier to read even if the team is new to the service. They can rapidly catch up and maintain and deploy the service. Also, it is easier to maintain the code clean.

Cons of microservices

• Microservices create different types of complexity than monolithic applications: In a monolith, communication between modules is done by synchronous function calls, while in microservices you will have to implement some sort of communication, ie API calls. The more services you have, the more complex your communications become. Debugging is also more difficult, each service has its own logs and you may need to cross-reference those to find the source of the problem.
• Interface control is critical: Each service has its own API, which other services rely on it to be consistent. If you happen to change the API, any service using that interface will be affected if you did not make your API backward compatible (using versioning in your APIs could solve this issue).

How big should a microservice be?

So you are convinced that microservices is the way to go for your application and now you are wondering, how big should any of my microservices be? That is a great question that nobody has yet to answer. There is no rule of thumb for these kinds of things but a good measure would be: one microservice, one responsibility. But as Martin Fowler puts it, if you think of payroll, it would in theory be one responsibility but that would result in a very big system. Perhaps the best example is the two pizza rule, a team in charge of a microservice should only be as big as the number of people you can feed with two pizzas. So, hire a few people that eat a lot, or if you have the budget for it, a lot of people that eat very little.

Migrating to microservices

First and foremost, don't do it all at once! If you decide that microservices is the way to go for your enterprise you should do it bit by bit. It would be really bad if, in the next iteration of your application, everything was separated into microservices and after deploying you find out that nothing works as imagined. Your migration should be phased in in each iteration, removing brick by brick the monolith until you fully working with microservices.

Some good tips to start this process is to:

• Look at your application and try to identify business logic that can be separated.
• Find naturally isolated code, like static auxiliary functions.
• Look for parts of your application that could benefit greatly by being scalable separately from the rest of the application. This could potentially result in saving costs because you would only be scaling a single part of your logic instead of the whole application (which would have greater computing requirements).

Conclusion

Microservices can be a very powerful architecture but as a popular proverb says “With great power comes great responsibility” and if you choose to wield it you must do it properly. If done right, you are looking into a new scalable world but if done the wrong way, you are in for a world of suffering and pain, which will probably result in you going back to the monolith, wasting time and resources that could have been otherwise used in continuing building the monolith. It is also important to note that you should not just use microservices so that you can throw buzz words around and show how much better your company is because you are using microservices, it is important to know that the monolith is not inherently bad and that in most cases you simply build your application as a monolith and it will be implemented faster and work better than what it would with microservices. Always pick the right tools for your task.

I hope you have enjoyed reading my article, if you have any suggestions or disagree with any of my points, please let me know. I do not claim to be an expert in this subject so your feedback would be very welcome.

Until next time.