В наши дни нам очень сложно дать определение DevOps, потому что проблема, которую он первоначально решал, давно исчезла.

Для некоторых недавних компаний эта проблема на самом деле никогда не существовала! Они все делают правильно, но вместо этого среда разработки программного обеспечения развивалась настолько быстро, что пробел был заполнен инструментами и облачной инженерией.

Мы далеки от первых дней DevOps и его культурного изменения, направленного на разрушение барьеров между Dev и Ops.

Разрозненность разработчиков и эксплуатации

Еще в 2008 году, когда Патрик Дюбуа Впервые задумавшись о DevOps, он рассматривал неэффективное сотрудничество между разработкой и эксплуатацией в контексте, когда управление проектами только что перешло от водопада к Agile.

В то время операционные группы управляли всем: от сетей, серверов, виртуальных машин, ОС и обновлений программного обеспечения. Это эффективно скрыло множество ручных операций. Не все было вручную, но это было до появления Puppet, Chef и Ansible — или даже до появления Terraform.

Управление выпусками серверов и программного обеспечения было непростым делом и требовало большого опыта. Что-то, что помешало бы быстрой и надежной доставке новых версий программного обеспечения.

Облако — первый признак исчезновения изолированности

AWS, созданная в 2006 году, была первым крупным поставщиком облачных услуг. DevOps был придуман в 2008 году и предназначался не для решения проблемы управления облаком, а для решения реальных разрозненных задач между работой локальной инфраструктуры. В этом корень путаницы в отношении того, что такое DevOps. Два крупных изменения в сфере разработки программного обеспечения начались примерно в одно и то же время.

Когда дело доходит до облачных вычислений, мы используем три основные модели: программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) и инфраструктура как услуга (IaaS). Поскольку мы использовали эти конструкции высокого уровня, OPS (системное администрирование) практически исчезло. Это как если бы первоначальная культурная проблема, выявленная отцами DevOps, больше не существует.

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

Таким образом, пока движение DevOps пыталось решить «разрозненные» проблемы между Dev и Ops , облачная инфраструктура уже частично угасала, делая Ops устаревшим .

Нет операций, нет бункеров

Ключевыми девизами DevOps являются «сдвиг влево» и «ты создаешь это, ты запускаешь это», что может привести только к передаче того, что было задачей(ами) Ops, разработчикам. Облако сократило потребность в системных администраторах (Ops), предложив модель IaaS, уменьшив усилия разработчиков по управлению и развертыванию приложений самостоятельно.

Мы можем перефразировать его, чтобы оно звучало лучше! Операционные службы расширяли возможности разработчиков, предлагая инструменты для упрощения интеграции и развертывания программного обеспечения, тем самым сокращая тяжелую работу, необходимую операционным группам для обслуживания инфраструктуры. В результате мы оказались в ситуации, когда нам не требовалось системное администрирование (Ops).

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

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

DevOps переопределил себя

DevOps никогда не был связан с инструментами; речь шла о культуре. Идея состоит в том, что разработка программного обеспечения также может стать более «бережливой» и что поставка программного обеспечения может осуществляться точно в срок. Первоначальная проблема DevOps, возможно, уже давно решена, но она породила самую важную идею в разработке программного обеспечения: непрерывную доставку.

Я давно поддерживаю тех, кто утверждает, что DevOps — это не роль и не команда, и если вы это так называете, то вы делаете это неправильно. Позже я понял, что все было сложнее. Мы неуместно создали роль «парня(ов), который поддерживает инструменты для упрощения интеграции и развертывания программного обеспечения», но у нас не было для нее названия.

Если задуматься, действительно ли вам нужны «парни, которые поддерживают инструменты для упрощения интеграции и развертывания программного обеспечения», если все было предложено в облаке? Полностью управляемый? Работает по нажатию кнопки?

Это мечта большинства облачных провайдеров и многих SaaS-продуктов DevOps (например, GitLab). Правда не так проста. Хотя в теории всё могло быть просто, задачи Ops могли быть автоматизированы, сервис полностью управляем и т. д. На самом деле мы создали монстра.

В результате задача большинства операционных/инфраструктурных групп (также известных как Ops) заключается в навигации по карте бесчисленных инструментов и сервисов, понимании, развертывании и объединении этих инструментов в целостную инфраструктуру и инструменты, которые могут использовать разработчики.

DevOps «застрял» — это ключевое модное словечко, из которого легко получить: DevSecOps, FinOps, GitOps, MlOps и т. д.

Но если вы заметили, аромат, который остается, всегда Ops. Самое смешное, что каждый подход направлен на устранение Ops уравнений. Оперативник, он же «парень(и), который входит в систему и делает все, чтобы она работала».

ТЛ;ДР

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

Хотя термин «DevOps», возможно, и остался модным словечком, он привел к разработке новых подходов, таких как DevSecOps, FinOps и GitOps, каждый из которых направлен на устранение необходимости в традиционных задачах Ops.

В конечном счете, ландшафт DevOps и облачной инфраструктуры постоянно развивается, и сложно оставаться в курсе событий и выбирать правильные инструменты. По иронии судьбы, DevOps изначально подразумевал сотрудничество между Dev и Ops, но теперь оно сместилось в сторону исключения Ops из уравнения.