Монолит против микросервисов
Честно и откровенно про жизненный выбор между одним большим и сотней мелких. На личном опыте человека с непростой судьбой.
Давайте начнем с небольшого списка:
https://about.gitlab.com/install/
https://www.atlassian.com/software/jira/download.
https://www.jenkins.io/download/
https://www.sonarsource.com/products/sonarqube/downloads/
https://docs.sentry.io/product/cli/installation/
Вот плюс-минус так выглядит мой «джентельменский» набор софта для разработки последние лет 15.
Каждая из этих интересных штук — сама по себе большая и сложная: содержит точно больше миллиона строк кода, сложный интерфейс, скрипты установки и много чего еще.
Каждая является законченным, стабильным продуктом, с историей, аудиторией и четкими планами на будущее.
И каждая технически является тем самым монолитом, который вы так усердно распиливаете на микросервисы на вашей дневной оплачиваемой работе. Я специально вставил ссылки на скачивание и установку, чтобы было понимание — все это отдельные устанавливаемые продукты, а не какой-то «облачный сервис».
Обидно стало?
Мне тоже, потому что весь этот сложный мощный и надежный софт используется для работы над очередным мразотным «облачным ERP», который будучи в десятки раз проще, размазан разбит на сотню-другую «микросервисов». С надежностью соломенного шалаша, разумеется.
Откуда оно лезет
Сейчас будет опять обидно и неприятно но:
верить во что-то куда проще чем производить расчеты и думать.
Инженерное мышление есть у очень немногих, вне зависимости от красноты диплома. Гораздо чаще встречаются обряды, ритуалы и верования — даже среди инжернеров-айтишников.
Типичным примером такого тотемного мышления является святая вера в «разделение ответственности»:
Если некий сервис отвечает только за один узкий функционал и предоставляет его другим сервисам — он считается надежным.
Идея в том что, например сервис почты отвечает только за отправку почты и больше ничего, сервис справочников отдает только справочники. Ну и так далее.
Знакомо? Типа разделяй и властвуй, ага.
Так вот специально для пересмотревших «Игру Престолов» обьясняю:
вашим пользователям п#хуй. И менеджерам п#хуй и начальству.
Им всем надо «чтоб работало» максимально долго и без сбоев, а не рассказы про микросервисы.
У любого ПО и любой системы, с точки зрения пользователя есть лишь два состояния:
работает и не работает.
А вот что получается на практике:
Сервис почты перед каждой отправкой вызывает сервис со справочниками, для получения значений подстановки в шаблон письма, разумеется. И вместе они используют одну и ту же базу данных. И пишут логи на один и тот же диск, из разных контейнеров.
Сколько тут точек отказа сами посчитаете.
Поэтому для сбоя такого вот «чудо-облака» достаточно пинка сапогом по серверной стойке — как это и было 20 лет назад c более простыми техническими решениями.
Или единичного сбоя в сети — уборщица провод выдернула случайно и все ваши микросервисы встали колом.
Почему микросервисы популярны
Неужели шаманов и духовных практик в современном ИТ сообществе стало больше чем инженеров с калькуляторами? А выбор архитектуры теперь происходит путем гадания на картах Таро и общения с «духами предков»? Не совсем.
Еще есть много интересных причин:
лень, гордыня, психотравмы и комплексы.
Вот например, начинается разработка нового проекта. Очевидно что нужно сделать большое количество базового общего фукнционала, интенсивно поработать.
Как думаете, современная команда из «не-таких-как-все» и «уникальных снежинок» станет работать вместе?
Коммиты в общую ветку это же нарушение личных границ, а ревью кода — психотравма.
Поэтому для современной айтишной «снежинки» психологически комфортнее создавать свой отдельный микросервис и отвечать только за него.
Ну и гордость конечно, пополам с самомнением. Куда же теперь без них:
Чего это я буду дорабатывать сервис Васи? Я свой хочу! Я ведь не тупее Васи. Быстра дали мне свой отдельный сервис а то уволюсь к х#ям!
Получается что разработка чего-то общего и единого стала противоречить самим настроениям в айтишном обществе, его ценностям и установкам.
Но однако джирой и дженкинсом все также пользуются повсеместно. Без малейшего диссонанса.
Честно про плюсы
Теперь про хорошее — зачем все-таки нужны микросервисы и где они обязательны.
- Вы делаете массовый сервис, который никогда не будет установлен локально;
- Вам на самом деле нужна 99.9 надежность — настолько нужна, что вы даже знаете что это такое;
- У вас есть инфраструктура для обеспечения отказоустойчивости: запасное все, от датацентров и сетевых подключений до отдельных серверов и дисков;
- Вы большие и вас много.
Микросервисы придумала компания, в которой на момент создания работало больше тысячи одних только разработчиков.
Микросервисами решались проблемы стандартизации и взаимодействия между очень большой массой специалистов — разработчиков, админов, тестировщиков, колдунов Вуду задействованных на одном большом проекте.
Половина работ над настоящей системой на микросервисах — внезапно не разработка, а инфраструктура.
Не кодинг вебсервисов, а развертывание каких-нибудь Eureka и Hystrix.
Развертывание бл#ть, а не скачивание и запуск по-умолчанию ради модной строчки в резюме.
В догонку
До тех пор, пока всю команду можно накормить парой больших пицц, а весь ваш проект спокойно запускается на обычном офисном ноутбуке условного «менеджера по продажам» — не лезьте в микросервисы.
Нет ничего положительного от микросервисов для маленьких проектов, нету. Развивайте ваш продукт, добавляйте новые фичи, тестируйте и гоните в шею всех советчиков «распила монолита».