«Независимое развертывание — ну очень смелое заявление»: разработчик в пух и прах раскритиковал работу микросервисов

Да-да, знаю, микросервисы стали хайповой темой. Но оправдан ли весь этот хайп? Давайте проанализируем факты.

Автор уверен, что значение микросервисов переоценено

Редакция Highload публикует перевод материала.

Переведено бюро переводов «Профпереклад».

Перевод от

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

Давайте посмотрим.

А теперь давайте разберем эти утверждения более подробно.

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

Звучит логично, но давайте вспомним, что это практически не касается микросервисов как таковых. Дело в организации процесса разработки. Допустим, какая-нибудь организация наладила процесс разработки так, чтобы каждая группа работала над сервисом независимо от остальных, но конечный продукт построен и развертывается как монолит. Удобство сопровождения останется на прежнем уровне. Но вот микросервисов здесь нет. Какая жалость!

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

То же, что и выше. Это вопрос организации процессов, и конкретно к микросервисам это никак не относится.

«Среди преимуществ отметим и независимое развертывание. Это, в свою очередь, ускоряет работу сервисов. Вдобавок, можно организовать разработчиков ПО в автономные мелкие группы».

Независимое развертывание — ну очень смелое заявление. Проблема в том, что это актуально только для ограниченного набора ситуаций – когда новая версия сервиса обратно совместима со старой версией. Опять-таки это не является особенностью именно микросервисов. То же самое можно сделать, если, к примеру, использовать контейнер OSGi для развертывания сервисов (или любой другой способ динамической загрузки/разгрузки модулей/классов и т.д.). В отличие от микросервисов, OSGi даже обеспечивает управление встроенными версиями и параллельную развертку нескольких версий. А это гораздо упрощает работу с различными сценариями (например, переход между несовместимыми версиями сервисов). В микросервисах в их исходном состоянии нет подобной функции.

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

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

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

Но опять-таки это конструкторское решение, а не характерная особенность монолитной структуры.

По какой-то причине приверженцы микросервисов объявляют частично работающую систему «доступной» и утверждают, что это преимущество!

Частично работающая система, которая может повредить или удалить данные, считается «доступной»? Ну очень вольная трактовка термина.

«Благодаря автономности развертки сервисов можно масштабировать экземпляры сервиса в сторону увеличения или уменьшения, в зависимости от объемов трафика. Это улучшает масштабируемость и доступность приложения в целом».

Кто вообще решил, что сервисы можно масштабировать исключительно разверткой большего количества экземпляров?

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

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

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

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

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

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

Автор: Сергей Евтушенко