Инфраструктура облачных приложений из кода (IfC)
5 апреля 2022 г.Следующий логический шаг в облачной автоматизации
Это техническое продолжение статьи IDG Connect , в котором представлена относительно новая концепция Infrastructure from Code (IfC) как следующий логический шаг в автоматизации облачных вычислений. По своей сути IfC относится к полностью автоматизированному созданию спецификаций конфигурации облака на основе интерпретации кода приложения. Он основан на широко распространенном подходе Инфраструктура как код (IaC), который на сегодняшний день требует ручного создания и обслуживания спецификаций облачной конфигурации. Эта статья направлена на предоставление более формализованного обоснования утверждения, что IfC является логическим преемником IaC и будет быстро развиваться.
Чтобы понять, почему традиционная инфраструктура как код больше не подходит для нового бессерверного мира, нам нужно вернуться к самым основам. Поскольку тема обширна, а количество доступных материалов, инструментов и решений велико, мнения о том, что именно включает в себя IaC и куда она направлена, сильно расходятся. Во-первых, нам нужно согласовать дедуктивную методологию и структурный анализ технологии, доступной сегодня, а затем перейти к наиболее правдоподобным сценариям будущего развития — и вытекающим из этого потребностям или ограничениям.
В этой публикации я намереваюсь изложить связный и не очень сложный ход мыслей, который может служить концептуальной основой для предстоящей практической работы. Ход статьи следующий:
- Концептуальная основа
- Технологическая эволюция
- Облачная инфраструктура как стек кода
- Решение проблем IAC
- Инфраструктура из потребностей кода
- Новая волна IfC
Концептуальная основа
Принцип: технологии и практики развиваются вместе
Технологии никогда не стоят на месте. Всякий раз, когда появляется что-то новое и полезное, вскоре после этого начинается процесс товаризации. Все больше и больше людей учатся делать это с большей эффективностью. Коммодитизированные и стандартизированные технологические возможности порождают новые технологические инновации [1].
Технологии и практики развиваются вместе [2]. Новые технологии делают некоторые методы устаревшими (погонщики мулов сегодня менее востребованы) и создают потребность в других (водители грузовиков необходимы, по крайней мере, до сих пор). Хотя случайность и полное отсутствие играют значительную роль в совместной эволюции технологий и практик, маловероятно, чтобы вещи произвольно перескакивали с одной точки на другую. Некоторые вещи более вероятны, чем другие. Используя немного более формальный язык, мы можем утверждать, что совместная эволюция технологии и практики составляет ткань семантического пространства-времени [3].
Контекст: DevOpsFinSec — это не то, что вы думаете!
Концепцию DevOpsFinSec часто путают с написанием и поддержкой сценариев автоматизации для распределения ресурсов инфраструктуры. Иногда это также связано с мониторингом. По крайней мере, это то, что подразумевается в объявлениях о найме DevOps Engineers.
Это узкий взгляд на предмет, который противоречит исходному определению DevOps. Как объяснил Патрик Дебуа, придумавший этот термин, DevOps призван «устранить разрыв между разработчиками, операторами и системными администраторами с помощью Agile».
Я думаю, что эта диаграмма [4] лучше всего объясняет всю концепцию DevOps (рекомендуется: распечатать ее на формате A3 и прикрепить к доске перед собой). В этой модели DevOps существует четыре ключевых области взаимодействия (обмен знаниями и обратная связь) между разработчиками и операторами.
![Рис. 1: Области DevOps] (https://cdn.hackernoon.com/images/-eu92ik4.png)
Если мы углубимся в статью Патрика, мы найдем еще одну интересную диаграмму, описывающую слои, на которых происходит взаимодействие.
![Рис. 2: Слои DevOps] (https://cdn.hackernoon.com/images/-mga2i0e.png)
Что мы узнаем из этих двух диаграмм? Этот подход DevOps (или, в более широком смысле, DevOpsFinSec) предполагает четыре типа сотрудничества между дисциплинами, участвующими в предоставлении программных услуг конечным пользователям: два из них связаны с разработкой, а два — с эксплуатацией. В каждой области нужны инструменты для автоматизации, процессы (желательно облегченные) и люди с открытым мышлением.
Здесь я хочу предельно ясно заявить, что без человеческого сотрудничества в различных дисциплинах ни один инструмент или процесс не могут помочь.
Беспорядок + автоматизация = автоматический беспорядок
Мотивация: инфраструктура как код
Теперь Инфраструктура как код (IaC) может быть определена более точно как набор инструментов для автоматизированного распределения ресурсов инфраструктуры (Область I: Расширение доставки до производства; Область 3: Внедрение проектных знаний в работу). Обратите внимание, что IaC сам по себе не говорит о наблюдаемости (Область 2: Распространение отзывов об операциях на проект) и автоматическая корректировка (Область 3: Внедрение знаний об операциях в проект). Тем не менее, он принимает участие в инструментировании для мониторинга или оповещения и неявно учитывает специфику работы и требования в сценариях автоматизации.
Хотя эти различия широко распространены по многим причинам, они далеко не точны. В 1993 году Марк Берджесс создал новаторскую систему CFEngine, которая охватывает все аспекты автоматизации, оказала влияние почти на все инструменты IaC, представленные сегодня на рынке, и до сих пор остается непревзойденной. Нехватка места в этой статье не позволяет углубиться в CFEngine теоретические основы и практические решения. Я настоятельно рекомендую посмотреть "Beyond Automation with CFEngine 3 серию лекций об O'Reilly.
Подводя итог этому предварительному анализу, IaC предназначен для создания исполняемых документов, описывающих распределение компьютерных ресурсов и их взаимосвязь для достижения определенной цели.
Технологическая эволюция: как мы к этому пришли?
Как упоминалось выше, технологии, инструменты и практики развиваются одновременно, но они не развиваются совершенно произвольно. Некоторые силы определяют вероятность движения. Некоторые вещи проще, чем другие, и, как и вода, вещи движутся к минимально возможному расходу энергии.
В контексте автоматизации в целом и IaC в частности ключевыми движущими силами являются:
- количество компьютеров для управления
- мощность отдельных компьютеров и предпочтения масштабирования по сравнению с масштабированием
- скорость и надежность сети
- количество приложений и сервисов для доставки
- частота выпусков ПО
- количество конечных пользователей для обслуживания
- ожидаемая задержка и доступность
Эти факторы влияют друг на друга. Поскольку пространство-время и материя влияют друг на друга (спасибо, мистер Эйнштейн), эволюция и инновации, способности и потребности порождают друг друга.
Давайте посмотрим, как эта динамика работает в пространстве IaC.
Все началось с дата-центров без ПО
В начале, в 1990-х годах, количество компьютеров в типичном центре обработки данных было небольшим, сети все еще были относительно медленными и ненадежными, преобладали только предпочтения масштабирования, количество приложений и сервисов не было слишком большим, и выпускались обновления относительно редко.
В такой среде ручная сборка компонентов опытными системными инженерами была нормой. Я начал работать в такой компании в 1995 году. Руководство компании было убеждено, что платить высокую зарплату группе опытных системных инженеров будет стоить меньше, чем разработать высокоавтоматизированную систему доставки, которая отвлечет лучшие таланты от основного бизнеса компании (в в этом случае условный доступ к платному телевидению). Конечно, эти системные инженеры использовали только некоторые базовые сценарии установки и ничего более.
С другой стороны, с появлением нового поколения веб-приложений и сервисов (например, Google, eBay, Amazon и Facebook) появилась тенденция, когда компании предпочитали горизонтальное масштабирование, нуждались в большем количестве компьютеров и программных компонентов для управления и более высокая частота обновлений. Для них схема умных системных инженеров-ковбоев не сработала. Тем не менее, управление физическими вычислениями, хранилищем, сетевыми блоками в центрах обработки данных организации было нормой.
В 1993 году был представлен CFEngine для решения проблем, возникающих при управлении крупномасштабными центрами обработки данных. С самого начала нужно было различать:
- управление физическими ящиками (компьютеры, диски хранения, сетевые коммутаторы и маршрутизаторы)
- установка, исправление и обновление базового системного программного обеспечения (операционные системы, базы данных или серверы обмена сообщениями)
- установка, исправление, обновление и удаление приложений и пользовательских сервисов
Вслед за CFEngine было представлено множество инструментов, решающих различные аспекты этих проблем, с разной степенью успеха и популярности.
Поскольку весь процесс, хотя и полностью автоматизированный, был медленным, дорогим и подверженным ошибкам, предпочтение было отдано тому, чтобы автоматизация распределения ресурсов инфраструктуры была относительно отделена от разработки приложений. Для этой цели был придуман специальный термин плотность сервисов , чтобы измерить, сколько сервисов или приложений может работать в одной и той же базовой инфраструктуре.
А потом пришла виртуализация
С введением виртуализации (VMWare и т. д.) в центрах обработки данных внезапно стало возможным значительно повысить плотность обслуживания за счет перераспределения физических ящиков для различных потребностей программного обеспечения. Эта публикация не является трактатом по истории индустрии программного обеспечения, поэтому я не буду вдаваться в подробности. Важно отметить, что виртуализация была своего рода подъемом и перемещением центров обработки данных с нуля в виртуализированный мир. Концептуально, однако, мало что изменилось.
Лестница к инфраструктуре как услуге (IaaS) Heaven
С развитием интернет-технологий следующим логическим шагом стала сдача в аренду виртуализированных сред для доступа по сети. Он начался с AWS S3 Storage и быстро распространился на другие области вычислений и сетей. Действительно, во многих случаях не имело значения, где физически расположена эта виртуальная среда (каламбур). Предложения IaaS обещают все меньше и меньше головной боли, связанной с управлением физическими ящиками на месте. Но концептуально инструменты IaC остались на том же уровне, поднимая и перемещая конфигурации центров обработки данных с нуля в виртуализированный мир.
По иронии судьбы, AWS S3 был, вероятно, первым облачным сервисом, и с самого начала он был полностью управляемым и бессерверным. Однако с появлением сервиса AWS EC2 тенденция пошла по другому пути.
Пусть это будет платформа как услуга (PaaS)
Как только мы научились выделять базовые виртуальные машины, прикреплять их к устройствам хранения и подключать их по сети, было вполне естественно упаковать кластер таких запущенных ресурсов, скажем, базу данных, и предложить этот набор ресурсов в качестве новой услуги.
Для поддержки новых предложений «Платформа как услуга» существующие инструменты IaC были расширены, чтобы обеспечить спецификацию такого пакета. Итак, вместе со спецификацией группы автоматического масштабирования виртуальной машины можно было запросить кластер базы данных MySQL. Эта упаковка требуемых высокоуровневых и низкоуровневых ресурсов концептуально по-прежнему поднимала и перемещала центр обработки данных с нуля в виртуализированный мир.
Благодаря облачной архитектуре, впервые предложенной Netflix, и достижениям в технологии контейнеров такая упрощенная картина стала все меньше и меньше соответствовать исходным архитектурам и практикам. Тем не менее, очень мало что изменилось на концептуальном уровне инструментов IaC.
Бессерверный облачный тектонический сдвиг
А затем появилась бессерверная парадигма, когда разработчикам не нужно было беспокоиться о емкости. Как мы туда попали? Проще говоря, как и в физическом мире, как и в случае с развитием технологий, близость определяет возможные шаги в любой момент времени. Автомасштабирование было распространено в сервисах облачных вычислений с самого начала. Это означало, что когда нагрузка на сервер достигает определенного уровня, необходимо выделить другой сервер; когда он упадет ниже порогового уровня, убейте одного. Но вначале пользователям облака приходилось вручную указывать эти цифры, и чаще всего они понятия не имели, какими должны быть эти пороги. Это был лишь вопрос времени, когда поставщики облачных услуг задались вопросом, смогут ли они угадать эти цифры на основе обширной статистики использования, которую они собирали с течением времени.
Простой ответ на вопрос "Почему такая шумиха по поводу serverless?" и "как это связано с IaC ?», заключается в том, что когда инфраструктура превращается в товар, вспомогательные инструменты и методы должны соответствующим образом корректироваться. В настоящее время ведущие инструменты и практики IaC серьезно отстают.
Первоначально решения IaC предназначались для создания исполняемых документов , фиксирующих конфигурацию ресурсов инфраструктуры общего назначения (физические или виртуальные вычисления, сеть, блоки хранения) для удовлетворения потребностей приложений. Позже он был расширен для поддержки пакетных сервисов платформы, таких как кластеры баз данных. Но концептуально он остался прежним.
Поскольку весь процесс, даже полностью автоматизированный, был медленным, дорогим и подверженным ошибкам, предпочтение отдавалось тому, чтобы автоматизация распределения ресурсов инфраструктуры была относительно отделена от разработки приложений. (Я намеренно повторяю это предложение).
Но что, если больше нет низкоуровневых ресурсов инфраструктуры, таких как экземпляры виртуальных машин, диски, кластеры или маршрутизаторы? Правда, выделять бессерверные или полностью управляемые ресурсы по-прежнему нужно, но это качественно другое.
Являются ли те же инструменты и методы идеально подходящими для новой среды? Как утверждает С. Уордли в упомянутой выше статье, ответ — «Нет». В новых условиях нам нужно думать по-новому и действовать по-новому. Действительно, Бессерверность влияет на дизайн. Но концептуально инструменты IaC остались прежними, только включили спецификации бессерверных ресурсов, используя тот же язык подъема и переноса центра обработки данных на «голом железе».
Создание шаблонов IaC вручную — утомительный и подверженный ошибкам процесс. Даже для скромного бессерверного облачного приложения его шаблон IaC может легко содержать сотни строк JSON или YAML. Еще одна проблема заключается в том, что конфигурации могут сбивать с толку, например, что такое роль AWS IAM, чем она отличается от IAM-политики и насколько они актуальны, если приложению нужно только рассчитать общее количество отпусков на одного сотрудника в год?
Однако на этом все не заканчивается. Хотя всегда важно реализовать правильную доменную логику, для производственного развертывания в режиме реального времени существуют дополнительные проблемы, например, защищены ли API от несанкционированного доступа или DDoS-атак, открыта ли база данных для Интернета, если данные перемещаются. и данные на отдыхе правильно зашифрованы, и так далее. Все эти проблемы можно решить с помощью правильного распределения облачных ресурсов. Еще одна серьезная проблема заключается в том, что требования к ресурсам различаются между средами разработки, тестирования и промежуточной среды.
Для среды разработки выделение всех ресурсов может быть дорогостоящим делом. Точно так же для тестовых и промежуточных сред нам может понадобиться лишь несколько ресурсов. Если шаблоны IaC создаются вручную, вполне вероятно, что это будет универсальный тип шаблона, который может быть неэффективным и привести к пустой трате ресурсов. В качестве альтернативы он может превратиться в общую, сверхсложную и параметризованную структуру. Таким образом, несмотря на бессерверный прорыв, мы все еще находимся на нулевом уровне сложности DevOpsFinSec прошлого века.
Подводя итог, можно сказать, что современный стек IaC представляет собой лоскутное одеяло, отражающее эволюцию виртуализации и облачных технологий, включающую как минимум три различных концепции: традиционную инфраструктуру как услугу, элементы платформы как услуги и бессерверное облако.
Было несколько попыток облегчить боль, но я бы сказал, что ни одна из них не дает удовлетворительного решения, потому что я считаю, что основная причина еще не проанализирована. Чтобы понять проблемы, связанные со стеком IaC, и понять, что это означает на практике, давайте рассмотрим ингредиенты Cloud IaC.
Облачный стек IaC: компоненты и взаимосвязи
Чтобы понять, как идеально реализовать автоматическое выделение ресурсов бессерверных облачных приложений, нам необходимо сопоставить существующие компоненты и их взаимосвязи. В этой статье я буду использовать комбинацию серверных экосистем AWS и Python. Реальная ландшафтная карта слишком сложна, чтобы представить ее в одной публикации.
Давайте сначала посмотрим на бессерверную экосистему AWS:
Основные облачные сервисы
В нижней части стека находится постоянно растущий список облачных сервисов AWS (на данный момент их более 200). Каждый сервис предоставляет REST API. Немногие сервисы, такие как AWS S3, являются полностью управляемыми и бессерверными, а это означает, что вам не нужно напрямую заниматься резервированием ресурсов и управлением ими. Сервисы. Однако некоторые сервисы, такие как AWS Aurora, имеют полностью управляемые бессерверные варианты (иначе Aurora Serveless), но также может работать через традиционную кластерную конфигурацию (в данном случае AWS RDS ). Принимая во внимание, что существуют некоторые другие сервисы, такие как AWS Neptune и AWS OpenSearch в настоящее время у них нет полностью управляемых бессерверных вариантов, но они могут появиться в будущем (AWS каждый год объявляет о множестве новых бессерверных вариантов). Важно отметить, что облачный сервис REST API является единственным на 100 % надежным источником достоверной информации. о том, что эти облачные сервисы могут или не могут делать, и объявить о подлинных обещаниях [9] этих сервисов. Все остальное, построенное поверх этих API, гораздо менее надежно.
Некоторые облачные сервисы, управляемые или нет, имеют замену стороннего поставщика (например, ElasticSearch, Cassandra. .com/products/datastax-astra), MongoDB, а также управляемые или нет. Это еще больше усложняет всю картину. Я не буду останавливаться на этом в этой статье. Однако никакое окончательное решение не сможет игнорировать эту тенденцию.
Служба облачной оркестрации
AWS CloudFormation – это уникальный сервис, отвечающий за распределение всех ресурсов из других сервисов. Чтобы узнать об аналогичных услугах от других поставщиков облачных услуг, ознакомьтесь со ссылками ниже.
Все инструменты облачной оркестровки черпают свои основные принципы из CFEngine , но редко делают это в полном объеме и последовательно. Они позволяют указать конфигурацию облачных ресурсов в той или иной форме декларативного или полудекларативного стиля, закодированного как документ JSON или YAML. Служба облачной оркестровки берет этот документ и выделяет, обновляет или удаляет ресурсы для достижения желаемого конечного состояния с максимальными усилиями. По определению, служба облачной оркестровки дает только условные обещания [9]. Он может выделять скоординированный набор облачных ресурсов только в том случае, если базовые облачные службы выполняют свои обещания. Обычно это работает так, как задумано. Но иногда что-то терпит неудачу между трещинами. В любом случае обычно существует задержка между предоставлением основных возможностей службы и ее поддержкой облачной службой оркестрации.
Кроме того, важно отметить, что эта служба облачной оркестровки не делает различий между полностью управляемыми, частично управляемыми или неуправляемыми службами. Один и тот же язык используется для всех сервисов, и один шаблон может содержать произвольное сочетание различных типов сервисов.
Изначально задуманный чистый декларативный стиль никогда не работал должным образом. Итак, язык шаблонов AWS CloudFormation начал внедрять Параметры, Псевдопараметры, Условия, Встроенные функции, Пользовательские ресурсы, Макросы, Модули, Регулярные выражения, Вложенные стеки прогрессивно чтобы сделать шаблоны CloudFormation более гибкими и модульными.
Что касается бессерверных технологий, язык шаблонов AWS CloudFormation имеет еще один серьезный недостаток, и AWS SAM косметика (см. ниже) не учитывала эту проблему. Поскольку шаблоны создаются вручную, существует настоятельная тенденция указывать одну лямбда-функцию для каждого триггера (например, для всех HTTP-запросов). Мы, люди, оптимизаторы энергосбережения. Есть даже сильные голоса [21], утверждающие, что это правильный способ сделать это. И это серьезно проблематично. Во-первых, разные события, приходящие от одного и того же триггера, в общем случае требуют разного количества ресурсов и таймаутов обработки. Во-вторых, эти события требуют разных разрешений и доступа к разным ресурсам (подумайте о HTTP GET и HTTP PUT). И в-третьих, может быть полезно использовать разные версии во время выполнения или даже разные языки (например, для постепенных обновлений или оптимизаций). Правда, мы могли бы, в принципе, начать с одной монолитной лямбда-функции и выдвигать отдельные функции по мере необходимости. Однако обычно это не так. Кроме того, никто не может гарантировать, что конкретную функциональность будет легко выделить в отдельную лямбда-функцию. Вещи, которые когда-то были собраны вместе, обычно сопротивляются разделению.
SDK для облачных служб
Облачные сервисы оркестрации, такие как AWS CloudFormation, — не единственный способ доступа к облачным сервисам. API-интерфейсы REST облачных служб упакованы в библиотеки SDK для конкретных языков. Для доступа к сервисам AWS с помощью Python существует два типа интерфейсов: низкоуровневый интерфейс botocore и высокоуровневый интерфейс boto3.
Как и в случае с упомянутой выше облачной службой оркестровки, SDK дают условные обещания в зависимости от исходных API REST и могут вызывать задержку, обычно небольшую. Кроме того, возможности зависят от языка. Например, возможности Python и Go SDK могут совпадать, а могут и не совпадать.
Излишне говорить, что облачная служба оркестрации имеет свои собственные REST API со своим собственным SDK.
Облачный интерфейс командной строки и консоль
Помимо облачного SDK, есть два дополнительных способа взаимодействия с облачными службами: через интерфейс командной строки, например aws cli и с помощью Консоли управления. Является ли последний реализованным поверх некоторых, скажем JavaScript SDK, я могу предположить (я не знать это точно). Но это кажется правдоподобным предположением, поскольку работа напрямую с REST API может быть громоздкой.
Решение проблем IaC: инструменты и платформы
Концепция IAC имеет свои проблемы и проблемные области. Было много фреймворков и инструментов, которые пытались в некоторой степени уменьшить или решить проблемы IaC.
Модель бессерверных приложений (SAM) — хорошая попытка
Кто-то в AWS довольно рано понял, что язык шаблонов AWS CloudFormation слишком сложен и слишком низкоуровнев для типичных бессерверных приложений и попытался решить проблему, внедрив Модель бессерверных приложений AWS (SAM). Он поставлялся с упрощенным языком шаблонов SAM, SAM CLI и Репозиторий бессерверных приложений AWS. На стороне клиента он был объединен с AWS Amplify Framework.
Это была хорошая попытка, и многие люди использовали ее, включая вас искренне, по крайней мере, в начале. Но, ИМХО, не зашло и не могло зайти слишком далеко. Если язык шаблона AWS CloudFormation может рассматриваться как язык машинного кода [10], то Язык шаблонов SAM можно считать для него макроассемблером. Он не обеспечивает достаточную абстракцию и фактически вводит дырявую абстракцию (слишком легко откатиться на синтаксис CF). Короче говоря, это просто позволило написать меньший JSON/YAML и не решило основную проблему.
Комплект для разработки облака AWS
Как типичный американский бизнес, AWS представляет собой большую организацию, в которой разные люди постоянно пробуют свои идеи. Похоже, кто-то в AWS (или они только что приобрели стартап) осознали, что независимо от трюков, применяемых к JSON/YAML, он никогда не будет таким же мощным, как основной язык программирования. Кто-то предложил внедрить CloudFormation Domain-specific_language в основной хост, что привело к запуску AWS Cloud Development Kit .
Первоначально он был доступен в TypeScript. Позже поддержка была доступна в Python и других языках.
И действительно, с точки зрения гибкости, модульности и автоматизации тестирования AWS Cloud Development Kit решил все проблемы, унаследованные языком шаблонов AWS CloudFormation без введения еще одного сервиса — он автоматически генерирует шаблоны CloudFormation. Что мне не понравилось, так это очень самоуверенное решение о том, сколько нужно создать стеков CloudFormation, но это уже другая история для другой статьи.
Моя самая большая проблема с AWS Cloud Development Kit заключается в том, что он остается на том же уровне абстракции, смешивая бессерверные и несерверные типы ресурсов. Другими словами, остается макроассемблер CloudFormation, просто встроенный в TypeScript или Python. В принципе, чистый бессерверный фреймворк можно построить поверх базового CDK (например, CDK SAM), но я бы серьезно сомневался, стоит ли это делать. Макроассемблер все равно останется макроассемблером.
Чаша AWS
AWS Chalice был на полшага вперед по сравнению с IaC.
Если все, что мы хотим сделать, это разработать набор функций AWS Lambda , которые будут активироваться различными облачными событиями (например, API Gateway Запрос HTTP), почему бы не сгенерировать эти функции непосредственно из кода Python (или любого другого языка)? Это рассуждение лежит в основе AWS Chalice Framework (еще одно приобретение стартапа?), которое мы можем классифицировать как одну из первых попыток перейти от инфраструктуры к коду. (IaC) в инфраструктуру из кода (IfC).
AWS Chalice Framework использует декораторы функций Python для создание лямбда-функций прикрепленных к различным триггерам. Полученный сервис можно развернуть с помощью Python SDK, CloudFormation, Terraform или AWS CDK.
Как было сказано выше, это был большой полушаг вперед (каламбур). Почему полушаг? Потому что он сместил много традиционного мусора IaC под ковер отдельного файла конфигурации. Этого не видно в коде, но некоторым инженерам DevOps по-прежнему необходимо тщательно обработать этот файл конфигурации. В итоге мы остаемся на том же уровне абстракции, просто продвинулись немного дальше.
Лично я не поддерживаю использование декораторов функций Python для маршрутизации протоколов и триггеров событий [11]. На мой взгляд, это скрывает слишком много бизнес-логики и выявляет много нерелевантных низкоуровневых деталей, скажем, протокола HTTP.
Блокировка поставщика/платформы — более серьезный вопрос, требующий решения. Если мы начнем говорить о IfC, должны ли мы также стремиться к нейтральности облачной платформы, чтобы вместо s3_trigger мы говорили о cloud_storage_object_created trigger, независимо от того, является ли он AWS S3 или GCP Cloud? Использование надлежащего уровня абстракции и освобождение разработчиков приложений от сложных деталей облачной платформы — веский аргумент в пользу нейтралитета облака. (Мультиоблако и полиоблако являются разными стратегиями и большими темами, которые следует рассматривать в другом месте). Опасность выродиться в посредственность господствующего с наименьшим количеством простых людей — сильный аргумент против этого. Я вернусь к этому в последнем разделе.
Сторонняя бессерверная экосистема
AWS не одинока в своих попытках решить проблемы облачного IaC. Многие сторонние игроки, коммерческие или нет, разработали дополнительные или альтернативные решения поверх AWS CloudFormation:
Некоторые из этих сторонних поставщиков перечислены ниже (еще больше см. в ссылках ниже). Подробный анализ каждого из них выходит далеко за рамки данной публикации. Я приведу здесь некоторые общие наблюдения:
- Serverless Framework продолжает внешний макроассемблер DSL (более короткий YAML, некоторый облачный нейтралитет, но по сути тот же уровень абстракции)
- Pulumi, InGraph и Тропосфера продолжить ту же линейку встроенных (на Python) макроассемблерных DSL
- HashiCorp Terraform начиналась как внешний DSL макроассемблера, но теперь с его новым Terraform CDK начал переходить на встроенный DSL
- Zappa и Gordon (оба, похоже, больше не поддерживаются) искренне усилия по внедрению инфраструктуры из кода для Python, но не продвинулись дальше AWS Chalice
- Domovoi – интересная попытка расширить AWS Chalice для обрабатывать AWS Lambda источники событий кроме HTTP-запросов через шлюз API. Он делает это с помощью декораторов Python, тем самым смешивая базовую логику приложения с шаблоном инфраструктуры и делая его зависимым от облачной платформы.
- Mangum – еще одна интересная попытка интегрировать Python__ASGI приложения, созданные с использованием популярных такие платформы, как Django и Fast API с AWS Lambda и API Gateway. Таким образом, это может быть полезно для быстрого переноса существующих приложений Python в бессерверное облако при сохранении облачной нейтральности, но из-за отсутствия интеграции с генерацией облачных ресурсов он оставляет это внешним инструментам IaC, таким как Serverless Framework или Модель бессерверных приложений AWS (SAM)__
Основываясь на этом кратком анализе, можно с уверенностью заключить, что ни одна из существующих сторонних бессерверных платформ не обеспечивает адекватного решения для полной реализации инфраструктуры из кода.
Инфраструктура из Code Needs: мечтать не вредно!
Инфраструктура из кода (IfC) требует внесения изменений в существующие технологии поставщиками облачных услуг, поставщиками языков программирования, а также поставщиками инструментов и библиотек. Давайте посмотрим на список пожеланий для каждого из них один за другим.
Усовершенствования облачной платформы
Это не имеет прямого отношения к преобразованию простого кода приложения (на языке программирования) в спецификации бессерверных облачных ресурсов. Однако, если однажды это реализовать, это значительно упростит всю задачу.
- Сокращение объема обещаний службы оркестровки облачных вычислений: основные облачные службы должны взять на себя полную ответственность за выполнение своих обещаний, предоставив службе оркестровки облачных вычислений делать то, что она должна делать. Это особенно важно для так называемого обнаружения дрейфа. Службы должны делать это для себя и отклонять любой запрос на изменение спецификации ресурса, если только он не исходит от владельца ресурса. Забавно и грустно осознавать, что CFEngine делает это уже много лет, а облачных сервисов до сих пор нет. С недавним появлением AWS Control API есть надежда, что все пойдет в нужном направлении.
- Скрыть как можно больше сведений о конфигурации: нужно ли указывать, сколько RAM/vCPU требуется для функции, и чем это отличается от планирования емкости старого поколения? Как насчет автоматического определения среды выполнения? Как насчет помощи в обеспечении соблюдения Принципа наименьших привилегий? Список таких вопросов довольно длинный. Теоретически поставщики облачных услуг в состоянии это сделать. Большой вопрос, сделают ли они это, и если да, то когда?
Расширения языка программирования
На данный момент ни один из основных языков программирования не предоставляет облачную среду выполнения. Новые языки, такие как Ballerina и Ecstasy, могут занять много времени, прежде чем сообщество разработчиков их примет. (разработчики программного обеспечения очень консервативны). Настройка существующих основных языков для поддержки облачных сред может быть лучшей стратегией:
- Облачная система импорта [31]: Нет никакой существенной причины устанавливать что-либо в облаке. В идеале все открытые и коммерческие библиотеки должны быть доступны непосредственно из облачного хранилища.
- Автоматическое вычисление дайджеста модуля: при наличии облачной системы импорта необходимо обеспечить принудительный холодный запуск облачной функции, когда что-то меняется. Наиболее надежным способом достижения этого было бы эффективное вычисление цифровой подписи для каждого метода.
- Расширенная библиотека стандартных протоколов и абстрактных интерфейсов: Это необходимо для автоматического определения облачных ресурсов, выделяемых в различных сценариях. Например, Python DB API указывает точный протокол для объекта подключения к базе данных, но отсутствует Python Protocol Class определены для него, которые можно использовать для обнаружения необходимых облачных ресурсов. Действительно, если приложение определяет, что оно будет использовать объект
db_connectionс MySQL диалект языка запросов, Aurora Serverless для MySQL может выделяться автоматически.
- Улучшенная поддержка абстрактного дерева компилятора: В Python ast выполняет довольно зарождающуюся работу. Помогло бы больше осведомленности поставщиков языковых компиляторов о том, что целью генератора кода может быть облачный ресурс [11]. PyPy добился определенного прогресса в этой области, но он все еще не является основным и непростым в использовании.
Инструменты и улучшения библиотеки
- Надлежащая поддержка системы облачного импорта : Очень часто речь идет о следовании лучшим языковым практикам, но это редко так, особенно зависимость инструментов от локальной файловой системы слишком ограничена.
- Удобная для облака система сборки: Создание облака для облака требует другого подхода к управлению зависимостями и координации задач сборки. Существующие инструменты неадекватны в этом отношении и нуждаются в развитии.
Стандартизация сопоставления ресурсов Object-Cloud
Эта тема терпит неудачу где-то между облачной платформой, компилятором, инструментами и поставщиками библиотек. Для сохранения облачного нейтралитета необходимо максимально использовать стандартные интерфейсы. Например, вместо того, чтобы полагаться на AWS SES, AWS SQS и AWS SNS загадочные API, почему бы не определить стандартный Channel Protocol с функцией send и позволить службе указать, является ли она Очередь, PubSub, Электронная почта или любая их комбинация? Такая спецификация будет полностью нейтральной для облачных вычислений и может быть преобразована в базовую спецификацию облачных ресурсов с небольшими усилиями по программированию.
Другим примером может быть перевод стандартных API структур данных, таких как Python MutableMapping в облачное хранилище, SQL или ресурсы базы данных NoSQL. Это может не сработать для случаев, требующих специальной оптимизации, но в большинстве случаев вполне сработает.
Наконец, как насчет доступа к облачным ресурсам через стандартные интерфейсы? Например, зачем мне использовать AWS IAM arcane API для управления списком пользователей , роли и политики, а не использовать одно и то же Python MutableMapping с разными типами возвращаемых значений?
Кто должен реализовывать такие сопоставления, на данный момент неясно. В идеале об этом должны позаботиться поставщики облачных услуг в сотрудничестве с поставщиками языковых компиляторов. На самом деле это будет открытый проект, управляемый сообществом, объединяющий нескольких игроков, которые считают, что это правильное решение для повышения производительности и качества разработки облачных приложений.
Бессерверная среда разработки
В бессерверном мире и мире инфраструктуры из кода становится все труднее оправдать традиционные системы интегрированной среды разработки, работающие на локальных компьютерах или облачных виртуальных машинах. Действительно, современные браузеры достаточно мощны, чтобы запускать приличный редактор внутри, в то время как должна быть возможность создать бессерверную серверную часть для хранения, вычислений, IntelliSense и т. д. Зачем мне клонировать его из git на мой локальный диск, чтобы позже загрузить его в облако место хранения? Почему облачное хранилище не может выполнять всю работу? Почему я не могу запускать модульные или интегрированные тесты в Cloud Function? Почему Language Server Protocol нельзя реализовать с помощью другого набора облачных функций через WebSockets или REST API?
Короткий ответ на эти вопросы: «Все это осуществимо и в пределах досягаемости». У нас пока нет этих инструментов, хотя концептуально они были продемонстрированы в 1968 году на The Mother of All Demos. Разработка программного обеспечения — это всего лишь немного особый вид умственной работы. Таким образом, Интегрированная система разработки программного обеспечения должна быть просто вариантом Мастерской расширенных знаний. Можем ли мы после многих лет проб и ошибок, усугубляемых жадностью и амбициями как основными движущими силами индустрии высоких технологий, использовать практически неограниченную мощь современных облаков и реализовать видение, задуманное так много лет назад и естественно требуемое здравым смыслом?
Новая волна IfC
В последнее время появился ряд решений, которые пытаются продвигать концепции «Инфраструктура из кода», иногда под разными именами.
- CAIOS, облачная операционная система искусственного интеллекта: по сравнению с традиционными процессами DevOps производительность разработчиков и скорость развертывания повышаются до 10 раз в производительности разработчиков и скорости развертывания. Он также в некоторой степени рассматривает оптимизацию производительности и лучшие практики безопасности как часть IfC. В настоящее время CAIOS поддерживает разработку и развертывание Python на AWS. Отказ от ответственности: Автор этой статьи работает в BST LABS (подразделение BlackSwan Technologies), создатель CAIOS.
- Serverless Cloud: вероятно, самое известное, задокументированное и продвинутое предложение, поддерживающее JavaScript и TypeScript
- Lambdragon: позиционирует себя как облачная IDE нового поколения для JavaScript и TypeScript
- CloudCompiler: Это говорит о том, что описано выше (см. Диаграмму ниже). Он все еще находится в закрытой бета-версии, и пока доступно недостаточно подробностей (сайт не обновлялся с 2020 года).
![Рис. 5: Облачный компилятор] (https://cdn.hackernoon.com/images/-75d2i37.png)
Подведение итогов
Бессерверный мир — это быстро развивающееся пространство, где инфраструктура из кода — это следующий шаг вперед, который может заставить его двигаться еще быстрее. История и эволюция облачных технологий, а также проблемы, связанные с текущими технологиями, представленные выше, ясно указывают на вероятность развития IFC в ближайшие годы. IfC обладает потенциалом для оптимизации и обеспечения столь необходимого повышения гибкости облачных приложений.
Автор, Ашер Стеркин, является генеральным директором BST LABS. BST LABS преодолевает облачный барьер, помогая организациям реализовать весь потенциал облачных вычислений с помощью ряда предложений с открытым исходным кодом и коммерческих предложений. Мы наиболее известны благодаря CAIOS, облачной операционной системе искусственного интеллекта, платформе разработки с технологией "инфраструктура из кода". BST LABS — это подразделение по разработке программного обеспечения BlackSwan Technologies.
Использованная литература
- [С. Уордли, «Все развивается»] (https://blog.gardeviance.org/2013/01/everything-evolves.html)
- [А. Стеркин, «Если ваш компьютер — это облако, как должна выглядеть его операционная система?»] (https://medium.com/analytics-vidhya/if-your-computer-is-cloud-how-its-operating-system -должен-выглядеть-24f62e274a95)
- [Devops with the S for Sharing — Патрик Дебуа, Jax 2012, Лондон] (https://www.slideshare.net/jaxlondon2012/devops-with-the-s-for-sharing-patrick-debois)
- [Работа над культурой DevSecOps — взгляд, ориентированный на команду — Патрик Дебуа] (https://www.slideshare.net/jedi4ever/working-on-devsecops-culture-a-team-centric-view-244991675)
- [Это код, но не такой, каким мы его знаем: инфраструктура как код — Патрик Дебуа, Jax, 2012, Лондон] (https://www.slideshare.net/jaxlondon2012/code-butnotasweknowit121017054820phpapp02)
- [А. Стеркин, «Бессерверная облачная система импорта» (https://asher-sterkin.medium.com/serverless-cloud-import-system-760d3c4a60b9)
Оригинал