Nevymlouvat se na to, že DevOps není technologie, ale kultura. A není ani pravda, že režim DevOps musí být spojen výlučně s dalšími moderními technologiemi, jako jsou cloud či kontejnery. A co DevOps a personální zemětřesení? Na analýzu C. Harvey navazuje komentář, který pro InformationWeek napsal John Edwards.
Mezi základní chyby považují Edwards a jím dotazovaní analytici alibistický odkaz na kulturu, tedy ono časté tvrzení, že DevOps není záležitost vývoje softwaru, ale celkové firemní kultury nebo dokonce „filozofie“. Ne že by to vůbec nebyla pravda, ale takový pohled pak vede k tomu, že zavedení DevOps bude považováno za příliš náročné. Nebo se proces bude považovat za dlouhodobý a odloží se/protáhne, protože kulturu firmy nelze změnit ze dne na den. Eventuálně se přechod na DevOps sice uskuteční, ale bez toho, že by se na něj od počátku pohlíželo pomocí nějakých použitelných metrik („jak chcete měřit kulturu?“). Na DevOps lze ale přejít rychle, často přitom přitáhnout do firmy nové lidi a zatraktivnit ji (poznámka: ačkoliv to není řečeno přímo, jde tedy nejlépe spojit DevOps i s personální obměnou tam, kde je to možné?).
Další chybou je při přechodu na DevOps příliš spoléhat na automatizaci a nástroje. Základem by měl být návrh procesů; automatizovat současné procesy často znamená pouze zrychlení neefektivity. Bez pořádného návrhu procesů je nasazování nových specializovaných softwarových nástrojů vyhazováním peněz, které často vede pouze k nárůstu chaosu a stresu (což není synonymem pro efektivitu a nemělo by být ani synonymem pro DevOps, i když praxe bývá mnohdy jiná).
Zapomínat nelze ani na zabezpečení. Procesy DevOps bývají dle Edwardse často navrženy bez vazby na tuto problematiku, o nějakém SecDevOps nikdo nic neví. V takovém případě může implementace metodik DevOps vyvolat bezpečnostní problémy nebo alespoň chaos a nutnost dolepovat zabezpečení dodatečně. Často se pak také celý přechod na DevOps kvůli tomu stopne, protože proces je v určitý okamžik vyhodnocen jako problém z hlediska řízení rizik, shody s regulacemi apod. A méně obecná rada pro praxi: hned na počátku vývoje DevOps projektů by vývojáři měli mít pouze minimální potřebná oprávnění (takže se např. jednoduše nedostanou ke skutečným citlivým datům, až budou vložena do systému během spouštění).
Firmy se domnívají, že ve světě s DevOps není místo pro neúspěch. Nakonec ale i zde platí, že kdo neexperimentuje, ničeho nedosáhne. Některé z projektů prostě občas selžou, s tím se nedá nic dělat.
Samozřejmě je třeba zajistit řízení rizik a pružnost/orchestraci architektury jako celku. Selhání jednoho projektu/jedné části infrastruktury by nemělo ohrozit zbytek, pružnost umožní dokázat rychle zajistit náhradní řešení alespoň pro klíčové podnikové procesy a služby zákazníkům. Ani v DevOps ale neplatí „všechno, nebo nic“.
Režim DevOps sice funguje nejčastěji v prostředí kontejnetů, řízení API, cloudu, servereless architektury (funkce jako služba) a jiných hypermoderních technologií,značná část podnikového vývoje i klíčových aplikací běží ale ještě na on-premise systémech a s operačními systémy/aplikacemi na fyzické infrastruktuře (tj. i bez virtualizace). Režim DevOps lze ovšem nasadit i pro vývoj a správu v prostředí klasických databází či ERP systémů. V režimu DevOps je ovšem neustále třeba produkovat i nástroje pro integraci moderních a starších systémů.
A nakonec, i když DevOps umožňuje rychlejší dodávání softwaru/produktů na trh, není to jediný přínos tohoto režimu a úspěšnost by neměla být posuzována pouze touto metrikou. Automatizace by např. měla umožňovat snížení rizik, rychlá metoda vývoje s reakcí i na ad-hod požadavky by měla zvyšovat spokojenost zákazníků atd. I na tyto faktory je třeba mít vhodné metriky.
Více v článku Přijetí modelu DevOps: hlavní problémy
