Компания Bluebricks спонсировала этот пост.
Счета за облако легко измерить. Операционные затраты, связанные с поддержанием работоспособности облачных сред, учесть труднее. Это все, от инструментов до мониторинга и людей, которые заставляют все это работать. Эти затраты часто превышают сумму, указанную в вашем счете за облако, особенно после того, как вы начнете добавлять поставщиков облачных услуг, решите перейти на региональный уровень или внедрить пакетное расширение облака.
Венчурные капиталисты Андриссен Горовиц назвали это «парадоксом триллиона долларов». Хотя облако дает компаниям гибкость, без которой они не могут жить, в долгосрочной перспективе это им дорого обходится. Локальные системы могут показаться более дешевыми, но они надежны. Обойти этот парадокс невозможно.
Сегодня, с появлением распределенного искусственного интеллекта и периферийных рабочих нагрузок, этот парадокс стал более актуальным, чем когда-либо: все находится повсюду, и управление всем этим обходится дорого. Вот тут-то и подойдет взрыв облаков.
Войдите в гибридное облако
Гибридное облако — это когда локальный центр обработки данных работает вместе с облачными ресурсами. Гибридная установка обычно обусловлена конкретной потребностью. Во многих случаях данные должны храниться географически в определенном месте по соображениям соответствия. Другими потребностями являются экономия средств, в первую очередь, чтобы избежать затрат на выход.
Однако гибридная установка вновь создает проблемы дооблачной среды, где компании необходимо поддерживать цепочку поставок оборудования, управлять системами охлаждения и готовить другой план аварийного восстановления, поскольку сбой в локальной среде не похож на выход из строя облачного провайдера.
Локальная инфраструктура не является гибким решением для компании, поэтому она может решить объединить свои вычислительные мощности и хранилище с облаком.
Облако предназначено для обеспечения эластичности, поглощая всплески спроса, будь то эксперименты с искусственным интеллектом или просто из-за пикового использования платформ или систем.
Использование этого метода — перехода в облако при высокой нагрузке — использует преимущества эластичности облака и позволяет компании избежать как избыточного выделения ресурсов (наличия большего количества серверов в локальном центре обработки данных, чем необходимо), так и простоев (наличия меньшего количества серверов, чем требуется).
Теоретически этот баланс дает вам лучшее из обоих миров. В действительности, большинство команд не уверены в том, что их облачные среды будут работать стабильно. Проблема не в облаке; это инструменты под ним. На самом деле то же самое касается всего, что связано с окружающей средой. То, что кажется простым на бумаге, требует времени и усилий.
Реальные препятствия на пути динамического гибридного масштабирования
Когда организации пытаются масштабироваться между локальной средой и облаком, они сталкиваются с тремя предсказуемыми стенами:
- Фрагментация инструментов и среды: Каждая облачная и локальная платформа имеет свой собственный язык, конвейер и особенности. Их соединение превращается в хрупкую смесь скриптов и модулей «Инфраструктура как код» (IaC).
- Совместимость приложений: Программное обеспечение, которое переносится в облако, должно быть совместимо с управляемыми сервисами, предлагаемыми облаком, а также с его топологией сети и базовым оборудованием.
- Слепые зоны: Для управления двумя разными типами развертываний в разных средах требуется единая панель, где конфигурации, журналы и аудит централизованы для поддержки устранения неполадок и принятия решений на основе данных.
Разрыв облаков терпит неудачу не потому, что он концептуально ошибочен, а потому, что уровень оркестровки требует слишком много человеческого внимания и легко ломается.
Речь идет не только о том, чтобы ничего не нарушать или о принципах «не повторяйся» (DRY). Важно также знать, что соблюдаются стандарты и их соответствие.
Вот пример того, как выглядит традиционный процесс:
- Команда приложения упаковывает свои сервисы в контейнеры, такие как Docker. Команда по инфраструктуре использует Terraform для подготовки облачной среды, настройки кластеров Kubernetes (K8s) и связанных с ними диаграмм Helm.
- Конвейер предназначен для планирования и применения конфигурации Terraform во время пакетного события, в то время как другой конвейер запускает диаграммы Helm, выполняет тесты и развертывает приложение.
- В момент пакета человек-оператор должен определить цель пакета, настроить параметры кластера и запустить конвейеры. Сканирование и проверка безопасности проводятся для обеспечения соответствия требованиям и предотвращения появления критических уязвимостей.
- Время безотказной работы должно постоянно контролироваться, и может потребоваться ручное вмешательство для восстановления или очистки ресурсов после того, как пик трафика утихнет.
Это означает, что каждое событие масштабирования каждый раз требует координации между командами инфраструктуры, разработчиков и безопасности.
Почему инфраструктуры как кода недостаточно
В течение многих лет мы рассматривали автоматизацию инфраструктуры как проблему кодирования. Мы создали файлы Terraform, обертки поверх оберток и внедрили GitOps. Такое мышление принесло столь необходимую дисциплину, но также создало новые трения. Каждое изменение среды начинается с изменения кода; каждое масштабирование требует принятия решения, плана, утверждения и слияния.
Если кодовая база не поддерживается должным образом, каждое слияние может включать нежелательные коммиты, что приводит к выбору вишен, несогласованностям и колебаниям во время развертывания.
Процесс не предсказуемый, не быстрый и тоже может сломаться. Это также требует определенного набора навыков со стороны инфраструктуры, множества заинтересованных сторон, а это не всегда так.
Пришло время автоматизации и оркестрации инфраструктуры выйти за рамки кода. Рабочие процессы, основанные на коде, научили нас структурировать, но они также связали автоматизацию с синтаксисом и циклами проверки человеком.
Управление средой
Платформа оркестрации среды преобразует IaC, инструменты настройки и сценарии в многоразовые схемы среды с поддержкой версий, также известные как спецификации. Это означает, что сложные готовые к использованию среды можно создать одним щелчком мыши, независимо от базовой конфигурации, IaC и облака.
Blueprints стандартизируют способы создания, развертывания и обслуживания сред в облаках, командах и регионах. Его механизм выполнения на основе направленного ациклического графа (DAG) организует сложные рабочие процессы параллельно, сокращая время развертывания и сохраняя при этом детерминированный, проверяемый контроль над каждым изменением.
Это подход более высокого уровня, который рассматривает каждую среду — будь то AWS, Azure, Google Cloud Platform (GCP) или локальную среду — как часть единой операционной модели.
В оркестрованной системе:
- Зависимости отображаются, а не подразумеваются. Оркестратор отвечает за их синхронизацию и предупреждение, прежде чем что-то сломается.
- Чертежи заменяют одноразовые сценарии, выполняемые вручную. Они пригодны для многократного использования и включают в себя безопасность и лучшие практики.
- Рабочие процессы управляют различными технологиями, используемыми на разных уровнях среды — Terraform, Helm, Ansible и MySQL — одновременно, чтобы быстро настроить и достичь желаемого результата.
- Развертывания включают время жизни (TTL) и могут быть легко удалены, гарантируя, что пакеты останутся временными и сохранят эластичность.
- Контроль затрат и управления носит упреждающий, а не реактивный характер. Платформы оркестрации обеспечивают утверждение контроля доступа на основе ролей (RBAC) и максимальные расходы до развертывания одного узла.
Результат: вместо того, чтобы «прорываться» через конвейер ручных действий, организации могут масштабироваться динамично и безопасно в рамках установленных ограничений.
Важно отметить, что этот подход также хорошо работает для агентного ИИ, поскольку подход «чертежа» дает агентам детерминированный контекст, необходимый им для безопасного предоставления, масштабирования и исправления облачных сред. Или, если перефразировать с учетом разработки на основе спецификаций, это дает агентам все, что им нужно для последовательной и безопасной работы.
При этом ваши текущие инвестиции в IaC используются как в качестве основы, так и в качестве ограждения, чтобы агенты ИИ могли легко создавать облачные среды по мере необходимости. Это обеспечивает стандарты и безопасность, необходимые для того, чтобы агенты могли предоставлять и поддерживать облачную инфраструктуру.
От автоматизации к интеллекту
Рассмотрим компанию, предоставляющую финансовые услуги, которая выполняет транзакции, чувствительные к задержкам, локально, но масштабируется в общедоступное облако во время пика торговли, например, в Черную пятницу или Киберпонедельник. В традиционной настройке масштабирование этой рабочей нагрузки означает работу с несколькими репозиториями Terraform, координацию работы команд безопасности и DevOps и надежду, что все будет работать без проблем, когда это необходимо.
В оркестрованной модели компания определяет этот гибридный шаблон один раз как план — когда спрос резко возрастает, он выполняется автоматически с использованием встроенных политик и отката.
В этом смысле взрыв облаков больше не является нишевой тактикой. Это испытательный полигон того, как должно работать интеллектуальное управление инфраструктурой: управляемое, контекстуальное и адаптивное по своей сути. автоматизация привела нас сюда. Оставшуюся часть пути нам проведет оркестровка.
Bluebricks — это оркестратор среды, который преобразует IaC, инструменты настройки и сценарии в многоразовые, версионные схемы, готовые для агентов ИИ. Это позволяет командам создавать сложные готовые к работе среды одним щелчком мыши, независимо от базовой конфигурации, IaC и облака. Узнайте больше ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Идан Ялович — соучредитель и генеральный директор Bluebricks, платформы оркестрации среды, которая преобразует инфраструктуру как код, инструменты конфигурации и сценарии в многоразовые, версионные схемы среды, готовые к доставке агентами. Подробнее от Идана Яловича
