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

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

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

Возникает ряд трудностей:

Монолитная модель плохо масштабируется, поэтому компании переходят на контейнеры и оркестрацию через Kubernetes. Это закономерный этап для бизнеса. Такое решение изолирует компоненты, автоматизирует управление ресурсами и упрощает поддержку продукта. Например, в 2017 году компания Adidas перенесла интернет-магазин в Kubernetes. В результате релизы стали выходить не каждые 4-6 недель, а 3-4 раза в день. Сайт стал загружаться в два раза быстрее, а его работа стала более отказоустойчивой. Или, например, известная онлайн-платформа Reddit до 2016 года существовала в виде монолитного приложения с небольшой командой инженеров. Однако когда количество сотрудников и изменений в разные компоненты платформы значительно выросло, команда решила перейти на архитектуру микросервисов, что упростило запуск новых сервисов, повысило их доступность и производительность.

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

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

Кроме того, это дает принципиально другой ритм: команды могут разрабатывать, тестировать и развертывать части приложения отдельно от остальных, а продукт становится гибким и легко масштабируемым. Например, облачная платформа для управления подписками AppDirect после перехода на Kubernetes увеличила количество релизов со 130 до 1600 в неделю. Это позволило командам работать автономно и быстрее выводить обновления на рынок.

Во многих отраслях сбой в работе цифровых сервисов приводит к прямым финансовым потерям. Например, компании Amazon час простоя обойдется примерно в $13 млн, а обычной крупной компании, согласно данным исследования EMA Research, в среднем в $23 750. Сбой платежной системы в разгар «Чёрной пятницы» будет еще более болезненным. В чувствительных к SLA индустриях, например, e-commerce, финтехе, логистике и медиа, базовым требованием к инфраструктуре становится устойчивость.

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

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

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

онлайн-магазин в будни и в дни распродаж — это разные размеры инфраструктур; B2B-сервисы днём работают с полной нагрузкой, а ночью почти не используются; корпоративные приложения фиксируют всплеск посещаемости и увеличение потока данных в начале и конце месяца, а бухгалтерские — только в периоды сдачи отчетности, но ресурсы для них закуплены на весь месяц. Kubernetes решает эту задачу за счет автомасштабирования. Он следит за реальной нагрузкой и автоматически увеличивает или уменьшает объем ресурсов без вмешательства инженеров. В облачной среде это особенно эффективно: компания платит только за то, чем действительно пользуется.

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

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

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

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

Переход можно начать с пилотных кластеров или облачных сервисов вроде Kubernetes as a Service, при этом установку, настройку, обслуживание и обновление всех компонентов инфраструктуры кластера берет на себя облачный провайдер. Это позволяет разработчикам сосредоточиться на написании кода, бизнес-логике продукта и более быстром выводе приложений на рынок. Главное — внедрять Kubernetes не потому, что модно, а потому что по-другому уже не работает.