У микросервисов есть несомненные преимущества. Однако, как когда-то Scrum, микросервисы поддаются все большей компрометации от бездумного внедрения.

Например, кто-то услышал, что микросервисы - это автономные команды, автономная поставка. Это, действительно, так, однако беда случается тогда, когда решение перейти на микросервисы становится политическим, а не продиктованным потребностью бизнеса с четкой оценкой все требуемых изменений в архитектуре, орг. структуре, процессах, инфраструктуре.

И тут начинается самое интересное. Оказывается, что отсутствует хотя бы гигиенический минимум инженерных практик и процессов, все тестирование ручное, все развертывание ручное, разработчики работают по четкому тз и не особо погружены в предметную область...ну то есть все как-то работает и даже вроде неплохо, и фичи выпускаются «быстро» и продукт зарабатывает.

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

Но задачи выполняются. И в таком «типа скраме» звучит «нам нужны микрсоервисы».
Нет. Не нужны.
Для начала нужны простые вещи:
1. Визуализация потока создания технологической ценности (то, что станет delivery pipeline)
2. Выявление потерь в этом потоке
3. Готовность к устранению этих потерь (это может привести и к политике работы с help desk и процессам взаимодействия с безой и инвестициям в обучение/автоматизацию тестирования)
4. Обложить все что можно телеметрией. Иначе мы даже эффект от перехода на микросервисы не оценим.
5. Сделать систему разработки предсказуемой и надежной. Так, чтобы планировать было можно и выполнять работу без постоянных переработок. Для этого существует исчерпывающий набор практик на сокращение объемов незапланированной работы (в том числе вносящей серьезный вклад в неопределенность).

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

И вот, когда разработчики перестанут уходить, когда все поймут, что это не потогонка в погоне на индивидуальным KPI на внедрение микросервисов, тогда можно переходить.

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

В поддержку прерыдущего поста лишь небольшой список недостастков микросервисов в сравнении с монолитом от участников моих курсов (ничего не додумывал, большинство кейсов связаны с попыткой резкого перехода на MSA). Обратите внимание, что немало недостатков таковыми не являются в сильной DevOps-культуре, однако и в области проектирования явно наблюдается skill gap, требующий повышения навыков (может потому, что микросервисы — это архитектурный стиль, а не «практика разработки?» 🙂 ):

Сложность управления и мониторинга транзакций
Сложность сопровождения
Сложность проектирования
Сложный вход, так как толстый технологический стек
Дублирование данных (но не доменных сущностей)
Проблемы с целостностью межсервисных операций
Сквозное логирование бизнес-процесса
Дорогие специалисты
Сложность отладки
Сложность в поиске специалистов и обучении команд
Отсутствует качественная "теория" по моделированию распределенных асинхронных процессов - BPMN и прочие UML не эффективны
Хайп
Сложность диагностики
Сложность проектирования и разработки
У каждой успешной компании в MSA свой "опыт" и "заплатки" трудно обобщать
Сложно всем этим зоопарком управлять
Сложность управлением памятью
Сложность системы в целом
Дольше разрабатывать
Сложнее определить требования к ресурсам
Стоимость владения может оказаться выше
Высокие затраты на входе
Производительность массовых операций из-за межсетевых вызовов
Поиск ошибок среди всего множества сервисов
Сложность использования общих библиотеки
Необходимость наличия культуры в организации
Сложность декомпозиции
Наличие множества БД и их поддержки
Необходимость в большом количестве инфраструктурных ресурсов
Требуется организация взаимосвязи между микросервисами
Больше оборудования чем в монолите
Без должно автоматизации деплой сложнее

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

Гибкое перераспределение нагрузки на всех уровнях
При необходимости отдельные микросервисы могут быть развернуты или масштабированы независимо
Независимый релизный цикл
Разные языки программирования и БД в разных сервисах
Высокая скорость доставки
Интересный стек технологий для разработчиков
Выделение и изолирование функциональности
Канареечные релизы
Небольшие команды
Возможность перепридумать решение с нуля
Высокая отказоустойчивость
Актуальные технологии индустрии, появилось большое число качественных opensource платформ
Слабая связанность
Можно быстро переписать код
Легко заменять модули
Устойчивость
Улучшение доступности за счет изоляции сбоев в границах отдельного сервиса
Изоляция и слабая связанность ведут к возможностям более гибкой эволюции в границах модуля
Поддержка множества платформ и языков
Быстрое тестирование
Быстрый деплой
Автономный деплой
Использование трассировки запросов между сервисами
Быстрота решения инцидентов
Быстрее локальная разработка - не нужно все разворачивать
Возможность динамического распределения нагрузки
Независимая разработка
Проще рефакторить, меньше тех.долга - проще переписать один независимый сервис
Свой архитектурный подход для каждого сервиса (DDD, CRUD)

Неслабый gap образовался в области enteprise architecture в отношении микросервисов. В любой компании в том или ином виде существует архитектура этой компании. Порядка 3-х лет консолидировал данные из книг, научных источников, подкреплял собственными знаниями из практики, помогал нескольким компаниям построить agile enteprise architecture (отлично открывает путь к микросервисам).

Одна из наиболее подходящих базовых моделей, как мне кажется, все-таки togaf. Она удобна своей полнотой, из нее легко «извлекаются» не нужные в конкретной компании практики и при этом она остается рабочей. Хотя для монопродуктовых компаний на стадии роста у меня есть своя модель, построенная на циклах обратной связи, куда более простая и так же проверенная на практике.

Не так давно начал переносить консолидированные данные в миро, укладывая в понятную и простую структуру, наполненную практиками и циклами обратной связи (не «мифическими», а вполне конкретными). Получается достаточно наглядно, на мой взгляд.

Если есть желающие принять участие в разработки модели Agile Enterprise Architecture с уклоном в микросервисы, пишите в личку (@sergey486), объединим усилия.

На фото текущая версия модели с высоты птичьего полета.

В качестве вводной хорошо подойдет статья от Open Group

USING AGILE PRACTICES IN ENTERPRISE ARCHITECTURE
https://publications.opengroup.org/w194

Я иногда вспоминаю первый софт, который писал, а было это 20 лет назад. Мелкие эксперименты.

Например, корпоративные сайты.
Я тогда все писал ра Perl и было достаточно удобно - каждая .pl-ка (cgi-скрипт) выполняется в своем процессе, не пересекается с другими, развивается автономно. Правда, не было тестов, а деплой был по F5 в mc. И сразу работает :)

Это, конечно, не промышленный софт, но если посмотреть на всю последующую историю работы с промышленным софтом, то можно выделить несколько важных тезисов (и еще пару десятков к этим):
1. Промышленным стандартом стали языки, в которых разрабатывать в рамках отдельных независимых модулей стало сложнее (java/c#). Этому же способствовал и инструментарий IDE.
Да и лицензии на application servers стоили как самолет. Даже там, где обычного apache хватало с лихвой.
2. Основной объем сложности находился в окружающем контексте. Те самые пресловутые требования, по кусочкам собираемые с сотен человек, затем зачем-то переводимых с бизнес-языка на технический людьми, которые бизнес знают с чужих слов и код если и писали, то в далеком прошлом.
3. Динамика изменений стала высокой. И совмещая тезисы один и два мы получаем достаточно странную структуру того самого легаси-монолита. То есть монолит нас вроде бы уберегает от того, что при неверном проектировании запросов между сервисами не станет больше (все ж локально), но при этом он же позволяет нам дать слабину и не сильно заморачиваться с проектированием. Но даже, если попробуем построить хороший, модульный монолит (а это возможно только при хорошем понимании бизнес-сущностей, предметной области), то окажется, что мы ее не знаем, потому что см тезис 2. И это несмотря на то, что те самые IDE позволяют нам проводить крутейший анализ и рефакторинг над всей кодовой базой. Только код остается кодом, а семантика зависимостей лежит над ним, в области бизнеса.

Микрофронтеды в PayPal: https://medium.com/paypal-engineering/how-micro-frontend-has-changed-our-team-dynamic-ba2f01597f48

Свежая статья о принципах использования feature toggles от thoughtworks.

Каждый из принципов поясняется:
- Feature toggles should be flippable
- Feature toggles should be used by default
- Feature toggles should be added per story
- Feature toggles should be visible
- Feature toggles should be short-lived
- Feature toggles should be tested

https://www.thoughtworks.com/insights/blog/managing-feature-toggles-teams

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

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

​​Крис Ричардсон на DDD SoCal поделился десятью принципам рефакторинга при движении в сторону микросервисов. По ссылке и преза и видео. Классное выступление, я бы сказал — обобщающее.

https://chrisrichardson.net/post/refactoring/2020/08/21/ten-principles-for-refactoring-to-microservices.html

Фантастическая статья о выборе CI-платформы, куча полезных и интересных исследований для всех, кто сейчас оценивает CI и системы сборки: https://buoyant.io/2020/09/16/linkerds-ci-kubernetes-in-docker-github-actions/

​​На ArchDays все-таки будет выступление про LeanIX!

Сергей Лукин расскажет и покажет как документировать 150+ микросервисов в LeanIX. Я очень давно хотел посмотреть на этот инструмент вблизи, но всё как-то не было возможности, в России он не сильно распространен.

Ссылочка на описание выступления: https://archdays.ru/?speaker=430

К слову, у LeanIX очень крутые ресурсы по Enterprise-архитектуре, через ресурсы о них в свое время и узнал: https://www.leanix.net/en/resources/

20 ноября пройдет конференция по микросервисной архитектуре ArchDays, проходить будет в онлайне, подготовка идет полным ходом. В этом году значительно меньше про переход от монолита к микросервисам и больше про сами микросервисы и архитектуру распределенных систем в целом.

Участникам этого канала скидка 30% по промокоду microservices_arch 👌

http://archdays.ru

Не супер-подробная, но достаточно интересная статья про полирепо vs монорепо в микросервисах. Автор статьи больше выступает за монорепо, судя по тону статьи — по собственному опыту, так что относитесь к мыслям в статье критически и перености в свой контекст.
https://caylent.com/the-shift-from-polyrepos-to-monorepos

В обсуждениях можете поделиться своим опытом использования моно/поли репозиториев.

Последние несколько лет изучаю вопрос применения теории графов к микросервисам используя различный инструментарий. Идея в том, чтобы формализовать часть свойств микросервисов через мат аппарат графов. Что это дает на практике? Как минимум: возможность автоматизации в выявлении паттернов (циклические зависимости, сильная связанность, рассчет нагрузки и таймаутов), автоматизации соблюдения архитектруных принципов, наглядный knowledge sharing, построение моделей угроз.

Достаточно обширная практическая (с jQAssistant и Neo4j) статья на эту тему:
https://dzone.com/articles/fixing-your-microservices-architecture-using-graph

Все готово 🙂
В 10:00 стартуем #archdays

Пока готовятся видео с архдейз можно посмотреть видео выступления Патрика Куа, соавтора книги Эволюционная архитектура на agiledays 2019 с переводом на русский язык :)

https://youtu.be/DwJE_nBw0Fk

Видео с ArchDays с мастерклассом взлома приложения в в докере от Дениса Якимова (@sec_devops и @cloud_sec) и Павла Канна
https://www.youtube.com/watch?v=0_Lb9OVxmbw

Еще одно видео с ArchDays, на этот раз с мастерклассом от Жени Пешкова (@dddevotion) по агрегатам
https://www.youtube.com/watch?v=SaTz4vS_CGE