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

в 7:46, , рубрики: Amazon Web Services, AWS, cloud native, devops, ITSumma, SberCloud, selectel, selectel cloud, vk cloud solutions, vkcs, Yandex.Cloud, Блог компании ITSumma, облачные сервисы
Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 1

Исторически так сложилось, что AWS стал промышленным стандартом на рынке облачных услуг, как с точки зрения набора предоставляемых услуг и решений, так и с точки зрения поддержки, комьюнити, готовых библиотек для использования, провайдеров для работы с подходом IaaC. Но ввиду изменившейся геополитической ситуации, а также других различных факторов (например, 152 ФЗ), зарубежные решения становятся всё менее доступными. Так что необходимо искать альтернативы на российском внутреннем рынке.

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

Дисклеймер №1
Данная статья не является рекламой. Все совпадения с реальностью — всего лишь совпадения с реальностью. А все несовпадения с реальностью — всего лишь несовпадения с реальностью.

Дисклеймер №2
Для анализа произвольным образом были выбраны Yandex.Cloud, SberCloud, Selectel, VK cloud solutions (экс-MCS).

Дисклеймер №3
Говоря о Terraform-провайдере, мы всегда будем говорить именно о провайдере с названием <имя-облака>-terraform-provider (не об openstack).

Часть первая — сравнительная

Для проведения сравнительного анализа по услугам, которые предоставляют нам облачные сервисы, имеет смысл определить “обязательный минимум” по базовому набору, сгруппировав эти услуги следующим образом:

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

Среда выполнения

Отталкиваясь от того, что нам предлагает AWS, можно выделить четыре основных услуги, а именно:

  • виртуальные машины,
  • среда запуска контейнеризированных приложений (AWS ECS),
  • managed Kubernetes,
  • serverless.

Заодно дополнительно посмотрим, предоставляют ли нам провайдеры Container Registry и конфигурируется ли оно через Terraform (как для работы с средой для запуска отдельных контейнеров, так и для работы с k8s).

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 2

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 3

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 4

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 5

Итак:

  • абсолютно все провайдеры предоставляют базовый минимум, необходимый для работы любого веб-проекта, — виртуальные машины (с видеокартами при необходимости) и managed K8s.
  • возможность конфигурирования ресурсов через Terraform максимально представлена Яндексом.
  • serverless-вычисления представлены практически всеми провайдерами (кроме VKCS).

Из интересного:

  • Selectel также предоставляет виртуальные машины на базе MacOS, что будет полезно разработчикам софта для IOS/MacOS.
  • SberCloud предоставляет сервис для запуска приложений на любом ЯП под названием Service Stage (аналог AWS Elastic Beanstalk Service / Google App Engine), который будет полезен для тестирования различных проектов, без забот об организации рабочего окружения.

Сети, балансировка, безопасность

Следующий немаловажный набор услуг:

  • организация Virtual Private Cloud
  • DNS
  • CDN
  • SSL
  • API Gatewaty
  • Load Balancing
  • Security (WAF, DDoS-protection, Security issues)

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 6

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 7

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 8

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 9

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

Отдельно стоит отметить, что все провайдеры предоставляют достаточно широкий спектр услуг по безопасности, вплоть до поиска уязвимостей в docker-образах, хранящихся в containers’ registry. Однако CDN, предоставляемый SberCloud’ом, на момент проведения сравнения находился в состоянии preview и полноценно протестировать его на реальной нагрузке не удалось.

Базы данных. Хранение объектов

Последним немаловажным срезом по услугам являются решения для организации хранения данных, как в базах данных, так и в объектных/файловых хранилищах (на примере AWS S3). Что именно нам необходимо:

  • объектное хранилище (S3-совместимое),
  • managed RDS (MySQL, PostgreSQL),
  • документоориентированные БД (like MongoDB),
  • БД для организации поисковых систем (like Elasticsearch),
  • TSD,
  • Key/value хранилища, in-memory DB (like Redis, Memcached).

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 10

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 11

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 12

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 13

Промежуточные выводы

  • все провайдеры предоставляют базовый минимум услуг по организации данных, необходимый в 99% процентов для любого веб-проекта, а именно — managed MySQL/PostgreSQL и S3-совместимого хранилища;
  • некоторые провайдеры не предоставляют только одну услугу, представленную нами в списке для сравнения, — чаще всего это TSDB или система для организации поискового движка;
  • не все провайдеры предоставляют Terraform-ресурсы для конфигурирования данных ресурсов через IaaC;
  • максимальный набор “всего-всего” у Yandex.Cloud;
  • на мой взгляд, не совсем удобным является работа со всеми хранилищами через одну услугу/конфигурацию DBaaS у Selectel’а.

Часть вторая — практическая

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

  • фронтенд: SPA (Angular)-приложение, развернутое в s3-бакете в режиме хостинга статичного веб-сайта, с дополнительно настроенным CDN поверх бакета.
  • бэкенд: Nest.js приложение, развернутое в managed K8S.
  • хранение данных: managed PostgreSQL в качестве основной базы данных + managed Redis для хранения кэшей, пользовательских сессий и т.д.
  • загружаемый пользовательский контент: S3-бакет с дополнительно настроенным CDN, presigned-urls на уровне бакета / signed-urls на уровне CDN для раздачи приватного загружаемого контента.

Также попробуем разворачивать инфраструктуру для нашего проекта, используя как штатный Terraform-провайдер, так и Openstack-провайдер), а при отсутствии возможности конфигурации через Terraform произведем конфигурацию инфраструктуры «руками» через веб-консоль облачного провайдера).

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 14

Выводы после развёртывания фронтенд-приложения:

  • Все облачные провайдеры позволяют задеплоить SPA-приложение через S3-бакет, и практически все (за исключением SberCloud) — дополнительно настроить для этого бакета раздачу контента через CDN.
  • Сконфигурировать через Terraform удалось только Yandex.Cloud и SberCloud, все остальные конфигурации делались руками.
  • Presigned-urls предоставляют только Yandex и Selectel.
  • Signed-urls для CDN недоступны ни в одном из провайдеров.
  • Даже при выставлении TTL для кэша CDN у Yandex на минимально допустимое значение изменения конфигурации подхватываются очень долго.
  • При полном соблюдении пунктов документации при конфигурации связки S3-бакет + CDN у VKCS мы получили нерабочий сайт (ошибка доступа к данным между бакетом и CDN).
  • Создание SSL-сертификата для CDN у Yandex.CLoud пришлось «подпинывать» руками из веб-консоли.

Можно ли в российских облаках реализовать архитектурные схемы, стандартные для западных провайдеров - 15

Выводы после конфигурации инфраструктуры и деплоя нашего бэкенд-приложения:

  • Во всех сервисах получилось реализовать инфраструктуру и деплой приложения на 100%.
  • Инфраструктура в Yandex.Cloud и SberCloud была ПОЛНОСТЬЮ сконфигурирована с использованием штатного Terraform-провайдера.
  • В VKCS через Terraform получилось запустить только базу данных и K8s, остальные части инфраструктуры пришлось сетапить «руками».
  • Инфраструктура в Selectel была сконфигурирована через комбинацию штатного и openstack Terraform-провайдеров.
  • В документации от VKCS были найдены устаревшие/нерабочие примеры, что может ввести в заблуждение начинающих инженеров в процессе сетапа инфраструктуры.

Итоговая картина

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

  • «Почётное первое место» занимает Yandex.Cloud: наиболее широкий спектр услуг, отличная документация, практически полное покрытие инфраструктуры Terraform-провайдером.
  • Остальные облачные провайдеры «не отстают», но им есть куда развиваться, есть какие услуги добавлять и как дорабатывать свои Terraform-провайдеры (openstack — не панацея).
  • На 95% удалось реализовать привычные архитектурные схемы, которые мы использовали при работе с AWS.

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

  • инструменты администрирования (мониторинг, логи, бэкапы),
  • инструменты для работы с аналитикой, очередями, бигдатой, ML.

P.S.

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

Автор: Сережа

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js