Skip to content

Instantly share code, notes, and snippets.

@joebew42

joebew42/notes-on-when-to-use-microservices-and-when-not-to.md

Created December 8, 2022 16:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save joebew42/c88c878b7b5f52104f02ae3195480ea5 to your computer and use it in GitHub Desktop.
Save joebew42/c88c878b7b5f52104f02ae3195480ea5 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
notes-on-when-to-use-microservices-and-when-not-to.md

Notes on When To Use Microservices (And When Not To!)

🎥 Link to the video

When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020

📚 Cited books

When people should even consider using microservices?

I have actually only heard you complain of people using microservices when they shouldn't have done. - Martin Fowler

People often tend to focus on the tech tool (the output), not the thing the tech tool let's you do (the outcome).

Going microservices should be a conscious choice that you have made because of some outcomes you are looking for, because of some benefits that such architecture can give you.

Good to ask: What is the benefit is going to give to you?

Example of benefits:

  • More options to scale up the applications
  • Independent deployability
  • Limit the "Blast Radius" failures

When adopting microservices you always buy options. This means that all the advantanges you get comes with a cost!

The default option should be to not use microservices unless you have a very good reason.

Why?

  • Microservices are not an ON/OFF switch
  • Microservices are distributed systems, and they are hard

If you ever consider to try out microservices, don't spend months on deciding which platform to use. Just go with one and see what happens.

Top 3 reasons why adopting microservices:

  • Zero-downtime independent deployability.
  • Isolate the data and its processing (example: GDPR).
  • Enable an high-degree of organizational autonomy (distribute responsabilities into teams and reduce the amount of coordination needed between teams).

One of the major pitfalls of adopting microservices is ending up with a distributed monolith: when the deployment of a service is dependant on another. "I need to deploy this service before you can deploy your service."

How to avoid distributed monolith?

  • Create a deployment mechanism (don't bundle deployment of different services together)
  • Look for recurring patterns (look for services that changes together)
  • Information hiding (expose API, not data)

Why strive for independent deployability if we are just fine with a monolith?

  • Easier to limit the impact of each release
  • Time to release
  • Reduce the scope of the change (one team one codebase vs multiple teams one codebase)

Organization and teams

We already have team and responsibilities boundaries within a monolith architecture, using modules, but they are often violated. Breaking modules into services makes it hard to violate.

Handling data

  • Data is hard.
  • A lot of complexity of breaking complex systems lies in the data.
  • After extracting a microservice you need to understand what part of the old database will be used.

Handling people is far more complicated than handling data

  • There has to be a willingness to change as an organization if you want to make the most out of using microservices.
  • Microservices will very rarely save you money. They might help you make more money.
  • Going microservices it doesn't have to be overnight.
  • Rather than tech, it's more about how much degree of responsibilities and freedom we want each team to have. What kind of organization we want to be?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment