Как Managed Kubernetes помогает бизнесу поддерживать доступность сервисов

Десять лет назад даже самые большие компании разрабатывали монолитные приложения и почти не задумывались, что с Managed Kubernetes может быть по-другому. Рынок IT-решений быстро развивался, а конкуренция вытесняла сервисы, которые не могли быстро масштабироваться и работали нестабильно. Какой прок от уникальных фичей, если ими нельзя воспользоваться, когда удобно?

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

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

Сами по себе микросервисы не решали проблемы как волшебная палочка. Например, ошибки с авторизацией могли привести к недоступности сервисов, но это уже проблема одного компонента, а не всего приложения — появился Damage Control. Получается, что монолит — это пережиток прошлого и всем нужны микросервисы? На самом деле, нет.

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

Выбор архитектуры зависит не только от задач проекта, но и от размера команды. Для команды от 2 до 5 человек работать с монолитом будет удобнее. Почему так?

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

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

На графике представлено примерное отношение стоимости строчек кода по мере развития проекта. Стоит выделить две закономерности:

• Чем больше прибавляется кодовая база в монолите, тем дороже окажется решение.
• Чем больше кода будет в микросервисах — тем меньше за это придется заплатить.

Монолит — это не приговор

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

Одной из первых больших компаний, которые перешли на микросервисную архитектуру, стала Netflix. Компания еще в 2009 году решила, что это технологическое решение поможет вырваться в лидеры стриминговых площадок, а в 2015 команда DevOps-инженеров даже получила JAX Special Jury Award за внедрение решения, которое позволило проводить деплой до тысячи раз в день.

Переход от монолита к микросервисам чаще проходит по двум сценариям — подход «большого взрыва» и пошаговый рефакторинг:

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

Когда команда выбирает путь рефакторинга, важно учесть следующие моменты:

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

Как устроена микросервисная архитектура и причем здесь контейнеры

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

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

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

Разницу с монолитом можно объяснить на примере кубиков. В микросервисах строится замок из одинаковых по форме контейнеров. В любой момент их можно добавить, если нагрузка на замок (проект) возрастает, или обновить, а пользователь не заметит замены. Монолит скорее похож на башню из Дженги. Кубики вынимать удобнее, но рисков больше.

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

При повышенной нагрузке контейнер может «сгореть» — это нормально. Чтобы восстановить функциональность, достаточно замены из образа.

На заре Kubernetes

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

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

За 9 лет Kubernetes прошел путь от частного решения и группы разработчиков из Google до стандарта. Решение оказалось удобно и для разработчиков, и для бизнеса. Впрочем, здесь есть неочевидные подводные камни:

• Компетентных специалистов тяжело найти.
• Не все могут себе позволить содержать свой отдел DevOps-инженеров.

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

Kubernetes как Managed Service

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

Чем будет полезен Managed Kubernetes в Servercore:

• Стартапы могут не тратить ресурсы на самостоятельное разворачивание и обслуживание кластера. За 11 лет команда накопила необходимый опыт, чтобы предоставлять надежное решение.
• Для среднего и крупного бизнеса это возможность создать отказоустойчивую платформу для работы в разных облаках, с разным кодом и ОС. Servercore помогает масштабировать вычислительные мощности без ограничений.
• Провайдер отвечает за доступность IT-инфраструктуры во всех регионах присутствия и занимается поддержкой актуальных версий Kubernetes.
• В Servercore можно настроить Kubernetes как решение с автохилингом кластеров. Это помогает менять сгоревшие контейнеры на новые автоматически и избегать даунтаймов.
• Через панель управления Servercore можно получить готовый кластер всего за пару кликов в любой зоне доступности: Кении (Найроби), Казахстане (Алматы) и Узбекистане (Ташкент).

Managed Kubernetes помогает использовать необходимые сервисы для работы с веб- или мобильными приложениями. Решение полностью совместимо с другими продуктами Servercore, поэтому его можно быстро развернуть и начать использовать.

Остались вопросы? Напишите нам. Наши технические специалисты отвечают 24/7.