Привет! Меня зовут Андрей Квапил (или kvaps). Я CEO в Ænix, и мы делаем Open Source-платформу и фреймворк Cozystack, с которым очень удобно строить облака. В этой статье я проанализировал, как современные облачные подходы повлияли на инфраструктуру, какую роль стала играть виртуализация и что происходит с локальными сервис-провайдерами.

Главный вызов для локальных сервис-провайдеров

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

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

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

Именно поэтому клиенты сервис-провайдеров постепенно переходят от модели IaaS (в которой им по-прежнему приходится отвечать за операционную систему и высокоуровневые инфраструктурные сервисы) к более высокоуровневой PaaS, оставляя за собой только работу с данными и собственными приложениями. Сервис-провайдер же в модели PaaS уже не только управляет инфраструктурным уровнем, но и предоставляет бизнесу managed-сервисы, которые можно заказывать так же просто, как и любые другие инфраструктурные сущности вроде виртуальных машин.

Все эти изменения очень сильно повлияли и на роль виртуализации. Сейчас виртуальные машины утрачивают популярность и всё чаще вместо них используют managed-сервисы: managed Kubernetes, Database-as-a-Service, managed cache, queues и прочие. Естественно, это ставит облачные платформы вроде AWS, GCP, Azure в заметно более выгодное положение по сравнению с традиционными провайдерами (особенно локальными, у которых нет такой развитой инфраструктуры): в то время как гиперскейлеры благодаря мощным вложениям и огромным командам разработки успели создать, протестировать и полноценно запустить свои PaaS-решения, локальные сервис-провайдеры, не имея сравнимых ресурсов, зачастую всё ещё покрывают лишь базовый уровень IaaS, оставаясь в этой технологической гонке в роли догоняющих.

Давайте разберемся, как индустрия пришла к текущему состоянию, откуда взялись бесконечные “as-a-Service” и что могут сделать локальные провайдеры, чтобы составить достойную конкуренцию техногигантам, прочно обосновавшимся на рынке. 

С чего все начиналось: когда сервер — это просто pet

Изначально вся серверная нагрузка запускалась только on-site: интернет был медленным и нестабильным, а публичные сервисы существовали в рамках университетов и крупных организаций. Железо чаще всего размещалось in-house — то есть в собственной серверной — и управлялось системным администратором. Виртуальных машин тогда не существовало в принципе. Каждый сервер настраивался вручную и выполнял сразу несколько различных функций, то есть на нем приходилось запускать несколько приложений — изолирование их друг от друга тогда не было стандартной практикой. Да, можно было запускать одно приложение на одном сервере, но в таком случае железо простаивало впустую, и а такую роскошь могли позволить себе только крупные корпорации. С масштабированием всё тоже было очень непросто.

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

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

• Установить операционную систему.

• Настроить сеть.

• Установить и настроить одно или несколько приложений.

А после настройки и запуска всю эту систему надо было поддерживать, дебажить проблемы, и заботиться о сервере так, как будто бы это домашний питомец (pet): холить и лелеять его, поднимать, когда он падал и делать всё, чтобы он не упал снова.

Появление виртуализации

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

В результате появилось множество платформ, заточенных именно под виртуализацию инфраструктуры (VMware, Hyper-V, Xen, Proxmox). Такие платформы предоставляли инструменты для автоматизации деплоймента, сети и даже шаблоны виртуальных машин. Однако подходы к использованию виртуальных машин оставались прежними: всё еще приходилось следить за каждой ВМ и ее жизненным циклом. Установка ОС, как правило, производилась с помощью CD-ROM, хоть и виртуального, с последующей настройкой вручную или с помощью конфигураторов.

Но даже если упростить процесс установки ОС путем клонирования готовых образов с предустановленной системой, такие виртуальные сервера, продолжали рассматриваться и работать как “pets”. Если ВМ умирала, вслед за ней отправлялись в небытие запущенные внутри нее приложения. То есть это всё еще была модель “pet”.

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

Переход от виртуализации к облакам

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

Благодаря тому, что за такую модель клиенты голосовали деньгами, провайдеры начать активно развиваться и строить надежные центры обработки данных, проектировать отказоустойчивые системы хранения данных и сети. Появился целый класс платформ виртуализации, построенных по новому принципу — они предоставляли инфраструктуру как сервис (IaaS). В этой связи стоит упомянуть такие платформы, как OpenStack, OpenNebula, CloudStack — они заточены под запуск большого количества VM и оперировали такими сущностями как темплейты, golden image, ресурс пуллы, flavor, instance и instance type.

Новое поколение платформ уже не ставило перед собой цели заботиться о “pets”, напротив, они оперировали инфраструктурой по другому принципу — просто предоставляя пользователям интерфейс для утилизации ресурсов облака. Виртуальные машины перестали восприниматься как виртуальный аналог железного сервера с приложением и превратились в инструмент для отрезания и использования «кусочков» железной инфраструктуры. «Смерть» виртуальной машины перестала быть значимым событием, поскольку в облаках приложения чаще всего запускаются на множестве ВМ и стали гораздо менее чувствительны к сбоям.

Парадигма была пересмотрена и сдвинулась в сторону автоматизации, когда пользователь может по запросу заказать себе любой виртуальный сервер в облаке и получить готовую систему. Пользовательские данные при этом чаще всего выносятся за пределы системного диска виртуальной машины, на отдельные persistent volumes и внешние хранилища. То есть виртуальные машины из конечной сущности превратились скорее в юниты, смысл существования которых — поставка вычислительных ресурсов (CPU, RAM и т.д.), в то время как данные уже надёжно хранились в отдельном месте.

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

Infrastructure as Code

Когда мы взаимодействуем с облачными платформами, веб-интерфейсы удобны разве что в качестве инструментов визуализации, при этом инженеры предпочитают работать с API. Это понимают и ведущие облачные провайдеры, поэтому AWS, GCP и Azure предоставляют своим пользователям удобные API.

Для управления IaC можно использовать инструменты вроде Terraform: он позволяет описать потребности приложения и быстро разворачивать дев, стейдж и продакшен-окружения. Кроме того, такой подход позволяет более эффективно тестировать новые фичи путем развертывания идентичных окружения, что в итоге позволяет избегать неприятных сюрпризов в продакшене. А тот же Ansible и другие CMS позволяют настраивать операционную систему и деплоить софт внутри виртуальных машин. Такой паттерн популярен и сейчас, хотя все чаще бизнес прибегает к технологиям контейнеризации. 

Итак, проблема автоматизации запуска инфраструктуры была решена, и индустрия сосредоточилась на следующей задаче: мы научились создавать инфраструктуру, но сущности внутри нее не были автоматизированы. Дело в том, что помимо декларативно описанной инфраструктуры оставалась ещё куча императивной логики, как например настройка и обновление ОС, установка пакетов и доставка приложений. Чаще всего такие проблемы решались с помощью Ansible. Но на каждом шаге при запуске приложений что-то могло пойти не так, а бизнес хотел получить гарантии повторяемости именно при запуске рабочих нагрузок. Кроме того у всех провайдеров очень разные API, что мешало унификации и неизбежно приводило к vendor-lock in. 

Docker и расцвет контейнеризации

В какой-то степени можно сказать, что Docker позаимствовал успешный облачный паттерн и применил его в рамках обычной ОС. Например, вместо установки пакетов теперь достаточно было взять готовый образ контейнера и запустить его как есть с необходимыми параметрами. Image скачивался из Docker Registry, а из него запускался контейнер — это похоже на запуск виртуальной машины в облаке из golden image, только на уровне операционной системы.

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

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

Kubernetes как стандарт контейнеризации

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

С самого начала Kubernetes тесно взаимодействовал с API облачного провайдера, предоставляя такие возможности, как автоматический заказ инстансов (автоскейлинг), балансировщиков нагрузки и томов для хранения данных. 

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

Однако это не помешало Kubernetes обзавестись огромным сообществом и успешно нести в массы новые подходы к проектированию приложений. В конечном счете Kubernetes предоставляет бизнесу унифицированные абстракции для работы с любым облаком, которое поддерживает managed Kubernetes service, а это делает приложения even more cloud-agnostic.

Как результат Kubernetes предоставил механизмы расширения и стал поддерживать больше функций для запуска stateful-нагрузок с помощью операторов и CRD. Что позволило унифицировать работу многих сложных баз данных и других решений, аккумулируя в себе опыт квалифицированных разработчиков в коде этих операторов. В результате теперь пользователи могут работать с высокоуровневыми абстракциями, вроде - postgres кластер, redis, rabbitmq, а вся логика обрабатывается специализированным оператором.

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

Платформы и будущее локальных провайдеров

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

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

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

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

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

До последнего времени не существовало и единого open source-стандарта для предоставления managed-сервисов. Именно этой проблемой мы и занимаемся в Ænix, разрабатывая свободную платформу Cozystack (которую мы передали в CNCF, чтобы каждый мог использовать ее и иметь гарантии того, что она не перестанет быть open source).

Таймлайн процессов, описанных в статье

• 1995 — On-Premise Servers. Ручной деплоймент и ЦОДах. Отсутствие гибкости и абстракций.

• 2001 — Virtualization Emerges. Запуск нескольких ВМ на одном сервере, начало автоматизации, вычисления постепенно абстрагируются от конкретного железа.

• 2006 — Public Cloud Emerges. IaaS позволяет получать вычислительные ресурсы и использовать хранилища данных через API. Появление модели pay-as-you-go.

• 2013 — Containerization Rises. Docker позволяет создавать и запускать легковесные, переносимые, иммутабельные окружения.

• 2015 — Managed Services Era. Облачные провайдеры предоставляют базы данных, кэш, queues и Kubernetes as services.

• 2018 — Kubernetes Becomes the Standard. Единый стандарт оркестрации и в облаках, и on-prem. Новый control plane.

• 2022 — New Generation Platforms. Kubernetes-native-платформы, подобные Cozystack. На любой инфраструктуре можно работать с PaaS.

Заключение

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

Cozystack — это наш ответ на вызов времени. Это не просто технологическая платформа, а инструмент, дающий сервис-провайдерам шанс стать на один уровень с мировыми лидерами. Мы верим, что будущее — за открытыми, прозрачными решениями, построенными на проверенных cloud-native подходах. И мы приглашаем вас строить это будущее вместе.

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

Additional materials

Статьи

• DIY: Ваше собственное облако на базе Kubernetes

• Как мы создавали динамический Kubernetes API server для API Aggregation Layer в Cozystack

• Платформа Cozystack стала проектом CNCF Sandbox

• В Open Source-платформе Cozystack появилась поддержка GPU

• Cozystack добавили на Cloud Native AI Landscape

• Простой способ установки Talos Linux на любую машину и у любого провайдера

• Неизбежное будущее Kubernetes: почему оркестратор должен пойти по пути Linux Kernel

Видеозаписи докладов Андрея Квапила

• Journey to Stable Infrastructures with Talos Linux & Cozystack | Andrei Kvapil | SREday London 2024

• Talos Linux: You don’t need an operating system, you only need Kubernetes / Andrei Kvapil

• Comparing GitOps: Argo CD vs Flux CD, with Andrei Kvapil | KubeFM

• Cozystack on Talos Linux

• GPU-Powered AI on VMs, Kubernetes & Bare Metal with Cozystack

• Kubernetes is the new Skynet or the rise of Kubernetes automation: CNCF webinar

Присоединяйтесь к сообществу Cozystack

• Telegram (eng, ru)

• Slack (in Kubernetes Slack workspace)

• Community Meeting Calendar