I want to argue that you should build your product on microservices; not because of technical reasons, but because you should see it as a team management strategy.

The Double-Edged Sword of Microservices

Let’s zoom out and first remember what a microservice is. A microservice is basically a small, deployable piece of service that, when meshed together with others, forms a larger application. If you’re already working with microservices or even if you haven’t built any so far, you’ve probably heard about it.

If an application has dozens, maybe hundreds of microservices, it means you need some kind of orchestration. What does that mean? Once you have hundreds of small applications instead of one large one, you now need to monitor all of them. This creates overhead. Each will have its own CI/CD system. Each will have its own lifecycle. You need to orchestrate all of them—and that creates huge overhead.

Meanwhile, this overhead and these downsides can also be upsides.

If each microservice is deployable and has its own lifecycle, it means they are independently deployable. They can be scaled up without scaling the other microservices. If you want to scale up one part of the product or scale down another part, you can do it without dealing with the rest of the product.

It’s Really About Team Management

This is exactly where team dynamics come into play. Since you have separate parts that can be deployed separately, you can assign responsibility to different people/teams.

Let’s use an example: You have an application. It’s Friday afternoon and your payment system fails. If this is a monolithic application with a search engine, recommendation engine, authentication service, and hundreds of moving parts, even though you have a problem only in the payment system, you have to fix it and deploy this huge product.

But look at this from another perspective. If this application is based on a microservices architecture, you can just fix the specific part and deploy it without being blocked or blocking others. If there’s downtime during the payment process, only one part of the product will have downtime, not the whole application. Maybe users can still authenticate and use the product—they just won’t be able to use the payment system until you fix the problem.

Now you have a payment team, and you’re asking the payment team to fix the payment problem in the payment service.

Do you know Conway’s Law? Basically, Conway’s Law tells us that systems built in an organization reflect the organization’s communication structure. If there’s a flat organizational structure, then the systems they build will be flatter.

By using microservices architecture, we’re doing the opposite. We’re building the system, thereby changing the organization’s communication structure. Now you have separate deployable units, separate microservices, and different teams responsible for these different services. This time you’re building small teams in the organization.

These small teams will communicate with each other. Teams will still have communication (for example, authentication might communicate with the recommendation engine) but it’s separated. There’s only one thin line from the authentication system to the recommendation system. They’re dependent on each other, but not in a way that makes them fully dependent, they can still operate without being blocked.

When It Actually Makes Sense (And When It Doesn’t)

If your product is large – I’m not talking about a product with only thousands or millions of records in the database, I’m talking about a large product with billions of records, thousands of users, and maybe dozens of engineers, not a team with three people – then you want team members to act freely.

So what you do is: divide and conquer. You divide the team into separate parts. Each team takes responsibility for some microservices and then takes action on those microservices.

Here is my point: You should not build microservices just because it’s sexy, just because it’s trendy. You should use microservices if you want to manage your teams and organization in that way.

Unfortunately, I see organizations with 3-5 people on the team and they are trying to build microservices, they are just creating overhead for themselves.

This rule of thumb applies to 95% of companies with small teams. These small companies don’t need to use microservices. I also think there are unique cases where there’s good justification to use microservices even when the team size is small, maybe the team size is very small but the product is huge.

Next time someone on your team says, “Hey, let’s just build microservices,” and if your team size is small, just stop and ask these questions:

  • Do we really need it?
  • Are we blocking each other?
  • What’s the justification to switch to microservices?
  • Is it worth the overhead?

I believe once you answer these questions, you’ll figure out whether you really need microservices or not.

Watch the Video

I also shared this perspective on microservices in video format. You can watch it here: