Платформа как продукт расширяет возможности разработки платформ за пределы узкого технологического решения. Платформы требуют изменения в том, как организации приносят пользу. Эффективная платформа дает командам разработчиков программного обеспечения больше времени для работы, ориентированной на получение прибыли, предоставляя высококонтекстуализированные инструменты, масштабируемые и устойчивые.
Проекты платформ, ориентированных на технологии, часто решают лишь часть более широкой задачи. Чтобы реализовать все возможности платформ, организации должны думать не только о технологических компонентах, но и о том, как они упаковывают опыт предоставления и использования управляемых услуг, которые отражают стандарты и ограничения организации.
Тесты, которые следует применять при оценке дизайна платформы
Применение продуктового мышления дает понять, что платформа не должна пытаться решить каждый вариант использования и не должна навязывать один узкий путь. Вместо этого платформенные продукты представляют собой тщательно подобранный набор решений, которые содержат то, что уникально для бизнеса, но достаточно распространено среди команд разработчиков приложений, чтобы ими можно было поделиться.
Практический способ оценить ценность платформы — проверить, насколько хорошо она может обеспечить три важных результата:
- Сколько времени требуется потребителю платформы, чтобы получить доступ к тому, что ему нужно, когда оно ему нужно? Платформа должна обеспечивать доступ к услугам и ресурсам по требованию. Когда разработчики сталкиваются с большим количеством передач, длительным ожиданием и другими трудностями, они в конечном итоге тратят много времени и энергии или в конечном итоге прибегают к теневым ИТ-отделам.
- Сколько людей и сколько времени потребуется для внедрения общеорганизационных изменений возможностей платформы? Владельцы централизованного хранилища должны иметь возможность обновлять и контролировать каждый экземпляр одним действием. Без этого окружающая среда будет дрейфовать, а техническое обслуживание выйдет на неуправляемый уровень.
- Сколько людей и сколько времени потребуется, чтобы добавить на платформу новую возможность? Устойчивая архитектура платформы позволяет специалистам использовать свои собственные возможности. Команды платформы сами по себе не могут поддерживать все услуги в таких областях, как CI, данные, искусственный интеллект или сети. Специалисты должны иметь возможность без промедления публиковать возможности, прошедшие первые три теста. Роль команды платформы — сделать эту модель вклада возможной.
Технические принципы, лежащие в основе эффективных платформ
Распространенной ошибкой при проектировании платформы является слишком сильная зависимость от текущей инфраструктуры и инструментов настройки. Эти инструменты полезны, но недостаточны для управления сложными переходами, разнообразными системами и собственными процессами организации.
Следующие три принципа постоянно создают платформы, которые проходят тесты на ценность и при этом адаптируются к меняющимся потребностям с течением времени.
Композиция вместо простой абстракции
Абстракция важна, поскольку она дает разработчикам единый интерфейс, скрывающий особенности базовых инструментов. Когда эти абстракции предлагаются в виде API, они отделяют пользовательский опыт от реализации. Разработчику не нужно беспокоиться о том, реализована ли возможность с помощью Ansible, Terraform или сценария мэйнфрейма.
Как только существуют согласованные абстракции API, становится возможной композиция. Композиция позволяет создателям возможностей полагаться на API, опубликованные другими, и повторно использовать их, не будучи экспертами в каждой области. Без композиции платформы либо дублируют работу, либо слишком агрессивно централизуют, замедляя способность организации приносить пользу своим конечным клиентам.
Инкапсуляция процесса и конфигурации
Выбор «строить» в рамках проектирования платформ, учитывая варианты сборки, покупки или объединения, обходится дорого. Это означает, что вам следует инвестировать только в создание того, что уникально для организации и ценно для многих команд. Уникальность компании делает сочетание не только индивидуальной инфраструктуры, конфигурации и политики, но и любых связанных с ней процессов.
Декларативные языки, такие как Crossplane, Terraform/OpenTofu, Open Policy Agent (OPA) и Kyverno, имеют расширенную инфраструктуру, конфигурацию и управление политиками. Тем не менее, императивные действия остаются обычным явлением, особенно в интерфейсах командной строки облачных провайдеров, внутренних системах или средах, в которых отсутствуют подходящие декларативные интерфейсы. И ни один из этих языков не включает в себя такие процессы, как управление длительными рабочими процессами, автономные действия и ручные действия, такие как утверждения, которые являются основными требованиями.
Платформа должна инкапсулировать инфраструктуру, конфигурацию, политику и процессы в единое целое. Без этого вы не сможете безопасно создавать сервисы или полагаться на них как на строительные блоки. Это связано с тем, что поведение любого нетривиального сервиса охватывает несколько инструментов, которые невозможно синхронно скоординировать.
Говорят, что организации создают процессы как рубцовую ткань от своих прошлых болей. Это делает любые процессы уникальными для организации, и их трудно изменить и модернизировать. Системы, которые не учитывают необходимость включения этих критически важных для бизнеса требований, в конечном итоге добавляют больше сложности, чем устраняют.
Платформы — это единственное место в вашей организации, где вы должны полностью осознавать, что значит поддержка бизнес-решений.
Отдельная доставка, оптимизированная для каждой среды
Выбор архитектуры программного обеспечения переключается между центральной оркестровкой и распределенной хореографией. Платформы выигрывают от обоих, поскольку им необходим контроль над тем, когда и как предоставляются возможности, но также необходимо масштабировать множество кластеров и мест, не относящихся к Kubernetes.
Централизованное планирование дает контроль. Децентрализованная доставка обеспечивает масштабирование. Платформа должна позволять определять правила и обеспечивать их соблюдение в центральном оркестраторе, а затем полагаться на механизмы распределенного развертывания для предоставления возможностей в нужных местах и форме. Это позволяет избежать ограничений тесно связанной оркестрации и снижает операционную нагрузку, связанную с масштабированием.
Применение принципов на практике
Хотя этим принципам можно соответствовать во многих архитектурах, Kubernetes стал плоскостью управления по умолчанию для создания платформ. Появился ряд облачных проектов для создания собственной архитектуры Kubernetes, поддерживающей платформы в любом масштабе.
Состав определений пользовательских ресурсов (CRD)
Несколько инструментов помогают управлять инфраструктурой изнутри Kubernetes. Операторы кроссплатформенных и облачных провайдеров показали, как декларативная сверка может решить проблемы дрейфа и масштабирования, с которыми сталкивались более ранние подходы «Инфраструктура как код» (IaC).
По мере появления новых ресурсов Kubernetes потребность в их составлении растет. Инструменты упаковки, такие как Helm и Kustomize, а также решения на базе контроллеров расширяют эту возможность. Композиции Crossplane v2, kro ResourceGroupDefinitions и Kratix Compound Promises собирают наборы ресурсов Kubernetes в одном CRD. Это формирует чистую абстракцию для разработчиков.
Управление критически важными бизнес-требованиями с помощью специализированных контроллеров
Инкапсуляция дает создателям возможностей возможность внести одно изменение в конфигурацию, политику и процесс, которое можно проверить. Декларативные инструменты решают большую часть проблем настройки. Но корпоративные платформы также должны поддерживать императивную логику из-за устаревших систем, этапов обеспечения соответствия и сложных рабочих процессов. Намеренная упаковка может предоставить стабильный API, закодировать логику рабочего процесса и вывести развертываемый модуль, которым смогут управлять последующие системы.
Фреймворки контроллеров, такие как Kubebuilder и Crossplane Providers, основаны на низкоуровневых инструментах выполнения контроллеров, которые позволяют разработчикам встраивать императивную логику внутри операторов. Kratix Promises достигает тех же результатов благодаря часто более простому и доступному интерфейсу контейнеров, совместимых с Open Container Initiative (OCI).
Двухуровневый GitOps как модель несвязанной доставки
Лишь немногие реальные возможности развертываются с использованием только одного кластера. Платформам необходимо координировать развертывание в кластерах, облачных провайдерах и системах SaaS. Такие инструменты, как KCP и Karmada, помогают планировать ресурсы для нескольких плоскостей управления. Kratix использует двухуровневую модель GitOps для маршрутизации декларативных рабочих нагрузок в правильный пункт назначения.
Достижение разблокировано: построение демократизированной платформы
Архитектура, ориентированная на Kubernetes, построенная на этих принципах, может выдержать испытания API-интерфейсов по требованию, контекстно-зависимых решений и ресурсов, управляемых группой. Однако устойчивость платформы требует, чтобы мы также учитывали затраты на поддержание каталога предложений на платформе. Это и есть суть третьего теста платформы: сколько людей и сколько времени требуется, чтобы добавить к платформе новые возможности?
Если все дополнения должны проходить через централизованную команду, либо потому, что они единственные, у кого есть разрешения, либо потому, что они единственные, кто обладает навыками расширения платформы, тогда рост платформы не будет устойчивым. Хотя большинство видит проблему в том, что централизованная команда является единственной, кому разрешено вносить свой вклад, больший риск представляет собой второй блокировщик: люди не осознают, что создают неявных блокировщиков из-за сложности внесения вклада.
Если участникам необходимо понимать слишком много операторских инфраструктур, механизмов рабочих процессов или предметно-ориентированных языков, платформу становится сложнее расширять, и она замедляется — часто требуется, чтобы одна централизованная команда предоставляла все новые возможности платформы и участвовала в обновлении и расширении существующих возможностей, даже если архитектура допускает независимые плагины.
Последовательная модель упаковки, которая придерживается принципов компонуемости, инкапсуляции и несвязанной доставки, позволяет экспертам сосредоточиться на кодификации своего опыта, а не на связях, чтобы заставить его работать с другими частями экосистемы. Например, Kratix Promises инкапсулирует логику в виде OCI-совместимых контейнеров, которые можно написать на любом языке при определении возможности, тем самым снижая барьер для специалистов.
Три простых теста качества платформы могут выявить более глубокую потребность в такой конструкции платформы, которая сделает вклад безопасным и простым, тем самым открывая масштаб и поддерживая долгосрочную устойчивость.
Обеспечение долговременной выгоды за счет краткосрочных исправлений
Когда команды могут получить доступ к тому, что им нужно, по требованию, когда центральные владельцы могут управлять поведением, не возясь с каждой средой вручную, и когда специалисты могут расширять платформу, не изучая множество инструментов, вся система становится проще в эксплуатации и развитии.
Надежные платформы возвращают инженерам время, уменьшают операционные трудности и превращают организационную сложность в то, чем вы можете управлять с уверенностью, а не со страхом. Платформа, построенная на этих принципах, не просто устраняет сегодняшние препятствия. Это создает условия для масштабирования, безопасных изменений и стабильного вклада во всей организации.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Эбби — главный инженер Syntasso, разрабатывающий Kratix — облачную платформу с открытым исходным кодом для создания внутренних платформ на базе Kubernetes. Ее живой интерес к поддержке внутреннего развития обусловлен более чем десятилетним опытом консультирования и доставки продуктов… Подробнее от Эбби Бангсер
