Отношение бизнес- и ИТ-сообщества к микросервисной архитектуре разработки приложений сегодня столь же противоречиво, как в свое время к RPA. Энтузиасты называют монолитные приложения атавизмами уходящей эпохи. В то же время не всем, кто принял решение о переходе на микросервисы, удается окупить вложения в них.
Потребность в микросервисной архитектуре приложений возникла совсем не спонтанно. ИТ-инфраструктура становится с каждым годом всё сложнее, обрастает новыми системами и сервисами. Объемные приложения с большим количеством взаимодействующих между собой функциональных модулей, большие команды разработчиков, создающих проект, требования к скорейшему выпуску и своевременному обновлению приложений, необходимость периодического масштабирования отдельных модулей – всё это предпосылки к тому, чтобы серьезно задуматься о разработке приложений на микросервисной архитектуре с нуля или перестраивании на микросервисы уже существующей монолитной структуры.
Слабые стороны монолита
Проблема при разработке и поддержке приложения с монолитной архитектурой может возникнуть, в частности, в момент слияния веток – merge conflict, когда несколько программистов одновременно модифицируют один и тот же участок кода. Этот недостаток некритичен, но увеличивает время разработки, особенно если в приложение добавляется новый модуль: например, функциональность доставки товара со склада интернет-магазина дополняется модулем закупки или аналитики.
Проблема масштабируемости (scalability) приложения появляется, когда количество его пользователей начинает расти, причем выстреливший стартап зачастую демонстрирует очень активную динамику. Некоторые модули монолита могут иметь специальную архитектуру, которая будет обеспечивать высокие нагрузки, но масштабировать в любом случае придется всё приложение целиком. В монолите мы не можем отдельно поменять архитектуру только высоконагруженных модулей. Эту ситуацию можно образно сравнить, к примеру, с развивающейся сетью магазинов, у которых единая служба бухгалтерии: в случае монолита при масштабировании приложения нам пришлось бы в каждый из этих магазинов добавить бухгалтера, несмотря на то что с ростом количества покупателей нагрузка на этот отдел осталась прежней. То же происходит с приложениями: некоторые модули с постоянной нагрузкой удобнее выделить в отдельные микросервисы.
Приложения с монолитной архитектурой предполагают единую базу данных, причем они взаимодействуют с хранилищем только синхронно, запросы выполняются последовательно. И это узкое место любого монолитного приложения. В микросервисной архитектуре у каждого микросервиса своя база данных и такой проблемы не существует.
В классической монолитной архитектуре невозможно одновременное использование разных языков программирования. Например, если весь проект написан на Java, а модуль для бухгалтерии выгоднее и актуальнее написать на Go, то осуществить это будет проблематично.
Отказоустойчивость монолитного приложения обеспечить сложнее, чем микросервисного, поскольку при сбое единой базы данных все его модули становятся неработоспособными. Выход из строя базы данных одного из микросервисов не так сильно повлияет на остальные.
Нюансы микросервисов
Наличие трудностей, с которыми сталкиваются разработчики современных монолитных приложений, не означает, что микросервисная архитектура однозначно подойдет компании лучше. Дело в первую очередь в том, что каждый микросервис всегда снабжен определенной обвязкой – собственным сервером приложений (application server), собственной базой данных и т. д. Получается, что при той же функциональности приложения ресурсов на него (серверных мощностей, затрат на поддержку системы) при микросервисной архитектуре уходит больше, чем при монолитной. В том числе потребуются дополнительные ресурсы для того, чтобы обнаружить новый микросервис в рамках одного приложения и связать с остальными. В большой системе необходимы специальные инструменты для того, чтобы отслеживать появление новых сервисов и организовывать их взаимодействие (например, REST или gRPC).
В микросервисной архитектуре сложнее организовать балансировку нагрузки приложения. Запрос, поступивший приложению (например, заказ товара от пользователя на сайте интернет-магазина), должен определенным образом маршрутизироваться, чтобы попасть в нужный микросервис, тогда как в монолите все запросы приходят в одну точку и легче обрабатываются.
Следующий нюанс связан с распределенными транзакциями – когда для проведения одной операции необходимо обеспечить атомарность операций, выполняющихся на разных микросервисах. К примеру, организовать возврат перевода денег со счета клиента в рамках единой базы данных банку будет проще, чем обеспечить взаимодействие нескольких микросервисов.
При тестировании нового релиза в микросервисной архитектуре необходимо учитывать, каким образом изменения одного микровервиса повлияют на работу других. В случае с монолитом мы можем прогнать unit-тесты один раз. В микросервисной архитектуре, кроме того, процессы обеспечения безопасности приложения и его мониторинга нужно умножать на количество входящих в него микросервисов.
Переход на микросервисы: за кем последнее слово?
С развитием ИТ потребность компаний, разрабатывающих собственный софт, в альтернативе монолитной архитектуре приложений стала проявляться всё отчетливее. В России такие компании, как «Леруа Мерлен», «Спортмастер», «М.Видео-Эльдорадо», «МегаФон», успешно переносят на микросервисы модули своей разветвленной ИТ-инфраструктуры. Новые разработки, как правило, сразу начинаются с микросервисов – с нуля это делать проще. Облачные PaaS-сервисы для разработчиков, изначально заточенные под микросервисную архитектуру, могут стать хорошим вариантом для решения описанных выше проблем с мониторингом, безопасностью, масштабированием приложения, особенно если в штате компании нет команды DevOps и Database Administrator.
С другой стороны, многие крупные компании, чьи бизнес-процессы глубоко завязаны на монолитные системы (чаще всего промышленные решения), не спешат от них отказываться. Большинство банков, в свою очередь, используют комбинированную архитектуру.
Нет определенного набора паттернов, «примерив» который на свою компанию, можно с уверенностью сказать: мы готовы к переходу на микросервисную архитектуру. Всё зависит от специфики бизнеса, наличия специалистов и необходимых ресурсов, параметров ИТ-систем, политики и участия руководства. Если такое решение все же принято, возникает другой вопрос: каким образом реализовать этот проект? Необходим прежде всего качественный аудит бизнес-процессов и выбор тех из них, которые должны быть автоматизированы с помощью микросервисов.
Компетенции ИТ-команды – ключевой фактор успеха при переходе от монолита к микросервисам. Например, если разрабатывать микросервисы берется группа, которая до этого занималась только поддержкой монолита, они могут допустить критичные для бизнеса ошибки. Случаи, когда бизнес терял время и деньги из-за неопытности исполнителей или недостаточной проработки проекта, нередки. Другой вариант – привлечение профессионального ИТ-архитектора, который проведет комплексный анализ системы, учтет все нюансы и организует работу команды. Но и в этом случае есть риск: бизнесу придется довериться одному дорогостоящему специалисту, найти которому замену в случае форс-мажора будет нелегко.
Как показывает практика, при внедрении микросервисной архитектуры наиболее целесообразно воспользоваться услугами компании, занимающейся ИТ-консалтингом или системной интеграцией, где работают эксперты с опытом миграции ИТ-инфраструктуры разной сложности. Микросервисная архитектура при всех ее преимуществах требует профессионального подхода и участия квалифицированных специалистов на всех этапах проекта: выбора решения, непосредственно миграции, сопровождения системы и обучения специалистов заказчика.
Переход на микросервисную архитектуру приложений позволит компании обеспечить условия для роста – гибкость, масштабируемость, отказоустойчивость систем. Однако для достижения желаемых результатов необходимы серьезный, комплексный подход и значительные организационные изменения.