Привет, Хабр!

Поскольку первая встреча прошла очень полезно и интересно, мы решили повторить и снова в эфире телеграм-канала Dev Q&A  продолжили дискуссию о микросервисах и скорости разработки. Собрались технические эксперты из BPMSoft, DevTale, Revizto и Диасофт (в лице меня). Обменялись практическими примерами на тему как же упростить жизнь разработчикам и получать результат быстрее, дешевле и качественнее.

Как я и писал в прошлый раз для нас в Диасофте тема разработки в микросервисной архитектуре  особенно актуальна,  поскольку всю новую разработку мы ведем только в ней с использованием нашей экосистемы Digital Q,  которая берет на себя всю рутинную работу позволяет существенно увеличить скорость разработки.

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

Полная версия дискуссии на Rutube или Youtube:

Сотни команд, один продукт: как вообще это возможно

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

Александр Сахаров из Диасофт описывает масштаб проблемы на примере крупных российских компаний: «Например, в крупном российском банке работает пятьсот команд. Одна команда отвечает за функциональность в одной части сайта, другая команда — за функциональность в другой части мобильного приложения, третья команда — за что-то еще. И все это собирается в единый интерфейс. Как сделать так, чтобы это работало в монолите с непрерывным развертыванием? Каждая команда имеет свой график работы, свой pipeline, свои релизы, которые выкатываются в любое время. Без микросервисной платформы это превращается в хаос», — задается вопросом Сахаров.

Проблема не ограничивается банками. В e-commerce и foodtech ситуация еще сложнее из-за интеграции с внешними партнерами.

«То же самое происходит в Яндексе. Представьте себе приложение Яндекс.Еда, в котором восемьсот магазинов и служб доставки. Как сделать так, чтобы это работало как единое целое?» — продолжает Сахаров. «Я просто не могу представить, как пятьсот команд должны работать в распределенном режиме с такой нагрузкой, которую испытывают большие банки, Яндекс, Ozon и другие крупные компании. Как это решить в монолите с тестированием обратной совместимости, с тестированием всего регрессионного функционала, с отсутствием конфликтов между командами, с единым интерфейсом, с единым пользовательским опытом и еще с отсутствием падений при обновлении какого-то маленького кусочка? Для меня это практически нерешаемая задача без микросервисной архитектуры или хотя бы low-code платформы для координации», — отметил эксперт.

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

Александр Тырышкин, основатель DEVTALE LLC, подтверждает: «Александр Сахаров подсветил для меня ключевую мысль: это устранение блокировок. Команды работают независимо друг от друга, команды имеют свой релизный цикл, и команды слабо связаны между собой. Придерживаемся Domain-Driven Design модели с доменами, все работают внутри своих доменов на базе микросервисной платформы», — говорит Тырышкин.

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

Павел Копельман из BPMSoft формулирует четкие критерии: «Мы делаем микросервисы не ради микросервисов. Мы внедряем микросервисную архитектуру, когда нам надо масштабироваться, когда нам нужно повысить отказоустойчивость, когда у нас десятки тысяч пользователей, и мы вынуждены предоставлять определенный уровень качества и доступности системы», — утверждает он.

Платформа как необходимое условие для микросервисов

Переход на микросервисную архитектуру без подготовленной инфраструктуры — это путь в никуда. Компании, которые пытались сделать это «на коленке», быстро сталкивались с хаосом в управлении десятками сервисов.

Александр Сахаров делится опытом создания микросервисной платформы для двухсот команд: «Наше решение разработано в компании Диасофт, где работает почти тысяча сотрудников и 200 команд. Чтобы эти 200 команд слаженно работали с микросервисной архитектурой и нужна единая low-code платформа. Она берет на себя функции, о которых не нужно думать программисту. Аналитик рисует картинки в виде бизнес-процессов и диаграмм сущностей. На основании этих схем наша микросервисная платформа генерирует скелеты кода, создает CRUD API, сервисы и их описания. После этого программисты могут добавлять в созданные ячейки необходимый код, в том числе с использованием инструментов искусственного интеллекта», — описывает Сахаров.

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

«Каждая команда, даже если это опытные люди, делает что-то по-своему. Когда начинаешь собирать единое приложение без low-code платформы, это становится практически невозможным», — продолжает Сахаров. «Единственным ответом на эту сложность, как раз и стало создание платформы, которая позволяет унифицировать «подкапотные» вещи: информационную безопасность, управление ролями, логирование, покрытие юнит-тестами, сборку, весь CI/CD pipeline, развертывание, контроль производительности, контроль обратной совместимости», — отметил эксперт.

Павел Копельман из BPMSoft подтверждает, что без платформенного фундамента микросервисная архитектура превращается в головную боль: «Без платформенного основания, без нескольких основополагающих связующих элементов разрабатывать, связывать, крепить и эффективно управлять микросервисами крайне затруднительно. Реализовывать все CI/CD пайплайны, пакетную архитектуру для нормального обновления — все это требует серьезной инфраструктуры и, желательно, микросервисной платформы», — говорит Копельман.

Александр Сахаров использует яркую метафору для объяснения роли low-code платформы в микросервисной архитектуре: «Чтобы вскопать поле лопатой, кроме лопаты ничего не нужно, но чтобы вскопать поле трактором, нужно пройти обучение пользованию трактором, чтобы не навредить себе и не развалить дом», — иллюстрирует он.

Платформа меняет саму модель работы разработчиков. Вместо того чтобы решать инфраструктурные задачи, они фокусируются на бизнес-логике благодаря возможностям low-code платформы.

«Мы не требуем от наших молодых программистов и аналитиков, которые вчера закончили учебу и приступили к работе, знания всех этих сложных вещей микросервисной архитектуры. Платформа обеспечивает связанность. Они садятся на трактор, этот трактор начинает выпускать сорок три борозды единого стандарта и единого размера. При этом тракторист копать эти борозды не умеет, да ему и не нужно. Его задача — нажимать на педали и рулить рулем, программировать конкретный кусок бизнес-логики, слушая при этом музыку», — заключает Сахаров.

Независимые релизы и масштабирование без блокировок

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

Александр Тырышкин из DEVTALE LLC приводит показательный пример: «Сейчас, если посмотреть, все движутся в сторону суперприложений. Ты сделал что-то одно, один маленький кусочек красиво, но потом хочешь войти в новое направление. Допустим, можно на Wildberries посмотреть, как они начинают сейчас и в тревел-бизнес входить, и в банкинг, и в другие направления. С нуля у них, я подозреваю, нет экспертизы в определенных доменах, например, в банкинге. И выглядит очевидным решение посмотреть, кто есть из небольших игроков на рынке, кого можно выкупить целой командой», — объясняет Тырышкин.

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

«Таким образом, микросервисное разделение может быть оправдано. Мы не опускаемся до абсурда, когда кнопка «Оплатить» улетает в команду биллинга, а кнопка «Добавить в корзину» — это другая команда. Но все-таки мы делаем разумное распределение между командами», — продолжает Тырышкин.

Крупные компании решают проблему координации через создание платформенных команд, которые обеспечивают единообразие базовых подходов.

Тырышкин делится опытом работы в AliExpress: «Когда я работал в AliExpress, у нас также была команда платформы. Я знаю, что и в Т-банке есть, и в Альфе есть команда платформы, которая поддерживает единые библиотеки для всех. Есть наработанные практики по работе с Kafka, по работе с базами данных, всякие коннекторы, сайдкары и другая накопленная экспертиза внутри компании, которой ты обязан пользоваться. И тогда твоя работа сводится только к написанию бизнес-логики конкретного сервиса», — рассказывает он.

Такой подход кардинально меняет баланс ответственности и скорость разработки.

«В таком случае, мне кажется, микросервисная архитектура достаточно сильно выигрывает у монолита, где ты должен быть мастером на все руки: и с DevOps разбираться, и с CI/CD решать вопросы, и вот у тебя еще ClickHouse рядом поднимается, и с этим тоже нужно как-то справляться. А в случае с платформой у тебя все выстроено: сервис — это оболочка, которую ты просто наполняешь бизнес-логикой, запускаешь, и все работает красиво», — отмечает Тырышкин.

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

Павел Копельман из BPMSoft поднимает важный аспект: «Для меня микросервисы — это менеджмент не только на уровне команды и бизнеса. Здесь я не могу не согласиться с тем, что выделение одной команды на отдельную кнопку — это, наверное, перебор. Но это еще и менеджмент ресурсов. И он часто оказывается даже более важным, чем менеджмент команды. Потому что где-то убрать одну ноду, где-то добавить одну ноду — это бывает значительно проще», — утверждает Копельман.

Особенно это критично для систем с неравномерной нагрузкой на разные компоненты.

«На условных пятидесяти-ста тысячах пользователей можно развернуть кусок монолита для аналитики или для задач с динамической нагрузкой. Но будет ли это лучше и удобнее, чем взять пять-шесть разных сервисов — почтовый сервис, ML-сервис, аналитический сервис и другие — запустить их спокойно в Kubernetes и динамически распределять между ними ресурсы?» — задается вопросом Копельман.

«Микросервисы — это стрельба себе в колени»

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

Александр Тырышкин из DEVTALE LLC формулирует жесткую позицию: «Эксперты выступают в поддержку микросервисов, все здорово и классно. Они подсвечивают такие позитивные моменты, как CI/CD пайплайны, распределенные транзакции и прочее. Не кажется ли вам, что это просто стрельба себе в колени? Мы сами себе создаем проблемы на ровном месте, чтобы оправдать те ценники, которые мы выставляем за микросервисную архитектуру. Куда проще сделать решение в лоб, то, которое просит заказчик, и не тормозить разработку микросервисами», — заявляет Тырышкин.

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

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

Его вывод категоричен, но подкреплен практическим опытом.

«Я буду защищать монолиты, потому что это проще, это дешевле, и зачастую это выигрышнее, чем поддерживать глобальную микросервисную архитектуру», — утверждает он.

Евгений Евсеев, технический директор PelidTeam, видит в микросервисной архитектуре крайнюю меру, а не архитектурный выбор по умолчанию: «Микросервисы — это вынужденная мера. Мы в своей разработке делаем и монолиты, и микросервисы, и в зависимости от задачи выбираем тот или иной подход. По-разному бывает, но при проектировании подход обычно такой: мы начинаем с того, чтобы проектировать систему именно как монолит, а не сразу бросаться к микросервисной платформе», — объясняет Евсеев.

По его словам, микросервис появляется только когда все другие варианты исчерпаны.

«Мы решаем выделить микросервис только в одном случае: если видим в системе компонент, слабо связанный с остальными, который можно будет переиспользовать — в других задачах или даже в других проектах. И если понимаем, что затраты на его разработку окупятся: например, благодаря тому, что над ним смогут параллельно работать несколько команд, мы быстрее получим результат или добьёмся других ощутимых плюсов», — объясняет Евсеев свой подход.

Критерий выбора предельно прост и прагматичен.

«Если очень нужен микросервис на Node.js, тогда мы его используем. Это как последняя опция. Это когда мы все остальное перепробовали, и у нас получается, что микросервис — это все еще лучшее решение из возможных. Вот тогда мы его делаем», — говорит он. «Когда все остальное хуже, тогда делаем микросервис», — резюмирует Евсеев.

Николай Алёшин, разработчик на Golang, скептически относится к теме, опираясь на опыт работы с так называемыми «псевдо-микросервисами»: «Я видел проекты, которые называли микросервисами, но на деле это были монолиты или, в лучшем случае, просто отдельные сервисы — без признаков настоящей микросервисной архитектуры. Такая подмена понятий только вносит путаницу», — отмечает Алёшин.

Его вывод однозначен.

«Те проблемы, которые хотят разработчики и компании решить с помощью микросервисной платформы, вполне возможно решить монолитом. И в монолите это даже будет сделать проще, быстрее, и поддерживать потом это будет также гораздо проще. То, что внедрение микросервисной архитектуры решит часть вопросов — возможно, но добавит еще больше новых вопросов и проблем, которые надо будет снова решать», — утверждает Алёшин.

Правильная архитектура монолита решает проблемы параллельной разработки

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

Евгений Евсеев из PelidTeam считает, что микросервисную архитектуру часто выбирают как ложное решение организационных проблем: «Долгое время микросервисы воспринимались как панацея от проблем, которые бывают с монолитами. У нас монолит, он очень большой, нам тяжело сделать так, чтобы много людей участвовало в разработке, они не толкались над одним монолитом. Много сложностей именно организационного характера, связанных с тем, что у нас очень большой объем кода, нам тяжело с ним работать — давайте разобьем на штуки поменьше и внедрим микросервисную платформу», — описывает типичную логику Евсеев.

Но это решение он считает в корне неверным.

«Здесь, мне кажется, это не популярно, но при этом в корне неверное решение, потому что проблему можно решать иначе. Если для монолита выбрать правильную архитектуру, то на самом деле можно добиться высокой управляемости кода и высокого параллелизма разработки, когда у нас очень много людей работает над одним программным продуктом, даже без создания микросервисной архитектуры», — утверждает он.

Ключевой момент — это заблаговременное проектирование с учетом будущего масштабирования команды.

«Это вопрос архитектурный. Его нужно продумывать заранее и закладывать на старте проекта. Эту вещь очень тяжело привнести, когда проект уже несколько лет хаотично развивается — это не получится. Но если думать об этом заранее, то на самом деле можно и с монолитом прекрасно жить без всяких low-code платформ. Десять человек может параллельно работать над одним монолитом, и они не будут толкаться, если архитектура подходящая», — делится опытом Евсеев.

Его подход к решению задач крупных компаний кардинально отличается от микросервисного.

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

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

«То есть мы часть разработчиков выделяем в команду поддержки, которая занимается разработкой десятков библиотек, и создаем команду, задача которой — этими библиотеками пользоваться и собирать конечные продукты. Обычно именно так это и решается, без необходимости в low-code платформе», — объясняет он.

Александр Сахаров признает естественность эволюционного пути от монолита к сервисам, но подчеркивает важность правильной гранулярности: «Это на самом деле является краеугольным камнем дискуссии. В разговоре приводились примеры, когда слово «микро» в микросервисной архитектуре понимают буквально и делают супер-микро, что приводит к катастрофическим последствиям. Нужно уметь находить баланс между микро и не-микро», — отмечает Сахаров.

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

«Слушаешь, и волосы дыбом встают. Ребята совсем отрываются от реальности. Они такие: «У нас есть диалоговое окно. А как же мы это диалоговое окно выведем без дополнительного микросервиса с Docker-контейнером в нашем замечательном кластере Kubernetes? Ну никак! Вы что?» То есть даже pop-up окно — это отдельный микросервис», — иронизирует Сахаров над крайностями микросервисного подхода.

Александр Тырышкин предлагает прагматичное решение для задач, которые часто пытаются решить через микросервисную архитектуру: «Пример: у нас есть аналитика, что-то мы хотим делать. Да в чем проблема? Сделал два коннекта, ClickHouse или что-то еще прикрепил, два коннекшена сделал к реляционке и нереляционке и добавил железок. Пожалуйста, все у тебя работает, никаких проблем не будет с нагрузкой и всем остальным. Это я просто к тому, что всегда можно взять молоток и просто зафигачить решение в лоб, и оно будет работать, и ничего с ним не случится», — утверждает Тырышкин.

Проблема не в архитектуре, а в умении выбирать

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

Для небольших команд ответ часто очевиден. Алексей Каньков из Revizto делится опытом: «Так уж получилось, что я всегда работал в компаниях, в которых было максимум около сотни разработчиков. И микросервисы для нас были самой крайней мерой», — рассказывает Каньков.

Даже вынужденный переход на микросервисы не всегда оправдывает ожидания.

«Единственное место, где мы начали применять микросервисы, это когда мы начали друг другу наступать на пятки. Изменения, которые делал я, безболезненно перетирались изменениями, которые сделали люди из другой команды», — объясняет он причины перехода. «Но это сильно стало замедлять нашу разработку. Необходимо повышать квалификацию DevOps-инженеров, повышать квалификацию разработчиков, как-то научить коммуницировать эти сервисы друг с другом», — описывает последствия Каньков.

Скорость разработки в монолите для небольших команд остается непревзойденной.

«Сейчас мы можем в небольшой компании созвониться утром, обсудить ту фичу, которую мы хотим сделать, и уже к вечеру мы можем ее задеплоить в продакшен. Потому что это быстро, просто, ничего не нужно изобретать нового», — утверждает он.

Но даже когда микросервисы кажутся правильным выбором, реальность вносит свои коррективы. Николай Алёшин поднимает критически важную проблему: «Все слова про слабосвязанность и быстроту разработки вызывают вопрос: а как вы это тестируете? Представьте: вам надо собрать десять разных сервисов, десять отдельных команд условно. Это все надо согласовать между ними при слабой связанности проектов», — описывает проблему Алёшин.

End-to-end тестирование превращается в бесконечный цикл доработок.

«Когда проводишь end-to-end тест, идет процесс, и только в процессе узнаешь, что какая-то команда получает параметр, который не ожидала получать. Все останавливается, начинается доработка, снова анализ — у всех ли все нормально. И этот круг повторяется снова и снова», — делится болезненным опытом он.

Возможно, ключ к пониманию проблемы лежит не в технической плоскости. Александр Тырышкин формулирует важную мысль: «Микросервисы — это в первую очередь не про саму разработку, код, сервисы, а это больше про менеджмент. То есть как ты умеешь жонглировать твоей большой системой, как ее разбить на маленькие кубы, как перестать толкаться между друг другом в мерж-реквестах», — объясняет Тырышкин.

Александр Сахаров предлагает взглянуть на проблему с точки зрения естественной эволюции: «Эволюция перехода от монолита к микросервисам является естественным путем развития. Сначала появляется один монолит, потом он разбивается на два, потом на десять. Появляется набор монолитов, которые должны между собой общаться. Эти монолиты принимают вид сервисной архитектуры, и в предельном переходе мы получаем микросервисы», — описывает он.

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

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

Может быть, пора перестать искать универсальное решение и начать задавать правильные вопросы: Сколько у нас команд? Как часто они блокируют друг друга? Готовы ли мы инвестировать в платформу и DevOps? Есть ли у нас экспертиза для поддержки распределенной системы?

Ответы на эти вопросы важнее, чем следование архитектурной моде.