Кратка история за еволюцията на DevOps — DevOps означаваше сътрудничество между Dev и Ops, но вместо това те премахнаха Ops от уравнението

В наши дни ни е толкова трудно да дефинираме 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, към Devs. Облакът намали нуждата от системни администратори (Ops), като предложи модела IaaS, намалявайки усилията за разработчиците да управляват и внедряват приложения сами.

Можем да го перифразираме, за да звучи по-добре! Операциите упълномощаваха разработчиците, като предлагаха инструменти за опростяване на софтуерната интеграция и внедряване, като по този начин намаляваха тежестта, необходима на оперативните екипи за поддържане на инфраструктурата. В резултат на това се озовахме в ситуация, в която не се нуждаехме от системна администрация (Ops). Нуждаем се обаче от някой, който да поддържа тези „инструменти за опростяване на софтуерната интеграция и внедряване“.

Тази нова нововъзникваща роля все още нямаше име, тъй като ви беше предоставена от бившия Ops, преименуван на „DevOps guys“. Нека го наречем DevOps инженер, някой вероятно е казал в някакъв момент и е останало.

DevOps се предефинира

DevOps никога не е бил за инструменти; ставаше въпрос за култура. Идеята е, че софтуерното инженерство също може да стане по-„икономично“ и че доставката на софтуер може да се извърши точно навреме. Първоначалният проблем на DevOps може би отдавна е отминал, но той роди най-важната идея в софтуерното инженерство: „Непрекъсната доставка“.

Отдавна съм на страната на тези, които твърдят, че DevOps не е роля, не е екип и ако го наричате по този начин, го правите погрешно. По-късно разбрах, че нещата са по-сложни. Неуместно създадохме роля, „човек(а), който поддържа инструменти за опростяване на софтуерната интеграция и внедряване“, но нямахме име за това.

Като се замислите, наистина ли имате нужда от „момчето(ите), което поддържа инструменти за опростяване на софтуерната интеграция и внедряване“, ако всичко беше облачно предложение? Напълно управляван? Работи с едно натискане на бутон?

Това е мечтата на повечето облачни доставчици и на многото DevOps SaaS продукти (помислете за GitLab, например). Истината не е толкова проста. Въпреки че на теория нещата можеха да бъдат прости и задачите на Ops можеха да бъдат автоматизирани, услугата да се управлява напълно и т.н. В действителност създадохме чудовище.

В резултат на това предизвикателството за повечето оперативни/инфраструктурни екипи (известни още като Ops) е навигирането в картата на безброй инструменти и услуги, разбирането, внедряването и свързването на тези инструменти в съгласувана инфраструктура и инструменти, които разработчиците могат да използват.

DevOps stuck е тази ключова модна дума, лесна за извеждане: DevSecOps, FinOps, GitOps, MlOps и т.н.

Но ако забележите, ароматът, който остава, винаги е Ops. Смешната част е, че всеки подход има за цел да премахне Ops от уравненията. The Ops, известен още като „човекът(ите), който влиза в системата и прави неща, за да работи тя“.

TL;DR

Първоначалният проблем, който DevOps реши да реши, може вече да не съществува поради възхода на облачната инфраструктура. Въпреки това DevOps роди важната идея за непрекъсната доставка и доведе до културна промяна в софтуерното инженерство.

Въпреки че терминът „DevOps“ може да се е наложил като модна дума, той е довел до разработването на нови подходи като DevSecOps, FinOps и GitOps, всички от които имат за цел да премахнат необходимостта от традиционни Ops задачи.

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