Часть первая: общий фон

Введение

«Инфраструктура из кода» (IfC) — это относительно новая технология, ориентированная на преобразование чистого кода приложений в спецификации облачной инфраструктуры.

В прошлом году его представил Джереми Дейли на re:invent 2022 в Лас-Вегасе. Тем не менее, он остается неизвестным широкой публике. Результаты поиска Google по запросу Инфраструктура из кода в основном состоят из ссылок на публикации Инфраструктура как код. С другой стороны, игроков на этом поприще уже около десятка.

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

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

В этой серии я собираюсь более подробно рассмотреть фундаментальные ограничения, которые определяют выбор технологий и выбор, сделанный нынешними игроками. Что общего, а что отличается в их предложениях? Они конкурируют за один и тот же сегмент рынка? Насколько велик общий потенциал и какая его часть еще не раскрыта существующими предложениями?

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

  1. Часть первая: общий фон
  2. Часть вторая: пятифакторный анализ
  3. Часть третья: Изометрический вид и резюме

Отказ от ответственности

Поскольку я являюсь техническим руководителем одного из продуктов IfC, а именно Cloud AI Operating System (CAIOS), я не могу быть на 100% объективным и нейтральным. Как и любой другой игрок в этой области, я предвзято отношусь к конкретным технологиям и бизнес-выборам. Единственное, что я мог сделать, это открыто признать это заранее.

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

Я также буду избегать, насколько это возможно, прямого маркетинга моего собственного продукта. Эта серия ни в какой форме не отражает официальную позицию или бизнес-стратегию моей материнской компании BlackSwan Technologies или продукта, за который я отвечаю.

Одним словом, относитесь к этой серии как к чисто профессиональному трактату на тему, которая меня искренне интересует, отражающую мое собственное понимание предмета.

Аналитическая основа

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

Многие аналитические системы используют ту или иную форму матриц N x N, вероятно, отражающую тот факт, что на бумаге мы ограничены двумерным пространством. Мы также больше привыкли к декартовским структурам, чем к более общим структурам семантического пространства-времени.

Ален Хелтон проанализировал три концепции IfC с использованием пяти атрибутов:

  • Время на сборку – как быстро я смог что-то запустить и запустить.
  • Подход — какая методология использовалась для абстрагирования или вывода инфраструктуры из кода.
  • Развертывание — насколько легко было разместить то, что я написал, в облаке
  • Производительность — была ли задержка API в пределах допустимого порога.
  • Видимость — насколько я могу видеть, изменять или управлять созданной инфраструктурой.

Хотя эти критерии могут быть полезны для оценки текущей зрелости продуктов, отвечая на вопрос «что я могу сделать с ними сегодня?», это не тот вопрос, на который я пытаюсь ответить.

Глядя на свою дорожную карту продукта на год вперед, я спрашиваю себя, каков общий потенциал технологии IfC в целом, и только после этого, в какой степени она используется или планируется к использованию нынешними игроками.

Мое основное предположение для этого анализа заключается в том, что до тех пор, пока они не достигнут истинного, убедительно доказанного соответствия продукта рынку, все текущие предложения являются предварительными MVP, предназначенными для проверки принятия рынком и готовности инвесторов вкладывать больше денег.

Ала Шибан из Klotho недавно опубликовал свой анализ подмножества существующих предложений IFC, перечислив следующие четыре основных подхода к реализации IFC:

Такая линейная структура перехода от «что-то меньше» к «что-то больше» вполне приемлема для технической документации по продукту, чтобы оправдать сделанный технологический выбор и продемонстрировать превосходство продукта над конкурирующими предложениями. Моя цель в этой серии другая.

Меня больше интересуют стратегические варианты с потенциально долгосрочными последствиями, избегая, насколько это возможно, любых преждевременных хороших/плохих или правильных/неправильных выводов. Все продукты плохи, если они не приносят ценности и не приносят денег. Все решения ошибочны, если только не доказано обратное… оглядываясь назад.

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

Итак, какой подход мне выбрать?

В моем списке на данный момент 12 продуктов IfC, включая мой собственный CAIOS плюс 3 исключения, исключенные по той или иной причине. Предполагая, что я не собираюсь бороться с ограничением пространства 2D-страницы, это предполагает размещение их всех в виде строк некоторой таблицы. Теперь вопрос, какие столбцы должны быть в такой таблице, сколько их и для чего?

Одним из возможных способов было бы начать с одного столбца и посмотреть, есть ли какие-либо полезные идеи, которые мы могли бы извлечь из такого анализа. Если нет — увеличивайте количество столбцов с учетом известного ограничения 7+/-2.

Одномерный анализ

Жизненный цикл внедрения технологии

Для анализа с одной колонкой, давайте для начала проверим, может ли использование Гаустической кривой внедрения технологии Роджера соответствовать всем требованиям. Мне больше привычна работа с вариацией Джеффри Мура, в которой явно упоминается Пропасть.

Как показано на рис. 1 ниже, моя оценка состоит в том, что технология IfC в целом в настоящее время находится на стадии раннего рынка, в основном подходящей для ранних пользователей, которым, как мы знаем, требуется высокий уровень гибкости и открытости системы для того, чтобы иметь возможность адаптировать его к своим конкретным потребностям.

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

Открытость и взломоспособность отдельных систем (если я мог позволить себе такой термин) могли оценить только ранние последователи, которые действительно пытались играть с системой. Для них будет важно знать, как расширить/исправить систему, если что-то отсутствует или работает не так, как ожидалось.

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

Тип инновации

Тип инновации, например. подрывной и поддерживающий может быть следующим кандидатом на основу сравнительного анализа предложений IfC:

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

Основная причина такой оценки заключается в том, что нынешнее поколение разработчиков шаблонов IaC (иногда их называют инженерами DevOps) и программистов Cloud SDK уже слишком глубоко усвоили эти специальные знания, которые, по крайней мере в начале, будут рассматривать IfC как не серьезно, утверждая, что он никогда не достигнет уровня сложности, необходимого для создания шаблонов Terraform (или CloudFormation) и Helm производственного уровня, и никогда не сможет идти в ногу с постоянно меняющимися SDK облачных сервисов. Когда-то одни и те же аргументы использовались программистами машинных языков против любого компилятора…

Исходя из этой оценки, на нынешнем этапе развития IfC в основном придется заботиться о недостаточно обслуживаемых группах населения — людях, которым необходимо разрабатывать программное обеспечение для облака, но для которых текущий вариант IaC + SDK слишком громоздкий, трудоемкий и/или подвержен ошибкам и безопасности.

Тип рынка

Стив Бланк в своем основополагающем Руководстве для владельцев стартапов рассказал нам, что тип рынка влияет на ВСЕ, что делает компания, поэтому нам, вероятно, также следует обратить внимание на эту ось:

  • Вывод нового продукта на существующий рынок
  • Выведение нового продукта на новый рынок
  • Выведение нового продукта на существующий рынок и попытка:
    — Пересегментировать этот рынок в качестве участника с низкими затратами
    — Пересегментировать этот рынок в качестве участника ниши 👈
  • Клонирование бизнес-модели, успешной в другой стране

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

Для обозначения этого малообеспеченного населения я иногда использую термин «грамотные программисты умственного труда» — люди, которые не против писать код для решения каких-то реальных бизнес-задач с помощью облака, но не имеют времени, навыков и терпения разбираться с низкоуровневыми гайками. и болты текущего варианта IaC+SDK.

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

Следовательно, «работник умственного труда» может играть роль «гражданского разработчика», если он может добиться прогресса в рамках ограничений, налагаемых отсутствием кода/платформами с низким кодом. Когда ответ «нет», что означает, что доступные варианты без кода/малого кода не являются гибкими, неизвестными или просто слишком дорогими, тогда «работник умственного труда» может предпочесть написать некоторый код, если он не требует глубокого понимания. опыт работы с базовыми облачными технологиями.

Технология IfC точно чувствует этот пробел. Следуя рецепту Руководства для владельцев стартапов, мы могли бы получить следующую карту рынка (не волнуйтесь, компании конкурируют с бизнес-моделями, а не с высокоуровневыми диаграммами, отражающими очевидные факты):

Диаграмма выше пытается показать, что IfC предлагает радикальное упрощение разработки полного кода по сравнению с более традиционными вариантами IaC + SDK и гибкость джейлбрейка по сравнению с вариантами без кода / с низким кодом, а также резко снижает блокировку поставщика.

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

Двухколоночный анализ

Магический квадрант Gartner разделяет компании на две оси: полнота видения и способность к реализации. Это потенциально очень полезная модель для выявления лидеров рынка, но в меньшей степени для анализа технологий. По понятным причинам я решил оставить Gartner Magic Quadrant… Gartner.

Карты Уордли

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

По сути, в нем утверждается, что технология IfC на данный момент находится на этапе становления, который по определению является неопределенным и рискованным, предназначенным для упрощения, предположительно индивидуальной разработки приложений, изолируя ее от сложных деталей ведущих облачных платформ (например, AWS, Azure). , GCP и т. д.) с некоторым использованием программного обеспечения с открытым исходным кодом, которое является зрелым и хорошо изученным.

Некоторые специалисты Wardley Maps, включая самого Саймона Уордли, вероятно, будут возражать против того, чтобы я отнес облачные платформы к категории Продукт, а не полезность. У меня были свои причины для этого: с точки зрения IfC, отдельные облачные платформы достаточно различны и не так широко распространены и развиты, как решения с открытым программным обеспечением (например, MySQL или Apache SPARK).

Как и в случае с картой рынка IfC, представленной выше, дальнейшая разработка карты IfC Wardley перенесет нас в проблемную область сравнения стратегических действий различных поставщиков IfC, и это, опять же, должно оставаться за закрытыми дверями, по крайней мере, некоторое время. .

Предварительные выводы

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

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

Является ли такая стратегия доступной для одного поставщика или будет использоваться несколькими поставщиками — это другой вопрос, на данный момент выходящий за рамки этой серии статей.