Junior’s view of Microservice Architecture

What and why?

The microservice architecture is a software design architecture that tends to break traditional monolithic applications in multiple services, each of them having its own purpose. This division results in a collection of services that are:

• Loosely coupled: each service is independent, has its own database.
• Independently deployable: As each service is independent, it can be developed and deployed on its own without affecting other services.
• Each organized around its own business: A microservice handles only the features linked to its purpose. One purpose, one microservice.
• Highly maintainable and testable: As each one is independent, it’s easier to identify in which one an error occurs. And less features means less code to test.
• Owned by a small team: A microservice can be developed by a smaller team than a big monolithic application. The different teams can work separately, the only thing they have to discuss about is the communication between services: how they will communicate, what they will share. But you don’t need to know how other services than yours work.

Others advantages:

• Each service can use its own language, framework, and so on, while it still can easily communicate with other services.
• Smaller applications are easier and quicker to develop.
• As there can be multiple instances for a same microservice, if one instance goes down it’s not a problem since others can do the same work.
• You can easily switch between technologies or languages without risk.
• You can reuse small microservices as login systems.

On the other side, there are some inconveniences:

• Microservice Architecture is not adapted for every company. So you have to make sure yours is capable of managing it.
  • You have to be able to provision an infrastructure to support microservices. For example, with a Docker platform who can help you to manage multiple instances of microservices.
  • You have to manage multiple teams working on different features and entities of your project.
  • Microservices work better with a DevOps culture, so everyone in each team is responsible for service provisioning, from the development to the deployment. “You build it, you run it!”
  • With features added over time, complexity increases so you have to be able to handle a reasonable level of issues (database error, network latency, …).
  • You have to think about failures: you will have multiple issues. It’s inevitable. But you have to handle them. When a service fails, it must still work even in a degraded version, in order to keep the entire system working. A solution to this issue is the use of an Entreprise Service Bus as RabbitMQ. This way, if a microservice is called but it doesn’t answer, the bus will try to call it later when the microservice will be working again.
• Microservices are not for every project. Sometimes, division can bring complexity to simple applications. Think about what your application has to do and what you can earn using or not microservices.

How?

The heart of a microservice application is the Registration Service. Indeed, even if each microservice is independent, they have to find each other, and mostly find the client or Gateway Service that is the entry point of the whole application. So, each service has to register itself on the Registration Service. Then, when one has to call another, it first asks the Registration Service where to find an instance of the service needed. Then it can make a call to that instance.

And that’s it! You just have to tell to the microservices where to find the Registration Service. Well, in fact, you have to implement the different calls between the services yet. And most of the time, services will communicate with REST calls.

In conclusion, as a junior developer, microservices seem to be a great architecture pattern, bringing a lot of advantages and being able to lower the complexity of an application. But actually, even with a short experience, I understood that was not adapted to all projects, mostly the simplest. So, first of all you have to decide if it’s the best architecture for your application. And if it is, someone has to keep a good overview to not be lost in the web of microservices and to not bring more complexity in the end. Finally, I think microservices have a bright future but sometimes you won’t be able to do without a monolithic application.