Всем привет! Меня зовут Максим Еремин, я занимаюсь развитием платформенных продуктов в beeline cloud. В этой статье поговорим про контейнерную разработку в облаках, рассмотрим, в каких реалиях живут облачные провайдеры, включая российских игроков и гигантов зарубежного рынка.
Отдельно расскажу про особенности serverless-подхода. А если вы хотите узнать о serverless больше, погрузиться в DevOps-практику и посмотреть демо по управлению контейнерами — жду вас на вебинаре «Easy to use: управление контейнерами в облаке», который пройдет 30 мая в 11:00 мск. Приходите — пообщаемся в онлайне ????
Микросервисы как стандарт де-факто
Разработка микросервисных приложений уже стала стандартом в различных отраслях бизнеса. Постоянные нагрузки на онлайн-сервисы растут с каждым годом, и для обеспечения бесперебойной работы приходится обращаться к реализации сервисов по принципу Highload.
В такой среде используются более сложные подходы, чем просто хостинг сайтов или чуть более гибкой инфраструктуры с виртуальными машинами. Обычно проще использовать платформенные сервисы, которые обеспечивают доступность и решают множество задач по организации инфраструктуры «из коробки». Так вы можете сконцентрироваться на разработке и эксплуатации собственного продукта без затрат на дорогостоящие ресурсы, в том числе человеческие.
Как дела у провайдеров
Сегодня трудно представить крупного облачного провайдера без платформенных сервисов для разработки, в задачи которых входит:
размещение и эксплуатация веб-приложений;
мониторинг;
масштабирование;
CI/CD;
контейнеризация.
Одним словом, большую часть DevOps-задач уже сейчас можно переносить в облако, не тратя свое время на проработку инфраструктуры и ее эксплуатацию.
Отдельно стоит отметить контейнеризацию, которая за последние лет пять уже стала своего рода стандартом при разработке микросервисных приложений. Она позволяет грамотно разделить зоны ответственности между участниками большой команды разработки, упрощает эксплуатацию приложения и нивелирует риски «сложить» все приложение при добавлении новых фич в продукт.
Вышеперечисленные задачи выполняют такие сервисы, как Docker, Kubernetes, Gitlab, развернутые в облаке. Они помогают закрыть практически 80% вопросов по эксплуатации и разработке продукта. У многих облачных провайдеров (в основном зарубежных) за долгие годы накопились собственные продукты, позволяющие улучшить качество разработки для компаний.
Например, Google разработал Kubernetes как раз для облачных сред, но при этом он стал opensource-продуктом, а Azure DevOps — чисто вендорский облачный сервис, который закрывает все стадии разработки, начиная с планирования, заканчивая мониторингом.
Не только ваниль, или Куда смотрят зарубежные гиганты
Обратимся к опыту зарубежных коллег на примере трех ведущих провайдеров: Microsoft, Google и Amazon. Помимо классического ванильного Kubernetes они предлагают множество его реализаций и сервисов вокруг высоконагруженного кластера. Некоторые из них переосмыслили подход к облачным вычислениям, перейдя от выделенных ресурсов к «бессерверным вычислениям».
С одной стороны, может показаться, что это очередная модная и никому не нужная фича, которая вряд ли приживется в реалиях крупных клиентов. Но когда компания или команда разработки находится на стадии проверки гипотез или имеет небольшой проект, для которого не важны такие моменты, как жесткая сетевая связность или хранение персональных данных, работа с serverless гарантирует совершенно новый опыт работы с облачными сервисами.
Рассмотрим core-сервисы, которые есть у топовых зарубежных облачных провайдеров для контейнерной разработки.
Azure
Azure Kubernetes Services
Container Registry
Web App for Containers
Container Instances
Container Apps
Functions
DevOps
Service Fabric
AWS
Elastic Container Registry
Elastic Container Service
Elastic Kubernetes Service
App Runner
Fargate
Copilot
App2Container
Lambda
GCP
Kubernetes Engine (GKE)
Container Registry
Cloud Run
Knative
Kubernetes Applications
Многие из этих сервисов могут быть знакомы вам не понаслышке. Kubernetes и веб-приложения всегда были одними из самых потребляемых сервисов в облаках.
Что касается классического K8S — это стандартный кластер, «растянутый» на несколько виртуальных машин, управляемых либо клиентом, либо провайдером — в зависимости от настройки сервиса. Возможно, у каждого вендора есть свои доработки в рамках того, какая сеть будет внутри Kubernetes (например, в Azure вместо классической кубовой сети используется Azure DNS), какой подход к эксплуатации самих контейнеров, а также системы мониторинга и логирования, что у каждого из перечисленных провайдеров уже давным-давно свое и самописное.
Также стоит отметить, что вокруг K8S у всех трех провайдеров уже хорошо выстроена экосистема сопутствующих сервисов. Ведь ванильный K8S — это еще полдела. Обычно нужно проработать схему хранения артефактов, образов контейнеров, кода, процессов сборки и релиза.
Хорошим примером может стать Azure DevOps, который максимально покрывает DevOps-процесс набором подсервисов. Здесь сразу же предлагается подвязывать артефакты планирования к коммитам в коде, подтягивать этот код на сборку, тестировать на предмет ошибок и нестандартных ситуаций, а потом отправлять на релиз и деплой.
У AWS есть схожесть с продуктом от Microsoft. Самое интересное, что такие сервисы у всех озвученных вендоров гладко взаимозаменяются и интегрируются друг с другом (например, можно использовать Azure DevOps для деплоя кода в инфраструктуру GCP или AWS). То есть, по сути, отсутствует жесткий Vendor Lock.
Я устал, я ухожу… в serverless
Последние несколько лет на зарубежном рынке облаков явно просматривается история с полным отказом от контроля за инфраструктурой или хоть какими-то ресурсами со стороны разработчиков. Если классические web-app’ы или Kubernetes — это всегда что-то связанное с ограничением ресурсов, оплатой за масштабирование в размере стоимости ядер и оперативной памяти, то такие сервисы, как Azure Functions или AWS Lambda, предлагают совершенно другой подход — бессерверный.
Возможно, многим такой подход покажется странным, поскольку никто не знает, на каких ресурсах и на каком железе это все работает и как там дела с отказоустойчивостью. Но обычно это оказывается значительно дешевле и оптимальнее для проверки гипотез и MVP для различных бизнес-задач.
Зачем покупать дорогостоящую инфраструктуру или платформу, если можно просто развернуть одну «функцию», написать какой-то код и посмотреть, как это работает? Идея вроде интересная, но тут можно столкнуться с жестким Vendor Lock. Ведь вам придется потратить время, чтобы разобраться с нюансами работы таких сервисов.
Лично я, работая с Azure Functions, нашел множество подводных камней в интерфейсе сервиса при написании кода. Было совершенно непонятно, как правильно работать с переменными среды на ранних версиях сервиса. А позже возникли вопросы с выполнением функций, жестко привязанных к местному времени, когда сама функция хостится где-то между Нидерландами и Дублином, а ваше московское время всегда придется учитывать при отправке уведомлений по триггеру или по таймеру.
Следующим витком развития этих двух концепций стали контейнерная и бессерверная разработка, которые фактически ознаменовали появление бессерверных управляемых контейнеров и бессерверных Kubernetes. В основе лежит та же идея, что и в Functions и Lambda. Только теперь мы не просто запускаем голый код сразу в загадочной исполняемой среде вендорского облака, а оборачиваем его в абстракцию, унифицированную для любого кода и любой платформы. Этим всегда проще управлять и проще переносить с облака на облако (вплоть до конечного переноса в собственную on-premise-инфраструктуру, если это необходимо).
Основная идея работы такой концепции лежит где-то посередине. Если в классическом Kubernetes или сервисе запуска контейнеров вам выдавались конкретные объемы от конкретных виртуальных машин, то теперь это выглядит иначе. Вы получаете определенную квоту ресурсов, гибко изменяющихся по запросу, и используемую абстракцию «под капотом». При этом мы как разработчики не видим, на каких конкретно виртуальных или физических машинах все это запускается и работает. Мы работаем с таким окружением как с обычным кластером Kubernetes.
Бизнесово же мы совмещаем решение наших DevOps-задач, закрываем нехватку компетенций и снижаем затраты на инфраструктуру. Примеры таких сервисов у зарубежных коллег: Azure Container Services, AWS Fargate, GCP Knative. Использование этого подхода дает больше эластичности для масштабирования разработанного продукта при изменении нагрузок и позволяет считать затраты по модели Pay-as-you-go.
Кубер в России — классика снова побеждает
А что происходит на рынке в РФ? Сейчас у нас много различных облачных провайдеров, которые предлагают услуги контейнерной разработки в облаке, но массово пока используются классические выделенные K8S-кластеры. Причин тому может быть несколько:
У клиента уже есть своя IaaS-инфраструктура в облаке провайдера и ему необходима жесткая сетевая связность.
Нежелание делить с кем-то облачные ресурсы, работая в «коммуналке».
Недоверие к высокому уровню абстракции, желание контролировать все — вплоть до ОС на виртуальных машинах, поднятых внутри Kubernetes, хоть и руками провайдера.
Но такие подходы бывают достаточно дорогими для сегмента SMB. В их интересах обычно лежит проверка каких-то гипотез через разработку и быстрый старт продукта либо решение определенных задач с низким потреблением ресурсов, что не повлечет вышеописанных проблем. Хотя некоторые точечные подходы уже существуют у отечественных облачных провайдеров. Например, Yandex и VK давно предлагают услугу брокеров сообщений, которые в целом похожи на бессерверные вычисления.
Мы в beeline cloud экспериментируем с данными подходами и смотрим в сторону бессерверных вычислений. Недавно мы запустили продукт Cloud Managed Kubernetes, который находится где-то посередине между классическим Kubernetes и бессерверным запуском контейнеров. Подробнее об этом сервисе я расскажу на вебинаре 30 мая. Приходите — отвечу на ваши вопросы.