От простого к сложному: путь от монолита к микросервисам
Привет! Я Александр Павленко, 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 человек. Добавились бэкенд-разработчики и бизнес-аналитики, заточенные под определенные спецификации.
Появились нюансы, усложняющие поддержку безопасности транзакций. В случае с микросервисами мы имеем дело с децентрализацией данных. Также, прежде чем писать код, разработчикам надо помнить о возможной несогласованности.
Не обошлось без сложностей для новых членов команды. Им нужно больше времени, чтобы понять, как микросервисы между собой взаимодействуют и делают ли это вообще. Насколько глубоко начинающий разработчик должен в этом разбираться? Чем разнообразнее база знаний, тем специалист ценнее на рынке и может оперативнее реагировать на изменения в проекте.
Когда есть с чем сравнивать, намного легче среди нескольких вариантов выбрать наиболее подходящий в текущий момент. Поэтому как минимум ознакомиться с этим архитектурным подходом я советую всем. Новичок может начать с более простых вещей — с монолита, но помнить, что когда-нибудь придется углубиться в микросервисы. Все-таки тренды индустрии никто не отменял.
Монолит словно здоровенный котел, в котором варится сразу много всего. С появлением новых «ингредиентов» мы пытались все структурировать. Но помешивая этот «суп», затрагивали другие «ингредиенты», даже когда это не требовалось. Микросервисы помогли создать современную технологическую кухню и разделить зоны функциональности. Мы уже не только «варили», но и «запекали», «кипятили», где-то «жарили», а где-то только «подогревали». Познав тонкости этой высокой кухни, в результате получили качественные продукты.
Монолит или микросервисы: что лучше
Универсального ответа нет, как и окончательного решения. В тех или иных ситуациях бывает логичнее стартовать с монолита. В будущем система может достичь таких масштабов, что переход к микросервисам неизбежен. Из личного опыта я отметил пару сценариев, в которых стоит задуматься о переходе на микросервисы:
- когда в монолитном проекте стоимость нового функционала не перекрывает ожидаемую пользу;
- когда проект разрастается до такой глыбы, что новые люди в команде теряются. В микросервисах можно взять отдельный компонент, определить, что в нем происходит, и работать только с ним. В крупных проектах разделение обязанностей рано или поздно приведет к архитектурным разграничениям. Микросервисы позволяют легче пережить этот момент.
Иногда мы сталкиваемся с настойчивыми клиентами, которые отказываются от здравой идеи разработчиков. Вот вздумалось заказчику только эту технологию или архитектуру применять. Почему? Да потому что. «Слышал в интернете» или «все так делают». Клиент редко задумывается о подводных камнях, на которые могут наткнуться программисты.
Если вы видите, что есть более эффективный подход, что идея заказчика вызовет новые проблемы или вообще остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав. Объясните, почему лучше использовать ту или иную технологию. Как показывает практика, когда вы можете аргументировать преимущества своей идеи и недостатки предложенного заказчиком решения, он спокойно примет вашу сторону. Проект — это его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.
Мы разработали много спецификаций, которые жили обособленно и полноценно не взаимодействовали друг с другом. А как только разбили их на независимые микросервисы, получили высокие показатели в перформансе и счастливого заказчика, который приумножил прибыль.
Мой основной посыл — не сравнивайте, а подстраивайтесь под особенности проекта и бизнес-задачи. Выбирайте архитектуру приложения взвешенно. Подходящий вариант упростит жизнь вам, команде и пользователям. Да и в целом сделает проект успешнее.
