Мой коллега, Андрей Квапил, недавно в своей статье "Эволюция платформ виртуализации: как мы пришли к миру managed-сервисов и как сервис-провайдерам конкурировать с AWS" выдвинул тезис, что

... AWS, GCP и Azure предоставляют своим пользователям удобные API ...

Честно говоря, реальность абсолютно обратна. Я согласен с Андреем в том тезисе, что

веб-интерфейсы удобны разве что в качестве инструментов визуализации

Но только отчасти.

Более того - назвать интерфейс Амазона удобным язык не поворачивается. Я бы выделил следующие претензии к интерфейсу:

• невозможность запуска в нескольких вкладках браузера. Теоретически это можно сделать, но работать нормально это не будет

• достаточно странная группировка сервисов. Например, балансировщики нагрузки ты видишь в EC2, хотя логичнее их было бы видеть в VPC - это все-таки про сеть. Но коли уж так исторически случилось - что поделать

• постоянные проблемы с обновлением данных на страницах. 2025 год, а вебсокеты похоже Амазон не научились делать. Надо сказать, что даже в таких крупных продуктах как GitLab тоже есть такого рода проблемы, но там они хотя бы решаются.

• нет возможности посмотреть удобно свои расходы. Конечно, есть выделенный модуль для Cost & Billing...

• очень многие компании используют мультиаккаунт. Таким образом удобнее контролировать бюджеты и реализовать изоляцию ресурсов между разными средами. К сожалению, интерфейс работы и логина оставляет желать лучшего. Залогиниться параллельно в несколько аккаунтов? Mission impossible

• Очень многие опции запрятаны куда подальше. Опять же можно попробовать побыть адвокатом Облака и сказать, что так получилось исторически. Но на самом деле цель очень простая - заставить пользователей страдать и идти к консультантам. А тут Амазон силен. Я бы даже сказал, что у каждой успешной компании есть своя конференция (re:Invent) и своя сертификация инженеров. И тут у Амазона действительно нет равных. А еще Амазон специально прячет некоторые крутилки, чтобы пользователь попросту платил больше. Просто надо понять - это его бизнес модель. Тут нет места благотворительности.

Самое забавное, что есть продукты вроде Wiz.io, которые позволяют вытянуть данные из облака и предоставляют намного более наглядные, удобные и быстрые интерфейсы посмотреть, что же там в облаке есть и как разные сущности взаимосвязаны. Не говоря уже о полнотекстовом поиске по всем объектам облака. Учитывая, что таким образом вырос целый отдельный рынок решений под общим названием CSPM, я как-то не особо верю в то, что какое-либо облако реализует подобный функционал у себя внутри. А это было бы конкурентным преимуществом. В этой связи очень интересно выглядит новость о покупке Wiz.io компаний Google: https://www.wiz.io/blog/wiz-joining-google Конечно, мы искренне считаем, что Wiz.io - лучшее решение из этого класса, и желаем ему дальнейшего развития, но пока неясно, что из этого выйдет, учитывая, что компания Google таким образом может попросту получить дополнительное преимущество, так как среди клиентов Wiz.io были и клиенты других облаков. А может быть Wiz.io попросту станет еще одним сервисом из предложения GCP.

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

Но и тут все не гладко.

Исторически так сложилось, что у Амазона есть один нативный способ управления облаком - это CloudFormation. И это в каком-то смысле логично, так как любой вендор желает иметь свой тулинг, который навязывает потребителю. Это уже сильно потом появились универсальные штуки вроде terraform, которые став популярными, вынудили всех поставщиков облака написать плюс/минус адекватные провайдеры. Но тем не менее - для Амазона даже до сих пор сохраняется принцип CF first. Повторюсь, что это в каком-то смысле вендорлок. Так как сменить инструмент управления гораздо сложнее, чем переписать манифесты в terraform. Но даже в terraform сделать полностью независимые от облака манифесты - отдельная и очень большая задача, которая потребует кучу инженерочасов. Тут еще сказывается не только разница в параметрах облаков (тут один набор зон доступности, тут другой; тут виртуалки имеют один набор названий flavour, тут - другой), но и попросту различные наборы сущностей. Хотя и база облака всегда одна и та же - виртуалки (EC, compute), сети (VPC), балансировщики и все строится вокруг этих базовых кирпичиков.

ОКей. Но может есть какие-то более практические примеры, где API облака становится неудобным? Ну, давайте посмотрим.

EKS

Первая болезненная история, с которой я столкнулся - невозможность создать EKS кластер в 1 шаг. В силу того, что облако предоставляет кучу разных абстракций, то ты вынужден все создавать последовательно с самого начала. Начинаешь с VPC и подсетей. Потом создаешь роли - они нужны, чтобы кластер, его узлы и различные системные компоненты кластера могли взаимодействовать с облаком. Потом надо создать сам control plane кластера. И уже потом создать группу узлов, которая будет ему принадлежать. К сожалению, какой-то общей абстракции на уровне облака нет. В CF это решается группой ресурсов под названием "стек". В terraform - нужно писать модули. Но это все инструмент-специфичные вещи. А еще полный процесс создания занимает минут 20. На мой взгляд, это неприемлемо долго, но хотя бы стабильно. Какой-либо проверки ресурсов в процессе нет. И запросто можно создать нежизненноспособный кластер - в частности, если ошибиться с настройкой групп безопасности. Как раз именно поэтому и становится важным написание правильных шаблонов и их тестирование.

S3

Второй очень популярный сервис - это S3. Самая первая странность, которые вы вероятно даже и не заметите сначала - это использование глобального пространства имен для бакетов. Название бакета должно быть уникально для любого региона и для любого аккаунта. Скорее всего "уши" торчат оттуда, что изначально сервис не был мультитенантным, а таковым его сделали потом. Жить с этим можно. Но, честно говоря, выглядит неаккуратно. Не говоря уже о том, что возможны ситуацию киберсквоттинга или, может помните, как злоумышленники придумывают названия пакетов или сайтов с одной опечаткой, в надежде, что пользователь или использует таковой пакет в своем приложении, или перейдет на такой сайт. На мой взгляд, лучше было бы делать отдельные пространства имен для каждого пользователя облака - это дало бы большую изоляцию. Потом еще есть особенности в API, то что лучше всего характеризуется английским словом quirks. Например, создав однажды бакет, вы не сможете включить на нем ObjectLock. Нет никаких предупреждений, если вы бакет создаете без этой опции. Поэтому если вам нужен OL, а вы забыли его включить — добро пожаловать в удаление бакета и создание его заново. Ой, мы же уже туда налили данные! Ой, мама! А еще не забудьте, что название бакета должно быть уникально — то есть пока он удаляется (а это происходит не мгновенно, как и многое в нашем мире) — вы это имя переиспользовать не можете. То есть если бакет нужен "здесь и сейчас" — придется создавать его с новым именем, неаккуратненько получается. Исторически у S3 была eventual consistency для PUT-DELETE-LIST операций, что вводило в заблуждение. Сейчас почти всё — strongly consistent, но в старых документациях до сих пор встречается устаревшая информация. Следующая вещь попросту взрывает мозг людям, которые привыкли работать с файловой системой. Для таких людей логична структура папка (каталог) / подкаталоги / файлы. И S3 как будто бы действительно так работает - по крайней мере визуализация рисует именно такую структуру. Но нет - в S3 нет папок! Фактически это просто префикс имени объекта (!). Это приводит к тому, что "удаление папки" в S3 — не атомарная и зачастую длительная операция, в частности, если в бакете есть куча объектов. Что приводит нас к мысли, что "один большой бакет хуже, чем куча маленьких", но смотри выше замечание насчет именования бакетов. Политики на бакет и объекты — две независимые системы. Возможны конфликты между ними: даже если бакет говорит "разрешено", объект может сказать "нет".

IAM

Следующий сервис, который все используют на каждодневной основе - IAM. Это сердце, это ролевая модель облака. В этом сервисе много тонкостей. И приоритет deny над allow, и отсутствие нормальных групп — они есть только для пользователей, и два набора политик - resource-based и identity-based. Отдельная история - это видимость встроенных политик (inline policies). Точнее то, что их невозможно отдельно посмотреть в интерфейсе массового управления. Но вот от чего у меня реально горит так это то, что хоть и роли могут ссылаться друг на друга, то в этом случае нужно будет их сначала создать, а потом уже настраивать между ними доверие. Иначе работать не будет. И не дай Бог ты роль удалишь, а потом пересоздашь — хоть и называться она будет так же, но ее внутренний идентификатор будет другой. Именно здесь видно, что IAM один из самых старых Амазона. И Амазон вынужден тащить совместимость и поэтому ограничен в возможностях рефакторинга сервиса, хотя, честно говоря, она назрела.

MSK, AMQ и прочие

В целом, многие сервисы в облаке сделаны действительно очень хорошо. Взять те же виртуальные машины и сети. С ними почти нет неожиданностей и как правило они работают хорошо. Еще очень хороший сервис — RDS — базы данных. Сервис такого уровня сделать самому или получить у каких-либо других провайдеров (не гиперскейлеров) достаточно сложно. Но так как суть облака подсадить пользователя на себя, то каждое облако расширяет предложение своих сервисов и за пределы базовых сервисов. Таким образом в облаке появляются kafka, elasticsearch, activemq, всякие штуки для AI и прочее прочее прочее. Что интересно — я пробовал и Kafka, и AMQ в Амазон, и могу уверенно заявить, что эти сервисы сделаны по остаточному принципу. И стабильность работы, и удобство — все сделано на "отвали". AMQ я смог завалить буквально в первый же день. У сервиса просто переполнились логи. Kafka — когда ждать KRaft? Как сделать кластер о пяти узлов, а не шести (ну, не хочу шесть — дорого). Внутри своей команды мы пришли к выводу, что нам дешевле, проще сделать сервис своими руками. Тем более для Kafka есть прекрасный оператор Strimzi для kubernetes, который позволяет сделать стабильную, надежную, отказоустойчивую и не очень дорогую (во всех смыслах) Kafka как сервис на своих ресурсах (пускай даже это и будет managed EKS).

В случае облака от чего у меня еще подгорело — процесс создания кластера Kafka асинхронный и может составлять час или более! При этом нормального способа проверить статус создания не существует. Далее — нельзя изменить конфигурацию брокеров на лету. Что в strimzi делается на раз два. Очень похожие истории с AMQ. Что еще раз доказывает, что эти сервисы были добавлены в облако "чтобы были". И это очень плохо, потому что подрывает доверие к облаку как к качественному сервису.

Решения?

Что может быть решением? Проектирование облака с нуля, с учетом знаний, наработанных индустрией к текущему времени. Тут мы можем взять все пути использования облака, пользовательский опыт. И облечь его во что-то новое. При этом бояться что-то испортить не надо. Действительно, облака делают ставку на очень сильную обратную совместимость, но надо сказать, что они часто реально сами плюют на нее. Сколько раз уже было, что Google выводило сервисы из обслуживания — не инфраструктурные (вроде kafka/vpc/etc), а скорее прикладные — вроде Jamboard (2024), Google Domains (2023), Hangouts (2022). Но даже инфраструктурные сервисы могут быть закрыты. Примером является Cloud IoT Core (2023). Амазон тоже так делает, но чуточку менее агрессивно. Так, к примеру, мы лишились Amazon Linux 1 (2023), регулярно случаются Lambda Runtime Deprecations, закрыт AWS EC2 Classic (закрыт для новых аккаунтов с 2013, окончательно закрыт в 2022). И так далее.

В этой связи мне очень нравится подход, который используют коллеги из Ænix в своем продукте с открытым кодом cozystack.io.

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

Еще очень важным конкурентным преимуществом CozyStack является использование принципе "все как YaML". Так как все объекты представлены в kubernetes API — они по сути являются текстовыми документами, которые обрабатывается специальными контроллерами внутри платформы. Хочешь получить инстанс базы данных? Просто положи в kubernetes API удобным тебе способом правильно сформированный манифест. Правильность этого пути подтверждается тем, что все мажорные облака уже сделали свои наборы контроллеров для управления облаком. В этой связи могу отметить набор операторов от Амазона — AWS Controllers for K8s - ACK. Очень удобно запрашивать потом статусы объектов. Так как kubernetes API из коробки поддерживает функцию WATCH, то есть подписки на события, а еще в поле status контроллер может передавать любой необходимый для конкретного сервиса набор данных о его состоянии.

Интеграция с terraform может быть получена "из коробки", так как в terraform уже есть kubernetes provider.

Недавно CozyStack перешел от использования универсального подхода с развертыванием инстансов сервисов через HelmRelease на использование уникальных и индивидуальных для каждого сервиса API. Это позволило улучшить качество сервисов за счет строгой схемы данных и возможности валидации передаваемых от пользователя параметров.

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

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

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

Давайте вместе строить будущее!