Starting a microservice architecture project
Starting a new project in a company can be stressful when it comes to deciding what technologies, tools and architecture to use. For the start-ups that are just beginning their journey, the temptation is to look at what other companies in their field are doing. One of the buzzwords in the IT industry right now is “microservices”, and many companies are trying to adopt this architecture into their new products. Unfortunately, for most of them, it might now be the right choice and it might be exactly the decision that kills their product. Here is a list of things to pay attention to if you plan on using microservices:
1. Making sure you need microservices
As the microservice architecture is quite new to the industry, there isn’t yet a defined set of rules that tells you exactly what you need to do in order to implement it correctly. There are many sources that are worth studying, such as microservices.io, but you might also want to check materials from big companies, which most likely have done a good amount of research on this subject. As with any subject, there are different layers to the microservice architecture that you need to understand, so make sure you research it properly before jumping straight to the implementation. You can find a list of useful materials at the end of this article.
2. Making sure everyone understands what it’s about
After you have done your research and you have concluded that microservices are something that your product will benefit from, it is time to help everyone else involved in the project to understand what this architectural style is about and why it is a good idea for you to use it. Sketching a diagram of what microservices have to be created, how they are used and how they interact with each other is a great way of explaining it. Make sure everyone has access to the materials that you collected and that everyone understand why microservices are necessary and why things work the way they do (for example, why you are using asynchronous communication between the services).
Apart from your development team having to understand all the technical details of microservices, you also have to make sure that the other people involved in the project — the design team, the marketing team, stakeholders — also understand, at least briefly, how the project is structured and why certain tasks are taking longer than what they are used to. Otherwise, this can be seen as a sign of inexperience from your development team.
3. Understanding the risks
If microservices would only only present advantages over the monolithic architecture, everyone would be doing it. While in the long run this architecture can offer benefits regarding scaling, maintaining or debugging your application, there are certain risks that you need to take, especially in the incipient phase of the project.
A significant portion of the development time will be dedicated to system integration, which means your team will have to use up a lot time without making any “visible” changes or additions to the project — which, as I mentioned in the previous point, can be viewed as something negative by investors or customers. If this is something that you cannot afford, choosing the microservices path is definitely a bad idea.
The costs for hosting your product will also be higher than in a monolith, since each service will have to be deployed separately, and you are also adding components that would not be present otherwise (such as an API gateway).
4. Taking advantage of anything you can
The base idea of microservices is that you divide your application into loosely coupled services that can be deployed separately. This offers you the possibility of using different technologies, programming languages or deployment spaces for each of them. And this is something that you should think about while deciding which services you need. Make sure you are not creating a monolithic application that is simply divided into multiple projects. Even if most of your microservices are written in NodeJS, an AI service might be better to write in Python or F#, for example. This also enables you to delegate multiple teams to work on separate services.
5. What if you are not ready for microservices yet?
Whether it’s about time, money or the team, you might not be ready to develop your project using the microservice architecture. However, if you foresee that you could benefit from using it, given that you had the right opportunity to implement it, there is still a solution: building and releasing your project as a monolith and then, slowly and strategically, decoupling parts of it and deploying them as separate services. With this approach, you can start the decoupling process whenever it suits you, so you are not pressured by the release deadline or investors, and you can also carefully choose which parts to decouple first, based on which functionality of your system is used the most.