В марте 2023 года рабочая группа CNCF по платформам (Platforms WG) представила первый релиз документа
Platforms for Cloud-Native Computing, в котором обсуждается в чем заключается ценность платформ, как измерять эту ценность и как выстраивать платформенные команды таким образом, чтобы максимизировать ее.
Целью документа является поддержка руководителей, архитекторов и лидеров платформенных команд в обосновании, исследовании и планировании внутренних платформ для облачных вычислений. Документ включает следующие разделы:
- Зачем нужны платформы?
- Что такое платформа
- Характеристики успешных платформ
- Характеристики успешных платформенных команд
- Проблемы при внедрении платформ
- Как измерять успешность платформ
- Возможности платформ
Зачем нужны платформы? (Why platforms?)Платформы и платформенная инженерия (Platform Engineering) являются популярной темой в современном мире облачных вычислений (Cloud computing). Прежде чем переходить к определениям, техникам и измерениям, связанным с построением платформ, важно сначала рассмотреть ценность, которую платформы создают и которая обусловливает этот заслуженный интерес.
Улучшения процессов за последние 2-3 десятилетия существенно повысили гибкость команд, занимающихся разработкой приложений и продуктов, предоставив им гибкие сервисы как для инфраструктуры, включая вычислительные ресурсы (Compute), сети (Network) и хранилища (Storage), так и для сервисов разработки, таких как сборки (Builds), тестирование (Tests), поставка (Delivery) и наблюдаемость (Observability). Эта автономия и развитие процессов также привели к постепенному переносу все большей ответственности за поддерживающие сервисы на продуктовые команды, вынуждая их тратить все больше времени и когнитивной энергии на вопросы инфраструктуры и сокращая время, которое они могут посвятить созданию ценности, значимой для их организации.
Стремление вернуть командам поставки (Delivery teams) фокус на их основную деятельность и сократить дублирование усилий в рамках организации мотивировало крупные компании внедрять платформы для Cloud-Native вычислений. Инвестируя в платформы, компании могут:
- снизить когнитивную нагрузку (Cognitive load) на продуктовые команды и тем самым ускорить разработку и поставку продуктов;
- повысить надежность и устойчивость (Reliability and Resiliency) продуктов, использующих платформенные сервисы, за счет выделения экспертов для их настройки и управления;
- ускорить разработку и поставку продуктов за счет повторного использования и совместного применения платформенных инструментов и знаний между многими командами;
- снизить риски возникновения проблем безопасности, регуляторных и функциональных проблем в продуктах и сервисах за счет управления платформенными сервисами, а также пользователями, инструментами и процессами вокруг них;
- обеспечить экономически эффективное и продуктивное использование сервисов публичных облаков и других управляемых сервисов, делегируя реализацию этим провайдерам при сохранении контроля над пользовательским опытом.
Эти преимущества достигаются, с одной стороны, потому что всего несколько платформенных команд обслуживают множество продуктовых команд, многократно усиливая свое влияние; с другой стороны, потому что платформенные команды консолидируют управление общей функциональностью, упрощая управление и контроль (Governance); и, наконец, потому что платформенные команды в первую очередь делают акцент на пользовательских интерфейсах и пользовательском опыте.
Команда платформенных экспертов (Team of platform experts) не только снижает объем типовой работы, требуемой от продуктовых команд, но и оптимизирует платформенные сервисы, используемые в этих продуктах. Платформенная команда также поддерживает набор общепринятых паттернов, знаний и инструментов, широко используемых в крупной компании, что позволяет разработчикам быстро подключаться к работе в других командах и над другими продуктами, построенными на тех же основаниях. Общие платформенные паттерны также позволяют встраивать управление и контроль (Governance and controls) в шаблоны, паттерны и сервисы. Наконец, поскольку платформенные команды координируют работу провайдеров и предоставляют единообразный пользовательский опыт поверх их предложений, они обеспечивают эффективное использование публичных облаков и сервисных провайдеров для базовых инфраструктурных функций, таких как управление базами данных, управление идентификацией и доступом (Identity access), эксплуатация и управление жизненным циклом приложений (App lifecycle).
Что такое платформа (What is a platform)Платформа для Cloud-Native вычислений представляет собой интегрированный набор возможностей (Capabilities), определенных и представленных в соответствии с потребностями пользователей платформы. Это сквозной слой (Cross-cutting layer), который обеспечивает единообразный опыт получения и интеграции типовых возможностей и сервисов для широкого набора приложений и сценариев использования. Хорошая платформа предоставляет единообразный пользовательский опыт при использовании и управлении своими возможностями и сервисами, например через порталы (Web portals), шаблоны проектов (Project templates) и Self-service API.
Согласно подходу Team Topologies, "Платформенные команды создают возможности, которые могут использоваться множеством stream-aligned команд с минимальными накладными затратами… платформенные команды минимизируют потребление ресурсов и когнитивную нагрузку stream-aligned команд… платформенные команды могут создавать целостный пользовательский опыт, охватывающий различные пользовательские интерфейсы или продукты".
Согласно Martin Fowler и Evan Bottcher , "Цифровая платформа (Digital platform) — это основа из self-service API, инструментов, сервисов, знаний и поддержки, организованных как привлекательный внутренний продукт. Автономные команды поставки (Autonomous delivery teams) могут использовать платформу для более быстрой поставки продуктовых возможностей при сниженной потребности в координации".
Конкретный набор cервисов и сценариев, поддерживаемых платформой, должен определяться потребностями стейкхолдеров и пользователей. При этом, несмотря на то что платформы предоставляют эти необходимые сервисы, важно отметить, что платформенные команды не всегда должны реализовывать их самостоятельно. Сервис-провайдеры или выделенные внутренние команды могут поддерживать базовые реализации, тогда как платформа должна представлять собой максимально тонкий разумный слой (Thinnest reasonable layer), обеспечивающий единообразие между предоставляемыми реализациями и соответствие требованиям организации. Например, простая платформа может представлять собой Wiki страницу со ссылками на стандартные действия и шаги для предоставления сервисов от провайдеров, как описано в паттерне Thinnest Viable Platform (TVP).
Поскольку такие платформы ориентированы ни на кого иного, кроме внутренних пользователей крупной компании, мы часто называем их внутренними платформами (Internal platforms).
Платформы особенно актуальны для Cloud-Native архитектур, поскольку они в большей степени, чем предыдущие парадигмы, отделяют поддерживающие сервисы от прикладной бизнес-логики. В облачных средах ресурсы и сервисы часто управляются независимо и интегрируются с пользовательскими бизнес-компонентами; такие ресурсы могут включать базы данных и объектные хранилища, очереди и брокеры сообщений, сборщики телеметрии и дашборды, системы аутентификации, планировщики задач и другие ресурсы. Внутренняя платформа предоставляет эти сервисы командам таким образом, чтобы их было легко интегрировать в приложения и системы.
Зрелость платформ (Platform maturity)На самом базовом уровне внутренние платформы предоставляют единообразный пользовательский опыт для получения и использования отдельных сервисов, таких как система запуска пайплайнов, система управления базами данных или хранилище секретов. По мере зрелости внутренние платформы также начинают предлагать композиции таких сервисов в виде Self-service шаблонов для ключевых сценариев, таких как разработка приложений или анализ данных, также известных как MLOps.
Сценарии использования, которые крупные компания может реализовать с помощью платформ, могут последовательно развиваться следующим образом:
- Продуктовые разработчики (Product developers) могут по необходимости (On demand) получать сервисы, такие как вычислительные ресурсы, хранилища, базы данных или системы идентификации, и сразу использовать их для запуска приложений;
- Продуктовые разработчики могут по необходимости получать сервисные пространства (Service spaces) и использовать их для запуска конвейеров и задач, хранения артефактов и конфигурации или сбора телеметрии;
- Администраторы сторонних приложений (Third-party software) могут по необходимости получать необходимые зависимости, такие как базы данных, и легко устанавливать и запускать приложения;
- Продуктовые разработчики могут получать полностью готовые окружения по шаблонам, объединяющие run-time и development-time сервисы, необходимые для конкретных сценариев, таких как разработка или MLOps;
- Продуктовые разработчики и менеджеры могут наблюдать за функциональностью, производительностью и стоимостью развернутых сервисов с помощью автоматических инструментов и стандартных дашбордов.
Предоставляя единообразный и соответствующий требованиям пользовательский опыт для отдельных сервисов или их наборов, внутренние платформы в конечном итоге упрощают и повышают эффективность поставки ценных продуктов для своих пользователей.
Обратитесь к
Platform Engineering Maturity Model, созданной после первоначальной публикации данного документа.
Характеристики платформ (Attributes of platforms)После определения того, что такое платформа и почему организации может понадобиться ее создание, выделим ключевые характеристики, которые влияют на успешность платформы.
- Платформа как продукт (Platform as a product). Платформа существует для удовлетворения потребностей своих пользователей и должна проектироваться и развиваться исходя из этих потребностей, аналогично любому другому программному продукту. Платформы должны предоставлять необходимые сервисы для поддержки наиболее распространенных сценариев использования в продуктовых командах и отдавать им приоритет по сравнению с более специфичными сервисами, которые используются только одной командой, чтобы максимизировать создаваемую ценность;
- Пользовательский опыт (User experience). Платформа должна предоставлять свои сервисы через единообразные интерфейсы и фокусироваться на пользовательском опыте. Платформы должны стремиться приходить к пользователям туда, где они уже работают, что может означать сочетание GUI, API, инструментов командной строки, IDE и порталов. Например, платформа обычно предоставляет сервис развертывания приложения. Разработчики могут использовать этот сервис через IDE, тестировщики — через инструмент командной строки, тогда как владелец продукта может использовать портал с графическим интерфейсом;
- Документация и онбординг (Documentation and onboarding). Документация является ключевым аспектом успешного программного продукта. Для использования возможностей платформы пользователям необходимы документация и примеры. Платформа должна поставляться с корректной документацией, учитывающей потребности ее пользователей. Она также должна предоставлять инструменты для ускорения онбординга (Onboarding) новых проектов, которые помогают пользователям быстро и просто подключаться к необходимым платформенным сервисам. Например, платформа может предлагать переиспользуемый процесс (Workflow) для сборки, сканирования, тестирования, развертывания и наблюдаемости приложения в Kubernetes. Такой процесс может поставляться вместе с начальным шаблоном проекта и документацией — набором, который часто называют Golden path;
- Самообслуживание (Self-service). Платформа должна поддерживать модель самообслуживания. Пользователи должны иметь возможность автономно и автоматически запрашивать и получать сервисы. Это свойство является ключевым для того, чтобы платформенная команда могла поддерживать множество продуктовых команд и масштабироваться по мере необходимости. Платформенные сервисы должны быть доступны по необходимости и с минимальным ручным вмешательством через описанные выше интерфейсы. Например, пользователь должен иметь возможность запросить базу данных и получить ее адрес и учетные данные, выполнив команду в командной строке или заполнив форму на портале;
- Снижение когнитивной нагрузки для пользователей (Reduced cognitive load for users). Одной из ключевых целей платформы является снижение когнитивной нагрузки на продуктовые команды. Платформа должна инкапсулировать детали реализации и скрывать сложность, возникающую из ее архитектуры. Например, платформа может делегировать часть сервисов облачному провайдеру, но пользователи не должны быть погружены в такие детали. В то же время платформа должна позволять пользователям при необходимости настраивать и отслеживать состояние отдельных сервисов. Пользователи не должны нести ответственность за эксплуатацию сервисов, предоставляемых платформой. Например, пользователям часто требуется база данных, но им не должно быть необходимо управлять сервером базы данных;
- Опциональность и модульность (Optional and composable). Платформы предназначены для повышения эффективности разработки продуктов, поэтому они не должны становиться препятствием. Платформа должна быть модульной и позволять продуктовым командам использовать только отдельные части предоставляемых ею сервисов. Она также должна позволять продуктовым командам предоставлять и управлять собственными сервисами вне платформы, когда это необходимо. Например, если платформа не предоставляет графовую базу данных, а она требуется для продукта, продуктовая команда должна иметь возможность самостоятельно развернуть и эксплуатировать такую базу данных;
- Безопасность по умолчанию (Secure by default). Платформа должна быть безопасной по умолчанию и предоставлять возможности для обеспечения соответствия требованиям и валидации на основе правил и стандартов, определенных в организации.
Характеристики платформенных команд (Attributes of platform teams)Платформенные команды отвечают за интерфейсы и пользовательский опыт взаимодействия с платформенными сервисами, такими как порталы, APIs и шаблоны для Golden path. С одной стороны, платформенные команды взаимодействуют с командами, реализующими инфраструктуру и поддерживающие сервисы, чтобы формировать единообразный пользовательский опыт; с другой — работают с продуктовыми и пользовательскими командами, собирая обратную связь и обеспечивая соответствие этого опыта требованиям.
Ниже перечислены задачи, за которые должна отвечать платформенная команда:
- исследование требований пользователей платформы и планирование дорожной карты функциональности (Feature roadmap);
- продвижение, популяризация и отстаивание ценностей, предлагаемых платформой;
- управление и развитие интерфейсов для использования и отслеживания состояния сервисов, включая порталы, API, документацию и шаблоны, а также инструменты командной строки (CLI).
Самое важное — платформенные команды должны понимать требования пользователей платформы, чтобы формировать и непрерывно улучшать возможности и интерфейсы, которые предоставляет платформа. Способы изучения пользовательских требований включают интервью с пользователями, интерактивные хакатоны, системы отслеживания задач и опросы, а также прямое наблюдение за использованием через инструменты наблюдаемости. Например, платформенная команда может опубликовать форму для подачи запросов на функциональность, проводить встречи по дорожной карте для обсуждения предстоящих сервисов и анализировать паттерны использования пользователей для расстановки приоритетов.
Входящая обратная связь и продуманный дизайн — это одна сторона поставки продукта; другая сторона — исходящий маркетинг (Outbound marketing ) и формирование активной поддержки (Advocacy). Если платформа действительно построена на основе требований пользователей, эти пользователи будут заинтересованы в использовании предоставляемых возможностей. Платформенная команда может способствовать принятию платформы пользователями через внутренние маркетинговые активности, включая широкие анонсы, демонстрации и регулярные сессии обратной связи и коммуникации. Ключевым здесь является умение приходить к пользователям туда, где они уже находятся, и сопровождать их в процессе вовлечения и получения ценности от платформы.
Платформенная команда не обязательно управляет вычислительными ресурсами, сетями, хранилищами или другими сервисами. Более того, внутренняя платформа должна по возможности опираться на внешние сервисы; платформенные команды должны создавать и поддерживать собственные реализации только в тех случаях, когда необходимые сервисы недоступны у провайдеров или внутренних инфраструктурных команд. Вместо этого платформенные команды в первую очередь отвечают за интерфейсы, то есть GUI, CLI и API, а также за пользовательский опыт взаимодействия с сервисами и возможностями, которые предоставляет платформа.
Например, платформа может описывать и даже предоставлять кнопку для предоставления идентификации внутри приложения, в то время как реализация этой возможности может осуществляться через облачный сервис управления идентификацией. Внутренняя платформенная команда может управлять описанием и API, но не фактической реализацией сервиса. Как правило, платформенным командам следует рассматривать создание и поддержку собственных сервисов только в тех случаях, когда требуемый сервис недоступен в других местах.
Проблемы и вызовы при работе с платформами (Challenges with platforms)Несмотря на то что платформы обещают значительную ценность, они также несут с собой ряд вызовов, которые необходимо учитывать при их внедрении.
- Платформенные команды должны относиться к своим платформам как к продуктам и развивать их совместно с пользователями;
- Платформенные команды должны внимательно расставлять приоритеты и выбирать первые продуктовые команды;
- Платформенные команды должны заручиться поддержкой руководства компании и демонстрировать влияние на цепочки создания ценности (Value streams).
Пожалуй, самым важным является отношение к платформе как к продукту, ориентированному на пользователей, и понимание того, что ее успех напрямую зависит от успеха ее пользователей и продуктов. В связи с этим критически важно, чтобы платформенные команды сотрудничали с командами разработки и другими пользователями при приоритизации, планировании, реализации и итеративном развитии сервисов и пользовательского опыта платформы. Платформенные команды, которые выпускают функциональность и пользовательские сценарии без обратной связи или полагаются на директивы сверху (Top-down mandates) для обеспечения принятия платформы, почти наверняка столкнутся с сопротивлением и недовольством пользователей и упустят значительную часть обещанной ценности. Для противодействия этому платформенным командам следует с самого начала включать продуктовых менеджеров (Product managers), чтобы совместно формировать дорожные карты, собирать обратную связь и в целом понимать и представлять потребности пользователей платформы.
При внедрении платформ выбор правильных сервисов и пользовательских сценариев, которые следует реализовать в первую очередь, может быть критически важным. Сервисы, которые требуются часто и не являются источником конкурентного отличия, такие как конвейеры, базы данных и сервисы наблюдаемости, могут стать хорошей отправной точкой. Платформенные команды также могут сначала сосредоточиться на ограниченном числе вовлеченных команд. Детальная обратная связь от таких команд позволяет улучшить первые пользовательские сценарии платформы, а участники этих команд помогают становиться сторонниками и популяризаторами платформы среди последующих пользователей.
Наконец, в крупных компаниях критически важно как можно быстрее получить поддержку со стороны руководства для платформенных команд. Многие руководители компаний воспринимают ИТ инфраструктуру как статью расходов, слабо связанную с основными цепочками создания ценности, и могут стремиться ограничивать затраты и ресурсы, выделяемые на ИТ платформы, что приводит к некачественной реализации, невыполненным обещаниям и недовольству. Чтобы снизить эти риски, платформенные команды должны демонстрировать свое прямое влияние и связь с продуктовыми командами, позиционируя платформенную команду как стратегического партнера продуктовых команд в создании ценности для клиентов.
Поддержка платформенных команд (Enabling platform teams)Из перечисленных вызовов очевидно, что платформенные команды сталкиваются с широким спектром разнородных обязанностей, что приводит к росту когнитивной нагрузки. Аналогично командам, разрабатывающим приложения, эта проблема усиливается по мере увеличения числа и разнообразия пользователей и команд, которые необходимо поддерживать.
Важно фокусировать усилия платформенной команды на пользовательском опыте и возможностях, которые являются уникальными для конкретного бизнеса. К способам снижения нагрузки на платформенную команду относятся следующие:
- стремиться к созданию максимально тонкого жизнеспособного платформенного слоя (Thinnest viable platform layer) поверх реализаций от провайдеров;
- использовать Open Source фреймворки и наборы инструментов для создания документации, шаблонов и композиций для использования командами приложений;
- обеспечить адекватную численность платформенных команд с учетом их предметной области и количества пользователей.
Как измерять успешность платформ (How to measure the success of platforms)Крупные компании стремятся измерять, обеспечивают ли их платформенные инициативы ценности и характеристики, рассмотренные выше. Кроме того, на протяжении всего документа подчеркивается важность отношения к внутренним платформам как к продуктам, а качественное управление продуктом опирается на количественные и качественные измерения его эффективности. Для выполнения этих требований внутренние платформенные команды должны на постоянной основе собирать обратную связь от пользователей и измерять пользовательскую активность.
Как и в других аспектах внутренних платформ, платформенным командам следует прикладывать минимально необходимое усилие для сбора требуемой обратной связи. Ниже предлагаются метрики, однако на начальном этапе наибольшую ценность могут представлять простые опросы и анализ поведения пользователей.
Категории метрик, которые помогут крупным компаниям и платформенным командам понять влияние своих платформ, включают следующее:
Удовлетворенность пользователей и продуктивность (User satisfaction and productivity)Первое качество, к которому стремятся многие платформы, — это улучшение пользовательского опыта с целью повышения продуктивности. Метрики, отражающие удовлетворенность пользователей и продуктивность, включают следующее:
- активные пользователи и удержание (Active users and retention): включают количество предоставленных возможностей, а также рост и отток пользователей;
- Net Promoter Score (NPS) или другие опросы, измеряющие удовлетворенность пользователей продуктом;
- метрики продуктивности разработчиков, такие как метрики, рассматриваемые в фреймворке SPACE (SPACE framework).
Организационная эффективность (Organizational efficiency)Еще одной ценностью, которую многие платформы стремятся обеспечить, является эффективное удовлетворение общих потребностей большой пользовательской базы. Обычно это достигается за счет поддержки формата self-service и сокращения ручных шагов и необходимого участия людей при одновременном применении политик, гарантирующих безопасность и соответствие требованиям. Для измерения эффективности платформы в снижении объема типовой работы можно рассмотреть следующие показатели:
- время от запроса до предоставления сервиса, такой как база данных или тестовое окружение;
- время, необходимое для сборки и развертывания нового сервиса в Production;
- время, необходимое новому пользователю для отправки первых изменений кода в свой продукт.
Поставка продуктов и функциональности (Product and feature delivery)Конечной целью внутренних платформ является более быстрая поставка бизнес-ценности клиентам, поэтому измерение влияния на выпуск продуктов и функциональности самой компании позволяет показать, что цели платформы достигаются. Команда DORA (DevOps Research and Assessment) рекомендует отслеживать
следующие метрики:
- частота развертываний (Deployment frequency);
- срок поставки (Lead time for changes);
- время восстановления (Time to restore services after failure);
- неуспешные изменения (Change failure rate).
В целом одной из ключевых задач платформенных команд является выравнивание инфраструктуры и других ИТ сервисов с цепочками создания ценности компании — ее продуктами. Таким образом, в конечном итоге именно успешность продуктов и приложений является истинной мерой успешности платформы.
Возможности платформ (Capabilities of platforms)Платформа для Cloud-Native вычислений предоставляет и комбинирует возможности и сервисы от множества провайдеров. Такими провайдерами могут быть другие команды внутри организации или внешние, такие как поставщики облачных сервисов. В общих чертах платформы выступают связующим звеном между провайдерами базовых сервисов и пользователями платформы, например разработчиками приложений; при этом они реализуют и обеспечивают соблюдение требуемых практик в области безопасности, производительности, управления затратами и согласованного пользовательского опыта. Следующая иллюстрация показывает взаимосвязи между продуктами, платформами и провайдерами: