This article is more than one year old. Older articles may contain outdated content. Check that the information in the page has not become incorrect since its publication.

Эволюция платформ виртуализации: рост управляемых сервисов и преимущество локальных провайдеров…

Эволюция платформ виртуализации: рост управляемых сервисов и преимущество локальных провайдеров перед гиперскейлерами

Всем привет! Я Andrey Kvapil, CEO Ænix и разработчик Cozystack — открытой платформы и фреймворка для построения облачной инфраструктуры. В этой статье я хочу поделиться своим видением того, как современные облачные паттерны изменили подходы к инфраструктуре, как менялась роль сервис-провайдеров и публичных облаков в этом ландшафте и, что самое важное, как фундаментально изменилось назначение виртуализации в современном инфраструктурном стеке.

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

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

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

В сегодняшнем мире, где доминируют облака, ответственность за инфраструктуру всё чаще ложится на сервис-провайдеров. Бизнес теперь предпочитает готовые решения «под ключ», перенося фокус с низкоуровневых операций на ключевые приоритеты. Это стимулирует переход от IaaS (где клиенты управляют ОС, middleware и средой выполнения) к PaaS, где провайдеры не только поддерживают инфраструктуру, но и предоставляют управляемые сервисы (базы данных, брокеры сообщений и т. д.) так же легко, как запуск VM.

Эти сдвиги радикально изменили назначение виртуализации. Виртуальные машины уступают позиции управляемым сервисам: Kubernetes, базам данных, кэшам, очередям и не только. Это по своей природе даёт преимущество облачным платформам вроде AWS, GCP и Azure перед традиционными провайдерами (особенно локальными, у которых нет сопоставимой инфраструктуры). Гиперскейлеры с их огромными бюджетами на R&D и армиями инженеров уже развернули зрелые PaaS-предложения, тогда как ограниченные в ресурсах локальные провайдеры зачастую вынуждены предлагать лишь базовый IaaS, постоянно играя в догонялки.

Так как же мы к этому пришли? Давайте проследим становление экосистем «as-a-Service» и рассмотрим практические стратегии, с помощью которых локальные провайдеры смогут конкурировать с укрепившимися техногигантами.

В начале: когда серверы были «питомцами»

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

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

Каждый раз, когда нужно было развернуть что-то новое, вы проходили один и тот же процесс:

  • Купить физический сервер, отвечающий вашим требованиям.
  • Установить операционную систему.
  • Настроить сеть.
  • Установить и настроить приложение или приложения.

А как только всё было запущено и работало, вы продолжали его обслуживать: устанавливать обновления, устранять неполадки и относиться к серверу как к «питомцу». Вы заботились о нём, чинили, когда он ломался, и делали всё, чтобы поддерживать его в живых. Такой подход неплохо работал, когда серверов было всего несколько. Но как только их число росло, это превращалось в утомительную ежедневную рутину.

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

Виртуализация произвела революцию в управлении инфраструктурой, упростив бесчисленное множество задач. Она позволила обращаться с серверами более гибко. Ушли в прошлое времена, когда для каждой настройки сервера приходилось покупать новое оборудование, — теперь можно было просто выделить ресурсы из гипервизора и запустить VM. Аппаратные сбои стали менее катастрофичными, поскольку VM могли мигрировать на другие серверы. Возможность делать снимки (snapshot) и резервные копии целых VM принесла невиданное удобство.

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

Даже когда процесс упрощался за счёт клонирования преднастроенных образов, эти виртуальные серверы продолжали работать как «питомцы». Если VM выходила из строя, работавшее внутри неё приложение погибало вместе с ней. Такая модель «питомцев» по-прежнему требовала значительных усилий на обслуживание.

Хотя эти решения существуют и сегодня, обзаведясь расширенными возможностями и более совершенными инструментами управления «питомцами», по своей сути они оставались ориентированными на «питомцев». Индустрии явно требовалась эволюция.

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

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

Поскольку клиенты голосовали кошельком, провайдеры стремительно расширялись, строя надёжные дата-центры с отказоустойчивыми системами хранения и сетями. Появился новый класс платформ виртуализации, предоставляющих инфраструктуру как сервис (IaaS). Решения вроде OpenStack, OpenNebula и CloudStack произвели революцию в эксплуатации, управляя парками VM через шаблоны, золотые образы (golden images), пулы ресурсов, flavors и типы инстансов.

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

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

Однако одна проблема сохранялась: бизнес требовал воспроизводимой инфраструктуры, что подпитывало взрывной рост практик Infrastructure as Code.

Infrastructure as Code

Хотя веб-интерфейсы хорошо подходят для визуализации, инженеры неизменно предпочитают работать с API, которые предоставляют все крупные облачные платформы вроде AWS и GCP.

Инструменты вроде Terraform обеспечивают управление инфраструктурой как кодом, позволяя описать требования вашего приложения и за секунды развернуть идентичные среды разработки, staging или production. Такой подход облегчает динамическое тестирование возможностей и предотвращает сюрпризы в production. Ansible и другие системы управления конфигурацией отвечают за настройку ОС и развёртывание ПО внутри виртуальных машин — паттерн, который остаётся популярным несмотря на растущее внедрение бизнесом технологий контейнеризации.

Хотя задачи автоматизации инфраструктуры были в основном решены, индустрия переключила внимание на новую проблему: мы освоили создание инфраструктуры, но компоненты внутри неё по-прежнему управлялись вручную. Помимо декларативных описаний инфраструктуры, сохранялась значительная императивная логика (настройка ОС, установка пакетов и доставка приложений), которую обычно реализовывали через Ansible. Однако каждый шаг развёртывания нёс потенциальные точки отказа, тогда как бизнес всё настойчивее требовал надёжной воспроизводимости развёртывания рабочих нагрузок.

Более того, существенные различия между API провайдеров создавали барьеры для стандартизации, неизбежно приводя к ситуациям привязки к вендору (vendor lock-in).

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

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

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

Однако у Docker есть свои ограничения. Он превосходно проявляет себя на локальных системах, но не справляется с кластеризованными рабочими нагрузками и управлением большим числом контейнеров. Решив проблему воспроизводимости рабочих нагрузок, он породил новый вызов: интеллектуальную оркестрацию в масштабе, включая автоматическое переключение при отказе и балансировку трафика. Именно здесь на сцену вышел Kubernetes, утвердившись в качестве нового стандарта развёртывания серверных рабочих нагрузок.

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

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

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

Источник — Kubernetes Project Journey Report

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

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

По мере развития Kubernetes вводил механизмы расширения и расширял поддержку stateful-нагрузок через операторы и CRD. Это унифицировало эксплуатацию сложных баз данных и других решений, инкапсулируя экспертные знания разработчиков внутри этих операторов. Теперь пользователи взаимодействуют с высокоуровневыми абстракциями вроде кластеров Postgres, Redis или RabbitMQ, а специализированные операторы берут на себя нижележащую логику.

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

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

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

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

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

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

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

Cozystack работает как гипервизор/облачная платформа нового поколения, позволяя локальным провайдерам предлагать не только VM, но и полноценные управляемые сервисы на собственном оборудовании с простотой в один клик. Полностью построенная на Kubernetes и решениях под эгидой CNCF, она отвечает потребностям современных провайдеров в настоящих управляемых сервисах, используя проверенные в бою cloud-native компоненты.

Как открытый проект CNCF (где живут Kubernetes, Cilium, Flux и др.), Cozystack помогает провайдерам обрести цифровой суверенитет, повысить маржинальность и устранить привязку к вендору, ускоряя при этом вывод на рынок прибыльных облачных сервисов — включая AI-нагрузки на GPU.

Заключение

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

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

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

Дополнительные материалы

Статьи

Видео

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