Команда 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

Техника... монолитизации — объединения сервисов в монолит.
Статья про Oat++, web-фрейморк для C++, так что и речь идет о нем, но в целом техника не зависит от языка.

Когда рекомендуют применять:
• Низкая нагрузка
• Отсутствие потребности в масштабировании

Заявленные выгоды:
• Снижение уровня потребления памяти
• Снижение затрат на инфраструктуру за счет сокращения нагрузки на сеть

Идея интересная, но я вижу такие риски:
• Когда потребуется масштабирование, команда и инфраструктура могут оказаться не готовы за счет отсутствия опыта развития и управления распределенной системой
• Усложняется тестирование, — есть автономные сервисы и к ним в довесок виртуальный монолит
• По описанию выглядит так, что для выделения сервиса из виртуального монолита требуется полная пересборка с измененным Monolith Config — не самый повторяемый и надежный процесс

При этом выгоды сомнительны, разве что если сервисы очень «говорливы», а сообщения достаточно объемны.

Поделитесь идеями, где можно применить (без привязки к фреймворку). Как минимум — подход не обычный.

https://oatpp.io/docs/monolithization/

#pattern

Так выглядит микросервисная архитектура PayPal.

#case

Список open source инструментов для микросервисов
(со ссылками на сайты, репозитории с исходниками и лицензиями)

Контейнеры: rkt, Docker, FreeBSD Jail, LXC, OpenVZ
Оркестраторы контейнеров: Kubernetes, OpenShift, Nomad, LXD
API Gateways: 3scale, API Umbrella, Apigee, Apiman, DreamFactory, Fusio, Gravitee, Kong, KrakenD, Tyk
CI/CD: Jenkins, GitLab, Buildbot, Concourse, GoCD, Hudson, Spinnaker
Балансировщики: HAProxy, Apache modules, Balance, Distributor, GitHub Load Balancer (GLB) Director, Neutrino, OpenLoBa, Pen, Seesaw, Synapse, Traefik
Service registry/discovery: Baker Street, Consul, etcd, Registrator, Serf, ZooKeeper
Мониторинг: OpenNMS, Grafana, Graphite, Icinga, InfluxDB, LibreNMS, Naemon, Nagios, ntop, ELK, Prometheus, Sensu, Zabbix, Zenoss

Роль Enteprise Architect сегодня

Статья просто и понятно объясняет изменения роли EA. Актуально для микросервисного стиля, как для частного случая.

В начале статьи автор рассказывает небольшую историю и задает контекст
- Команды стали автономнее
- Команды могут принимать серьезные инженерные решения (делегирование решений в команды)
- Команды стали изолированнее, знания в большей степени накапливаются в командах

Основываясь на своих наблюдениях автор пришел в выводу, что в современном мире EA должен:

Продолжать разработку
- Потратить немного времени на то, чтобы разобраться, как работает та или иная технология
- Писать код, распространяющий основные архитектурные идеи и помогающий развиваться разработчикам в компании
- Работать в паре с разработчиками из различных команд, чтобы не терять связь с землей
При этом он не часть команды, поэтому вклад в скорость команды не делает, что разумно.

Обеспечивать простой доступ к архитектуре каждому заинтересованному в ней
- Управление архитектурной базой знаний таким образом, чтобы каждый мог получить нужную информацию в нужное время
- Особенно о том, что уже реализовано и реализуется, чтобы не решать задачу дважды, трижды
- Пример из статьи — подготовить постер с архитектурой и раздать каждой команде, пусть висит на стене на видном месте, его сложнее игнорировать, чем wiki-страничку

Выстраивать мосты между командами
- Команды становятся изолированными друг от друга за счет своей автономности, архитектор за счет парной работы с членами команд может найти наилучших кандидатов для выстраивания мостов между командами
- И снова, за счет плотной работы с командами, архитектор может обнаружить команды, решающие похожие задачи и выстроить мостик вокруг этих задач
- Обнаружить разработчиков, у которых горят глаза от определенных технологий, платформ и помочь им в обучении других людей
- Собирать мнения команд о степени доступности, понятности и полезности архитектурной базы знаний и улучшать её на основе этих мнений

Таким образом цели и отвественность остаются теми же, что и раньше, но подход к работе меняется. И такой подход ведет к эволюционному развитию архитектуры в направлениях, о которых и подумать было сложно.

Titan — Data as a Code проект с открытым исходным кодом

Официальное описание:
«Titan's git-like CLI enables developers to clone, commit, checkout, push, and pull data just like code, making it easy to rollback to a previous state, build a test data library, or share a structured dataset with collaborators.»

Мы все ближе к Everything as a Code 🙂

#tools

Ода языку Go, микросервисы для Enterprise 🙂

Go преподносится как язык следующего поколяния для Entperprise-компаний.
На Go написаны Docker, etcd, Kubernetes, Terraform и istio; его используют такие компании как google, apple, dropbox, bbc, the economist, the new york times, ibm, twitter, facebook.

Go активно поддерживается Google, а его авторы активно участвовали в жизни C, Unix и JVM и него обширное и сильное сообщество (Gophers).

Далее приводится еще несколько преимуществ:
- Отличная реализация Concurrency
- Кросс-платформенность
- Garbage Collection
- Статическая типизация
- Приведена сравнительная таблица Go vs Java

В завершении примеры кода для реализации слоя контроллеров, слоя логирования, инит тестов, моков, реализации OAuth.

Сравнение SOA и микросервисов от pwc.

Похоже, что pwc брали не академически-теоретический идеальный SOA из учебников, а среднестатистическую реализацию. А вот для микросервисов взяли эталон. Оно и понятно, это базовые свойства микросервисов и среднестатистически близкие к эталону реализации встречаются чаще просто потому, что иначе их совершенно невозможно поддерживать и развивать.

#common

Язык, редактор и инфраструктура — три в одном.

Речь о языке Dark.
Основная идея выражена во фразе «Speed of developer iteration is the single most important factor in how quickly a technology company can move».
Интересно как минимум ознакомиться с видео на сайте и статьями в блоге. Пока тенденция слабая, но все больше появляется языков со встроенными механизмами снижения инфраструктурной сложности (другой пример — ballerina.io), присущей микросервисным решениям.

В настоящий момент Dark находится в beta-тестировании.

В международном сообществе язык, а точнее — концепция подобных языков, активно обсуждается и полагаю, что в ближайшее время мы увидим больше подобных решений.

#tools

​​Пример организации пакетов при использовании DDD

Из примера видно, что одна команда может владеть несколькими сервисами, но вот несколько команд одним сервисом — уже нет. На каждом из уровней полная изолция по горизонтали. Домены и/или контексты могут общаться только либо через четко определенный интерфейс, либо через Anti Corruption Layer.