Разработка эффективных интерфейсов в проектировании платформ включает переход от пользовательских, ручных процессов к стандартизованным и согласованным решениям, которые упрощают подготовку и запросы на обслуживание. В этой статье рассматриваются этапы разработки интерфейса, акцент на настройке сред разработки и диагностике поведения приложений.
Пользовательские процессы
Коллекция различных процессов существует для подготовки различных возможностей и служб, но согласованность интерфейса не учитывается. Процессы на заказ решают неотложные потребности отдельных лиц или команд и зависят от ручного вмешательства, даже если провайдер использует некоторые сценарии автоматизированного внедрения.
Знание того, как запрашивать эти решения, передается от человека к человеку. Процесс запроса службы не имеет стандартизации и согласованности. Подготовка и использование службы платформы, скорее всего, требует глубокой поддержки у поставщика возможностей.
Отсутствие центральных требований и стандартов делает этот уровень подходящим, если компания еще не определила и задокументировали ожидания. Это может быть эффективным для команд в компаниях на ранних стадиях или усилий по созданию платформ. В этих средах команды имеют свободу развивать процессы и возможности в соответствии со своими потребностями, что позволяет им быстрее создавать решения и платить за стандартизацию только когда это необходимо позже.
Настройка среды разработки: отдельные инженеры объединяют шаги, необходимые для настройки среды, запрашивая коллег, поиск документации и следуя своим собственным известным методикам.
Диагностика поведения приложения: инженеры выбирают собственные средства и процессы для диагностики поведения. Они отвечают за выполнение действий по доступу к приложениям и журналам.
Локальные стандарты
Инженеры и инженерные команды упреждающе определяют стандарты для различных возможностей и служб, чтобы увеличить объем обмена знаниями, который может происходить в организации. Неофициальные общины поддержки растут вокруг этих стандартов, но это зависит от ресурсов и обязательств от отдельных лиц и отдельных команд.
Настройка среды разработки: отдельные команды определяют собственные инструменты и процессы и пытаются обеспечить, чтобы инженеры в командах придерживались этих процессов. Это может быть с помощью документации или контейнеров, но выбор способа документирования инструментов и процессов управляется командой.
Диагностика поведения приложений: отдельные команды определяют собственные методики и процессы для диагностики поведения. Команды полагаются на DevOps/ИТ-группу для доступа к развернутыми ресурсам.
Согласованные стандартные интерфейсы для развертывания и мониторинга платформ и функций существуют и удовлетворяют широкие потребности. Пользователи могут определять доступные возможности и запрашивать необходимые возможности.
Проложенные дороги или золотые пути, в виде документации и шаблонов, предоставляются. Эти ресурсы определяют, как подготавливать типичные возможности и управлять ими с помощью совместимых и проверенных шаблонов. Хотя некоторые пользователи могут использовать эти решения самостоятельно, решения часто требуют глубокого опыта в области, поэтому поддержка от обслуживающих по-прежнему жизненно важна.
Значительное управление, необходимое от центральной команды для поддержания шаблонов и документации, особенно в ответ на изменение потребностей команд.
Настройка среды разработки: есть некоторые инвестиции в общий путь с документацией или шаблонами, определяющими необходимые инструменты и процессы в организации. Команды могут отступить от стандартов по мере изменения шаблонов, но не объединяются в централизованную команду.
Диагностика поведения приложения: стандартная практика, определенная для доступа и диагностики развернутых ресурсов.
Решения самообслуживания
Решения предлагаются таким образом, чтобы обеспечить автономию для пользователей и требует мало поддержки от обслуживающих. Организация поощряет и позволяет решениям предоставлять согласованные интерфейсы, обеспечивающие возможность обнаружения и переносимости взаимодействия с пользователем из одной возможности в другую. Хотя решения могут быть самообслуживания, они всё же требуют осведомленности и реализации со стороны команды. Для улучшения этого интерфейса может быть управляемый и упрощенный внутренний язык, позволяющий пользователям быстрее внедрять и интегрировать возможности платформы. Это создает ориентированную на пользователя, самообслуживаемую и согласованную коллекцию возможностей.
Настройка среды разработки: команды разработчиков зависят от платформы для настройки сред разработки. Возможности существуют для обнаружения доступных ресурсов. Инженерные команды принимают платформу исключительно для всех взаимодействий. Платформа помогает совместному использованию знаний с помощью обнаружения и изменения новых и существующих шаблонов, постоянно увеличивая ценность, предлагаемую платформой.
Диагностика поведения приложения: средства и службы для наблюдения за ресурсами и возможностями предоставляются через платформу по запросу. Платформа предоставляет возможность диагностики и наблюдения за ресурсами и возможностями.
Интегрированные службы
Возможности платформы прозрачно интегрированы в средства и процессы, которые команды уже используют для выполнения своей работы. Некоторые возможности предоставляются автоматически, такие как наблюдаемость или управление идентификацией для развернутой службы. Когда пользователи достигают пределов предоставляемых услуг, появляется возможность выйти за рамки автоматических решений и адаптировать их под свои нужды, не покидая внутренние предложения, так как возможности платформы считаются строительными блоками. Эти стандартные блоки используются для создания прозрачных и автоматических композиций для удовлетворения вариантов использования более высокого уровня, обеспечивая более глубокую настройку при необходимости.
Внутренние команды платформы могут определить, какие возможности работают хорошо для организации и могут использовать эти знания, чтобы определить, какие области инвестировать в дальнейшее улучшение платформы.
Возможности можно расширить и упаковать несколькими способами, обеспечивая максимальную гибкость для подготовки, управления и наблюдения за ресурсами и возможностями.
Настройка среды разработки: возможности платформы интегрированы в средства и процессы, которые команды уже используют для выполнения своей работы. Можно использовать с помощью интерфейса командной строки, интегрированной среды разработки или других сред.
Диагностика поведения приложения. Платформа автоматически настраивает возможности наблюдения для каждого развернутого приложения. Платформа предоставляет возможность взаимодействия с диагностическими данными и развернутыми приложениями.