Как Cloud Native меняет практику разработки

Сложность и скорость доставки ПО на базе Kubernetes в облаке делают необходимым сотрудничество между традиционно разделенными ролями — разработчиком, оператором и инженером по надежности системы (SRE), пишет на портале The New Stack Дэниел Брайант, директор по работе с разработчиками Ambassador Labs (ранее Datawire).

Более тесное сотрудничество и пересмотр традиционных ролей способствуют продвижению нативно-облачной разработки ПО, разрушению замкнутых структур, повышению ответственности разработчиков за весь жизненный цикл, а также более быстрой и безопасной доставке ПО.

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

Начнем с разработчиков.

Новая нормальность для разработчиков

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

Эта нативно-облачная «новая нормальность» для разработчиков зависит от поддержки в масштабах организации менталитета «shift-left» (сдвига тестирования безопасности на более ранние фазы цикла) и концепции владения разработчиком всем жизненным циклом. Это также требует совершенно иного подхода к сотрудничеству, то есть изменения того, как разработчики работают с SRE и операционными командами, чтобы больше сосредоточиться на стратегических целях, связанных с доставкой ПО, и меньше на тушении пожаров после инцидентов и внезапных запросов. Чем больше команды работают вместе, тем проще становится работа разработчика, принимающего на себя ответственность за весь жизненный цикл, и тем быстрее и безопаснее ПО доставляется до конечных пользователей.

Покончить со старым

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

Тем организациям и командам, которые хотя бы частично перешли на нативные облачные технологии, совершенно ясно, что экосистема нативной облачной разработки создает такой уровень сложности в создании, доставке и эксплуатации распределенных систем, который разработчикам, в частности, никогда не приходилось контролировать или понимать. Окружающая экосистема отреагировала на это созданием множества вспомогательных инструментов, но это привело к их «разрастанию». При этом разработчиков призывают владеть полным жизненным циклом разработки в условиях распространения этих инструментов и увеличения сложности и несмотря на их незнание важных аспектов формулы «доставил и запустил». Без изменения взаимоотношений между разработчиками, SRE и операционными службами и разрушения существующей изоляции наряду с изменением объема работ, выполняемых этими командами, вполне вероятно, что скорость, которую обещает нативная облачная разработка, не будет достигнута.

И подружиться с новым

Как выглядят эти новые отношения? И как разработчики могут изменить стиль взаимодействия с командами SRE и Ops, которые поддерживают их работу? Как принятие этих новых рабочих отношений может помочь разработчикам, SRE и операционным командам использовать гибкость и преимущества нативной облачной разработки для успешной доставки нативных облачных приложений?

С точки зрения разработчика, «инфраструктура — это очень, очень сложно». В организациях, которым необходимо жестко контролировать ресурсы, расширение возможностей разработчиков благодаря практическому пониманию инфраструктуры и запуску собственных приложений приносит пользу всей организации. Такая стратегия повышает квалификацию разработчиков и делает их более универсальными, освобождая существующие ресурсы SRE и операционных служб и позволяя быстрее разбираться с инцидентами.

Команда SRE, в свою очередь, должна поддерживать обучение разработчиков и помогать развитию культуры, чтобы принять подход «ты это создал, ты этим и управляешь». SRE должны обеспечивать интерактивное самообслуживание и понимание инцидентов, а не «приходить на помощь» по мере необходимости. Если разработчики понимают весь путь «код — доставка — запуск», они не позовут SRE тушить пожары, с которыми могут справиться сами.

И, наконец, функция операций заключается в том, чтобы помочь сбалансировать свободу и ответственность разработчиков. Операционная команда способствует этому, обеспечивая полное внедрение нужных технологий в практику разработки. Определение «мощеной дорожки» для разработчиков упрощает наращивание темпов разработки, помогает бороться с разрастанием инструментов и поддерживает ответственность разработчиков как ключ к быстрому и безопасному выпуску ПО.

Резюме: достижение общего языка

Несмотря на отсутствие универсального опыта разработчиков, большинство организаций, ориентированных на нативные облачные технологии, независимо от уровня их зрелости, имеют общие черты, которые сводятся к двум основным аспектам:

• межфункциональное сотрудничество. Для разработчиков очень важно межфункциональное сотрудничество с SRE и операционными командами. Эти партнерские функции могут снизить сложность работы разработчика и помочь обеспечить бесшовность и скорость безопасной передачи функций ПО в руки пользователей;
• расширение прав и возможностей разработчиков. Централизация CDP и подход самообслуживания являются ключевыми передовыми нативно-облачными практиками. Поддержка владением разработчиками всего жизненного цикла и предложение четких вариантов самообслуживания и интегрированных инструментов способствуют общему успеху и достижению инженерных и организационных целей.

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