Облак или хибридна инфраструктура за компаније

Zastoj u proizvodnom sistemu, platformi za upravljanje skladištem ili online prodajnom okruženju nije infrastrukturni spor, već direktan poslovni rizik. Pitanje oblaka ili hibridne infrastrukture treba odlučiti na osnovu kritičnosti poslovnih procesa, protoka podataka, regulatornih obaveza i očekivanja oporavka, a ne prema preferencijama provajdera. Loša odluka može rezultirati ne samo višim IT troškovima, već i gubitkom proizvodnje, netačnim podacima o zalihama, kašnjenjem u isporuci ili neauditabilnim operacijama.

Odluka retko kada je binarna. Čisto javni oblak, privatni data centar i hibridni modeli pokazuju različite profile rizika, operativne odgovornosti i discipline u planiranju. U korporativnom okruženju može se stvoriti odbranjiva arhitektura ako se obrasci opterećenja, zavisnosti, ciklusi podataka i ciljevi oporavka uzimaju u obzir u istom okviru odlučivanja.

Polazna tačka odluke: kontinuitet poslovanja

Većina infrastrukturnih programa prerano počinje sa tehnologijom. Postavljaju se pitanja o tome koja platforma oblaka, region ili rešenje za kontejnere treba da bude standard, dok osnovna pitanja ostaju neodgovorena: koji procesi ne smeju stati, koliko je gubitak podataka prihvatljiv i koliko brzo treba obnoviti uslugu.

Ova dva pokazatelja jasno definišu. RTO, odnosno cilj vremena oporavka, određuje koliko dugo sistem može biti van funkcije. RPO, odnosno cilj tačke oporavka, pokazuje koliko je gubitak podataka tolerantan. U slučaju dnevnog izveštajnog sistema, može biti prihvatljivo nekoliko sati RTO, ali u okruženju za kontrolu proizvodnje, obradu narudžbina ili transakcije skladišta, to može biti komercijalno neprihvatljivo.

Štaviše, kritične usluge retko kada funkcionišu samostalno. Real-time ili gotovo real-time integracije funkcionišu između ERP-a, WMS-a, e-commerce platformi, veza sa prevoznicima, baza podataka kupaca, sistema za kontrolu proizvodnje i upravljanja identitetima. Postavljanje jedne komponente u oblak ne znači automatski modernije funkcionisanje ako kašnjenje povezanih sistema, mrežne zavisnosti ili tolerancija grešaka nisu redizajnirani.

Kada je opravdano koristiti javni oblak?

Javni oblak nudi prave prednosti kada organizacija koristi fleksibilni kapacitet, geografski raspored, standardizovane upravljane usluge i automatizovano funkcionisanje. U periodima vršnog opterećenja e-commerce-a, promenljivim analitičkim opterećenjima, digitalnim kanalima za klijente ili brzo rastućim portfolijima aplikacija, fleksibilno skaliranje kapaciteta je poslovno opravdano.

Međutim, oblak ne oslobađa kompaniju od arhitektonske odgovornosti. Provajder je odgovoran za deo fizičke infrastrukture, ali identiteti, dozvole, mrežna segmentacija, konfiguracije aplikacija, sigurnosne kopije i pravila zaštite podataka ostaju pod kontrolom kompanije. Nesporazum u vezi sa modelom deljene odgovornosti jedan je od najčešćih razloga zbog kojih brzo pokrenut oblak projekat kasnije postaje problem bezbednosti, troškova ili usklađenosti.

Javni oblak može biti posebno dobar izbor ako se aplikacija može dizajnirati bez stanja, usluge su dobro automatizovane, a postavljanje podataka ne krši stroge pravne ili ugovorne ograničenja. U takvim slučajevima, oblak nije samo nova lokacija za hosting, već transformacija operativnih modela.

Troškovi oblaka nisu samo troškovi potrošnje

Model troškova oblaka može učiniti početne investicije predvidljivijim, ali ne garantuje niže ukupne troškove životnog ciklusa. Trajno visoka opterećenja, troškovi izlaska podataka, preveliki resursi, nekontrolisana razvojna okruženja i paralelno pokrenute, zaboravljene usluge brzo mogu akumulirati operativne račune.

Zato finansijska kontrola mora biti deo arhitekture. Bez standarda označavanja, odgovornosti vlasnika, budžetskih ograničenja, planiranja kapaciteta i redovne optimizacije, oblak lako može postati decentralizovani kanal nabavke. To nije tehnološki propust, već nedostatak upravljanja.

Hibridna infrastruktura: kontrola na kritičnim granicama

Hibridna infrastruktura nije prelazno stanje i nije dokaz neuspeha prelaska na oblak. Ako je dobro dizajnirana, ciljna arhitektura koja postavlja radna opterećenja u okruženja izvršenja koja odgovaraju njihovim tehničkim i poslovnim zahtevima.

Na primer, u proizvodnom pogonu sistemi povezani sa industrijskim kontrolama, lokalnim podacima o mašinama ili procesima sa niskim kašnjenjem mogu opravdano ostati lokalni. U međuvremenu, centralna analiza, izveštavanje, predviđanje potražnje, portali za partnere ili upravljanje dokumentima mogu se pokretati u oblaku. Granicu ne određuje da li je aplikacija stara ili nova, već zahtevi za kašnjenje, dostupnost, suverenitet podataka i integraciju koje nosi.

Vrednost hibridnog modela posebno je značajna kada kompanija mora povezati svoje postojeće, stabilne nasleđene sisteme sa novim digitalnim sposobnostima. Nije potrebno zameniti sve sisteme odjednom kako bi se poboljšao protok podataka, posmatranje ili oporavak nakon katastrofe. Postepena modernizacija može smanjiti operativni rizik, pod uslovom da prelazna arhitektura ne postane stalna kolekcija nedokumentovanih izuzetaka.

Cena hibridnog okruženja je složenost

Hibridna infrastruktura funkcioniše pouzdano samo ako su osnovne kontrole jedinstvene između dva ili više okruženja. To uključuje upravljanje identitetima, modele dozvola, logovanje, enkripciju, mrežnu regulaciju, upravljanje konfiguracijom i nadzor. Ako se razlikuju po okruženju, hibridni model rezultira nevidljivim operativnim rizicima umesto fleksibilnosti.

Prenos podataka zahteva posebnu pažnju. Nije dovoljno odrediti da li se podaci tehnički mogu preneti. Takođe je potrebno znati vlasnika podataka, klasifikaciju, period zadržavanja, svrhu obrade i lokaciju kopija. Integracija je kontrolisana ako je moguće pratiti, ponovo pokrenuti u slučaju greške i ne izaziva nedoslednosti u poslovnim sistemima.

Oblak ili hibridna infrastruktura je pitanje upravljanja

Kvalitet odluke u konačnici zavisi od toga ko ima kontrolu nad arhitekturom.U prisustvu više poslovnih jedinica, eksternih programera, SaaS provajdera i infrastrukturnih partnera, lako se može stvoriti okruženje u kojem niko ne vidi sve zavisnosti i rizike.

Upravljanje ne usporava administraciju. To je sistem odlučivanja i kontrole koji određuje ko odobrava novu vezu, koji sigurnosni minimumi važe, kako se upravlja promenama, ko testira oporavak i ko preuzima odgovornost u slučaju incidenta. U kritičnim okruženjima odgovori na ova pitanja ne smeju ostati kao projektno znanje ili u glavi jednog ključnog čoveka.

U odgovarajućem operativnom modelu, infrastruktura se može tretirati kao kod, verzionisati i auditovati. Implementacije su ponovljive, odstupanja u konfiguraciji mogu se identifikovati, pristup može biti vremenski ograničen, a promene se prenose u živo okruženje kroz lanac odobravanja. Ovo stvara ravnotežu između brže isporuke i disciplinovanog rada.

Arhitektonska validacija je potrebna pre donošenja odluke

Strategija oblaka ne počinje prezentacijom, već istraživanjem. Kompanija prvo treba da napravi mapu usluga: koje aplikacije podržavaju kritične poslovne procese, preko kojih interfejsa komuniciraju, koje podatke obrađuju i koje infrastrukturne zavisnosti imaju. Nakon toga sledi klasifikacija rizika i planiranje ciljnog stanja.

Tokom validacije, tehnička izvodljivost i operativna podobnost treba da se tretiraju odvojeno. Sistem može biti tehnički migrabilan, ali zbog uslova podrške proizvođača, licenciranja, mrežnog kašnjenja ili očekivanja oporavka, migracija možda nije poslovno opravdana. Slično tome, sistem koji se drži lokalno može biti prihvatljiv ako su sigurnosne kopije, redundancija i upravljanje životnim ciklusom dokazano na potrebnom nivou.

U CGAT pristupu, smer infrastrukture nije izolovana odluka o platformi, već deo integriteta celokupnog operativnog sistema. Cilj nije maksimizacija upotrebe oblaka, već osiguranje da svi kritični komponenti funkcionišu u kontrolisanom, dokumentovanom i obnovljivom okruženju.

Pravilnu odluku ne određuje to da li oblak ili hibridni model izgleda modernije. Odbranjiva infrastruktura je ona koja održava kontrolu poslovanja čak i u slučaju greške, promene ili neočekivanog vršnog opterećenja.