Indie Developers: Don't Use Microservices

By MzFit

- 5 minutes read - 1018 words

Microservices (mostly) solve organizational problems, not technical problems

It seems like every developer in the last 15 years thinks they need to build a micro services based architecture because that’s how you scale horizontally, just like Amazon, and what if, you know, your app is a really big success and you need to support a lot of users in a hurry?

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

– Amazon (emphasis mine)

Let’s do a little thought experiment. Imagine you’re Amazon. You have tens of thousands of developers. Imagine you have one codebase for the amazon.com web site with tens of thousands of developers all trying to update it.

Progress would grind to a halt. There is no way to support that many hands in the same pie.

Now imagine you have built out an organization with small teams each responsible for relatively independent features. You have a shopping cart team. They build a shopping cart web service or web services. You have a product search team. They build a product search web service or web services. etc. etc.

Don’t trust the idiots

Like most developers, each of these teams thinks they are awesome and everyone else is dumb, so they don’t want to share anything or have those idiots touch their stuff. So they have their own infrastructure. After all, you don’t want a coding error by those shopping cart idiots to use up all the CPU and bring down your perfectly wonderful product search.

In fact, a microservices architecture is just another example of Conway’s Law: that architecture follows the organizational structure that dictates how teams communicate.

Indie Developers: The only idiot is you.

Now, as an indie developer, you don’t have other idiots to blame. You only have yourself. If your product search goes down because your shopping cart ate all the CPU, who fixes it? You do.

But microservices provide isolation, don’t they?

Well… kinda. Time for another thought experiment. Imagine your shopping cart goes down but your product search stays up. You’re still making no sales. Your customers are leaving. Do they care that they were able to search for your products but not buy them? Probably not. In fact, they are probably angry they spent time on your site but weren’t able to check out. A hard failure is often easier to detect. And if users can’t reach your web site, they might just blame their cell service or internet provider instead of you.

But microservices scale better, don’t they?

Not really. I mean, organizationally they scale better because small independent teams can control their own destinies. This is basically how Amazon Web Services was born. The small little internal team can build for one server and the massive traffic of product search can be spread across thousands of servers without either having to get in the other’s business.

What’s the difference between these:

Monolith

Server 1:
Monolith 

Server 2:
Monolith 

Server 3:
Monolith

Notice how you can still scale your monolith horizontally? You just keep adding servers? Or deploy your monolith to serverless. As long as you picked a language with a fast launch time, who cares? (circa 2005 Java on WebSphere with it’s 6 minutes to launch on a Pentium 4, I’m looking at you…)

Microservices

Server 1:         Server 4:
Shopping Cart     Product Search

Server 2:         Server 5:
Shopping Cart     Product Search

Server 3:         Server 6:
Shopping Cart     Product Search

The only meaningful difference to you is that you spent twice as much effort on your infrastructure (and maybe money!), for no real benefit, when you could have been writing code that solves real customer problems for paying customers.

This holds true whether you’re using servers, VM’s, serverless, k8s, or whatever. Twice the codebase means twice the work to define and care for your infrastructure. Duplication of CICD pipelines. And face it, if you decided to build 2 microservices, you’re too clever to stop there, aren’t you? You’re building a dozen of ’em at least. That’s 12x the servers/load balancers/backups/k8s definitions/CICD pipeline definitions, etc. That’s also 12x the number of things that can fail. Don’t believe me? Start adding infrastructure in your head? At what point do you start thinking “that’s too much for one person to manage?” All the pieces start adding up.

What should I do instead?

Solve real problems

Start with a monolith. When you run into real problems with it, then solve those problems. Your batch job running in your monolith is taking up the CPU and ruining the customer experience? Fire up another server to isolate the batch part. One low volume web service call is running long eating your CPU? Performance tune that one service. Or put your monolith on a different server and add routing to send that call only to the monolith dedicated to running that service. Or put it on a bigger VM? Or run the monolith on a serverless cloud offering and route to the serverless for that one call. See all the ways we can solve that problem without needing to incur the overhead of microservices?

If, by solving real problems, you end up with a microservices architecture, great. You probably did the right thing. But don’t sign yourself up from the get-go for a maintenance nightmare.

“Once you have a service established, there is also ongoing maintenance. Keeping dependencies from software and a container/server level up to date might not be too bad for a single service, but when you have many… this overhead adds up!”

[https://www.linkedin.com/pulse/microservices-good-bad-truth-depends-benjamin-cane-mgnmc#:~:text=One%20of%20the%20biggest%20challenges,runbooks%2C%20data%20flows%2C%20etc.](Benjamin Cane, Distinguished Engineer, American Express)

Remember what Einstein almost said:

Make everything as simple as possible, but not simpler.

Remember: 12x microservices does not mean 12x better. It means 12x the number of things that can break. And there is still only one of you. And you most definitely do not scale horizontally.

P.S. This applies to corporate teams, too. It’s ridiculous for a team of 8 to build 20 microservices. Who are they isolating from? Themselves.