Команда Medium поделилась своим опытом.

Вначале описан подход Medium в принятии продуктовых и инженерных решений. Вся суть в вопросе «Почему именно сейчас?», отвечая на который выявляют скрытые ограничения.
Затем перечислено семь стратегий Medium перехода к микросервисной архитектуре. В частности, как не подтвергунться такой вещи, как «Microservice Syndromes from Day One»)

https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f

#case

Краткая история о том, как Twitter на Кафку переходил.

https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story.html

#case

Архитектурный шаблон, базирующийся на трех факторах:
1. Realtime GraphQL («Use GraphQL for a very simple and flexible frontend developer workflow.»)
2. Reliable eventing («Remove in-memory state manipulation in your backend APIs and persist them as atomic events instead»)
3. Async serverless («Write business logic as event handlers»)

Основная идея проста и не нова: в коде не должно храниться состояние, в идеале — вообще.
https://3factor.app

#pattern

Концептуальная схема self-healing (самовосстанавливающейся) системы, то есть такой системы, в которой автоматически выявляются аномалии и предпринимаются корректирующие действия.

Например: при отказе железа под кластером перевод на другой кластер, перезапуск хостов, изменение таблиц маршрутизации, расширение канала, остановка или запуск экземпляров сервисов.

Нередко в таких системах корректирующие действия появлятся как результат Chaos Testing на производственной среде.

#pattern

В микросервисных кругах Kubernetes - весьма популярная штука, но, не смотря на высокую надежность, широкую поддержку сообществом и изобилие статей и книг, — он сложен, он развивается и он может подвести, если его неправильно готовить.
По ссылке — множество историй фейлов, связанных с кубером (последняя история так вообще всего лишь двухнедельной давности):
https://github.com/hjacobs/kubernetes-failure-stories

#case