Without any doubts the year 2020 is one everyone is going to remember and it will appear in the history books (and wikipedia). Amidst so much chaos, the established way of working was forced to change, and companies that before rejected work from home had to adapt. In this way, teams that before shared a room and suffered unnecessary meetings, now started functioning as distributed teams (or distributed systems), that share a queue of messages using tools like email and slack (async communication) - and have meetings with lesser frequency (sync communication).

Great part of the IT industry agree with remote work, and beside topics like if the employer should pay for employees’ monitors and internet there is not any major complain.

If one make the assumption that a distribute team is better, can one also assume that a company using microservices is better? The answer is surely not black or white as there are certain topics to analyze.

In the next paragraphs you will find “the good, the bad and the ugly” of the microservices. This is an extract of two podcast episodes of Stream 404 , a channel on which, me and my friends, stream monthly about different IT topics. The content of the episodes is on spanish, so the extract will be on english to cover a broader audience.

The good, the bad and the ugly

Title of an old film and also of a retrospective , consists on naming good things (that the team should repeat), bad things (that should have never happened) and ugly things (which the team need to work with to make beautiful).

Applying this to microservices one can name:

  • The good things of using them.
  • The bad things as problems to avoid.
  • The ugly things as transitions and changes of paradigms that the team has to face.

The good

SOLID, a set of principles that apply to programming languages, establishes the “Single Responsibility Principle” (SRP): A class, file or package (depending on the language) must have an unique reason for changing. Microservices should take advantage of SRP to delimit the scope of a service and encapsulate that code within. In this way, the discoverability of certain functionality is way easier.

The development lifecycle is shorter. When the scope of the microservice is well delimited, it should not take more than two weeks (from book to reality it may vary) which makes it easier to replace in case one needs another implementation.

Following the same line of thinking, a service with a delimited scope is easier to test; a good base of unit tests which guarantee that the business rules are valid is fundamental for ensuring that the system works as expected.

Lastly, in bigger companies where every team represents a function, is common to find no more than six people specifically working in one or two services and having total freedom to develop them - without breaking any contract constraint established with other services of other teams.

The bad

Hashtags. It may sound ridiculous but to get people into start-ups there are teams that just try to do microservices, without considering the advantages / disadvantages, because they are trendy. The stigma of the monoliths is such that mentioning them cause pain. In a new company or in a new project, where the business is not super well defined and/or stable, the best alternative is to start with a monolith and then migrate to microservices.

The tooling (libraries, infrastructure, others) can be a problem in a not so mature team. The autonomy means that a team can pick a programming language that was not used before in the company. One needs to be aware that a established language is likely to have a tooling made for it and changing it “just-because” is most of the times a not reasonable option.

A company that handles a lot of languages also needs a lot of employees with different skill sets which can be a complication in case one employee leaves or wants to change team. Even when I do not agree that one only knows how to code on certain language and needs to start from “trainee” to learn a new one; there is still a learning curve in order to familiarize with syntax, frameworks and others.

The ugly

Microservices are not good for a new business in which there are no domain experts to brainstorm with. This, also mentioned in the bad, is something the team needs to work with. A monolith can be split gradually when the business scopes are stable and this can take from months to years.

There is also a change of paradigm in terms on how to test the system. Many teams rely too much on automated E2E (end to end) that covers the entire system. Even when this seems like a good idea, one of the microservices’ principles is that the deploy should be independent. If one has to deploy 10 services into production simultaneously and each time the E2E are executed takes 5 minutes; a total of 50 minutes is going to be spent rerunning the test one after another. This is not scalable on bigger systems and this is why the unit tests (for testing business logic) and integration tests (for testing database, amqp, other APIs) are favoured instead.

Everything needs to be observable and measurable. In a monolith the failure points are easier to detect as everything is on the same application. In a distributed system every service need to have their metrics and alerts in place to know when there is a problem and be prepared to downgrade functionality when this happens. Networks fail, it is not about how to avoid something breaking but how to alert and proceed when it happens.

From sync to async communication. A lot of the operations do not need to happen in batch. This is another change of paradigm. If a customer performs a buying operation it is probably not necessary for the sending of the receipt to happen in sync in the same transaction. For this, one can implement the pattern “Tell don’t ask” where a service tells the other (via an event) that something has happened. This is an async operation that decouples the transaction and that can be retried the amount of times needed. So if the mail service for sending the receipt fails, the buying operation of the customer will not fail and he/she will get the receipt whenever the mail service is working properly again.

Summary

The decision of using or not using microservices is going to vary for every company, team and business domain. Thinking cold and establishing what are the advantages and disadvantages that will bring is the best way to start.

Trends are fleeting and whatever today is “top notch” tomorrow is going to suck. A well informed and documented decision is always going to have a good impact.