Как строить бизнес-приложения: микросервисы, монолит и Kubernetes — легкое погружение с нуля

С чего начать и как не допустить ошибок при создании приложений? Поговорим о том, что такое монолиты и микросервисы, контейнеры и Kubernetes. Преимущества, недостатки технологий, и причем здесь облачные провайдеры.

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

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

Монолитная структура имеет ряд преимуществ. Она ускоряет разработку MVP (minimum viable product, минимально жизнеспособный продукт) и сокращает время от начала разработки до конечной реализации [time-to-market] на ранних этапах развития продукта.

Развернуть его тоже легче — часто монолитный сервис представляет собой единственный файл в формате WAR (запакованное веб-приложение). Однако есть у такой архитектуры и серьёзные недостатки:

• Монолитные приложения сложно поддерживать.

Да, монолит ускоряет разработку минимально жизнеспособного продукта, но за оптимальный старт приходится платить. Монолиты имеют тенденцию превращаться в «большие комки грязи» (забавно, но это настоящий термин), кодовая база становится неповоротливой, а модификации — трудоемкими. На запуск новых функций у команды разработки может уходить месяцы.

• Трудно масштабировать.

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

• Нет изоляции.

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

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

Альтернативная архитектура, которая предполагает принципиально иной подход к разработке — микросервисы. В этом случае каждую функцию приложения выполняет независимый компонент со своей логикой. Их называют контейнерами и они, как правило, содержат относительно небольшие объемы кода. Такие контейнеры «общаются» друг с другом через сеть по API. При необходимости их можно подключать, отключать и модифицировать по отдельности.

Подход имеет ряд преимуществ:

• Разделение труда.

За каждую функцию может отвечать отдельная команда разработки. При этом проблемы в одном модуле не отражаются на всем приложении. Если компонент «отвалился», то пока он перезагружается, сервис продолжит работу.

• Простота масштабирования.

Представим, что в интернет-магазине есть программа лояльности «Бонус за покупку». У неё под капотом находятся личные кабинеты пользователей с количеством баллов, личные кабинеты партнеров и так далее. С ростом нагрузки на сервис начисления бонусов можно предоставить ему дополнительные ресурсы, а остальные компоненты оставить как есть. В случае с монолитом пришлось бы запускать еще один инстанс (копию).

• Обновления можно вносить по частям.

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

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

Инфраструктура крупных компаний может содержать тысячи контейнеров и виртуальных машин, число которых постоянно меняется в течение дня. Как понять, какие необходимо перезапустить, какие масштабировать, а какие — удалить?

Взаимодействием контейнеров управляют специальные системы — оркестраторы. Среди них можно выделить HashiCorp Nomad, Docker Swarm и Kubernetes.

Kubernetes является одним из наиболее известных open source решений и входит в топ-3 самых быстрорастущих проектов на GitHub.

В некотором смысле Kubernetes стоит рассматривать как инструмент для масштабирования. Система понимает, что нагрузка на инфраструктуру возросла и подключает дополнительные ресурсы. Но на этом его возможности не заканчиваются, он также:

• Контролирует количество реплик.

Если один экземпляр сервиса «упадет», то второй продолжит работу. За процессом следит Kubernetes, восстанавливая недостающие реплики.

• Работает с данными.

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

• Балансирует нагрузку.

Когда на приложение поступает большое количество запросов (например, с появлением сезонного спроса в интернет-магазине) Kubernetes распределяет его между репликами, при необходимости запускает новые.

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

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

Эту точку зрения поддерживает программист Мэт Рикард, который долгое время работал над Kubernetes в Google. По его словам, компаниям следует органически дорасти до технологий оркестровки и расширять инфраструктуру по мере увеличения нагрузок и команды. С этим может помочь облачный провайдер, который возьмет часть нагрузки по администрированию Kubernetes на себя.

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

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

Разработчики могут не знать (и чаще всего не знают) тонкости устройства виртуальной ИТ-инфраструктуры. Этими вопросами займутся наши квалифицированные специалисты. Да, какой-то навык работы с Kubernetes в компании все равно будет нужен, но число необходимых администраторов, DevOps-инженеров будет сильно меньше. Бизнес может сфокусироваться на профильных задачах — процессах, приносящих деньги. То есть заниматься разработкой софта, а не углублением экспертизы в Kubernetes.