Do as I do: алгоритм размещения сервисов внешних поставщиков в Маркетплейсе VK Cloud

Закономерный этап развития Cloud Native — стремление компаний иметь возможность получения быстрого и простого доступа к инструментам и технологиям под разные кейсы и бизнес-сценарии. Поэтому большинство современных облачных платформ строится на концепции предоставления пользователям всех нужных ресурсов и инструментов в формате «единого окна». И основной способ реализации этой концепции — построение каталогов приложений.

Облачная платформа VK Cloud тоже имеет свой Маркетплейс приложений. И реализовали мы его таким образом, что каждый внешний поставщик ПО (ISV, Independent Software Vendor) может загрузить в него свой инструмент и сделать его доступным тысячам пользователей с минимальными усилиями. Рассказываем, как именно нам это удалось и к чему сейчас сводится алгоритм публикации приложений.

Отправная точка

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

Но мы понимали, что основной показатель, определяющий ценность нашего каталога сервисов для конечных пользователей, — многообразие инструментов для различных сценариев и задач. Соответственно, важна скорость и регулярность пополнения «магазина» новым «ассортиментом». Поэтому по мере развития Маркетплейса приоритетом для нас было создание условий, при которых наполнять каталог сможет не только наша собственная команда, но и внешние поставщики ПО без дополнительной разработки со стороны VK Cloud. 

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

К какой реализации Маркетплейса мы хотели прийти

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

Соответственно, перед нами стояла конкретная задача — сделать процесс публикации максимально простым и прозрачным, снизив риски и издержки для поставщиков ПО.

Чтобы обеспечить это, нам было важно:

• реализовать возможность размещения приложений разного типа: SaaS, Image-based и других;

• обеспечить возможность биллинга приложений по разным моделям: Upfront (предоплата), PAYG (Pay-as-you-go) или Usage-based (на основе разных метрик потребления), бесплатные и BYOL;

• исключить необходимость заводить в систему биллинга и другие подсистемы данные под конкретный продукт вручную и заранее;

• предоставить поставщикам возможность самостоятельного описания параметров, биллинга, тарифных планов, а также визарда заказа его продукта;

• предоставить возможность добавления нового продукта в Маркетплейс без изменения кода практически любой сложности: от простых Standalone-приложений на одной виртуальной машине до развертывания кластера с развесистой инфраструктурой;

• предоставить поставщику возможность тестирования его продукта до публикации.

От требований к реализации: как мы снизили порог входа для поставщиков ПО

В первую очередь мы реализовали возможность размещения двух наиболее востребованных типов приложений:

• SaaS-сервисы — централизованно установленные мультитенантные продукты. Внешний поставщик развертывает сервис либо на собственной инфраструктуре, либо на инфраструктуре в своем проекте в VK Cloud. Пользователю предоставляется доступ к сервису через отдельный аккаунт (тенант). Управление сервисом и его инстансами выполняется на стороне VK Cloud.

• Image-based-сервис — продукт, который разворачивается на основе образов виртуальных машин в проекте VK Cloud. Для поддержания продукта может использоваться дополнительная инфраструктура: виртуальные сети, балансировщики нагрузки, кластеры DBaaS, S3-объектное хранилище, резервное копирование. Управление сервисом, его инстансами, а также инфраструктурой выполняется на стороне VK Cloud.

Взаимодействие Маркетплейса с сервисами мы реализовали с помощью брокеров, которые обеспечивают доставку конфигурации сервиса в Маркетплейс VK Cloud по протоколу VK OSB, созданному на основе Open Service Broker API. 

При этом:

• SaaS-брокер обеспечивает взаимодействие конкретного SaaS-приложения с каталогом;

• Image-based-брокер обеспечивает взаимодействие Image-based-приложений с каталогом VK Cloud. Image-based-брокер внутри себя имеет тенанты, объединяющие Image-based-приложения одного поставщика.

Примечание: Стоит отметить, что SaaS-брокер разрабатывает поставщик SaaS-приложения, а разработчикам Image-based-приложений нужно лишь подготовить сервисный пакет для Image-based-брокера — сам брокер для Image-based-приложений уже разработан командой VK Cloud.

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

1. Предоставить каталог сервисов, которые он позволяет заказывать, их параметры и тарифные планы.

2. Дать возможность заказывать, изменять или удалять экземпляр сервиса.

3. Создавать сервисные привязки — сущности, которые создаются после развертывания инстанса сервиса на основании запроса от облачной платформы к брокеру, и связываются с инстансом сервиса.

Алгоритм добавления сервисов в Маркетплейс

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

Добавление в каталог SaaS-приложений 

Размещение SaaS-приложения в Маркетплейсе VK Cloud подразумевает несколько этапов.

1. Разработка брокера для сервиса

Маркетплейс приложений взаимодействует с сервисами через брокеры. Для SaaS-приложений они должны:

• быть реализованы по протоколу VK OSB (его можно получить у команды облака по запросу);

• реализовывать методы, описывающие жизненный цикл инстансов сервиса.

Подробнее о разработке брокера здесь.

2. Описание конфигурации сервиса (тарифных планов и опций)

На данных момент поддерживается четыре типа тарифов:

• Upfront commitment. Оплата в начале периода использования сервиса (например, помесячная оплата).

• Usage based. Оплата по факту потребления. Стоимость рассчитывается на основе произвольных метрик использования продукта.

• Free. Нет платы за использование ПО. Тарифицируется только потребление инфраструктуры.

• BYOL. Покупка лицензии на ПО вне контура VK Cloud.

Тарифные планы можно описать довольно гибко. Так, можно указать:

• тип тарификации;

• стоимость отдельных тарифных опций;

• стоимость метрик потребления.

3. Загрузка конфигурации сервиса в брокер

Если SaaS-брокер создан по шаблону, достаточно выполнить несколько простых действий из инструкции.

4. Загрузка и публикация сервиса в Маркетплейсе

Здесь подразумевается финальная подготовка к релизу — от развертывания брокера до тестирования сервиса и публикации.

Примечание: С полной детальной инструкцией по добавлению в каталог SaaS-приложений можно ознакомиться здесь.

Добавление в каталог Image-based-сервисов

Image-based — довольно популярный вариант поставки приложений. 

В первую очередь для нас было важно:

• предельно упростить размещение в каталоге облака продукта стандартной топологии (например, когда продукт размещается на одной ВМ);

• поддержать гибкость;

• дать возможность описывать развертывание сложных систем с использованием других PaaS-решений, представленных в облаке.

Для Image-based-приложений не нужно писать свой брокер: он универсальный и уже разработан командой Маркетплейса. Но для заведения в каталог продукта надо подготовить ряд артефактов:

• образ ВМ с предустановленным ПО и средства конфигурации приложения после развертывания;

• артефакты для деплоймента системы (представляет собой Terraform-файл);

• описание тарификации;

• описание сервиса;

• описание параметров и визарда заказа приложения.

Примечание: Для подготовки и хранения артефактов или их исходников лучше использовать инструменты и практики DevOps.

1. Подготовка образа ВМ

Подготовить образ ВМ можно двумя способами:

• вручную, установив приложение и выполнив необходимые конфигурационные операции;

• с использованием инструмента для автоматизации сборки образов Packer.

Вариант с применением Packer удобнее, поскольку решение позволяет реализовать подход Images-as-a-Code, а следовательно, дает возможность хранить образ в системе контроля версий, воспроизводить состояние образа в любой момент времени и вносить контролируемые изменения. То есть с Packer можно подготавливать новые версии приложений в Маркетплейсе быстрее, контролируемо внося изменения.

2. Подготовка сервисного пакета

Артефакты, которые описывают сервис, тарификацию и визард заказа сервиса с помощью DSL на базе YAML, а также инструкции по деплойменту приложения в виде terraform-манифестов, объединяются в сервисный пакет.

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

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

3. Подготовка деплоймент инструкций

Деплоймент Image-based-приложения состоит из двух этапов: 

• развертывание инфраструктуры (ВМ с приложением или его компонентами, настройка Firewall, сети, внешние IP-адреса, DNS, сертификат для HTTPS, S3 и другие);

• доконфигурация приложения в соответствии с параметрами, выбранными клиентом.

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

Причин выбора в пользу Terraform много, ведь инструмент:

• де-факто — стандарт отрасли;

• позволяет использовать удобный язык конфигурации — HCL (Hashicorp Configuration Language);

• имеет хорошо продуманную систему плагинов и большой набор уже готовых компонентов;

• может создавать не только инфраструктуру (ресурсом может быть все что угодно);

• позволяет использовать разные бэкенды для хранения стейта.

Важным преимуществом стало и то, что у Terraform есть готовый провайдер для работы с VK Cloud.

Единственным недостатком инструмента для нашего кейса было отсутствие готового решения Terraform-as-a-Service, который потребовалось реализовать самостоятельно. Но в результате мы получили гибкое решение для описания процесса развертывания приложения практически любой сложности, которое уже хорошо знаком многим: чтобы завести свой продукт в Маркетплейс VK Cloud, внешним поставщикам не придется учить специфический язык или инструмент.

4. Описание параметров и визарда

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

• инфраструктурные параметры: тип виртуальной машины, тип диска, размер, зона доступности и другие;

• параметры конфигурации самого приложения;

• тарифные опции;

• параметры, включающие определенные функции: бэкап, интеграции с VK Cloud Monitoring и другие.

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

5. Описание тарифных планов

Здесь все аналогично тарифам для SaaS-приложений — сейчас поддерживаются модели тарификации Upfront commitment, Usage-based, Free и BYOL. 

6. Описание сервиса

На последнем этапе остается только добавить имя сервиса, его описание, логотип и инструкцию для клиента с первыми шагами по использованию.

Примечание: С полной детальной инструкцией по добавлению в каталог Image-based-приложений можно ознакомиться здесь.

Краткие итоги

Благодаря выстроенной реализации Маркетплейса VK Cloud внешние поставщики ПО могут своими силами размещать в каталоге облачной платформы SaaS-сервисы и Image-based-приложения практически любой сложности. 

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

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