Платформы для разработчиков не отменят DevOps, но сделают приоритетным опыт разработчиков, пишет на портале The New Stack Дэниел Брайант, руководитель отдела по работе с разработчиками Ambassador Labs.
На протяжении 2022 г. неоднократно звучал рефрен о важности опыта разработчиков, который, скорее всего, станет еще громче в
Для многих организаций появление платформенного инжиниринга уже изменило повседневную работу команд DevOps, операционных специалистов и инженеров по надежности систем (SRE). По мере внедрения платформенного подхода для облегчения труда разработчиков, создание чего-то похожего на «инфраструктуру из коробки» в виде платформы для разработчиков будет активно формировать опыт разработчиков и обеспечивать операционную поддержку через «платформенные операции» («Platform Ops»).
Платформы влияют на опыт разработчиков, позволяя им на 99% сосредоточиться на кодировании, не заботясь об инфраструктуре или о том, как запустить свое ПО. Но многие платформы также обладают достаточной гибкостью, чтобы позволить 1% разработчиков исследовать и экспериментировать. Платформа для разработчиков, поддерживаемая командами архитекторов, DevOps и SRE, содержит ингредиенты трансформации для всех этих команд и ролей, способствуя улучшению опыта разработчиков, что ведет к более быстрому и безопасному выпуску ПО.
В настоящее время наблюдается несколько тенденций, которые демонстрируют первостепенную роль опыта разработчиков в ИТ-организациях и более широко в бизнесе, частью которого они являются.
Усиление ориентации Kubernetes на разработчиков
В начале эпохи нативных облачных технологий сложность Kubernetes почти неизбежно требовала, чтобы доставка ПО была ориентирована в первую очередь на операционных специалистов («ops-first»). Отрасль по необходимости создавала для них инструменты, которые помогали демаркировать новые границы, так сказать, при открытии новых территорий. Например, с появлением контейнеров и программно-определяемого всего возникли новые проблемы, которые, по понятным причинам, должны были решать опытные операционные специалисты.
В то же время разработчики столкнулись с необходимостью значительного и быстрого обучения, поскольку их попросили взять на себя необычный объем операционной ответственности. Хотя во многих организациях поощряются менталитет «shift left» (привлечение тестировщиков на ранних стадиях разработки ПО) и подход «сделай сам», большая часть работы, проделанной в последние годы над инструментарием и, в частности, платформами для разработчиков, облегчила этот путь и помогла вписать множество проблем, возникающих в связи с Kubernetes и нативной облачной разработкой, в управляемые рабочие процессы.
Переход Kubernetes от «ops-first» к «developer-first» — это не решающий проблему полностью, но необходимый шаг в правильном направлении, помогающий не только улучшить опыт разработчиков с помощью оптимизированных инструментов и рабочих процессов, но и расширить и повысить уровень внедрения нативной облачной разработки.
Платформы для разработчиков позволят повысить их продуктивность
В основе многих из этих улучшений лежит концепция платформы для разработчиков, которая — при правильном подходе — оптимизирует рабочие процессы и значительно снижает когнитивную нагрузку на разработчиков. В
В 2023 г., когда подход платформенной инженерии достигнет критической массы, мы увидим появление большего количества коммерческих вариантов платформ для разработчиков. Будет ли это действительно способствовать ориентации Kubernetes в первую очередь на разработчиков, или это будет просто попытка создать шумиху вокруг «продуктивизации» того, что расчетливые организации уже создали сами из широкого спектра доступных облачных инструментов? Несомненно, это будет зависеть от платформы.
Сокращение сроков обучения и предоставление путей и инструментов повышения производительности упростит разработку нативных облачных приложений для разработчиков всех типов и обогатит их общий опыт.
DevOps не мертва
В области нативной облачной разработки поощряются разработчики, которые сдвигают тестирование на ранние стадии и берут на себя операционные обязанности, включая доставку и запуск ПО, которое они кодируют. Мы многократно беседовали с разработчиками, владеющими полным жизненным циклом созданного ими ПО. И выяснили, что здесь нет универсального рецепта.
Мы пришли к общему мнению, что разработчики должны знать и понимать операционные проблемы, чтобы, например, быстрее и легче определять, что происходит, когда что-то идет не так, но при этом их основной задачей не является операционная деятельность или создание платформы. Именно потребность в расширении возможностей разработчиков, не перегружая их и не заставляя их погружаться в тонкости запуска программного обеспечения, лежит в основу подхода к созданию плоскостей управления разработчиками (DCP), или платформ для разработчиков.
Разработка такой платформы — это необходимый, но недостаточный шаг. Один из ключевых прогнозов на 2023 г. заключается в том, что развитие стандартов и реализаций, ориентированных на разработчиков, таких как OpenTelemetry для наблюдаемости и SPDX для спецификации ПО, будет расти в своей значимости и освободит разработчиков от части их дополнительных обязанностей.
Перенос тестирования на ранние фазы размыл фокус разработчиков и перегрузил их межфункциональными требованиями, включая наблюдаемость, безопасность и масштабируемость. Это привело к смелым пророчествам о смерти DevOps. В конце концов, если разработчики уйдут в мир, ориентированный на операционную деятельность, или будут создавать для себя платформы, то кому нужна DevOps?
Идея заключается в том, чтобы разработчики могли обеспечивать «shift left» без расфокусировки. Здесь мы возвращаемся не только к производительности и опыту разработчиков, но и к изменению роли команд DevOps, поскольку платформы для разработчиков становятся стандартом, предоставляя им столь необходимые абстракции и инструменты для выполнения их работы.
API наносят ответный удар
Ориентация на API является краеугольным камнем приложений, которые мы используем каждый день, и все более взаимосвязанного опыта, которым мы наслаждаемся как потребители, сотрудники и просто люди. Несмотря на то, что этот подход создает более бесшовный и удобный опыт для конечных пользователей, он остается сложным и запутанным для разработчиков, которые все больше полагаются на подключение к Интернету и множество инструментов для поддержки критически важных функций, обеспечивая при этом высокий уровень безопасности и производительности.
API существуют во многих различных средах, и их изменение может иметь непредвиденные последствия, которые распространяются на все связанные системы, частью которых они являются. Даже просто понимать и иметь хороший обзор этих связанных систем уже очень сложно. Но необходимость следить за развитием и обслуживанием системы делает запутанную паутину еще более беспорядочной и сложной для управления. Разработчики должны постоянно проверять свои предположения (и изменять их), чтобы последовательно создавать надежные и высокопроизводительные приложения на базе API.
