You don’t need microservices

In this post, I’ll show you that maybe you are choosing microservices for the wrong reasons.

I published a video about it. Check it out:

If you are here probably you are in one of these situations:

1. You want to start using microservices
2. You are already using it

In both cases, you want to use it right and for the right reasons. At least I hope so…

When I go to conferences is common that people ask me about “how to start using microservices?“, “what are the best practices?“, and so on… and I always ask them the same question: “why do you want to use microservices?“.

The usual answers that I got are:

• To scale my application
• To have smaller artifacts
• To save memory (what?)

I even got an answer from a big company where people said: “because our manager demanded it“… Ouch!

Let me tell you: all those answers are conceptually wrong! And the reason is:

You are using microservices to scale software, but it was made to scale people.

At this point, maybe you are uncomfortable on your chair, you are frowning, your disagreeing, or even you are mad at me! 

I get it… give me a few minutes and I’ll explain it to you! 😉

The reason why I’m saying that microservices are made to scale people is a foundation. A concept. A law. Something called “Conway’s Law”. It states that:

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

This was said by Mr. Melvin Conway in a paper written in… 1967! The link to the paper is at the end of this post.

Basically what Mr. Conway is saying is that the structure of your software is directly related to the communication structure of your organization. The way your company communicates is the way that it builds software.

But… how Melvin Conway came to this conclusion?

(I know, you are wondering what the hell all this has to do with microservices? You will get it, I promise…)

In this paper, he mentions a project where the team had 8 people and they needed to deliver two compilers: one for COBOL and another for ALGOL. After some discussions, they decided to assign 5 people for the COBOL compiler and 3 people for the ALGOL compiler.

At the end of the project they had: 

• A COBOL compiler that worked in 5 phases
• An ALGOL compiler that worked in 3 phases

In the paper, you’ll see more examples of this human behavior when building software.

So basically it was a sociological observation that ended in a technological result. Interesting, right?

Alright, back to microservices! What does it have to do with Conway’s Law?

Let’s perform a mental exercise. 

Imagine that one company has 3 teams:

• DBA team
• UI team
• Middleware team

Those teams are organized around themselves. DBAs working together, UI people as well, and so on…

Then let me ask you three questions:

• What the DBA team will deliver?
• What the UI team will deliver?
• What the Middleware team will deliver?

It’s quite obvious! DBAs will deliver databases, UI people will deliver UI, and Middleware devs will deliver services, APIs, and things like this.

This is called a siloed structure and it’s the classical structure used for companies that build monolith applications.

Now let’s imagine another company. It also has 3 teams, but they are structurally quite differently:

• Team 1 has a DBA, a UI dev and a Middleware dev;
• Team 2 has also a DBA, a UI dev and a Middleware dev;
• Team 3, guess what, also has a DBA, a UI dev, and a Middleware dev.

These are what we call cross-functional teams.

Now the one and only question for this company: what each team will deliver?

The tendency of each one of these teams is to deliver what we call a self-contained application. A deliverable that has a database, a UI, and a Middleware.

Can this deliverable be considered a monolith? Well, yes. But a very small one, because the team that built it is smaller.

If it’s smaller, it needs to be more specific, more specialized. It addresses one business task that has interactions with the other business tasks built by the other teams.

That’s the so-called… microservices!

This concept of siloed and cross-functional teams that led us from monoliths to microservices is very well explored in the famous article about microservices written by Martin Fowler. 

In fact, this article is so important that a lot of people include it in the history of microservices. The link to the article is at the end of this post.

Ok! So far you know:

• Conway’s Law
• Companies’ communication structure reflects the structure of their software
• Siloed structured companies tend to deliver monoliths
• Cross-functional companies tend to deliver microservices

After all… why did I say that you can be thinking about microservices for the wrong reasons?

Because another thing that I also said: microservices is something made to scale people, not software.

If you look to the companies who are well succeeded using microservices (Amazon, Netflix, Uber, Spotify, to name a few), what they have in common?

When they started getting really big they noticed they had a need of:

1. To scale their team management
2. To do it without loose agility (increasing it, actually)

So they came to the conclusion that they needed smaller and self-managed teams. 

And for those teams to have more agility, they needed to be as decoupled as possible from the other teams, for the sake of independence.

So these teams needed to be cross-functional and empowered enough to make their own decisions related to technology (languages, databases, etc).

(And yes, decoupled teams tend to generate decoupled services! Conway’s Law again…)

And suddenly it was born: the microservices!

Notice that all start with a *need*. A need to rearrange the company structure, a need to distribute the teams, a need to increase communication agility. 

In this scenario, microservices are inevitable. And if you don’t have any of these needs, you don’t need microservices as well.

Alright? I hope I’ve made my point clear here, and I’m looking forward to seeing your comments about it, so do not hesitate to leave them down below.

References:

• http://www.melconway.com/Home/Committees_Paper.html
• https://martinfowler.com/articles/microservices.html