Определение пространства проблемы
При определении внутренней платформы разработчика необходимо сначала определить самую тонкую жизнеспособную платформу (TVP). TVP — это вариант идеи минимально жизнеспособного продукта (MVP) в классическом управлении продуктами.
Эта схема поможет вам сориентировать свое мышление о том, как ваша платформа разработчика может развиваться с течением времени. Имейте в виду, что основной проблемой вашей организации может привести к отклонению от того, что описано здесь из-за существующих инвестиций или потребностей организации. Вам не нужно переходить к следующему этапу, если ваша организация не нуждается в ней.
Если вы начинаете с нуля, это представляет собой общую прогрессию. На ранних этапах сосредоточьтесь на обнаружении необходимых возможностей, анализе пробелов в оболочке с сжатием и создании минимальных средств числа или возможностей платформы. Далее, по мере масштабирования, вы, скорее всего, начнете сосредоточиться на повторном использовании и направлять людей вниз предопределенные проложенные пути с повторно используемыми ресурсами. Наконец, вы перейдете к модели" типа "цифрового хранилища", чтобы упростить создание и обслуживание приложений. Вы должны следовать мышлению продукта на протяжении всего, поэтому мы не рекомендуем переходить к концу, и ваш конкретный путь зависит. Эти заключительные этапы больше всего похожи на сжатие "продукт" в традиционном смысле, но это назначение, а не отправная точка.
Области проектирования платформы
Учитывая более простой размер этой статьи, мы рекомендуем разделить, как вы говорите о проектировании платформы внутри четырех разделов:
Инженерные системы: курируемый набор наборов DevOps, таких как GitHub и Azure DevOps, а также другие средства и службы разработчиков. Помимо критически важных средств и служб DevOps, таких как CI/CD или управление пакетами, эта область также включает возможности, используемые непосредственно во время процесса написания кода, таких как облачные среды программирования, сканеры кода и литровые, а также помощники ИИ, такие как GitHub Copilot.
Платформа приложений: проверенный выбор служб (таких как IaaS, PaaS и наблюдаемость), предназначенный для каждого "стека приложений" (класс приложения, модели приложений, языков), которые организация хочет использовать для предоставления бизнес-ценности. Это включает в себя сочетание служб стека приложений, а также общих служб, используемых во всем. Пример платформы приложений может включать Azure Container Apps, Cosmos DB для хранилища, Azure Key Vault для секретов, для управления доступом на основе ролей, Политика Azure для соответствия требованиям и аудита, наблюдаемости с помощью Grafana и связанной топологии сети.
Шаблоны приложений: набор хорошо определенных, созданных организацией, шаблонов быстрого запуска, которые инкапсулируют правильное руководство для конкретной платформы приложений, языка и набора инженерных систем. Они могут ссылаться на другие централизованные шаблоны и предоставлять начальный код, ссылки на API и пакет SDK, конвейеры CI/CD, конфигурацию инструментов и многое другое.
Возможности самообслуживания разработчика: это клей для ваших усилий по проектированию платформы. Это сочетание API, оркестраторов, каталогов, шаблонов и пользовательских интерфейсов, предназначенных для уменьшения нагрузки разработчиков и разрешения команд разработчиков самостоятельно обслуживать и быть более автономными, а также придерживаться выборов и рекомендаций или управления из предыдущих трех областей.
Интеграция инженерных систем, платформ приложений, шаблонов приложений и возможностей самообслуживания разработчиков формирует основу стратегии проектирования платформы. Сочетая средства DevOps, облачные службы и возможности самообслуживания, организации могут значительно сократить нагрузку разработчиков, повысить производительность и обеспечить соответствие стандартам управления.