You probably don’t need microservices

This blog post was fun to write. It'll most likely be hated by many, but… 

Dear fellow developers, we need to talk. We need to talk about microservices and some situations that are not OK. It won't be easy, but we need to do it. Or we are not gonna to make it.

Microservices are very popular nowadays. It's a great architectural style that helps to scale the system and the organization. Many successful companies use microservices (e.g. Netflix, Spotify, etc). Therefore, it's normal that most companies are using or planning to use it. But some miss the added costs it brings.

Before diving in, let me talk about my experience with microservices.

How it started - Is it microservices?

In 2012, in the company I was working at, we were presented with a challenge: how to grow the company to thousands of engineers and 1000x more transactions. This post isn’t focused on the hiring, onboarding, etc, but on the architecture.

I was reading Scalability Rules: 50 Principles for Scaling Web Sites at the time, and the book introduced the AKF Scale Cube.

I found it incredibly easy to understand. So I used it to explain to others why we needed different binaries running in production. The traffic pattern for the Search module was completely different from the traffic pattern for the Shopping Cart module. It made sense to split these components. Additionally, it would allow us to have multiple teams working independently and autonomously. That would help us with the challenge of growing the company to thousands of engineers.

We didn’t call it microservices at the time, just services. The term microservices wasn't on our radar. We made a lot of mistakes along the way. But we made a decision based on our problem and, looking back, it was a good decision.

So, you now know that I’m kind of familiar with the topic and I have scars from implementing a lot of services and doing a lot of re-architectures over these 10+ years.

So, what’s wrong?

There is nothing wrong with microservices per se. And there is nothing wrong with monoliths as well. But our industry seems to have forgotten that there is no silver bullet. And sometimes, there are bullets that can actually hurt you. Don’t believe me? Let me walk you through some examples.

Example 1 - You get a service, and you get a service, you all get a service

I like to have conversations with other folks in the industry to understand what they are doing and share some of my experiences. These conversations are a great way to grow your network and get insights from very smart people.

I remember one in particular with two Directors of Engineering at a startup with around 200 people in the technology department. Incredible folks, very smart, and easy to talk to. 

I usually like to dig in on the technology spectrum and understand what the company is doing and what are the main challenges. So, with no surprise, I asked if they could tell me more about the architecture and how teams were organized. 

One of the folks told me they were using microservices with a complex system in production. Then said that they had around 350 microservices running in production. The biggest challenge, they said, was to ensure all those microservices were maintained - outdated dependencies, outdated runtime versions, no know-how on the internals of some of the services, etc.

The company had more microservices than developers. In product-focused companies that deliver many features for the clients, it's hard to keep up with all these microservices.

Example 2 - You change, I change, we all change

Low coupling and high cohesion are hard to get right. It gets even harder to get it right in a microservices architecture. You may end up with very small microservices (also called nanoservices) that are tightly coupled and with low cohesion.

I remember one situation in a previous company where a “bounded context” had so many little services that any change required many teams to work together to deliver it. And even worse, the performance was awful.

This example is very good because, on top of that, the teams wanted to create another service to aggregate all the information to improve performance. The idea of merging little services to have more cohesion was considered bad because it, and I quote, "looked like a monolith”.

Example 3 - Everything was fine, until it wasn’t

With all the layoffs happening in tech, one thing I’m hearing more and more is companies having too many services after deep cuts.

This may not be a fair example because, who would guess that companies would start cutting 40 or 60% of their tech department, right? The thing is, simplicity is one of the hardest things in our industry. But we should aim to keep things as simple as possible, but not simpler.

Companies with simple systems in production have more agility. They can cut costs and reduce personnel without worrying too much about the operational overhead.

Example 4 - Let’s start our startup using microservices

This will be the final example, I promise. This is actually from a talk that I’m struggling to find - please comment if you know which talk I’m referring to so I can give proper credit. 

Greenfield projects are amazing, right? It’s like an empty canvas waiting for the creative artist to start drawing. In this case, the artist chose to have a colorful painting. The artist picked up all the main colors, Ruby, Golang, and Java. Mixed them with some Postgresql, Elasticsearch, and Cassandra. 

The painting? It could have been a Picasso if they could find the time to finish it. 

Is it always bad?

I’m not saying it's bad. I believe Jet.com actually started out using microservices and it had a great exit to Walmart. I’m just saying we, as engineers, need to have critical thinking and choose what is best.

Ok, but why?

Some people are reading this and thinking, “it's a skill issue”. Well, it's not. In the first two examples, I know the people involved. They are really smart, great engineers. I’m sure the people in the other examples are really smart as well. 

I think there is a deeper reason and Scott Hanner gives a good plausible one in this tweet:

We may have internalized microservices. Maybe that is the reason why we see so many small teams adopting microservices. It is deeply in our brain this way of thinking.

Zero interest-rate policy (ZIRP) may be also to blame. In this tweet, DHH talks about it.

I tend to agree with DHH, ZIRP probably has contributed to the phenomenon. Companies wanted to grow and hiring a lot of developers was a standard go-to option for most companies.

In a post-ZIRP era, I expect people to be more aware of the hidden costs of microservices. Management will probably be more reluctant to adopt it, even when it is a good solution for the problem at hand.

You still have time

If any of the examples above reflects your reality, don’t worry. The good thing about software is that you can - almost - always change it. If you see it as a problem, try to replace the word problem with opportunity instead - like the joke, I have a drinking opportunity.

Are you in a position where the number of services is affecting your ability to innovate? Create a strategy on how your company can reduce the operational overhead. Maybe you can relax on the reliability or maybe you can invest in simplifying the system architecture to have more capacity to innovate in the future.

The teams in example 2 did that. They presented a strategy to merge the services focused on cost savings and better customer experience. The stakeholders were very pleased.

Are you starting a company? If you are starting a company and considering using microservices, write a design doc explaining what challenges, why microservices, and the alternatives you have considered. If you have someone you trust, share that design doc and ask them for feedback - if you can legally do it (!). It may help clean your thoughts and clearly understand if microservices is the right architectural style for your startup.

Microservices are great, but they add complexity to your system and organization. The ways of working change, the architecture becomes more complex, and if you’re migrating from monolith to microservices understand it will take years. You need to wait before rushing into microservices, step back, and think about how they are going to help you and hurt you… 

And believe, it will do both. It will hurt you and please you, even when it is the best architectural style. Just like every good thing in life.

So, dear developers, I started this conversation because I care. I care about the future of our industry. I want a long-lasting, enduring, and sustainable industry that builds software that is resilient to time. I want an industry where we make pragmatic decisions and use technology as a means, not an end.

Sometimes microservices are great… but you probably don’t need microservices.