Za co platíte vývojářům a za co provozákům? Těm prvním za vývoj, těm druhým za provoz. Zdá se to samozřejmé…ale je to tak skutečně v praxi?

Pohled vývojáře

Rád bych dělal především to, proč jsem nastoupil – tedy psal kód. Tady je seznam věcí, které bych chtěl v mé firmě změnit:

• Všechno raději dělám na svém notebooku, protože nemusím na nikoho čekat. Jenže pak se často stane, že to, co u mě bez problémů fungovalo, ve firemním prostředí nejede.
• Když potřebuji něco otestovat nebo pracovat na nové funkci, musím žádat provoz o přidělení zdrojů (VM, jejich propojení, prostupy na firewallech, prostor pro data) a čekám minimálně dny, většinou ale týdny.
• Obvykle dostanu jen hrubé zdroje a je na mě, připravit si aplikační prostředí – instaluji si databázi, messaging, Tomcat, Apache. To mě zdržuje.
• Když napíšu novou funkci, trvá to rok, než se dostane do produkce. V ten okamžik už jsem dávno zapomněl, jak jsem to dělal. Rád bych viděl svůj kód ve skutečném provozu daleko dříve, abych mohl získávat cennou a včasnou zpětnou vazbu.
• Lidé z provozu architektuře mé aplikace nerozumí a nedokáží ji tak dobře podporovat v běhu. Musím psát sáhodlouhé release notes, které musí být dostatečně podrobné, aby to vůbec uměli alespoň nainstalovat. Zabere mi to mnoho času a stejně neprobíhá závádění hladce – pak mi neustále volají.

Pohled provozáka

Mojí starostí je provozovat infrastrukturu a aplikace, zajistit hladký průběh zavádění nových verzí a podporovat naše uživatele a zákazníky. Níže uvedené věci se mi vůbec nelíbí:

• Vývojáři nestíhají termíny a tak nám přistane nová verze aplikace jen pár dní před tím, než má být v ostrém provozu. Vzniká stres a chyby.
• Release notes k aplikacím mají nízkou kvalitu a pokaždé si projdeme zkoušením různých verzí návazností, OS, knihoven, aplikačních serverů apod. Vývojář se neobtěžuje vzít v úvahu co aktuálně provozujeme a v jakém stavu to je.
• Často nainstalujeme aplikaci a ona nefunguje. Voláme vývojáři a ten řekne: “divné, ale u mě to chodí”. Nezbývá, než začít ručně ladit aplikační prostředí a hledat stav, ve kterém se aplikace rozběhne (což je psychicky náročné, když jsou po dobu upgrade odstaveny důležité systémy).
• Vývojáři si pracují ve světě, kde je všechno nezabezpečené. Pak se diví, že když se nasadí v prostředí, které je v souladu s bezpečnostní politikou firmy, aplikace nefungují.
• Release každé aplikace je jako stavění skříně na míru. Máme vždy pocit, kolik jsme se toho při tom naučili, ale příště je situace stejně úplně jiná.
• Vývojáři neustále něco chtějí – server, VM, disk, VLANu, IP rozsahy, zónu na firewallu a mají nerealistické požadavky na SLA pro takové interní, tedy nedůležité, operace.
• Někteří vývojáři mají tendenci budovat si svoje stínové IT. To nemůžeme připustit zejména z provozních a bezpečnostních důvodů.

Platform as a Service

IaaS, jako je například OpenStack, situaci rozhodně pomůže tím, že zrychlí některé procesy. Ještě větší dopad má ale změna pravidel hry – nad IaaS nasaďte váš vlastní PaaS, například HP Helion Development Platform postavenou na Cloud Foundry, OpenStack a Docker. Provoz využívá IaaS a stará se o prostředí, ve kterém PaaS běží. Jejich starostí je spravovat fyzické i virtuální zdroje skrze Helion OpenStack, přidělovat je ve formě PaaS VM nodů cloud native aplikacím. Vývoj přistupuje do PaaS a je schopen tak definovat všechny potřebné návaznosti a potřebné služby pro své aplikace v kontejnerech.

Ochutnejte moderní svět PaaS v této české ukázce HP Helion Development Platform:

Jak PaaS funguje? Jak psát cloud native aplikace? Jaký je vztah OpenStack a Cloud Foundry? Co jsou to kontejnery a proč mě mohou zajímat? Jak dosáhnout DevOps, Agile vývoje a CI/CD? Jak řešit vývoj, testování a provoz aplikací bez nutnosti si objednávat pizzu na celou noc a podstupovat odstrašující rizika a nejistoty? Jak zařídit, aby vývojáři a provozáci dělali to, co je jejich práce, místo zdržování se tím ostatním? O tom všem budeme na cloudsvet.cz psát.