Хотя многие команды в нативных облачных средах перешли от монолитов на микросервисы, этот выбор стоит рассмотреть подробнее, в частности, с точки зрения наблюдаемости, пишет на портале The New Stack Эрик Шабелл, директор по евангелизму компании Chronosphere.

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

Что такое микросервисы

Микросервисы — это современная архитектурная модель ИТ, которая позволяет ускорить процессы разработки ПО и сократить время вывода приложений на рынок. С широким распространением облачных вычислений подход, основанный на микросервисах, по сути, заменил монолитную архитектурную модель.

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

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

Преимущества микросервисов

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

Компонентные, или микросервисные архитектуры дают организациям множество преимуществ, в том числе:

  • Высокая надежность и масштабируемость. С помощью микросервисов команды могут масштабировать независимые сервисы, ориентированные на решение конкретных задач, и управлять этим опытом в сотрудничестве с операционными командами с помощью автоматизации и шаблонов.
  • Ускоренный выход на рынок. Команды, работающие над приложениями с развивающимися наборами функций, могут использовать модульность микросервисов в своих интересах, разделяя сервисы и автоматизируя доставку одних возможностей в производство быстрее, чем других (даже много раз в день), чтобы соответствовать меняющимся требованиям бизнеса.
  • Эффективное использование ресурсов. Поскольку микросервисы независимы, организации могут масштабировать отдельные микросервисы в своем собственном темпе, не прибегая к масштабированию всего приложения. Команды также могут выбирать собственные технологические стеки для создания микросервисов.
  • Более продуктивные команды. Микросервисы обычно создают и быстро развертывают небольшие команды, что делает организации более гибкими, а сотрудников — более продуктивными.

Недостатки микросервисов

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

  • Сложность. Наличие множества команд, независимо работающих над микросервисами, может привести к возникновению новых сложностей и увеличению затрат в жизненном цикле разработки. Из-за разрастания и снижения производительности команды могут столкнуться с тем, что в организации начнется перекладывание вины друг на друга.
  • Более высокие затраты и операционные накладные расходы. Отдельным командам для успешной работы требуются собственные системы, ПО, инфраструктура и операционные процессы, что может привести к увеличению расходов как на оборудование, так и на лучших специалистов.
  • Проблемы наблюдаемости. Хотя компоненты приложений в микросервисных архитектурах проще, чем в монолитных, запросы на выполнение работ здесь сложнее. Это может затруднить обнаружение проблем в архитектуре микросервисов. Отслеживание запроса в сложной и расширяющейся архитектуре микросервисов в организации является одним из наиболее технически сложных аспектов решения по обеспечению наблюдаемости в облаке.
  • Единороги. Отсутствие стандартизации между командами и системами может привести к тому, что организациям придется поддерживать уникальные среды для поддержки широкого спектра приложений.

Что такое монолитное приложение

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

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

Преимущества монолитной архитектуры

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

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

Недостатки монолитной архитектуры

Монолитный подход похож на «складывание всех яиц в одну корзину»: он хорошо работает до тех пор, пока не произойдут существенные изменения, например, командам нужно быстро добавить новые возможности, требуется масштабирование или снижается производительность. Вот некоторые из недостатков монолитной архитектуры:

  • Медленный выход на рынок. Поскольку весь код должен быть спроектирован, разработан и развернут в определенной последовательности и в виде единого пакета, может потребоваться больше времени для вывода на рынок новых возможностей, отвечающих требованиям клиентов или сотрудников. Тесная интеграция компонентов монолитного приложения затрудняет изменение любого аспекта решения и от этого становится тем хуже, чем дольше срок службы монолита.
  • Проблемы Dev vs. Ops. Команды разработчиков тесно сотрудничают при выпуске монолитных приложений до момента их запуска в производство, когда ПО передается операционной команде для долгосрочной поддержки, включая исправление ошибок и повышение производительности. По мере роста кода управлять им становится все сложнее, а подключение ресурсов для устранения неполадок требует много времени.
  • Препятствия при масштабировании. Монолитные архитектуры имеют тесно связанные между собой программные компоненты, работа которых зависит друг от друга. Эффективное масштабирование практически невозможно. При замедлении работы или поломке одного из компонентов все приложение может перестать функционировать должным образом.

Различия микросервисной и монолитной архитектур

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

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

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

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

Выбор архитектуры микросервисов

Организациям следует обратить внимание на архитектуру микросервисов, если им необходимы:

  • Быстрый выпуск программных функций (в качестве нового или в существующее приложение). Микросервисы ускоряют время выхода на рынок, позволяя разработчикам независимо друг от друга параллельно работать над новыми возможностями и быстро объединять эти сервисы в одно целое в производстве.
  • Масштабирование приложения при свободе выбора. Команды могут использовать те инструменты, которые им нравятся и нужны для быстрого добавления множества микросервисов и масштабирования приложения в соответствии с неожиданными и/или меняющимися требованиями.
  • Повышение надежности и отказоустойчивости. Поскольку микросервисы представляют собой отдельные фрагменты кода, приложения могут продолжать работать даже в случае отказа одного из них.

Выбор монолитной архитектуры

Организациям следует придерживаться монолитной архитектуры, если им необходимо:

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

Чем может помочь наблюдаемость

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

Монолитный архитектурный подход обеспечивает прямолинейный вызов приложения, что позволяет легко найти точное место возникновения проблемы с помощью базового ПО для мониторинга производительности приложений (APM). В отличие от этого, нативное облачное приложение — и его многочисленные контейнеры — эфемерны, а значит, существует больше возможных источников и мест возникновения проблем. Именно поэтому командам, внедряющим микросервисы, необходима наблюдаемость нативных облачных приложений с возможностью распределенной трассировки. Последняя показывает командам, где именно возникает проблема, чтобы они могли быстро устранить ее.

Почему распределенная трассировка является ключом к наблюдаемости распределенных нативно-облачных систем? То, что было одним отслеживаемым запросом в рамках монолита, который можно было увидеть с помощью APM, здесь превращается в затянувшуюся «игру в телефон», когда для выполнения одного первоначального запроса к сервисам нужно сделать несколько запросов. То, что обеспечивало наблюдаемость монолита, — фокусировка на одном компоненте и взаимодействии внутри него — в современных нативно-облачных системах является лишь частью пазла.

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

Благодаря наблюдаемости инженеры могут:

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

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