During my career, as with most developers with enough experience, I have seen bad and very bad microservice architectures and I have made bad decision too because it’s not obvious, everything related to software architecture is quite hard and requires a lot of experience. If you are new to the world of application architecture, this article is for you. Here I will try to show you what measures to use to to divide your application into services, when you need it, and when you don’t.

When You Need a Separate Service

When we talk about splitting an application into separate services, we have to be very cautious because every new service is a point of failure, an additional headache to the process of QA, deployment, etc.

Performance

One of the big reasons to have a separate service for some chunk of functionality is performance requirements. You may have your service built in Node.js or Python, but you definitely don’t want to write CPU-intensive calculations in these languages because you will be limited by their nature. In this case, it’s better to make it a separate service. Make a service in a more performant language such as: Rust, Golang. You can make it a service or you can embed it into an existing service.

Wrong Tool for the Job

Another case is if you have your core functionality written in, let’s say, Rust. You don’t want to write an admin portal or client portal in the same Rust service; it will take you ages. In this case, you are better off writing a separate service in Elixir, Ruby, JavaScript, or something that provides a full-stack framework that will save you time.

Criticality of the Service or Different Security Standards

Another considerable reason to split a piece of functionality into a separate service is the level of criticality of that service. Let’s say you wrote a piece of logic that does some calculations that do not require a lot of CPU or RAM, but these calculations are critical and must not be messed up. I would argue that it’s a serious reason to split that logic into a separate service in order to have a dedicated process for QA, CI/CD, and testing standards. You won’t need to give access to this repository to anyone except people who are responsible for this chunk of code; you will always know what to test and be highly cautious dealing with this service.

Infrastructure Cost

Another reason to have a separate service is infrastructure costs. Let’s take this example: you have a service A that is replicated into multiple geographical zones, and you have a piece of functionality that has heavy I/O load to and from a source that is located in one place. In this case, it’s better to split the I/O-related functionality into a separate service and place that service near the data source, because almost all cloud providers either provide output traffic for money or have limits. If your data-related service outputs terabytes of data, you have to care about the price that you will pay for this data.

When You Don’t Need a Separate Service

From my experience, you don’t need to make a separate service if you have one of the following cases.

Different Contexts

If you have a piece of functionality that has a different context, even if this context looks like a perfect candidate for a separate service – DON’T DO IT. Make it a different module and relax; there is nothing wrong with having your user management service as a module in your core monolithic service.

Different Scaling Requirements

If you have a chunk of code that will require serious scaling and you think that it’s better to make it a separate service, you shouldn’t if you can scale the incorporating service without too much cost. It’s always better to make something a separate module than a service unless you have different performance requirements (see “Performance” section). A module is always easy to split out into a service than do the opposite.

Language Preferences of Different Developers

No, you should not make a separate service if your developers don’t like the language and want to write in something else. It’s pretty much always better to keep the codebase consistent and in one place. By keeping things consistent, you will avoid a lot of headaches.

Thank you for reading!

👏Don’t forget to like if you liked the article👏

Contacts
If you like this article don’t hesitate to connect on LinkedIn and follow me on Twitter.

Subscribe to my mailing list: https://sergedevs.com

Be sure to like and follow 👏