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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


Исторически так сложилось, что 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).









Итак:
  • абсолютно все провайдеры предоставляют базовый минимум, необходимый для работы любого веб-проекта, — виртуальные машины (с видеокартами при необходимости) и 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)









Исходя из представленных выше данных, можно уверенно сказать, что все облачные провайдеры предоставляют необходимый набор услуг по организации сети/безопасности для ваших приложений, но, к сожалению, не все из них полноценно представлены в 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).









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


  • все провайдеры предоставляют базовый минимум услуг по организации данных, необходимый в 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 произведем конфигурацию инфраструктуры «руками» через веб-консоль облачного провайдера).



Выводы после развёртывания фронтенд-приложения:
  • Все облачные провайдеры позволяют задеплоить 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 пришлось «подпинывать» руками из веб-консоли.



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

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


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

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

P.S.


В данной статье намеренно не рассматривались биллинг и всё прочее, связанное с стоимостью услуг российских облачных провайдеров, так как главной целью было сравнение их функциональных возможностей, а не потенциальных затрат пользователей.
Источник: https://habr.com/ru/company/itsumma/blog/671644/


Интересные статьи

Интересные статьи

О спутниковом интернете, который постепенно продвигают в массы Starlink, OneWeb и ряд китайских компаний, на Хабре писали неоднократно. Активнее всех развивается как раз Starlink Илона Маска. Вероят...
Фейковые новости влияют на политику больших стран, их создатели зарабатывают немалые деньги, используя различные схемы монетизации, а в будущем fake news смогут сокрушать бизнесы. Рассказывае...
Несмотря на то, что “в коробке” с Битриксом уже идут модули как для SOAP (модуль “Веб сервисы” в редакции “Бизнес” и старше), так и для REST (модуль “Rest API” во всех редакциях, начиная с...
В прошлой статье мы говорили о трёх картриджах с интересной особенностью: у них был разъём, в который вставлялись другие картриджи. Некоторые другие картриджи развили эту идею, позволив подключ...
Всем привет! В данной статье, описаны шаги которые необходимо выполнить, для добавления к вашему WDS, возможности загрузки в режиме UEFI. Т.е. инструкция в данной статье, предполагает, что у ва...