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

Установка: от базовой химии к квантовой механике

Настройка базовой БД и приложения с фоновым процессом была довольно чётким процессом. Я публикую readme на Github — и часто через один час, максимум, парочку часов, всё работает, а я начинаю новый проект. Добавление и запуск кода, по крайней мере, для начальной среды, делается в первый же день. Но если мы отважились на микросервисы, время первоначального запуска взлетает до небес. Да, сейчас у нас есть Docker с оркестровкой и кластер машин K8, но для начинающего программиста всё это на порядок сложнее. Для многих джуниоров это бремя, которое действительно является ненужной сложностью.

Систему непросто понять

На минутку остановимся на нашем джуниоре. С монолитными приложениями в случае возникновения ошибки её легко было отследить и сразу перейти к отладке. Теперь у нас есть служба, которая разговаривает с другой службой, которая ставит что-то в очередь на шине сообщений, которая обрабатывает другую службу — и тут возникает ошибка. Мы должны собрать воедино все эти части, чтобы в конечном итоге узнать, что служба А работает в версии 11, а служба Е уже ожидает версию 12. Это сильно отличается от моего стандартного консолидированного журнала: приходится использовать интерактивный терминал/отладчик, чтобы пройти через процесс шаг за шагом. Отладка и понимание по сути стали сложнее.

Если нельзя отладить, возможно, мы их протестируем

Непрерывная интеграция и непрерывная разработка в настоящее время становятся общим местом. Большинство новых приложений, которые я вижу, с каждым новым релизом автоматически создают и запускают тесты и требуют, чтобы тесты проходили и просматривались перед регистрацией. Это отличные процессы, от которых нельзя отказываться, они стали большим сдвигом для многих компаний. Но теперь, чтобы действительно проверить сервис, я должен поднять полную рабочую версию своего приложения. Помните того нового инженера с кластером K8 из 150 сервисов? Ну, теперь мы научим нашу систему CI, как поднять все эти системы для проверки что всё действительно работает. Вероятно, это слишком много усилий, поэтому мы просто изолированно протестируем каждую часть: я уверен, что наши спецификации достаточно хороши, API чисты, а отказ службы изолирован и не повлияет на других.

У всех компромиссов есть веская причина. Верно?

Есть много причин для перехода на микросервисы. Я видел, что это делают для большей гибкости, для масштабирования команд, для производительности, чтобы обеспечить лучшую устойчивость работы. Но в реальности мы вложили десятилетия в инструментарий и практики разработки монолитов, которые продолжают развиваться. Я работаю с профессионалами в разных технологиях. Обычно мы говорим о масштабировании, потому что они сталкиваются с лимитами одного узла базы данных Postgres. Большая часть разговоров посвящена масштабированию БД.

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

Источник: habr.com