Публикувано на: 7 ноември, 2022*Текстът е предоставен от Bosch.IO
Какво е и какво не е DevOps
В последните няколко години в IT средите все повече се говори за нарастващата нужда от DevOps. Името идва от Development (разработване на софтуер) и Operations (IT операции и поддръжка) и вече се налага като водещ принцип при разработка на софтуер. Някои казват, че е задължителна част от всеки нов екип. Други казват, че е бъдещето. А някои го възприемат като магическа формула, която просто прави нещата да работят.
Основната цел на DevOps е да оптимизира времето и процесите по разработка на софтуерни продукти и тяхната поддръжка. Затова и все повече компании залагат много на DevOps като ефикасен метод на работа, създавайки цели DevOps екипи.
Покрай всеки нов тренд обаче има и някои заблуди. Затова решихме да разгледаме по-детайлно темата заедно с един от специалистите в тази област – Петър Кръстанов, който е DevOps Lead в Bosch.IO. Компанията е глобално подразделение на Група Бош за проекти от най-ново поколение в областта на Интернет на нещата (IoT) и изкуствения интелект (AIoT), като в екипа в София вече работят над 220 експерти.
Петър има дългодогишен опит в IT, заемайки различни роли – програмист, системен администратор, дори VoIP инженер и всичко това го ориентира към DevOps. Вече четири години е част от екипа на Bosch.IO, участвайки в множество проекти в областта на IoT, разработвайки и поддържайки разнообразни решения.
A сега да видим какво е и какво не е DevOps.
Какво не е DevOps?
DevOps не е SysAdmin
Може би еднa от най-често срещаните неточни концепции е, че SysAdmin-ът на практика е DevOps. Развитието и поддържането на инфраструктурата е голяма част от ежедневните задачи на DevOps, но това не означава, че миналогодишният ви екип от системни администратори тази година е DevOps.
Много от тясно специализираните задания се припрокриват и от двете страни, но това е поради Ops частта от DevOps.
Все пак DevOps като цикъл (всички сме виждали онази красива картинка, включайки знака за безкрайност) има в себе си и активна част на development.
Дали това ще е някой scripting език за програмиране или пък enterprise ориентиран няма значение. Да, DevOps пишат и код.
DevOps и Cloud инженер не са едно и също
Напоследък забелязваме все повече обяви за работа като „Cloud Engineer“, “Cloud Specialist”, “Could Architect”, но с почти идентично съдържание на тези от типа “DevOps”. Критериите откъм технологии и работен опит са същите, но защо тогава са със различни заглавия? Не бихме ли могли да сложим всичко под “DevOps with Cloud”? Всъщност не.
Като DevOps би трябвало да знаеш основните концепции относно cloud computing и какво стои като функционалност зад различните service-и. Но като Cloud инженер би трябвало да знаеш спецификите на дадената платформа и кое би било най-рентабилно. Тук границата на моменти може да бъде много тънка, но да вземем за пример сертифицирането. Може ли да работиш като DevOps с Azure, GCP или AWS? Да, можеш. Но, за да бъдеш Azure Cloud Engineer ще е нужно доста повече усилие и работа с точно тази платформа за сметка на други технологии. А ако сега погледнем нещата от другата страна: можеш ли като Azure Cloud Engineer да бъдеш DevOps, ако не знаеш поне един декларативен програмен език? Ами не, не би могъл.
DevOps не е просто роля
Loading …
София
HybridЗа мен това е една от най-грешно разбираните концепции за DevOps, а именно, че DevOps е роля заемана от човек в екипа. Всъщност не. Да, може би имате колега на позиция DevOps, но това е само защото той би могъл да реализира по-голямата част от DevOps цикъла на development и operations. Всъщност цикълът на DevOps ни показва, че това не е роля, а метод на работа.
За мен DevOps не е просто цикъл за Development & Operations, а най-вече култура на работа. Някои го наричат идеология, а други философия – намирам всички за прави. DevOps ни помага да изпълним всички 8 стъпки нужни за реализирането и поддръжката на даден продукт или проект. Разглеждайки го малко по-внимателно виждаме, че той включва Plan, Code, Build, Test, Release, Deploy, Operate, Monitor. Сега нека да вземем един често срещан екип от Backend, Frontend, QA, SysAdmin и Project Manager специалисти. Дали този екип не би могъл да попълни всичките 8 стъпки от по-горе? Тогава защо да не разглеждаме този екип като DevOps екип?
A какво е DevOps?
DevOps е ефикасен
Тук трябва да споменем, че не е правилно да сравняваме DevOps с методологии като Waterfall, Scrum, Kanban и други. DevOps е цикъл за разработка и подържане на софтуер.
Но бихме могли да го сравним с добре познатия ни вече 60 години SDLC (Software Development Life Cycle) цикъл. Разглеждайки двата има доста сходни неща, но разликата е в организацията на екипа и какви технологии знае той. Доста позната структура за SDLC e да имаме по един екип за backend, frontend, QA, infrastructure и management. И те някак си трябва да се сработят. От време на време си прехвърлят топката относно някой нов feature. Но като цяло има точно изразени рамки къде започва и свърша работата на всеки един от тях.
За сметка на това един DevOps екип би могъл да се справи изцяло сам. Вече отбелязахме, че в него имаме представител от споменатите по-горе роли и това го прави независим. Затова и самоорганизацията вътре в него е доста по-добра. А и предвид директния контакт рамките започват да падат, различните членове започват да си кооперират все повече, излизайки и разширявайки тяхното поле на знания и компетентност. Мисля, че е много видимо как DevOps подходът е много ефикасен.
DevOps се стреми към последните edge технологии
Последните 5 до 10 години света на IT се разрастна експоненциално. Какво ще рече това: с всеки нов релийз нещата се случват два пъти по-бързо от предходния. Ако преди чакахме по година за нова версия, то вече се случва всеки месец, седмица ако не и ден.
Пример за това е една от най-известните платформи за преотдаване на жилища за престой, която има повече от 125 000 deployments на година посредством multicluster Kubernetes среда. Версия 1.0 на Kubernetes излезе официално през юли 2015. Седем години по-късно предоставя възможността на една компания да извърши повече релийзи за година отколкото на целия софтуерен свят за същото време в началото на 21 век.
Спомням си когато за първи път видяхме Terraform. За първи път имахме решение как да автоматизираме цялата си инфраструктура, включвайки и мрежите. Да може лесно и бързо да имплементираме промени и дори да пазим история за тях ако нещо се случи.
Преди 2-3 години презентирахме новозавършен проект за автоматизация върху целия процес относно CI/CD (Continuous Integration & Continuous Delivery), включвайки и Continuous Deployments посредством Ansible. По средата на демото реших да покажа как автоматизацията елиминира човешката грешка (на всички се случва) и нарочно изтрих половината тест среда, която вече работеше. В същия момент колегата до мен стреснато се опита да ме разубеди с „Не, не, недей, изчакай“, но беше късно. Пет минути по-късно всичко беше възобновено и напълно функционално, а това се случи посредством няколко кликания на мишката.
DevOps винаги ще се стреми да имплементира елегантни решения, използвайки най-новите технологии за постигането на възможно най-добрите резултати.
DevOps е необходимост
DevOps като термин се появява за първи път през 2009 година, когато Патрик Дебоа, един от първите DevOps гурута, решава да направи малка конференция в Гент на теми относно Development & Operations. Оттогава насам виждаме как необходимостта от DevOps нараства все повече и повече. Българският пазар не е изключение – днес DevOps e в топ три на най-търсените длъжности в IT сектора.
В един толкова бързо разрастващ се свят като този на технологиите е нужно да си бърз, ефективен и иновативен, за да може да се конкурираш с другите на пазара. А DevOps е точно това – oптимизира процеса за разработка и поддръжка на софтуер. Независим е от другите екипи и използва последните cutting-edge технологии. Включва в себе си всичко, което е нужно от началото до самия край за разработването на един продукт.
DevOps освен като един от най-модерните подходи на работа ще бъде и един от най-използваните в бъдеще. Затова и вече не е просто допълнение, а чиста необходимост.
