Краткий рассказ об эволюции DevOps. DevOps означает совместную работу Dev и Ops, но вместо этого они убрали Ops из уравнения.
В наши дни нам так трудно определить DevOps, потому что проблема, которую он изначально решает, давно ушла.
Для некоторых недавних компаний проблема никогда не существовала! Они все делают правильно, но вместо этого ландшафт разработки программного обеспечения развивался так быстро, что пробел был заполнен инструментами и облачной инженерией.
Мы далеки от первоначального дня DevOps и его культурного сдвига, направленного на разрушение разрозненности между Dev и Ops.
Бункеры 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), предложив модель IaaS, уменьшив усилия разработчиков по самостоятельному управлению и развертыванию приложений.
Мы можем перефразировать его, чтобы он звучал лучше! Эксплуатационные службы расширяли возможности разработчиков, предлагая инструменты, упрощающие интеграцию и развертывание программного обеспечения, тем самым сокращая объем тяжелой работы, необходимой операционным группам для обслуживания инфраструктуры. В итоге мы оказались в ситуации, когда системное администрирование (Ops) нам не понадобилось. Однако нам нужен кто-то, кто будет поддерживать эти «инструменты для упрощения интеграции и развертывания программного обеспечения».
У этой новой появляющейся роли еще не было названия, так как она была представлена вам бывшими оперативниками, переименованными в «парней из DevOps». Давайте назовем это DevOps-инженером, возможно, кто-то сказал в какой-то момент, и это прижилось.
DevOps переосмыслил себя
DevOps никогда не касался инструментов; это было о культуре. Идея состоит в том, что разработка программного обеспечения также может стать более бережливой и что поставка программного обеспечения может выполняться точно в срок. Первоначальная проблема DevOps, возможно, давно ушла, но она породила самую важную идею разработки программного обеспечения: непрерывную доставку.
Я давно на стороне тех, кто утверждал, что DevOps — это не роль, не команда, и если вы это так называете, то делаете это неправильно. Позже я понял, что, ну, все было сложнее. Мы неуместно создали роль «парень(и), который поддерживает инструменты для упрощения интеграции и развертывания программного обеспечения», но не придумали для нее названия.
Если подумать, действительно ли вам нужны «парни, которые поддерживают инструменты для упрощения интеграции и развертывания программного обеспечения», если все было облачным предложением? Полностью управляемый? Работает по нажатию кнопки?
Это мечта большинства облачных провайдеров и многих продуктов DevOps SaaS (вспомните, например, GitLab). Правда не так проста. Хотя в теории все могло быть просто, задачи Ops можно было автоматизировать, полностью управлять сервисом и т. д. На деле мы создали монстра.
В результате перед большинством команд эксплуатации/инфраструктуры (также известных как Ops) стоит задача ориентироваться в бесчисленных инструментах и сервисах, понимать, развертывать и объединять эти инструменты в согласованную инфраструктуру и инструменты, которые могут использовать разработчики.
DevOps застрял — это ключевое модное слово, из которого легко вывести: DevSecOps, FinOps, GitOps, MlOps и т. д.
Но если вы заметили, аромат, который остается, всегда Ops. Самое смешное, что каждый подход направлен на удаление операций уравнений. Ops, также известный как «парень (парни), который входит в систему и делает что-то, чтобы она работала».
TL;DR
Первоначальная проблема, которую DevOps намеревался решить, может больше не существовать из-за роста облачной инфраструктуры. Однако DevOps породил важную идею непрерывной доставки и внес изменения в культуру разработки программного обеспечения.
Хотя термин «DevOps», возможно, остался модным словом, он привел к разработке новых подходов, таких как DevSecOps, FinOps и GitOps, каждый из которых направлен на устранение необходимости в традиционных задачах эксплуатации.
В конечном счете, ландшафт DevOps и облачной инфраструктуры постоянно развивается, и сложно оставаться в курсе событий и выбирать правильные инструменты. По иронии судьбы, DevOps изначально означал сотрудничество между Dev и Ops, но теперь он сместился в сторону исключения Ops из уравнения.
