От простого к сложному: путь от монолита к микросервисам

Привет! Я Александр Павленко, PHP Developer в NIX и спикер NIXMultiConf. Уже четыре года занимаюсь этим направлением и часто вижу статьи на тему «Монолит: плюсы и минусы», «Микросервисы: за и против», «Монолит vs микросервисы». И намного реже — о правильных переходах между архитектурными подходами и их взаимодействии. Хотя проекты могут быстро расти или кардинально менять свой курс развития, нужно знать, когда и какой архитектурный подход поможет поддерживать систему.

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

Иллюстрация Алины Самолюк

Выбирая подход, учитывайте все риски

Мировые компании давно используют микросервисы. Например, монолитные приложения Amazon, Coca-Cola и Netflix в какой-то момент переросли в более масштабные инфраструктуры. Брендам такое решение пошло на пользу и привлекло еще больше аудитории. Но тренд не значит, что монолит — это вчерашний день. Мы с командой не привыкли слепо гнаться за новомодными тенденциями. Всегда анализируем, когда тот или иной вариант эффективен и как безопаснее к нему перейти.

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

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

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

Наш стартап стремительно развивался. Росло количество пользователей, клиентов, регулярно добавлялся различный функционал. Спустя некоторое время проявились недостатки монолита. То, что было критично для нас:

  • из-за стремительного роста системы становилось сложнее ее поддерживать и развивать без дополнительных ресурсов. Прежде всего это касалось стоимости внесения новых изменений. Чем дальше мы шли и внедряли новые фичи, тем больше они дорожали;
  • рисковали в будущем застрять на старых технологиях. Думаю, многие коллеги сталкивались с legacy-монолитами — за окном 2020 год, а на мониторе в коде 2003-й. Переписывать все это крайне сложно. Обычно не хватает ни времени, ни ресурсов.

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

Многократное использование микросервисов позволило легче адаптироваться под новые требования стартапа и масштабировать его. Теперь мы знаем, что для подготовки MVP лучше взять монолит, а дальше, с ростом проекта, дело за микросервисами.

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

Теперь мы уходим от сильной монолитной связанности. Большая часть функций делятся на небольшие независимые группы и реализуются в виде микросервисов. Последующие изменения или новые фичи внедряют внутри такой группы или отдельно в качестве другого микросервиса. При этом не затрагивается ничего лишнего. Что особенно радует: появляется свобода в выборе технологий и языков. У каждого из них есть свои преимущества.

Использовать разные языки программирования под микросервисы и разные виды протоколов для общения между ними.

Но тут же всплыли недостатки. Во-первых, повысился порог вхождения в проект. Во-вторых, усложнилось поддержание, конфигурация и тестирование настроек. По сути, это не является минусом. Главное, что микросервисами закрыли самые важные вопросы.

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

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

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

Что микросервисы дали нашему проекту:

  • взаимодействие PHP и Golang. Отлично дополняют друг друга и в некоторых случаях перекрывают слабые стороны. По сравнению с PHP, с помощью Golang можно значительно улучшить перфоманс. За счет параллелизма ускорить обработку и выполнение тех или иных процессов. В то же время у PHP есть все для быстрой реализации удобного CRUD;
  • переход от пяти крупных клиентов к более чем 20 — все благодаря разграничению монолита на отдельные решения;
  • оптимизация нагрузки на сервер. По сравнению с PHP, Golang потребляет намного меньше памяти. С внедрением Golang в проект и переписыванием отдельных частей на Go серверам стало легче. Больше мы с этой проблемой не сталкиваемся;
  • разнообразие команды. Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. Мы поделились по зонам ответственности. Когда-то нас было пятеро, сейчас около 40 человек. Добавились бэкенд-разработчики и бизнес-аналитики, заточенные под определенные спецификации.

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

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

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

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

Монолит или микросервисы: что лучше

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

  • когда в монолитном проекте стоимость нового функционала не перекрывает ожидаемую пользу;
  • когда проект разрастается до такой глыбы, что новые люди в команде теряются. В микросервисах можно взять отдельный компонент, определить, что в нем происходит, и работать только с ним. В крупных проектах разделение обязанностей рано или поздно приведет к архитектурным разграничениям. Микросервисы позволяют легче пережить этот момент.

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

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

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

Мой основной посыл — не сравнивайте, а подстраивайтесь под особенности проекта и бизнес-задачи. Выбирайте архитектуру приложения взвешенно. Подходящий вариант упростит жизнь вам, команде и пользователям. Да и в целом сделает проект успешнее.

Похожие статьи:
Онлайн-курс VD Bootcamp підійде для тих, хто вже вміє збирати дрони і бажає масштабувати процес їхнього виробництва для фронту. Навчання...
Кристина Голышева до переезда в Штаты четыре года работала рекрутером в киевском офисе SoftServe. Переехав в США по визе L2, она попала...
Зібрали найбільші українськомовні YouTube-канали, автори яких — ІТ-спеціалісти. Та наразі їх так мало, що в добірці, напевно, є всі,...
Я Натали Ростова, биздев в Pridis, нидерландской IT-компании, где удаленно из Киева работаю уже почти три года. А также...
Парламент не встигає у другому читанні проголосувати за урядовий законопроєкт № 8401 про скасування пільгової...
Яндекс.Метрика