Every piece of software comes with Terms and Conditions.

Nobody reads them.

They click Accept, install the software, and only discover six months later that it runs slower, costs more, and wants permission to everything.

I sometimes think companies adopt microservices the same way.

No one reads the terms

People install software all the time, but almost nobody reads the Terms and Conditions. If one of them said, “By installing this software you agree to give me half your paycheck and accept that your computer will run slower,” you’d probably notice eventually—but only after clicking Accept.

Companies adopt microservices the same way.

There has been a fever over the last decade. Somewhere along the way, “Should we use microservices?” quietly became “Of course we’re using microservices.” That sounds so lovely. But have you thought of what the terms and conditions are? I decided to make a small list that every CTO must sign before embarking on this trek. So without further ado, here is:

The microservices Terms and Conditions

By adopting microservices I __________ (the decider) understand that:

• I acknowledge that every method call I replace with an HTTP request will become a network call that is orders of magnitude slower and capable of failing in entirely new and exciting ways.
• I acknowledge that debugging one request may now involve reading logs and traces from six different services instead of one process.
• I understand that grep is no longer a debugging strategy. I agree to purchase distributed tracing software and spend several weeks learning how to use it
• I understand that SQL databases spent forty years becoming exceptionally good at joining data.
  • I further acknowledge that I will voluntarily throw this capability away.
  • If I wish to display a customer’s name next to an order, I agree to either:
    • call another service,
    • duplicate the customer data,
    • maintain a cache,
    • build an event replication pipeline,
    • or invent yet another read model.
  • I also acknowledge that I will eventually ask myself why I no longer have joins.
• Transactions
  • I understand that @Transactional was nice while it lasted.
  • I acknowledge that distributed transactions are no longer my database’s problem.
  • They are now my problem.
• Every service now needs authentication, authorization, secrets management, certificate rotation, monitoring, and rate limiting.
• I acknowledge that API versioning is now forever.
• Coordination: you have a young app and you want to change some business logic. Before you had to change one app, that took one day. Now you have to change 3 - 8 apps. It takes a sprint or two due to coordination. Remember Conway’s law. Your code probably mirrors your org.

Notice what’s happening here.

Microservices don’t eliminate complexity. They relocate it.

The database used to solve joins, transactions and consistency. Now your application, infrastructure, and engineering organization solve those problems instead.

What they are good for:

Hey I am not a hater. I think microservices are very valuable. For companies with hundreds of engineers, dozens of teams, and enormous infrastructure costs, these tradeoffs can absolutely be worth it.

If you are going to go hiking in the park there is no reason to buy Everest level equipment. No one thinks of getting an F1 race car as their first vehicle. And yet many businesses do exactly that by adopting microservices.

Free fact

If your infrastructure bill isn’t keeping your CFO awake at night, microservices are probably solving tomorrow’s problem with today’s engineering budget.

Write me an essay:

Before approving a microservices initiative, every CTO should submit a one-page essay answering three questions:

1. What business problem does this solve today?
2. Why can’t a modular monolith solve it?
3. How much extra engineering time will this architecture cost over the next five years?

If you can’t answer those questions, you’re probably buying Everest gear for a walk around the neighborhood.