Micro services in the agency development?

As you might know from our previous blogs, our primary language for writing backends is Node.js. One of the main reasons why we have chosen this technology was that we started to feel the limits of all the other classic monolithic applications, where all the basic logics, renders, request processing and so on were done in one codebase. It was rather limiting not only technologically, but also from the human resources point of view. Also in the area of our PHP “ends”, according to our recently finished projects, we used to divide the final depicting layers into the individual thin client written in React. But we wanted to go even further; dividing the backend into multiple smaller and self-maintaining parts.

We knew about the existence of a concept called micro services. By this time it was successfully used by companies like Netflix or Sporify. However we do not operate like any of these companies, we do not create one big product. That brought up the speculation if we would be able to understand and apply this concept properly in the development process schemed specifically in our agency.

The first project where we used this concept was Tapito. And the result turned out to be absolutely amazing as you can further discover in our case study. From this point until today we have walked a long journey during which we have been harmonizing our attitude and now we are able to use it in any project we develop.

The smallest structure we use is built out of 3 parts:

Gateway

Gateway is the only part visible from the Internet. It takes care of the incoming requests redirect to particaular services and provides translation of security tokens and users details so that each service included in the cluster could decide if the request shall be served or not.

User Service

This service is pretty simple but crucial. It preserves information about users and deals with the authentication of a user’s role across the whole system.

Core

In the core you will find 1-N services containing the whole business logistics of the application and the request service. They communicate with the third party services and execute periodical requests. These services communicate straight forward. Their number differs in each application. It is important to keep each one of these to serve only one clear purpose so that it doesn’t become a good old monolithic juggernaut. On the contrary, over-dividing into “nano services” might cause even bigger chaos. It is important do think each proposal through regarding previous experience and healthy judgement.

What are Micro services to be blamed for?

Micro services are often criticised for complicated deployment management and maintenance. I believe this could be a problem, however with our infrastructure built on CI, Docker and Google cloud we can’t be happier. By all means, it can get really cumbersome while testing locally more micro services at the same time. Another disadvantage might be a re-writing the same code all over and over again. Clearly, using multiple smaller applications calls for more codes so that the apps would be able to serve requests, load configurations etc. For these purposes we have developed a modular template that facilitates this process a lot. By the way, in a short notice we want to exhibit this template on our Github.

What have we gained?

We have ameliorated the organisation and clarity of our applications. Smaller codebase is easier to maintain. Another advantage is that now two developers can work simultaneously on two independent modules without a need to coordinate with each other. Not only this speeds up he main development but also allows the smoother engagement of new team members into the process.

We have gained well-arranged and safer architecture, which isn’t anyhow complicated but is sturdy enough, variable and independent. Also we got rid of “Single point Failure”. The failure of one service doesn’t have to cause the dysfunction of the whole system. The services can be independent on each other, so that overload of one segment doesn’t lead to breakdown of another critical service. The possibility to re-use the already existing segments in another project might also come in handy. We do not plan to change this attitude as long as it brings more happiness and serenity during the development to us and high-quality software to our clients. 

So in conclusion, I must confirm that micro services are not just a privilege of big product companies, they might be easily used also in agency development.