Notes on microservices

Notes on microservices pattern made after reading Building Microservices by Sam Newman.

The need to change our system to deal with scale isn't a sign of failure. It is a sign of success.

Building Microservices by Sam Newman

What is microservice

Modern application architecture

Microservice can be rewrote in 2 weeks or less (Jon Eaves).

Every microservice inside application infrastructure may be wrote in language that most suitable for the problem the microservice solving, use libraries and instruments it needs even if other microservices use another.

Small team (see Two-pizza teams) can own one small microservice. Small teams works with small codebase are more efficient and can be easily distributed across the globe.

Microservices allows us to deliver new features faster. Although deploy and infrastructure may be a bit more sophisticated comparatively to solid application.
Microservices allows us to use resources more efficiently, manage them more agile.

How to share code between microservices:

  1. Create packages (add them to requirements and install using pip, npm, etc.)
  2. Copy/paste sometimes also acceptable (be relaxed about violating DRY across all services)

Microservices is for organizations where developers have a lot of freedom.

It's possible that to start from monolithic application is better idea than to use microservices, and if we will need it in future: see quote in the beginning.

Other

Single Responsibility Principle (Robert C. Martin): Gather together those things that change for the same reason, and separate those things that change for different reasons.

The Twelve Factors by Heroku.

Orchestration vs Choreography:

Postel's Law (robustness principle): Be conservative in what you do, be liberal in what you accept from others (about communication between services).

Semantic versioning (major.minor.patch):

Two-pizza teams by Amazon: no team should be so big that it could not be fed with two pizzas.

Google goes beyond simple tests to mimic server failure (include DiRT - Disaster Recovery Test, annually).
Netflix runs programs that cause failures on daily basis (Chaos Monkey, Chaos Gorilla).

Nice idea is to temporary disconnect service if it start producing enormous number of errors.

What's else in the book

See AWS Lambda.

Licensed under CC BY-SA 3.0