This was the most enjoyable technical book I've ever read. Though I haven't read many technical books. What fascinates me about microservices is the fact that mastery is attainable. There is a lot of upfront work required to develop a robust chassis and an accompanying deployment/monitoring/authentication/etc pipeline, but the benefit is that, for less critical applications, you can start small and worry about adding the rest later. Maybe way later. Microservices are fun and approachable to build from scratch, and, though many practitioners are more likely to be tearing down a monolith and thus be facing immense pressure from the get-go, I hope that they one day can experience building a webservice ecosystem from the ground up without inflated expectations. It is an adventure in big picture problem solving combined with thinking critically about business requirements that might not exist yet.

Over the last few months, I have become increasingly involved with the fledgling services department at work. Many times, while improving the chassis or building new services I have paused and let my curiosity get the best of me. Who is doing this better? What's the ideal approach? Should I be rolling my own _____? When picking up this book, I was at least vaguely familiar with each topic, and my takeaway is that Sam Newman has done it all a great justice. In the span of 280 pages, he's succinctly evangelized this new approach and provided a solid reference and overview. I am much better prepared to tackle the challenges I face on a daily basis.

While some may be concerned about lack of depth, I think that for many of the technologies covered it would have been plain silly to keep going. No, reading the overviews aren't going to make you an expert. But, the standards can change so fast and the book contains so little fluff that it makes sense for it to have been constructed this way. For this reason, the book has staying power even as the surrounding technologies morph and evolve.

There are many pain points surrounding developing microservices. Some will be business domain specific. While they may be glossed over at times, the big picture provided in the book is still realistic. The examples given--namely Netflix--are examples of perfect, ideal, industry-leading architecture. It's a standard to strive for but that level of expertise is not required from the start. Does a team of 5 have the resources to emulate the world-class? You can certainly try, and, realistically, I think that reaching an elite tier of competence and function is attainable.

Whether you are familiar with microservices, suspect you may be in a position to implement microservices, need to learn microservices by tomorrow, or are just looking for a fun technical book to read- your search should end here.

See this review and others on my blog

Книга понравилось и уверен в ее пользе для меня.
Если в двух словах - рекомендации по построению архитектуры больших и сложных систем, чтобы избежать головных болей в дальнейшем :)
Никакого кода - только обсуждение проблем, способов их решения и преимущества/недостатки таких решений.
Краткий перечень тем: Мониторинг, логирование, аутентификация, авторизация, возможность расширения системы, тестирование, деплоймент и другие темы.
Остался очень доволен.

IMO a MUST-READ for software engineers working with microservices.

The book is a very good introductory book about all aspects of micro services. The point of the book as said by the author is more of letting you decide if microservice fits your needs, not necessarily hand holding you to transition to micro services step by step. It covers so many aspects so it does not go into details for any of them, but on each topic, the author usually provides examples or other resources for further reading.

Great primer for microservices, but also for backend engineering. It goes into details but not too many details, and provides references for further reading if you want to go deeper into specific topics. The chapter breakdown makes the book easy to follow, with illustrations that quickly bring to life some harder-to-picture explanations.

As someone who is not a backend engineer, I recommend this book if you are interested in learning more about what goes on in the world of microservices.

Covers a wide amount of information on where microservices are needed and how to build them. Useful for all the references to other technical books and libraries. First technical audiobook I've ever tried, it worked out well I think!

This book provides a reasonable quick overview of the microservices idea with pointers to technologies and ideas that will be necessary for implementation.

I never knew reading about microservices could be so exciting! This book offers a comprehensive look in nicely condensed form and reading never gets tedious.

Excellent reading and highly recommended.

This is a very good book for the domain it covers. It provides breadth into several different topics: independent deployability, API gateways, streaming, distributed transactions (sagas, two-phase commits), builds, deployments and security etc.

It summarised the business goal of microservices well: they don't reduce costs but can increase profits (microservice tax). The other goal of a microservice is to have as small an interface as possible (although size cannot be prescribed).

Independent deployability is the goal of microservices - a team should be able to have end-to-end ownership of business functionality to make changes more efficient. This involves encapsulating UI, business logic and data. This reduces effort to change business functionality and coupling of systems. Note that the goal is not high cohesion of technical functionality.

It mentions things that have since become common knowledge:
* Sharing databases is one of the worst things you can do if you wish to achieve independent deployability (unless the same team owns the systems sharing it).
* API Gateways have a tendency to become bloated with logic that belongs in code
* Avoid distributed transactions entirely if possible (even sagas), and never do 2PC due to latency and coupling.
* Client SDKs can unnecessarily couple systems and can be avoided in most cases.
* Only one artifact needs to be built and uploaded since this confirms that the artifact we deploy is the one we tested.

The section on builds was probably the highlight. Especially when it talks about how just because you may use continuous integration (CI) tools (e.g. Gitlab CI or CircleCI), it doesn't mean you are doing CI. The main questions to ask if you are doing CI or not:

(1) Do you check into mainline once per day? The less frequent, the harder future integrations become,
(2) Do you have a suite of tests to validate your changes and
(3) When the build is broken, is it top priority to fix it?

Other key points from this section:
* DORA found that merging code into mainline on a daily basis contributed to higher performance.
* Continuous deployment != continuous delivery. Continuous delivery has manual steps to verify changes even though each artifact is treated as a release candidate. Continuous deployment means that whatever is merged goes through the stages to production automatically.
* Stages of a pipeline should be (from fastest and least-prod-like to slowest and most-prod-like): local (compile and fast tests), prod-like (slow tests), performance tests and production.
* People often do smoke tests in production because of the challenges in creating a production-like environment.
* Environment-based config should live outside of the artifact itself.
* Monorepos makes more sense when org is small vs polyrepos at larger scale. It is easier to make this shift early on or the migration becomes hard. A CODEOWNERS file should be required if there is a monorepo with > 20 developers. Google's scale is different and even Microsoft created a dedicated VFS to deal with scale issues.

The section on deployments discusses how database load should be split (all writes going to a primary with other nodes designed for read-only - the latter is easier to scale). It also helped the value-add of virtualisation finally click for me rather than just dedicated servers (although Docker opened my eyes to this, it didn't fully click). The other main part here was how Kubernetes/Nomad provide Desired State Management out-of-the-box (to handle pod failures).

The section on security is interesting, one of the key highlights is knowing when to use TLS in your system vs mTLS (a user just needs TLS, but backend services in an ecosystem need mTLS). It explains the over-use of JWTs and discusses other examples, and their pros and cons.

Good visuals...old concepts