Kdaj podjetje potrebuje lastno cloud infrastrukturo

Kdaj podjetje potrebuje lastno cloud infrastrukturo?#

Podjetje potrebuje lastno cloud infrastrukturo takrat, kadar standardne javne storitve ne zmorejo več podpreti obsega podatkov, števila uporabnikov ali zahtevane ravni nadzora nad delovanjem ključnih sistemov. Gre za trenutek, ko IT oddelek ne more zagotoviti dovolj zmogljivosti, varnosti ali razpoložljivosti znotraj obstoječe postavitve. Potreba se najpogosteje pokaže ob rasti poslovanja, uvedbi novega informacijskega sistema, povezovanju več oddelkov v skupen sistem ali ob zahtevah strank in regulatorjev po višji ravni nadzora nad podatki in sledljivosti dostopov.

Odločitev o lastni infrastrukturi redko sproži en sam dogodek. Pogosteje gre za vrsto manjših opozoril: počasnejše delovanje sistemov ob konicah, težave pri povezovanju ERP, CRM in proizvodnih sistemov, ali negotovost, kje se podatki dejansko hranijo in kdo do njih dostopa. Ko se ta vprašanja ponavljajo v več oddelkih hkrati, postane jasno, da gre za sistemsko vprašanje in ne za posamezno tehnično težavo, ki jo lahko reši en zaposleni ali ena popravljena nastavitev.

Pomembno je razumeti, da lastna cloud infrastruktura ne pomeni avtomatično gradnje lastnega podatkovnega centra. Lahko gre za zasebni oblak, namensko okolje pri ponudniku, hibridno postavitev ali kombinacijo obstoječih in novih virov. Odločitev, kateri model je primeren, je odvisna od tega, kaj podjetje dejansko potrebuje: nadzor, zmogljivost, varnost, skladnost s predpisi ali kombinacijo vsega naštetega. Zato je prvi korak vedno analiza obstoječega stanja, ne izbira tehnologije.

Kaj sploh pomeni lastna cloud infrastruktura#

Lastna cloud infrastruktura pomeni okolje, v katerem ima podjetje jasen nadzor nad tem, kje tečejo njegovi sistemi, kdo do njih dostopa in kako se podatki varujejo, ne glede na to, ali gre za zasebni oblak, namensko najeto okolje ali kombinacijo z javnimi storitvami. Razlika od standardne javne storitve ni v tem, da je dražja ali zapletenejša, temveč v tem, da je prilagojena konkretnim zahtevam enega podjetja in ne splošni množici uporabnikov.

V praksi to pomeni, da se arhitektura, varnostne nastavitve, dostopi in postopki za okrevanje po izpadu določijo glede na dejanske procese podjetja, ne glede na privzete nastavitve ponudnika. Podjetje s tem pridobi možnost, da infrastrukturo prilagodi svojim sistemom - ERP, CRM, dokumentnim sistemom, proizvodnim podatkom - namesto da prilagaja svoje procese omejitvam standardne storitve.

Lastna infrastruktura tudi pomeni večjo odgovornost. Podjetje mora opredeliti, kdo znotraj organizacije odloča o dostopih, kako se spremljajo varnostne posodobitve in kdo je odgovoren, če sistem odpove. Zato se vzpostavitev lastne cloud infrastrukture skoraj vedno povezuje z vprašanjem vzdrževanja in podpore po uvedbi, ne le z enkratno postavitvijo okolja.

Znaki, da obstoječa infrastruktura ne sledi več poslovanju#

Nekaj znakov se v praksi ponavlja pri podjetjih, ki razmišljajo o lastni cloud infrastrukturi. Največkrat gre za kombinacijo tehničnih omejitev in organizacijskih vprašanj, ki se pojavijo hkrati v več oddelkih - od IT prek financ do proizvodnje. Ko se ti znaki začnejo kopičiti, postane smiselno infrastrukturo pregledati sistematično, namesto da se posamezne težave rešujejo ločeno.

Ko se našteti znaki pojavijo posamično, jih je mogoče obravnavati kot manjše tehnične popravke. Ko pa se pojavijo skupaj in vplivajo na več oddelkov hkrati, gre za signal, da obstoječa infrastruktura ne sledi več dejanskim potrebam poslovanja. V tej fazi je smiselno vprašanje preusmeriti iz tega, kako popraviti trenutno težavo, v to, kakšna infrastruktura podpira naslednjih nekaj let rasti.

Pri tem je pomembno razlikovati med težavo posamezne aplikacije in težavo celotne infrastrukture. Počasna spletna stran je lahko posledica ene napačne nastavitve, medtem ko ponavljajoče se zastoje pri več sistemih hkrati pogosteje povzroča osnovna arhitektura, ki ni bila zasnovana za trenuten obseg podatkov in uporabnikov.

• Sistemi se ob konicah obremenitve upočasnijo ali postanejo nedosegljivi.
• Povezovanje ERP, CRM in drugih sistemov prek API-jev postane vse bolj zapleteno ali nezanesljivo.
• Ni jasno, kje se določeni podatki hranijo in kdo ima do njih dostop.
• Revizije ali zahteve strank po dokazilih o varnosti podatkov so vse pogostejše.
• Vsaka nova funkcionalnost zahteva izjeme ali obvode v obstoječi postavitvi.
• Odzivni časi ob izpadu niso dogovorjeni ali niso jasni.

Oblak, lastni podatkovni center ali hibridni model#

Izbira med javnim oblakom, zasebno infrastrukturo in hibridnim modelom je odvisna od tega, kaj je za podjetje pomembnejše: hitrost postavitve, nadzor nad podatki ali prilagodljivost pri rasti. Nobena od treh možnosti ni univerzalno boljša; vsaka ustreza drugačni kombinaciji zahtev glede varnosti, skladnosti s predpisi, obstoječih sistemov in načina dela zaposlenih.

Hibridni model se v praksi pogosto izkaže kot vmesna rešitev za podjetja, ki del sistemov že imajo urejen, a potrebujejo dodatno zmogljivost ali ločeno okolje za občutljive podatke. Omogoča, da se del infrastrukture ohrani na obstoječi lokaciji, del pa se prenese v okolje, ki ga je lažje širiti ali nadzorovati, brez enkratne selitve vseh sistemov hkrati.

Odločitev med modeli ni dokončna. Infrastruktura, zgrajena za trenutne potrebe, se lahko kasneje širi ali preoblikuje, če je bila zasnovana z mislijo na rast. Zato je pri načrtovanju pomembno vprašanje ne le, kaj podjetje potrebuje danes, temveč tudi, kako se bodo zahteve spremenile v naslednjih letih in ali bo izbrana postavitev to omogočala brez ponovne selitve.

• Obseg in občutljivost podatkov, ki jih je treba obdelovati in hraniti.
• Zahteve regulatorjev ali strank glede nadzora nad lokacijo in dostopom do podatkov.
• Število in zahtevnost obstoječih sistemov, ki jih je treba povezati prek API-jev.
• Pričakovana rast obremenitve in potreba po hitrem dodajanju zmogljivosti.
• Razpoložljivost notranjega znanja za upravljanje infrastrukture po uvedbi.
• Zahtevana raven razpoložljivosti in načrt za okrevanje po izpadu.

Varnost, skladnost in odgovornost za podatke#

Lastna cloud infrastruktura pogosto postane nujna takrat, ko podjetje ne more več dokazati, kje se podatki hranijo, kdo do njih dostopa in kako so zavarovani. To vprašanje je posebej izrazito v reguliranih panogah in v javnem sektorju, kjer predpisi, kot je GDPR, zahtevajo jasno sledljivost obdelave osebnih podatkov, ne glede na to, kateri sistem jih hrani.

Varnost v lastni infrastrukturi ni enkratna nastavitev, temveč stalen proces: upravljanje dostopov, spremljanje ranljivosti, utrjevanje sistemov in odziv na morebitne incidente. Pri tem je pomembno ločiti razvojno, testno in produkcijsko okolje, saj se napake najpogosteje pojavijo takrat, ko se testne spremembe nenadzorovano prenesejo v okolje, kjer tečejo resnični podatki strank ali zaposlenih.

Odgovornost za podatke ostaja pri naročniku, tudi kadar infrastrukturo upravlja zunanji izvajalec. Zato je del vsake vzpostavitve lastne cloud infrastrukture tudi vprašanje, kdo ima dostop do gesel in konfiguracij, kako se dokumentira dostop do produkcijskega okolja in kaj se zgodi z dokumentacijo in dostopi ob zamenjavi izvajalca ali ob koncu sodelovanja.

Visoka razpoložljivost in odzivnost na obremenitve#

Visoka razpoložljivost postane pomembna takrat, ko izpad enega sistema ne prizadene več le enega oddelka, temveč zaustavi več povezanih procesov hkrati - na primer naročanje, proizvodnjo in poročanje. V takih primerih standardna javna storitev brez dodatnih nastavitev za odpornost na izpade ne zadostuje več, saj ne ponuja dovolj nadzora nad tem, kako se sistem obnaša ob okvari posamezne komponente.

Lastna infrastruktura omogoča, da se zmogljivost sistemov prilagaja dejanski obremenitvi, namesto da je fiksno določena vnaprej. To je pomembno za podjetja, pri katerih se obremenitev spreminja glede na sezono, proizvodni cikel ali dogodke, kot so konec meseca v financah ali konice naročil v prodaji. Infrastruktura, ki se ne zna prilagajati, pogosto postane ozko grlo prav v trenutkih, ko je zanesljivost najbolj pomembna.

Pri načrtovanju razpoložljivosti je treba vnaprej določiti, kateri sistemi so kritični in kateri ne. Ne vsak del infrastrukture potrebuje enako raven zaščite pred izpadom; za to so namenjeni razredi obravnave, od kritičnega izpada do manjših napak, ki se lahko počakajo na naslednjo redno objavo sprememb.

Kako poteka prehod na lastno cloud infrastrukturo?#

Prehod na lastno cloud infrastrukturo se začne s pregledom obstoječih sistemov, podatkov in povezav, ne z izbiro tehnologije. Pred vsako selitvijo je treba razumeti, kateri sistemi so med seboj povezani, kje se podatki podvajajo in kateri procesi se bodo med prehodom morali začasno izvajati vzporedno v starem in novem okolju.

Med prehodom je ključno, da se spremembe testirajo pred objavo v produkcijsko okolje, saj selitev infrastrukture pogosto razkrije povezave med sistemi, ki prej niso bile dokumentirane. Zato je smiselno prehod razdeliti na sklope, ki jih je mogoče testirati in uvajati ločeno, namesto da se vsi sistemi selijo hkrati v enem samem koraku.

Projekt te velikosti praviloma zahteva določenega projektnega vodjo, jasno razdelitev odgovornosti med ekipami in dogovorjen način poročanja o napredku. Pri podjetjih, ki že imajo delno zgrajen ali nedokončan sistem, je prehod mogoče začeti tudi s prevzemom obstoječe kode, arhitekture in infrastrukture po predhodnem pregledu, brez nujnega začetka od začetka.

• Pregled obstoječe arhitekture, sistemov in podatkov, ki jih je treba preseliti.
• Opredelitev kritičnih sistemov in zahtevane ravni razpoložljivosti za vsakega od njih.
• Načrt migracije podatkov, vključno s preverjanjem njihove celovitosti po prenosu.
• Ločitev razvojnega, testnega in produkcijskega okolja pred začetkom dela.
• Testiranje povezav z obstoječimi sistemi, kot so ERP, CRM ali dokumentni sistemi.
• Primopredaja dokumentacije, dostopov in gesel ob zaključku vzpostavitve.

Vloga nadzora, DevOps in vzdrževanja po uvedbi#

Vzpostavitev lastne cloud infrastrukture ni enkraten projekt, ki se zaključi z zagonom. Po uvedbi je treba sisteme spremljati, posodabljati in prilagajati, saj se obremenitve, varnostne grožnje in zahteve podjetja spreminjajo. Brez dogovorjenega nadzora po uvedbi se tveganja, ki jih je prehod na lastno infrastrukturo moral odpraviti, čez čas lahko ponovno pojavijo.

DevOps pristop pri tem pomeni, da se spremembe v infrastrukturi obravnavajo enako strukturirano kot spremembe v programski opremi: skozi testiranje, nadzorovano objavo in sledljivost, kdo je kaj spremenil in kdaj. To je še posebej pomembno pri sistemih, ki so povezani z več oddelki, saj lahko nenadzorovana sprememba na enem mestu povzroči izpad na drugem.

Podjetje se mora vnaprej odločiti, kdo po uvedbi skrbi za delovanje infrastrukture: notranja ekipa, zunanji izvajalec ali kombinacija obeh. Pri tem je koristno vnaprej razdeliti obravnavo napak po prednosti - od izpada, ki zahteva takojšnjo obravnavo, do manjših napak, ki se lahko uvrstijo v naslednjo redno objavo sprememb - da je jasno, kaj se zgodi v posameznem primeru.

Kako izbrati izvajalca za vzpostavitev cloud infrastrukture#

Pri izbiri izvajalca za vzpostavitev lastne cloud infrastrukture je smiselno preveriti, ali ekipa obvlada celoten obseg dela - od arhitekture in varnosti do DevOps podpore in testiranja - ali pokriva le del, denimo samo postavitev strežnikov brez nadaljnje podpore. Projekti te vrste redko ostanejo omejeni na enkratno nalogo, saj se potrebe po nadgradnjah in podpori pojavijo kmalu po zagonu.

Pomembno je tudi, kako izvajalec obravnava podatke in dostope med projektom. Izvorna koda, konfiguracije in podatki morajo ostati last naročnika, dokumentacija in gesla pa del primopredaje ob zaključku ali ob morebitni zamenjavi izvajalca. Resen izvajalec to vprašanje odpre sam, še preden ga naročnik postavi.

Pri Epixu in njegovi specialistični partnerski mreži lahko projekt vzpostavitve cloud infrastrukture prevzamemo v celoti - od analize obstoječega stanja prek arhitekture, varnosti in migracije podatkov do nadzora delovanja po uvedbi - ali le kot posamezen sklop, na primer samo migracijo ali samo vzpostavitev varnostnega nadzora, odvisno od tega, kje je podpora dejansko potrebna.

Ker je obseg vsakega projekta drugačen, cene vzpostavitve cloud infrastrukture ne navajamo vnaprej. Odvisna je od količine podatkov, števila sistemov, ki jih je treba povezati, zahtevane ravni varnosti in razpoložljivosti ter obsega podpore po uvedbi. Zato pred vsako ponudbo predlagamo krajšo analizo, ki obseg razdeli na sklope, tako da je vsak del ocenljiv in izvedljiv ločeno.