Определение пространства проблем

При создании внутренней платформы разработчика сначала необходимо определить самую тончайшую жизнеспособную платформу (TVP). TVP — это вариант идеи минимально жизнеспособного продукта (MVP) в классическом управлении продуктами.

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

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

Если вы начинаете с нуля, эта последовательность представляет собой общую прогрессию.

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

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

Области проектирования платформы

Учитывая размер этой темы, мы рекомендуем разбить обсуждение проектирования платформ внутри компании на четыре области:

Инженерные системы: курируемый набор инструментов DevOps: таких как GitHub и Azure DevOps, а также другие средства и службы разработчиков. Помимо критически важных инструментов и сервисов DevOps, таких как CI/CD или управление пакетами, эта область также включает возможности, используемые непосредственно в процессе написания кода, такие как облачные среды программирования, сканеры кода и линтеры, а также помощники ИИ, такие как GitHub Copilot.

Платформа приложений: проверенный выбор служб (например, инфраструктуры как службы, платформы как службы и наблюдаемости), предназначенных для каждого стека приложений (класса приложения, модели приложений, языков), которые организация хочет использовать для предоставления бизнес-ценности. Это включает в себя сочетание служб стека приложений, а также общих служб, используемых во всем. Пример платформы приложений может включать приложения контейнеров Azure, Azure Cosmos DB для хранилища, Azure Key Vault для секретов, управление доступом на основе ролей Azure для идентификации и контроля, политику Azure для соответствия требованиям и аудита, наблюдаемость с помощью Grafana и связанную топологию сети.

Шаблоны приложений: набор хорошо определенных шаблонов для быстрого старта, созданных организацией, которые инкапсулируют руководство по правильному началу и устойчивому развитию для указанной платформы приложений, языка и набора инженерных систем. Эти шаблоны могут ссылаться на другие централизованные шаблоны и предоставлять начальный код, ссылки на API и пакет SDK, конвейеры CI/CD, конфигурацию инструментов и многое другое.

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

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

Следующий шаг

Планирование и приоритет