[💾] 🍄 Завтрак микоризы. Облачная экосистема (2021)

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

Порождающее ядро – облачный провайдет и идеологический центр

В центре модели у нас находится порождающее ядро, а в ядре – облачный провайдер. Я буду рассматривать модель в целом, но вы можете думать про Amazon, Microsoft или, скажем, Яндекс.Облако или Сбер.Клауд.

При этом роль облачного провайдера можно разделить на две:

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

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

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

Материальная проекция

Чтобы заполнить материальную проекцию, нам необходимо ответить на простой вопрос: а что нужно, чтобы это облако "собралось"? Фактически, мы должно размотать клубок цепочек создания ценности.

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

Важно, что описывая цепочки, мы начинаем видеть перекрестные связи. То есть у нас в архитектуре не звезда, а сеть. Например, производители чипсетов тесно сотрудничают с производителями операционных систем, потому что нужно договориться о драйверах и вообще одно без другого особе не работает. А часть разработчиков прикладного ПО "вываливаются" в позицию инструментальную, потому что по ходу дела сделали какие-то инструменты, которые имеют более широкую приминимость, чем изначально задумывалось. При этом поставщик SaaS-решений и особенно API, мечтает, чтобы его сервисы можно было "дергать" прямо из инструментов разработки.

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

Информационная проекция

Информационная проекция заполняется аналогично, но через призму сборки и распространения информации.

Для обоснования идеологии облачного перехода нужны исследования: академические и рыночные. Первые относятся к области Computer Science (CS), вторые больше территория больших консалтинговых компаний и визионеров. Кстати, на схеме выше между идеологом и академией нет прямой стрелочки, но это зависит от того, какого провайдера вы имеете в виду. У лидера рынка она должна быть.

Чтобы сказать, как правильно внедрять в конкретном заказчике, нужен интегратор. Знания упаковываются и транслируются в следующее поколение специалистов через вузы и online-курсы. Появляются центры сертификации провайдеров, сообщества специалистов и т. п. Оформляется медиа-поле с более или менее специализированными СМИ, блогерами и инфлюенсерами. Свою роль начинают играть регуляторы, переходя из позиции внешнего наблюдателя внутрь экосистемы.

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

Ресурсные циклы

Чтобы описать циклы, мы должны сказать, что у нас циркулирует. То есть что перемещается по тем самым связям, которые мы описали в предыдущих пунктах.

Деньги - да, мы говорили, что это важный элемент социальных экосистем. А что еще? Специалисты, не зря их называют human resources. Оборудование, включая его переработку и очистку. Кстати, тут цикл переработки частично погружен в саму экосистему, потому что провайдер должен убедиться, что данные клиентов не убегут со старыми дисками.

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

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

Циклы обратной связи

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

Местами это работает зеркально: вот был исходный код, давайте его оценивать по востребованности – появляются рейтинги на GitHub. Вот есть готовые решения, давайте посмотрим, что про него думают специалисты – появляются оценки на StackOverflow. Вот, забегая вперед, есть инвестиции, давайте посмотрим на котировки акций облачных компаний и SaaS-стартапов.

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

Обратите внимание, что с обоими типами циклов за оборотом ресурсов и обратной связи того или иного типа можно проследить профильных игроков, которые играют соотвутствующую поддерживающую роль. GitHub, кадровые агентства (или LinkedIn), CrunchBase или банк, предлагающий инвестировать в ПИФы IT-компаний, связанных с облаком, тоже становятся участниками экосистемы.

Материальная граница

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

Самое очевидное с расширением – это фонды и прочие инвесторы, вливающие потоки денег через инвестиции или скупку акций. Еще две силы, характерные для облаков – это:

• "дойная корова" основного бизнеса облачного провайдера (например, ритейл для Amazon AWS, реклама для Google Cloud, Windows/Office для Microsoft Azure, банковские активы для Сберклауда, реклама/медиа/транспорт для Яндекс.Облака) – и это лишь подчеркивает, насколько это ресурсоемкая история;
• специфичные клиенты, которые "топят" именно за облачную парадигму, потому что им так удобно. Например, разработчики мобильных игр и приложений, которые хотят сконцентрироваться на конечном опыте пользователей и не хотят возиться с серверной инфраструктурой.

В минус работают страновые регуляторы, которые, как Центральный банк Англии говорит: "Не-не, ребята, так нельзя". Есть те, кто просто не успевает, не окупил текущие вложения и перестраивается медленнее, поэтому тормозит развитие. Причем такие игроки зачастую тормозят не только себя, но и неудобную им экосистему, что с их точки зрения, конечно, абсолютно нормально.

Информационная граница

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

И вот тут интересный момент: "облачная парадигма" сама по себе от распространения наружу, как это было 5-10 лет назад, начала работать на недопуск внутрь. Уж слишком сложной она стала для массового сознания. Аналогично, как только DevOps стал слишком сложным и комплексным, мы получили еще один барьер входа.

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

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

Рынки информации

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

Рынки бывают как работающие в плюс, например, кадровый, венчурный, софтверный маркетплейс, так и, условно, в минус, паразитные: инсайтов в контексте инвестиций, уязвимостей в контексте безопасности.

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

Общая карта облачной экосистемы

В итоге у нас получилась такая большая красивая картинка, но важно помнить, что это всего лишь пример: схема не полна в своих деталях.

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