Микросервисы не нужны
Попытка объяснить, что у вас нет причин использовать микросервисную архитектуру.
в еврейской школе: ребе: Моше, сколько будет 2х2? Моше: Ребе, а мы продаем или покупаем?
Как в анекдоте, на утверждение из заголовка можно задать тот же вопрос: А мы продаем или покупаем?
Стартап
Нет смысла использовать микросервисную архитектуру при разработке стартапа.
- Мало специалистов.
- Единый набор технологий: язык программирования, СУБД, перечень библиотек и фреймворков. Нет времени на разные технологии и эксперименты.
- Необходимо сосредоточиться на функциональности продукта и максимально быстром получении MVP (минимально жизнеспособный продукт). Нет времени долго проектировать, распиливать на микросервисы, плодить сущности и невероятности. На это нет времени.
Миллионы клиентов
Ой, да ладно, Вы разрабатываете продукт с миллионами клиентов? Поздравляю!
Сколько RPS считается большой нагрузкой? 1000 RPS или 10000 или больше? Ответ банальный: как только обнаружите в работающем проекте бутылочное горлышко — Вы приближаетесь к большой нагрузке. Нужно проводить анализ нагрузки и применять мероприятия по оптимизации работы проекта.
Дополнительная информация: https://habr.com/ru/articles/262623/
Архитектура и инфраструктура
Монолит — это не модно! Нет простора и свободы для проектировщика и разработчика. Что мешает сделать модульный монолит? Да, это сервисная модель, работающая в едином адресном пространстве. Ограничения будут, но есть и решения этих ограничений. Микросервисы сложнее и медленнее буквально во всех частях, особенно в начальной архитектуре и первоначальной проработке API.
Инфраструктура в микросервисной архитектуре сложнее. Заказчик, используя собственных специалистов скорее всего не сможет развернуть соответствующую инфраструктуру (а для разработчика это плюс). Это не касается дефектов и проблем, там без разработчика никак (а для разработчика это большой плюс).
Чисто теоретически, в микросервисах проще повторно использовать код. Но, это только теоретически, пока не столкнешься. А вот любители микросервисов упоминают постоянно этот плюс.
Рефакторинг проще в монолите, у вас единая база кода на ОДНОМ ЯП.
Тестирование. Микросервисы сложнее по архитектуре и по инфраструктуре. Сложность касается и тестирования.
У монолита есть еще большой плюс, что часть системы можно объединить в ядро, а бизнес-логику выделить в разные модули. Разработать и внедрить простенький внутренний язык программирования, который позволит расширять функциональность и даже разрабатывать собственные модули со стороны заказчика. При такой структуре, компания-разработчик может распространять коробочное решение с услугами внедрения, доработки и сопровождения. А заказчик с собственными специалистами волен выбирать — обращаться к компании-разработчику для доработки или сделать собственными силами.
Сетевые интерфейсы
В монолите всё быстрее — это единое адресное пространство! Микросервисы большую часть полезной мощности железа отдают на перекладывание JSON между собой. Процедуры эти не отличаются скоростью. С одной стороны, у нас распределенное сетевое приложение, по-другому тут никак, но это универсальность. А с другой, продукт получается инерционный и не отзывчивый для пользователя.
Многообразие технологий
Использование разных технологий при разработке микросервисов является весомым преимуществом. Никто не привязывается к одной СУБД. Я уже не говорю про библиотеки и фреймворки. Полная свобода. Берем нового специалиста и пусть творит чего хочет. Зоопарк технологий? Точно, это он! А нужен ли этот зоопарк заказчику продукта? Вот как специалистам заказчика поддерживать этот зоопарк? Никак, что очень нравится компании-разработчику.
Поддержка и сопровождение
Заказчик на монолите держит 1-2 сисадминов для поддержки работы инфраструктуры и несколько автоматизаторов для оптимизации или доработки бизнес-процессов. Заказчик для микросервиса держит... кормит целую компанию разработчиков (а скорее не одну), чтобы у него что-то работало. И это работает обычно кое-как со всеми накладными расходами на время. Тайм2Маркет страдает именно на микросервисной архитектуре. Надо внедрить срочное изменение законодательства. Заказчик пишет разработчикам. Аналитики разбираются, архитектор проектирует и т.д. Это всё время и деньги. Естественно, компания-разработчик выкатит солидный счет за свои работы. А заказчику и некуда деваться. Это не местные автоматизаторы, которым сказали: "Завтра работаем по новому, готовьтесь". Тут зависит от уровня местных автоматизаторов, но если они не первый день на работе — они уже будут готовы к новшествам.
Неужели микросервисы настолько плохи? Нет, если надо сделать отдельный локальный бизнес-процесс (новый) и встроить в существующий продукт. Компания разработчик с этим справится быстрее и оптимальнее местных автоматизаторов, которых всего 2-3. Но, это отдельные микросервисы, дополнительные разработчики и новый бюджет.
Бюджет
Подошли к самому сладкому — к бюджету. В рамках неограниченного бюджета микросервисы выигрывают. Как часто такие компании встречаются? Далеко не все специалисты работают в таких компаниях. Я обычно сталкивался с дефицитом бюджета. И это нормальное положение дел.
В рамках скромного бюджета все расходы необходимо жестко контролировать. И тут микросервисы проигрывают и в количестве разработчиков (их надо больше) и в количестве технологий и разнообразия дополнительных библиотек (лицензии). Тоже самое касается инфраструктуры: нужны специалисты, технологии, оборудование.
На рабочих местах заказчика ситуация схожа, необходимы специалисты для поддержки работоспособности инфраструктуры. Здесь можно немного сэкономить, если не раздувать штат, а отдать полное сопровождение компании-разработчику. Да, это уменьшит контроль владения, но это может работать. Важно, все ли бизнес-процессы можно передать для сопровождения или только часть (компании-разработчику это очень выгодно). Во втором случае придется часть специалистов держать у себя.
Как решать проблемы, когда сопровождение находится в руках компании-разработчика? Вопрос больше риторический, часто такие взаимоотношения строятся на основе внедоговорных отношений (прод упал, не работал 2 дня, но мы устно договорились с представителями заказчика). Все должны понимать, что это до серьезных неполадок и потери реальных денег. Когда такое произойдет, разговор будет на основании договора.
Кому нужны микросервисы
Если есть программисты на языках программирования с динамической типизацией. У них не получится серьезный монолит.
Если есть разные части продукта, написанные на разных языках программирования. Ну, так получилось и переписать это сложно или невозможно.
Для компаний с безграничным бюджетом и ведущих бизнес в основном в сети Интернет. Лучше при этом иметь и серьезную клиентскую базу, хотя бы в перспективе.
Для компаний-разработчиков, которые очень любят деньги.
Итоги
Микросервисная архитектура выгодна для компаний-разработчиков. Надо просто найти заказчика с неограниченным бюджетом и можно бесконечно жить и богатеть.
Монолитная архитектура выгодна для заказчиков с ограниченным бюджетом и с собственным виденьем автоматизации и оптимизации бизнес-процессов.