How to split an application into services
In software architecture we have terms such as monolithic applications, microservices, and even macroservices. But the truth is that if you ask ten people to explain each of these terms you will receive ten different answers.
There’s one thing we all agree on, however: applications tend to grow and sometimes they become too big and hard to maintain. It sometimes makes sense to split those applications into smaller ones (called services) that communicate with each other somehow.
But how to split an application? In how many services? How are they going to communicate? We don’t agree on these issues yet.
The first problem we have is that we don’t know what exactly constitutes a service. So here is my own definition:
A service is an application that can be deployed independently, exposes a well defined set of operations through HTTP or any other communication protocol, shares nothing with other services, and is (or will be) maintained by an independent team.
You can think of services as products that could eventually be offered to other companies as well. This means that each service should provide its own authentication mechanism for others to use it (usually in the form of API keys), API versioning, and good documentation!
Some services also expose a user interface (Web or mobile), and libraries that ease the integration into other Web and mobile applications, but user interfaces and integration libraries are not services per se.
An example
Imagine that you are developing an e-commerce application and it includes a recommendation engine and a support chat among other functionalities. Your team thinks that these two components can be extracted as services. How would you go about it?
Ok, so the first question is: does it make sense to create a service out of these components? Maybe the company is growing quickly and you now have a specialized data science group that will work on the recommendation engine, and a group to improve customer support, so it might make sense.
But here is the catch: why not use a recommendation engine or support chat from a third party? We could use AWS Personalize (or any alternative) as our recommendation engine and Intercom (or any alternative) as our support chat and knowledge base, for example.
There are still good reasons to create our own services. Maybe it’s the secret sauce of the company, or maybe our service will be so specific that we don’t find a similar thing in the market right now. But the important thing to note here is that you should think of your services as products that could be offered to other companies.
A checklist for a service
Here is a list of characteristics that make a good service:
- Exposes a well defined set of operations through HTTP or any other communication protocol.
- Shares nothing with other services
- It is (or will be) maintained by a separate team.
- Handles authentication in the form of API keys (e.g. private/public keys or JSON Web Tokens).
- Provides versioning for the API.
- Provides good documentation
