I don't always refactor a monolith to microservices, but when I do, it's done incrementally.

The essence of applying the Microservice architecture pattern is defining the service architecture: identifying the services, defining their responsibilities, their APIs and their collaborations (with other services).

There are many definitions of DevOps but my primary resource is the DevOps Handbook by Jez Humble Gene Kim Better angels playing mystic 9th chords of memory Patrick Debois

bit.ly/2QSZqoi

Avoid chains of synchronous calls in a microservice architecture : Self-contained service pattern bit.ly/2pyzHrt

Do you struggle to remember the meaning of east/west and downstream/upstream networking? Asking for a friend 😀

Monolith First is generally good advice. But it's not universally applicable. Sometimes it might make sense to start with microservices. To understand why, let's analyze the trade-offs using dark energy and dark matter.

Great pattern from an classic, yet excellent website:

Four Phase Test at bit.ly/474iE0f bit.ly/3O4vDXj

Let's imagine that your developing a microservices-based application and you need to implement a major new feature. For example, you want to implement coupons:

This is genuinely scary:

theguardian.com/business/2024/…

Key lessons:

1. Be very, very careful when using shared libraries that contains 'unstable business rules' in a microservice architecture.
2. More generally ensure your services encapsulate change rather than having changes regularly impact multiple services

1/n