Как команды разработчиков программного обеспечения могут быть более продуктивными с помощью Platform Ops

Развертывание, использование и разработка API могут быть сложными. Отчет Postman 2021 State of the API показывает 39% респондентов тратят от 10 до 20 часов в неделю на работу с API. Это число выросло по сравнению с предыдущим отчетом в 2020 году. 🤯

Поскольку API быстро распространяются в организации, команды сталкиваются с новыми проблемами.

• Как создать повторяющиеся процессы сборки и развертывания?

• Есть ли последовательность в наших архитектурных шаблонах?

• Как мы поддерживаем темп доставки, поскольку мы продолжаем масштабироваться?

К счастью, платформенный подход может помочь!

Стремитесь к потоку

С появлением DevOps и автономных межфункциональных команд мы открыли целый мир возможностей для командной автономии. Больше нет одного правильного способа выполнения задач. Части бизнес-возможностей, живущие под теплыми одеялами [ограниченных контекстов] (https://martinfowler.com/bliki/BoundedContext.html), могут быть построены с использованием различных технологических стеков для удовлетворения различных требований и предпочтений.

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

Команды теперь несут ответственность за полный жизненный цикл своих приложений и, в зависимости от архитектурной связи, могут иметь возможность выполнять итерации изолированно. Одним из недостатков этой разработки является то, что д-р Джин Янг называет [проблемой неоднородности программного обеспечения] (https://future.a16z.com/the-case-for-developer-experience/). Когда нет двух одинаковых стеков приложений, как мы можем гарантировать качество и эффективное масштабирование? Как это влияет на опыт разработчиков? Перспектива может показаться довольно мрачной.

Не волнуйтесь. Мы можем это компенсировать!

Распространение API представляет собой путь к масштабируемой архитектуре и также побуждает нас оценить, как мы масштабируем общение между людьми в разных командах. 🤔

Подход, описанный в Team Topologies, учит нас, как моделировать состав команды для оптимизации потока изменений. Когда дело доходит до масштабирования команд API, наиболее значимой топологией команды в этом подходе является команда платформы.

Общий обзор 4 командных топологий

Потоковые команды

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

Включение команд

Может прыгнуть с парашютом, чтобы помочь в повышении уровня.

Команды сложных подсистем

Помогайте создавать и поддерживать программное обеспечение, требующее специальных знаний.

Команды платформы

Помогайте командам, ориентированным на потоки, разгружая обязанности более низкого уровня за проблемы, связанные с несколькими потоками.

Platform Ops для API

Одна или несколько команд платформы часто управляют набором обязанностей. Как инженер платформы или оператор, наши клиенты являются внутренними, и наша миссия состоит в том, чтобы создать отличный опыт для разработчиков и операторов. 🎉

Platform Engineering и Platform Ops тесно связаны, и фактически они могут быть одной и той же командой в некоторых организациях. Команды могут быть составлены в самых разных конфигурациях. Полезно разделить обязанности. В то время как разработка платформы может предоставлять общие услуги и стандартные шаблоны с помощью такого решения, как [Backstage] (https://backstage.io/), команда Platform Ops будет отвечать за:

• Запуск системы оркестрации контейнеров, такой как Kubernetes.

• Создание многоразовых активов конвейера CI/CD

• Применение лучших практик на уровне инфраструктуры

Имея общее представление о том, что может делать команда Platform Ops, давайте посмотрим, как наличие такой команды может помочь масштабировать разработку API.

Безопасность

Общей проблемой платформы является обеспечение безопасности связи. Это может быть в виде:

• Контроль доступа к сети

• [Непрерывное динамическое тестирование безопасности приложений (DAST)] (https://github.com/postman-open-technologies/openapi-security-scanner)

• Служба авторизации или токена безопасности

Управление движением

При работе на общей платформе, такой как Kubernetes, все управление трафиком можно делегировать команде Platform Ops. Примеры:

• Ограничение скорости

• Динамическая целевая маршрутизация

• Управление квотами

Узнайте, как API Gateways могут помочь.

Тестирование

Команда Platform Ops может предложить ряд преимуществ для тестирования:

• Тестирование производительности

• [Непрерывное регрессионное тестирование] (https://www.postman.com/webinars/continuous-testing/)

• Хаос-тестирование

Наблюдаемость

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

• Метрики

• Логирование

• Отслеживание

Они часто включаются в довольно сложные настройки, такие как [Модули мониторинга Prometheus в Kubernetes] (https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config).

Управление

Наконец, мы подошли к управлению. Консолидируя платформенный подход, команда Platform Ops может поддерживать:

• Готовый к аудиту дизайн

• Запуск [Архитектурных фитнес-функций] (https://www.thoughtworks.com/en-us/insights/articles/fitness-function-driven-development)

• Обеспечение [соблюдения рекомендаций по дизайну API] (https://github.com/postman-open-technologies/openapi-linter)

Запустите стратегию Platform Ops

Мы видели некоторые из проблем, которые требуют наличия команды Platform Ops: повторяющиеся процессы, архитектурная согласованность, соблюдение ритма выпуска. И мы рассмотрели лишь некоторые из обязанностей, которыми может управлять команда Platform Ops: безопасность, управление трафиком, управление. При оценке стратегии Platform Ops для масштабирования команд API необходимо задать несколько вопросов:

1. Быстро ли расширяются API по мере нашего роста?

1. У нас уже есть команда, ответственная за платформу? Подсказка: обратите внимание на команды, в названии которых есть слова «ядро» или «услуги».

1. Какие насущные потребности бизнеса лучше всего удовлетворить, предоставив командам, ориентированным на потоки, работу с Platform Ops? Заведите дело.

После того как вы проложили путь к платформе Ops, вот несколько советов для начала:

1. Определите любую потребность в платформе, которая может превратиться в предложение самообслуживания.

1. Оцените эти возможности в анализе затрат и результатов.

1. Выбирайте легко висящие плоды, чтобы договориться о входе с низким уровнем риска.

1. Измерение продуктивности разработчиков.

1. Внедрите минимально жизнеспособную платформу.

Относитесь к Platform Ops как к эксперименту, продолжайте совершенствоваться и обязательно сообщайте о своих выводах остальным сотрудникам организации! 📢

О, и не забудьте поспать. Создание отличного опыта для разработчиков — тяжелая работа. ✨

• Впервые опубликовано [здесь] (https://swiber.dev/scale-api-teams-with-platform-ops)*