Building Microservices

Is an excellent book by Sam Newman. As usual I'm going to quote from a few pages...

Because microservices are primarily modeled around business domains, they avoid the problems of traditional tiered architectures.

Microservices should cleanly align to bounded contexts.

Another reason to prefer the nested approach could be to chunk up your architecture to simplify testing.

With an event-based collaboration, we invert things. Instead of a client initiating requests asking for things to be done, it instead says this thing happened and expects other parties to know what to do. We never tell anyone else what to do.

We always want to maintain the ability to release microservices independenty of each other.

A red build means the last change possibly did not intergrate. You need to stop all further check-ins that aren't involved in fixing the build to get it passing again.

The approach I prefer is to have a single CI build per microservice, to allow us to quickly make and validate a change prior to deployment into production.

No changes are ever made to a running server.

Rather than using a package manager like debs or RPMs, all software is installed as independent Docker apps, each running in its own container.

Flaky tests are the enemy. When they fail, they don't tell us much... A test suite with flaky tests can become a victim of what Diane Vaughan calls the normalization of deviance - the idea that over time we can become so accustomed to things being wrong that we start to accept them as being normal and not a problem.

All too often, the approach of accepting multiple services being deployed together drifts into a situation where services become coupled.

Most organizations that I see spending time creating functional test suites often expend little or no effort at all on better monitoring or recovering from failure.