Могут ли облачные сервисы взять на себя роль DevOps?

Всех хороших DevOps’ов уже разобрали. Что с этим делать?

По мере ускорения процессов разработки рынок сталкивается с растущей потребностью в DevOps-специалистах. По данным рекрутинговой компании Hays, даже самые крупные работодатели с сильным HR-брендом ищут DevOps-специалистов не менее двух месяцев, и с повышением грейда растет не только длительность процесса найма, но и требуемый специалистами оклад. Срок закрытия вакансии DevOps-инженера уровня архитектора - около полугода, и стоить такой сильный специалист для компании иногда может более 300 тыс. рублей. В стремлении быстрее взять в штат DevOps-специалиста или удержать его от перехода к конкурентам компании активно практикуют контр-офферы, постоянно подогревая рынок труда, но даже с учетом привлекательных условий спрос на DevOps’ов многократно превышает предложение. Попробуем разобраться, как необходимость в штатном DevOps’е стала бутылочным горлышком в постоянно ускоряющемся мире разработки и как можно решить эту проблему.

Вернемся на 10 лет назад и рассмотрим процесс разработки условного сервиса - например, мобильного приложения для банка. Приложения онлайн-банкинга в 2010 году только входят в каждодневную жизнь пользователя. Единственное требование к банковскому приложению — это, по сути, его наличие и соблюдение базовых требований ИБ. Допустим, команда разработки выкатывает новый функционал или исправляет ошибку в двухфакторной аутентификации, и сервис на существенное время отключается на обслуживание. Клиент банка, до этого привыкший обходиться традиционными оффлайн-опциями, вполне может это стерпеть. Перенесемся обратно в 2020 год. Пользователь имеет совершенно другие требования к доступности сервиса: он готов отказаться от услуг банка, создающего ему неудобства, а не иметь возможности пользоваться мобильным банком несколько часов — это еще и повод поднять волну негатива в соцсетях. Таким образом, скорость развертывания и стабильность работы сервиса или приложения имеет прямое влияние на бизнес-показатели. Частота обновления кода при этом постоянно растет, и чем чаще релизы, тем быстрее, надежнее и “бесшовнее” должна осуществляться их поставка в production.

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

Это обуславливает растущую роль DevOps’а - эти люди работают на стыке разработки и эксплуатации и обладают глубоким пониманием работы компонентов, принципов тестирования и развертывания с учетом особенностей инфраструктуры. Разработчику, перед которым стоит задача поставить код, не интересно копаться в особенностях обеспечивающей его работу инфраструктуры, выясняя, как маршрутизируются пакеты, как обеспечивается безопасность на уровне операционной системы или сколько ядер требуется для обработки ожидаемой нагрузки. DevOps понимает все процессы цикла разработки и архитектуру продукта. Он способен видеть риски безопасности, использовать средства автоматизации, контролировать внесение изменений и последующую поддержку, строить процессы управления качеством и изменениями и соотносить их с ожиданиями клиента, предъявляя правильные требования к разработке.

Если обратиться к отчету DORA “Accelerate State in DevOps” от 2019 года, то картина следующая: компании, выжимающие максимум из современных devops-практик, деплоят в 208 раз быстрее, ускоряют время от коммита до выкатки в продакшн в 106 раз, снижают вероятность сбоя при выкатывании изменений в 7 раз, в тысячи раз сокращают время восстановления после инцидента. DevOps обеспечивают возможность быстрой реализации требований бизнеса, сокращая время поставки кода. Очевидно, что по мере развития микросервисных архитектур и ускорения процесса разработки обойтись без DevOps-инженера проблематично, но при этом эта функция в текущих условиях практически немасштабируема. Что могло пойти не так?

Каждый очередной виток развития привносит в ИТ-системы дополнительные уровни абстракции. Это влечет за собой очередное усложнение инфраструктуры, которое, с одной стороны, безусловно, ускоряет бизнес-процессы и развертывание кода и упрощает жизнь разработчика: оно предоставляет ему возможность сфокусироваться на коде и быстрее работать на выполнение бизнес-результата, эффективно используя свой ресурс. Но с другой стороны, это повышает требования к квалификации DevOps’а, ограничивая возможности при найме в штат.

Новые уровни абстракции делают жизнь разработчика легче и проще и помогают DevOps’у не “утонуть” в растущих объемах механической работы, хотя он берет на себя ответственность за все большее количество уровней инфраструктуры. Как это происходило исторически?

Начнем с Bare-metal. Здесь все традиционно: ты разрабатываешь некий сервис, для развертывания закупаешь железо, ставишь на него операционную систему, разработчики пишут код, который запускают на сервере. Первоочередная задача со стороны системного инженера (прото-DevOps’а) - максимально автоматизировать процесс развертывания оборудования: у тебя есть голое ненастроенное железо, и тебе нужно за часы включить полностью работоспособный сервер в инфраструктуру, обеспечить воспроизводимость. Но при этом сервер еще надо закупить, дождаться его поставки. Эта парадигма не дает достаточной гибкости и не успевает за текущей скоростью разработки.

Следом появляется виртуализация, которая упрощает процесс развертывания, но с появлением виртуализации поддержка on-premise решения влечет дополнительные затраты и поддержку соответствующих квалификаций в команде эксплуатации (сфера ответственности DevOps) либо целой команды, которая предоставляет этот внутренний сервис.

Затем возникают контейнеры как более “легкий” и более автоматизируемый способ виртуализации. Контейнеры более “легкие”, в отдельных контейнерах можно запускать разные процессы и легче строить виртуальную инфраструктуру, которая обеспечивает их взаимодействие, так как при этом будут “скейлиться” только необходимые процессы. Системы контейнеризации и средства оркестрации очень сильно упрощают возможности реализации микросервисов и масштабирования в случае, если код изначально это позволяет - то есть, написан так, чтобы его можно было легко масштабировать в парадигме контейнеров: контейнеризация позволяет еще больше абстрагировать приложения от инфраструктуры.

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

На этом уровне абстракции основная задача DevOps’а — это обеспечение повторяемости, и если разработчики сразу будут писать код, работающий в контейнеризированной среде, проблема повторяемости решена. Например, что может случиться, если обновится репозиторий зависимых пакетов? Вы можете получить нерабочую версию своего ПО или неконтролируемое поведение. Контейнер же запускается с определенного образа и обеспечивает воспроизводимость функционала в любом месте инфраструктуры. Однако, в отличие от виртуальной машины контейнеров можно запустить намного больше, так как они потребляют меньше ресурсов и легче развертываются. То есть, разработчик написал код на рабочей машине, создал образ, включив в него все необходимое ПО, обеспечил воспроизводимость сервиса или поведения, запустил в контейнере - работает. Если этот контейнер перенести в любую точку инфраструктуры, он будет работать точно так же, как и у разработчика на локальной машине.

Итак, сначала был человек, который отвечал за все (и за железо, и за код), затем эксплуатация перешла под ответственность системных администраторов, а потом появилась зона ответственности DevOps’ов, которые должны быть ближе к разработке, чтобы убрать “водораздел” между разработкой и эксплуатацией и исключить ситуацию, когда происходит разрыв зон ответственности (то есть, когда разработчики пишут код, не думая, как все будет эксплуатироваться, а инженеры эксплуатации не понимают, как работает код, который поставили программисты). DevOps начали привносить в процесс поставки кода свои требования.

Облака дают DevOps’у способ получить необходимый ему уровень абстракции как сервис и передать в облако основные компетенции, связанные с эксплуатацией инфраструктуры. DevOps’у больше не нужно думать о том, как реализовать систему виртуализации и оркестрации контейнеров или развернуть новое железо. В облаке DevOps автоматизирует часть процессов в пайплайне поставки кода, а разработчик, который через API получает нужный ему сервис, написав нужную команду, также может воспользоваться преимуществом облачных платформ.

С появлением микросервисных архитектур, контейнеров и сложных продуктов стало понятно, что DevOps’а много не бывает. Если вы разрабатываете небольшое и некритичное для бизнеса веб-приложение, ценность роли DevOps’а не так очевидна: разработчик может сам развернуть свежую версию сервиса вручную и на этом все. Если у вас сложный и постоянно меняющийся продукт, DevOps необходим: сложность архитектуры и взаимосвязей между компонентами инфраструктуры требуют глубокого понимания, и копание в этих деталях снижает продуктивность разработчика и качество: даже дорогой разработчик неспособен делать хорошо все сразу. Вместо того чтобы искать редких и дорогих “звезд” разработки на сложный продукт или сервис, логичней нанять DevOps’а, который возьмет на себя эксплуатацию инфраструктуры.

Будь это bare-metal, VM или контейнеры, при переходе на каждый новый уровень абстракции всегда стоит вопрос: что делать самим, что отдать на аутсорс. Если работа с физическим уровнем инфраструктуры отдается на аутсорс облачному провайдеру, в промежутке между ним и разработкой работает DevOps: он закрывает “гэп” между тем, что можно потребить как сервис, и разработчиком. Если же в качестве сервиса на аутсорсе использовать функцию (Function-as-a-Service), остается только вопрос поддержки кода. И тогда “гэп” между тем, что доступно как сервис, и тем, что нужно разработчикам, схлопывается до нуля, и штатный DevOps для этой задачи более не требуется.

Концепция FaaS (Function-as-a- Service) основана на подходе, при котором исполнение функций в бессерверной среде реализовано в виде сервиса, доступного по подписке. Бессерверные архитектуры и FaaS, по сути, помогают разработчикам сфокусироваться исключительно на разработке и исполнении бизнес-логики приложений. Это новый уровень абстракции от инфраструктуры, при котором все, кроме самого кода, может рассматриваться как часть платформы, и эту функциональность можно потреблять как сервис. Часть функций DevOps’а, связанных с обеспечением масштабируемости под нагрузку, переходит к FaaS-провайдеру.

Так как все нижележащие слои инфраструктуры максимально автоматизированы и стандартизированы, для передачи кода разработчику нужно выполнить простой и стандартный набор операций, и прослойка между ним и сервисом в виде функции DevOps’а становится не нужна. И теперь уже можно говорить не о DevOps, а о NoOps - о подходе, при котором функция поставки кода значительно упрощается и не требует отдельного специалиста, так как платформа дает разработчику простые инструменты для развертывания кода на инфраструктуре. Если разработчик выполняет все требования облачной инфраструктуры и исполняет их на уровне функции, ему остается только знать архитектуру своего приложения и писать код. Ему можно сфокусироваться на коде как на основной бизнес-задаче — это единственная нестандартная задача, требующая высокого уровня компетенций, а все остальное стандартизировано и реализовано на базе облачной платформы.

Это, конечно, влечет за собой изменение структуры стоимости конечного сервиса: из уравнения упраздняется дополнительный ФОТ на DevOps-инженера и прямые затраты на hardware-инфраструктуру, необходимую для масштабирования - биллинг FaaS-оператора в этом случае будет основан на фактическом исполнении специфических функций. То есть, в этом случае не нужно заранее закладывать запас под рост нагрузки, навскидку предугадывая необходимые параметры будущего облачного сервера вроде вычислительной мощности, I/O, размера хранилища и так далее.

Условно, чтобы поднять и далее поддерживать код крупного интернет-магазина на bare-metal’е, потребуется в разы больше DevOps’ов, нежели при использовании контейнеров в облаке. Учитывая дефицит кадров и ускорение цикла разработки, старый добрый аутсорс трансформируется в сервисную модель потребления инфраструктуры и объективно заставляет смотреть в сторону FaaS.

FaaS - новая ступень в парадигме XaaS-сервисов, которые в ближайшем будущем никуда не денутся. Разработчику предоставляется готовая среда, где он оперирует, имея под руками уже готовую инфраструктуру с механизмами балансировкой. Этот сдвиг не упраздняет роль DevOps’а - DevOps становится частью сервиса между разработкой и деплоем. За автоматизированным и стандартизированным сервисом сидят такие же DevOps’ы, как в штате, но теперь на стороне FaaS-провайдера.

Готовы ли к такому сами разработчики? Определенно, многих из них напугает перспектива исполнения их кода в serverless-среде: как узнать, что код работает? Кто отвечает за обновление ПО на сервере? Что ждет саму архитектуру сервисов с развитием FaaS и что изменится? В следующий раз поговорим о плюсах и минусах serverless и кейсах применимости FaaS.