Professional Documents
Culture Documents
Upravjanje Migracijom Preduzeća U Cloud
Upravjanje Migracijom Preduzeća U Cloud
Profesor: Dr Dragana Beejski Vujaklija Mentor: Mr Ognjen Pantelid Student: Nevena aptovid 3031/2012
Beograd 2013.
Sadraj:
Uvod .............................................................................................................................................................. 4 1.Cloud kao izazov za kompanije ................................................................................................................... 5 2. Istorija migracionih reenja ....................................................................................................................... 6 3. Interna poslovna pitanja............................................................................................................................ 7 3.1 Pomeranje odgovornosti ..................................................................................................................... 8 3.2 Razvijanje novih vetina ...................................................................................................................... 8 3.3 Regrutovanje i negovanje cloud profesionalaca ................................................................................. 9 4. Eksterna poslovna pitanja ....................................................................................................................... 10 4.1 Varijabilni trokovi ............................................................................................................................. 10 4.2 Izbor provajdera cloud usluga ........................................................................................................... 11 4.3 Vezivanje za provajdera..................................................................................................................... 12 5. Tehnika pitanja ...................................................................................................................................... 12 5.1 Bezbednosna pitanja ......................................................................................................................... 12 5.2 Pitanje performansi ........................................................................................................................... 13 5.3 Migraciona strategija......................................................................................................................... 13 5.4 Arhitektura za cloud .......................................................................................................................... 13 6. Planiranje i implementacija aplikacija u oblacima .................................................................................. 13 6.1 Planiranje migracije aplikacija u oblak .............................................................................................. 13 6.2 Karakteristike aplikacija u oblacima .................................................................................................. 15 6.3 Ogranienja i zahtevi ......................................................................................................................... 17 6.4 Arhitekturalna reenja....................................................................................................................... 19 7. Koristi i rizici migracije u cloud ................................................................................................................ 20 7.1 Prednosti migracije u Cloud.............................................................................................................. 20 Organizacione prednosti ..................................................................................................................... 21 Tehnike prednosti .............................................................................................................................. 21 Finansijske prednosti ........................................................................................................................... 21 7.2 Rizici i pretnje migracije u Cloud ....................................................................................................... 22 Organizacioni rizici............................................................................................................................... 23 2
Tehniki rizici ....................................................................................................................................... 23 Pravni i administrativni rizici ............................................................................................................... 24 Ekonomski rizici ................................................................................................................................... 25 Sigurnosni rizici .................................................................................................................................... 26 8. Metode i alati za podrku odluivanju za cloud migraciju..................................................................... 26 8.1 Portfolio analiza................................................................................................................................. 26 8.2 Modelovanje trokova....................................................................................................................... 28 8.3 Procene koristi i rizika ....................................................................................................................... 30 9. Studije sluaja .......................................................................................................................................... 31 9.1 Studija sluaja: Hipol ......................................................................................................................... 31 9.2 Studija sluaja: Optina Narvik .......................................................................................................... 33 Zakljuak ...................................................................................................................................................... 37 Literatura ..................................................................................................................................................... 39
Uvod
Raunarski oblaci su novi trend korienja informacione tehnologije. U ovom radu su navedeni neki od kljunih izazova u kretanju ka oblaku. Preduzee se moe opredeliti za migraciju podataka, aplikacija, delova ili itavog IT sistema u oblak; moe se opredeliti za SaaS, PaaS ili IaaS arhitekturu; moe izabrati privatni, javni ili hibridni model oblaka, ili se odluiti da neke aplikacije ostavi on premise, tj. u tradicionalnom okruenju; moe se odluiti za jednog ili vie provajdera; moe izabrati da migraciju vri odjednom ili postepeno itd. To su pitanja na koja se mora odgovoriti pre samog donoenja odluke o migraciji. Ne ulazei dalje u materiju, ve iz navedenog moe se naslutiti kompleksnost pitanja upravljanja tranzicijom u cloud. U ovom radu nisu predstavljena definitivna uputstva menaderima za migraciju IT sistema u oblak poto ona zavise od mnogo faktora specifinih za pojedine vrste oblaka, kao i od specifinosti same organizacije koja vri migraciju. Pored toga postoji veliki broj faktora koji utiu na arhitekturu reenja, a koja zavise od konkretnog provajdera. S obzirom na veliki broj specifinosti koje prate migraciju, teko je napraviti generalno uputstvo za uspenu tranziciju u oblak. Meutim, u radu su predstavljeni najbitniji aspekti migracije, kljuna pitanja koja menaderi moraju paljivo da razmotre u strategiji prelaska na oblak, procene koristi i rizika, kao i metode i alati za podrku menaderima tokom procesa donoenja odluka.
poslovanje kao to je internet softver za upravljanje rasporedom putovanja zaposlenih ili za podrku u sferi menadmenta ljudsih resursa. One e moda formirati sopstvenu privatnu arhitekturu cloud computing-a, skrivenu iza korporativnih firewall-a, kako bi iskoristile njihovu efikasnost, ali uz veu bezbednost i kontrolu. Cloud computing uspeva da prui izvrenje desetina triliona raunica u sekundi za probleme kao to su analiza rizika u finansijama, pruanje linih medicinskih usluga, ak i pokretanje zahtevnih kompjuterskih igara. To se radi umreavanjem velikih grupa servera koji esto koriste jeftinu potroaku PC tehnologiju, sa specijalizovanim konekcijama za irenje obrade podataka putem njih. Poreenja radi, novi i najjai kuni PC raunari izvravaju samo oko tri biliona raunica u sekundi. Jedna od odgovornosti menadmenta preduzea je da obezbedi neophodna sredstva za rad zaposlenima. U nekim firmama se to odnosi na hardver i softver koji je zaposlenima neophodan da bi obavljali svoje poslove. Kupovina raunara nije dovoljna, mora se nabaviti i odgovarajui softver i softverske licence da bi zaposlenima obezbedili potrebne alate. U sluaju da se zaposli novi radnik, menadment mora kupiti novi softver ili biti siguran da trenutna softverska licenca omoguava dodatno korienje softvera. Cloud computing prua manje stresnu alternativu. Umesto instalacije softvera na svakom raunaru, treba samo uitati jednu aplikaciju. Ta aplikacija e omoguiti radnicima da pristupe servisima zasnovanim na Web-u koji hostuju sve programe koji su korisniku neophodni da bi obavio posao. Udaljeni raunari u vlasnitvu drugih kompanija e izvravati sve od email-a do obrade teksta i to moe promeniti celu kompjutersku industriju. U cloud computing sistemu postoji znaajan napredak u radu. Lokalni raunari ne moraju vie da izvravaju teke poslove prilikom izvravanja aplikacija. Mrea raunara koje kreira oblak obavlja te poslove umesto lokalnih raunara. Hardverski i softverski zahtevi na strani korisnika se smanjuju. Jedinu stvar koju korisnik raunara mora da ima da bi mogao da radi u cloud computing sistemu je softverski interfejs, koji moe biti obian Web Browser, a cloud computing mrea obavlja sve ostalo.
Danas je proces premetanja aplikacije u oblak dosta sloeniji. Nisu sve aplikacije pogodne za primenu u cloud okruenju, a takoe neki provajderi cloud usluga nude bolja reenja od drugih tako da se i o tome mora voditi rauna. Dakle, dananja migracija ne prati istrorijski Microsoft BDD pristup, ali ukljuuje meavinu okruenja, kao to su: Rasporeivanje desktop aplikacija Sever-bazirana hosting reenja Okruenja viestruke virtuelizacije Viestruka cloud reenja
Zapravo, mnoge kompanije su se ve opredelile za hibridni model u podruju virtuelizacije. Top etiri vendora virtuelne tehnologije (Microsoft, Citrix, VMware i Symantec) se takmie u pruanju najbolje ponude, trudei se da karakteristike njihovih proizvoda potpuno odgovaraju zahtevima kupaca, tako da mnoge organizacije kombinuju dva ili vie proizvoda za virtuelizaciju kako bi najbolje zadovoljili svoje potrebe i zahteve skladitenja. Veliina rizika se poveava sa poveanjem broja aplikacija koje su prebaene u oblak [5]. Osim toga, hibridni model koji e mnoge organizacije morati da usvoje, takoe poveava rizik srazmerno broju reenja koja su ukljuena u model. Shodno tome, donosioci odluka moraju da balansiraju izmeu prednosti koje nudi optimalno hibridno reenja i rezultujue kompleksnosti nastajueg cloud-a. esto je hibridni pristup virtuelizaciji izabran iz nude: neke aplikacije jednostavno nisu kompatibilne sa App-V, na primer, dok druge ne mogu biti virtuelizovane reenjima koje prua Symantec. Ovo spreava organizaciju da izabere jednu virtuelnu platformu za sve aplikacije, jer bi problem sa kompatibilnou mogao da poremeti i onemogui izvrenje osnovnih poslovnih funkcija. Pored toga, preduzea neke aplikacije uopte ne ele da sele u oblak; na primer, ukoliko se aplikacija retko koristi ili je koristi samo nekoliko ljudi, povraaj investicija od migriranja u oblak bi bio veoma nizak. Dakle, organizacije mogu odluiti da neke aplikacije zadre u prirodnom obliku i uopte ne vre njihovu migraciju. U principu, administratori aplikacija bi trebalo da oekuju najmanje dve kljune platforme gde e aplikacije biti migrirane, i da se pripreme za veliku sloenost koja ih oekuje u upravljanju portfoliom aplikacija.
radno mesto, treba da razumeju da cloud otvara nove mogunosti za IT osoblje, jer e ono moi da posveti vie vremena stratekim IT pitanjima unutar organizacije. Cloud computing moda zatvara vrata odreenim IT vetinama, ali otvara nova, kao to su cloud menadment, kastomizacija aplikacija i razvoj, a to bi trebalo da motivie IT osoblje da istrai nove, uzbudljive oblati. Kada se menadment suoava sa prelaskom na cloud computing, treba da proceni tri stvari kako bi bio siguran da je kompanija spremna [3]: planiranje premetanja odgovornosti u IT-u; razvijanje novih vetina; regrutovanje, trening, zapoljavanje i zadravanje cloud profesionalaca.
sistem integrator firme niu na sve strane, i dalje postoji potreba za sistem integratorom u okviru firme koji treba da povee razliite cloud servise koje organizacija koristi. Takoe, oni se mogu specijalizovati u oblastima monitringa i kontrole, jer sa velikim brojem alata od strane treih lica uvek e biti potrebe da neko unutar organizacije radi na ovim servisima. Istina, to se tie strunog usavravanja ove vrste praktiara, jo uvek nema mnogo formalnih mogunosti za uenje. Zato se organizacijama preporuuje fleksibilan pristup, gde bi se zaposlenima dozvolilo poseivanje skupova namenjenih cloud computing i itanje odgovarajuih blogova. Vetine stratekog upravljanja Posebno kod cloud computinga je to to on prua priliku IT odeljenju da minimizira umenost u tehnike aspekte IT-ja i postane strateki partner u poslovanju. Umesto da se na IT gleda kao na troak, IT odeljenje moe postati ono koje dodaje vrednost organizaciji. Kao i kod odnosa sa vendorima, postoji obilje mogunosti za razvoj novih vetina. Organizacije treba da upare IT odeljenje sa zaposlenima koji donose strateke odluke, kako bi zaposleni u IT -ju mogli da prepoznaju reenja koja su u skladu sa ciljevima organizacije.
10
4.Gubitak interne IT ekspertize, koja je obezbedila konkurentnu prednost - Kompanije mogu koristiti strateke in-house sisteme ili aplikacije, koje bi prebacivanjem u oblak izgubile efektivnost. Mogue je da preduzee ima in-house reenja koja su toliko specifina za samu organizaciju da bi se njihovom selidbom u oblak izgubila konkurentska prednost. Na primer, Dell ima specifine sisteme za prilagoavanje potrebama kupaca sa ugraenim sistemom za upravljanje lanacim snabdevanja, i ukoliko bi se izvrila njegova migracija na oblak on bi izgubio svoju sposobnost prilagoavanja. 5.Vezivanje za jednog provajdera moe spreiti usvajanje open-standarda - Rizik zarobljavanja kod odreenog cloud provajdera moe ugroziti mogunost usvajanja open-standard usluga koje se tek pojavljuju. Zato treba biti paljiv prillikom potpisivanja ugovora i biti siguran da se lako moe promeniti provajder bez plaanja prevelike cene.
jednim vidom outsourcing-a, on obino nosi vei rizik. Zbog toga je u planu definisanje novog ISO/IEC 27017 standarda koji e se iskljuivo odnositi na bezbednost u cloud computing-u i koji e obuhvatiti sve njegove specifinosti. S obzirom da e u velikoj meri zavisiti od revidiranog standarda ISO 27001 i ISO 27002, u najboljem sluaju e biti objavljen krajem 2013., tj u prvoj polovini 2014. godine. Integrisanje razliitih oblika cloud postrojenja (privatni, hibridni i javni oblak) u jednu celinu nije jednostavan zadatak za preduzea koja ele da kombinuju ove vrste oblaka. Mogue je kombinovanje vie provajdera cloud usluga i razliitih modela cloud-a, tako da preduzea mogu izabrati odgovarajuu kombinaciju prethodno navedenog u zavisnosti od sopstvenih potreba i u skladu sa postojeom infrastrukturom, modelima podrke i potrebama IT menadmenta.
5. Tehnika pitanja
Organizacije su u nedoumici koje aplikacije bi trebalo premestiti na cloud. Iako je raunarstvo u oblacima sigurna budunost IT-ja, organizacije bi trebalo dobro da razmisle pristupu prilikom selidbe aplikacija u oblak. Prioritet za prebacivanje na cloud su aplikacije koje ve imaju interakciju sa eksternim aplikacijama i servisima i ne prave kompetitivnu razliku u odnosu na konkurenciju.
12
Drugi aspekti o cloud computing-u takoe zahtevaju veliko preispitivanje sigurnosti i rizika. Unutar cloud-a teko je fiziki locirati mesto gde se uvaju podaci. Ovaj nedostatak vidljivosti moe izazvati vie sigurnosnih i problema istinitosti. Infrastruktura deljenja poziva na visok stepen standardizacije i automatizacije procesa, a to moe poboljati sigurnost eliminiui rizik od greke operatera i previda. Meutim, rizici nerazdvojni od masovne deljene infrastrukture znae da cloud computing modeli moraju i dalje naglasiti znaaj izolacije, identiteta i istinitosti podataka.
veoma korisne informacije koje mogu pomoi preduzeima u usvajanju odgovarajueg cloud modela. Na osnovu izvrenih procena formulie se odgovarajua strategija, tempo i redosled akcija koje treba izvriti pri migraciji da bi se postigli optimalni rezultati. Polazna taka je razumevanje postojeih IT sredstava preduzea, vrednosti koja se stvara uz pomo njih i trokova njihove upotrebe. Pri tom se pod IT sredstvima podrazumeva kompletan portfolio, ukljuujui infrastrukturu, aplikacije i neophodno okruenje kojim se prua podrka za izvrenje aplikacija. Zatim, potrebno je obratiti panju na samu prirodu aplikacija. Neke aplikacije se mogu odmah prebaciti u oblak, dok je za druge neophodno izvriti posebna prilagoavanja da bi se mogla izvriti migracija, tj. njihovo prebacivanje e biti mogue u nekom buduem trenutku vremena. Za neke aplikacije je bolje da ostanu u tradicionalnom okruenju, tj.njihova migracija u oblak ne bi bila dobra za preduzee. Sadagopan Singam1 tvrdi da se aplikakacije za plaanja, putovanja, indirektnu kupovinu i nabavku lako mogu prebaciti u oblak [7]. Direktnoj nabavci, odnosno poslovnim tokovima koji u svom izvrenju moraju proi kroz vie poslovnih funkcija ili odeljenja, bolje odgovara privatni oblak, kao to su npr. regulatorni ili finansijski podaci. Aplikacije koje zahtevaju visok stepen odravanja takoe e bolje funkcionisati u privatnom cloud-u. Sloene aplikacije, koje imaju veoma visok koeficijent integracije, tj. koje je potrebno povezati sa mnogim drugim aplikacijama najbolje je ne seliti u oblak ve ostaviti u tradicionalnom okruenju. Operativno nestabilne aplikacije ili aplikacije na kojima se esto vre izmene je bolje ostaviti on-premise, u tradicionalom okruenju. Takoe ako je tip preduzea takav da zaposleni teko toleriu i minut ekanja u radu aplikacije, ne bi trebalo vriti migraciju u oblak. Aplikacije koje su visoko regulisane, kao to su one u kojima se uvaju podaci medicinskih i klinikih istraivanja ili informacije vezane za administraciju hrane i lekova takoe bi trebalo da ostanu unutar preduzea. Ako preduzee koristi aplikaciju koja je razvijena u zastarelom okruenju pre 50 godina, figurativno reeno, ona verovatno nee moi lako ni dobro da se migrira u oblak. ERP podaci bi takoe trebali da ostanu unutar preduzea. I na kraju, multidivizione organizacije u kojima se razliito vre poreski ili slini obrauni u zavisnosti od zakonodavstva na konkretnoj lokaciji, takoe bi trebalo da sauvaju tradicionalnu infrastrukturu, jer je teko objasniti revizoru gde se nalaze podaci konkretne filijale ukoliko se oni uvaju oblaku. Ovo je naroito znaajno ukoliko se podaci nalaze u drugoj dravi u kojoj vladaju drugaija pravila vezana za finansijske izvetaje.
1
Sadagopan Singam je globali potpredsednik za poslovne i IT usluge vezane za transformaciju i Cloud Computing u HTC Technologies Ltd. HTC Technologies Ltd. je najistaknutija kompanija u Indiji koja se bavi pruanjem tehnolokih usluga i konsaltingom.
14
Za razliku od fiksne infrastrukture standardnih aplikacija, oblak predstavlja skup velikog broja servera u kome se na fleksibilan nain mogu prerasporeivati komponente. Komponente aplikacije koje su statiki rasporeene u standardnom okruenju se postavljaju na dinamike servere u oblaku. Pojedine kopije aplikacije koje rade nezavisno na razliitim serverima se
15
nazivaju instance. Broj instanci obino nije fiksan i moe se poveavati ili smanjivati u zavisnosti od potrebe. Poveavanjem broja instanci poveava se mogunost paralelne obrade zahteva, dok se smanjivanjem broja instanci oslobaaju resursi u oblaku za druge aplikacije kojima su potrebniji. Dakle, fleksibilnost oblaka omoguava efikasnije iskorienje resursa. Ovaj proces je prikazan na slici 2.
Instance se mogu seliti meu serverima u sluaju da infrastruktura ili administratori zakljue da je potrebno preraspodeliti optereenje servera i celog oblaka. U ovom sluaju je potrebno posmatrati razliku izmeu perzistentnih i tranzijentnih instanci aplikacije.[2] Karakteristike aplikacija u oblacima zavise od modela clouda koji se koristi. IaaS prua razvojnim timovima kompletnu hardversku infrastrukturu koju mogu prilagoavati svojim potrebama, tj. virtuelno okruenje se moe konfigurisati u zavisnosti od potreba aplikacije. U PaaS modelu clouda aplikacija se mora prilagoditi platformi na kojoj radi. Jedino o granienje je da se ne mogu koristiti aplikacije koje nisu kompatibine sa platformom. Softver kao servis (SaaS) model predstavlja potpunu apstrakciju infrastrukture oblaka. U ovom modelu, razvojni timovi mogu da razviju aplikacije u skladu sa karakteristikama definisanim za svaku infrastrukturu. Takve aplikacije se postavljaju u oblak i izvravaju bez ikakve dodatne kontrole razvojnog tima. Kompletna administracija sistema je u odgovornosti provajdera infrastrukture koji prati korienje resursa i po potrebi ih dodaje ili oduzima. Ukoliko se aplikacija pravi ispoetka, tj. namenski dizajnira za cloud okruenje, ona e svakako bolje funkcionisati i bolje iskoriavati prednost clouda za razliku od standardnih aplikacija naknadno prilagoenih za rad u oblaku. Native cloud application (NCA) je naziv za softversku aplikaciju koja je specijalno dizajnirana za cloud computing i virtualizovano okruenje. NCA su dizajnirane, razvijene i primenjene na nain da iskoriste maksimalnu funkcionalnost i usluge cloud computing-a i virtualizovane infrastrukture. NCA aplikacije su prvenstveno razvijene imajui u vidu cloud computing arhitekturu. Iako mogu biti sline tipinim softverskim aplikacijama, pozadinski prorauni, skalabilnost i paralelno procesiranje kompatibilni su sa infrastrukturom cloud-a.
16
NCA bi trebalo da poseduje sledee karakteristike: Masovna paralelna izraunavanja Masivna paralelizacija podataka Potpuna iskorienost cloud resursa Cross-cloud paradigma
Pored navedenog seta karakteristika, cloud aplikacije bi trebalo da se lako koriste i jednostavno primenjuju. Masivna paralelna izraunavanja - Aplikacija koja podrava masivno paralelno izraunavanje je aplikacija koja moe jednostavno da distribuira proraune u okruenju kao to je cloud, gde se resursi mogu dodati ili ukloniti u bilo kom trenutku, bilo runo ili automatski. Ukoliko se doda resurs, aplikacija bi trebalo odmah da iskoristi njegovu prednost i da pone da distribuira proraune na njega, i obrnuto u sluaju uklanjanja resursa. NCA mora biti u stanju da automatski uputi oblak da srazmerno povea ili smanji potrebne resurse u zavisnosti od trenutnog optereenja i karakteristika kanjenja. Masivna paralelizacija podataka - Postoji miljenje da cloud sam po sebi podrazumeva distribuirano skladitenje. Realnost je da skladita, kao to je na primer Amazonov S3, uglavnom pruaju distribuirano skladitenje diska. Distribuirano skladitenje interne memorije, kao to je distribuirana ke memorija ili mrea podataka, nije podrazumevano obezbeeno. Dakle, da bi aplikacija u potpunosti iskoristila prednost clouda, skladitenje interne memorije se mora dinamiki poveavati kada god se izvri dodavanje novog resursa, i obrnuto. Potpuna iskorienost cloud resursa - Aplikacija bi trebalo da koristi izvorni API oblaka i ostale procedure kako bi pojednostavila zadatke i iskoristila veinu ili sve raspoloive resurse. Cross-cloud paradigma - Aplikacija bi trebalo da ima sposobnost lake migracije na okruenja i platforme razliitih cloud provajdera. Postoje razliiti tipovi cloud aplikacija. Tradicionalne aplikacije u cloud-u prate model arhitekture preduzea i dizajnirane su tako da zadovolje priblino stabilnu potranju. Sinhrone cloud aplikacije omoguavaju velikom broju korisnika da koriste sistem u kratkom vremenskom periodu. Obezbeuju dovoljno web servera za rukovanje ukupnim saobraajem i dovoljno posrednika za upravljanje tranjom. Asinhrone cloud aplikacije ne podravaju interakciju sa krajnjim korisnikom ve rade nad setom podataka i iskustvu prelaznog optereenja (kao to je jednomeseno izvetavanje ili jednokratni zahtev obrade).
Razliite nfrastrukture oblaka podravaju razliite softverske platforme, i najee se moraju izvriti prilagoavanja aplikacije pojedinim infrastrukturama. Aplikacija se u cloud-u izvrava na vie servera, to ima brojne prednosti, ali takoe i nedostatke. S obzirom da se aplikacija izvrava na vie servera javlja se problem sa uvanjem sesionih promenjivih. Svaka sesiona promenljiva poseduje pridruenu metodu za proveru validnosti i mogunosti pristupa. Njihova glavna svrha je da definiu trenutno stanje korisnika, kao to su identifikator korisnika, privremena podeavanja, trenutni kriterijum pretrage i slino. Sesione promenljive se nalaze u memorijskom prostoru servera, a poto se aplikacija u oblaku istovremeno izvrava na vie servera, nije mogue meu njima deliti iste memorijske promenjive, to predstavlja prvo ogranienje. Drugo ogranienje odnosi se na stanje same internet aplikacije. Internet aplikaciju koja se nalazi na serveru ne ini samo izvrni kod i pratei statiki resursi kao to su skript fajlovi i slike. Ona esto privremeno snima fajlove u lokalne foldere, upisuje informacije u lokalne log fajlove i baferuje podatke lokalno pre slanja ili obrade. U nekom trenutku se moe desiti da server na kome se izvrava odreena instanca aplikacije postane nedostupan ili da infrastruktura oblaka odlui da celu instancu jednostavno preseli na drugi server kako bi se preraspodelilo optereenje u mrei. U ovakvim sluajevima, instanca se obino potpuno resetuje, gube se svi podaci i ona se reinicalizuje na drugom serveru. Dakle, oblak ne garantuje da e privremeno stanje pojedine instance aplikacije uvek biti ouvano. Cloud aplikacije bi trebalo da budu konfigurabilne, tako da oslobode organizaciju od skupih prilagoavanja i omogue joj da izvri konfigurisanje procesa na nain da se zadovolje specifine potrebe organizacije. Trebalo bi da preduzee moe da vri izbor izmeu razliitih tipova konfiguracija. Standardne internet aplikacije se esto postavljaju kod vie razliitih klijenata gde se konfiguriu u skladu sa potrebama svakog klijenta ponaosob. Svaki klijent dobija svoju kopiju aplikacije koja se konfigurie u skladu sa potrebama i zahtevima. S druge strane, u aplikacijama u oblaku nema smisla praviti posebne klase identinih aplikacija za posebne klijente. Umesto toga, jedna aplikacija mora da bude dovoljno konfigurabilna da moe da opsluuje vie grupa klijenata. Sledei problem, koji je predmet brojnih diskusija, odnosi se na izolaciju i sigurnost podataka. Cloud provajder bi trebao da bude u stanju da obezbedi vei nivo sigurnosti i privatnosti podataka nego to kupci mogu sami sebi da priute u internom okruenju. Pod ovim se podrazumeva fiziki, mreni, aplikativni nivo zatite i nivo zatite podataka, kao i obezbeivanje njihove rezervne kopije i mogunost oporavka. Provajder bi trebalo da je usklaen sa postojeim zakonima o bezbednosti i programima revizije. Meutim esto se postavlja pitanje da li su, i u kojoj meri su klijentski podaci sigurni u oblaku. U narednoj sekciji su objanjeni neki pristupi i arhitekturalna reenja kojima se mogu prevazici ovakvi problemi.
18
Aplikacije koje se izvravaju u oblaku bi trebalo da budu konfigurabilne tako da omogue organizaciji da izvri konfigurisanje procesa na nain da se zadovolje specifine potrebe organizacije i opslue razliite grupe klijenata. Jedna od osnovnih karakteristika cloud aplikacije
19
je njeno deljenje meu vie grupa korisnika ili organizacija. Iz sigurnosnih razloga ne bi trebalo dozvoliti svakom korisniku da ima pristup svim podacima niti svim delovima aplikacije. Neki korisnici bi trebalo da vide specifine izvetaje, drugima treba zabraniti pristup pojedinim sekcijama u aplikaciji, nekima iste sekcije treba da se izvravaju na razliite naine u zavisnosti od podeavanja itd. Tj. potrebno je implementirati konfiguraciju aplikacije u kojoj e fiziki kod aplikacije biti zajedniki za sve korisnike, ali e se aplikacija potpuno drugaije ponaati za razliite korisnike koji joj pristupaju. Ovo se moe lako implementirati ako aplikacija konstantno ita podatke iz neke konfiguracije i u skladu sa tim prikazuje podatke i obrauje zahteve. U oblaku ovo nije jedna aplikacija ve skup zajednikih instanci u okviru aplikacije koje istovremeno opsluuju razliite klijente. Da bi se ispunio zahtev konfigurabilnosti potrebno je identifikovati za kog klijenta radi aplikacija i na osnovu toga odrediti tip konfiguracije koji e se za njega primeniti. To se obino se odreuje po kljuu koji moe predstavljati URL kojim se pristupa aplikaciji i koji odreuje tip konfiguracije koja e se primeniti. Takoe klju moe biti i neko polje korisnika, kao to je IP adresa sa koje dolazi, kompanija za koju radi ili njegova uloga. Podaci o konfiguraciji mogu biti postavljeni u konfiguracione fajlove i podeljeni po folderima koji odgovaraju kljuevima. Izolacija podataka takoe predstavlja jedan od najveih problema u aplikacijama u oblaku. Arhitektura mora da osigura da ni u kom sluaju jedan klijent ne moe da pristupi podacima drugog klijenta. Postoji vie naina za izolaciju podataka [2].
20
Sigurno da cloud computing donosi izazove za menadment organizacije. No, trebalo bi da oni, umesto da gledaju na cloud kao na problem, vide priliku u tome da edukuju zaposlene. Stvarajui jae IT odeljenje, dodae vrednost organizaciji. Jedna od glavnih prednosti koja migracija prua organizaciji je mogunost da se ona fokusira na osnovne poslovne aktivnosti i oslobodi menadment i IT osoblje svakodnevnih poslova (kao to je odravanje hardvera), tako da se preduzea mogu fokusirati na aktivnosti koje stvaraju vrednost za organizaciju. Ako se uporedi cloud computing sa elektrinom energijom, to je veoma esto koriena analogija, jasno je da organizacijama odgovara da koriste struju kada i koliko im je potrebno, bez potrebe da je sami proizvode, to im ostavlja prostora da se koncentriu na stvaran posao kojim se bave. Isto tako, posao organizacije kojoj to nije osnovna delatnost ne bi trebalo da bude upravljanje i odravanje mail servera, baza podataka ili aplikacione infrastrukture. Prva postava IBM-a kae da poslovna osoba, koja eli da razvije novu soluciju, veinu vremena i energije potroi na definisanju prave infrastukture hardvera i softvera da bi kreirala tu soluciju [4]. Cloud computing omoguava ljudima da dele resurse da bi reili nove probleme. Koristi se deljivo okruenje, tako da vreme koje se potroi na bilo kom projektu za dobijanje hardvera i softvera i njihovo konfigurisanje i rukovoenje sistemom je daleko manje, to ubrzava inovacije.
Tehnike prednosti
Cloud omoguava korisnicima da pristupaju raunarskim resursima i aplikacijama bilo kad, bilo gde i sa bilo kog ureaja (laptop, mobilni itd.). Ovo pojednostavljuje saradnju meu korisnicima, kao i podrku i odravanje aplikacija. Takoe vreme pokretanja/odziva sistema moe se prilino smanjiti usled mogunosti rezervisanja ogromnih raunarskih resursa u kratkom periodu vremena. Npr. batch posao kome treba 1000 asova za izvrenje moe se izvriti za 1 as korienjem 1000 servera, za istu cenu. Cloud computing uspeva da prui izvrenje desetina triliona raunica u sekundi to je naroito bitno za sloena izraunavanja koja zahtevaju dugo vremena za procesiranje. Poreenja radi, novi i najjai kuni PC raunari izvravaju samo oko tri biliona raunica u sekundi. Kroz cloud computing, kapacitet raunara drastino raste. Jo jedna prednost je fleksibilnost u proirivanju/smanjivanju upotrebe resursa bez prekida usluge i diskontinuiteta u radu. Takoe dosta je jednostavnije i jeftinije obezbeenje oporavka od katastrofe i planova kontinuiteta poslovanja usled geo-distribucije i replikacije postrojenja koje obezbeuju cloud provajderi.
Finansijske prednosti
Nije cloud computing samo bri nain dobijanja informacione tehnologije ve je i jeftiniji i efikasniji. Ako kupite server i ako on radi ceo dan ali nije u potpunosti iskorien, ne moete da sauvate raunarski sistemski kapacitet i da ga koristite kasnije. To predstavlja gubitak, ali to se
21
deava kada kompanije narue svoju IT infrastukturu i ne koriste je 24 sata 7 dana u nedelji sa 100% iskorienosti. Sa cloud computing-om kompanije nemaju te trokove, i nemaju besposlene sate za traenje svojih IT resursa. Kao dodatak infrastrukturnim resursima (hardver, softver, prostor), ovi resursi ukljuuju ljude koji upravljaju sistemom, kao i IT obezbeenje. Sa cloud computing-om, trokovi IT operacija kompanija znaajno opadaju. Trokovi se smanjuju i usled efikasnijeg poslovanja i manjih trokova odravanja infrastrukture, ali takoe i zbog ekonomije obima koja se moe postii cloud uslugama. Cloud smanjuje potrebu za kapitalnim investicijama i prua mogunost da se fiksni trokovi transformiu u varijabilne. Ovo moe pojednostaviti upravljanje novanim tokovima.
Menaderi bi trebalo da razjasne uloge i odgovornosti u organizaciji pre usvajanja oblaka, jer gubitak vlasti i kontrole nad resursima (i fizike i menaderske) moe dovesti do nejasnih uloga i odgovornosti, to moe biti uzrok mnogih problema. Na alost, odreeni broj ljudi e se uvek buniti protiv migracije na cloud, naroito oni koji se oseaju ugroenim. Zaposleni mogu pruati direktan ili indirektan otpor promenama usled organizacione politike i izmena u njihovom poslu. Smanjena produktivnost zaposlenih tokom migracije i neizvesnost posla (usled smanjenja broja zaposlenih u odeljenju ili irenju glasina u organizaciji) dovode do niskog morala osoblja i irenju anksioznosti u organizaciji. Preporuka organizacijama je da zadri strunjake u organizaciji i da ih ukljui u proces migracije. Preduzea se esto pri migraciji svojih sistema na cloud opredeljuju za vie cloud provajdera, jer jedan cloud provajder ne moe da zadovolji sve njihove potrebe. Takoe, cloud provajderi mogu imati razliite tipove mehanizama podrke. Upravljanje sistemom koji je razmeten na nekoliko cloud-a moe zahtevati dodatne napore menadmenta u poreenju sa rasporeivanjem sistema u kui (npr. upravljanje odnosima sa cloud provajderom, upravljanje problemima, upravljanje izmenama cloud usluga). Ovo je jedan od skrivenih trokova primene sistema na oblaku. Zato je neophodno stvoriti svest menadmenta o dodatnim naporima koji bi mogli biti potrebni. Jedan od organizacionih rizika je i neusklaenost izmeu postojeih procedura za postupanje prilikom incidenata i procedura cloud provajdera. Zato je neophodno proveriti provajderov SLA i osigurati se da on ima dobro definisane procedure o postupanju u sluaju incidenata, klasifikacione eme i procedure izvetavanja (npr. ta se izvetava, koliko se brzo vri izvetavanje, kome se izvetava). Rizik za organizaciju mogu biti i neoekivane izmene u uslugama cloud provajdera ili akvizicija cloud provajdera od strane druge kompanije koja menja/prekida usluge. Ovo naroito moe biti sluaj ukoliko koristimo malog cloud provajdera koji moe biti preuzet od strane veih firmi.
Tehniki rizici
Ukoliko organizacija koristi samo jednog cloud provajdera, prekid u radu glavnog servisa moe dovesti do velikih prekida i nedostupnosti ostalih servisa ili gubitka podataka. R eenje za ovaj rizik moe biti korienje vie provajdera ili nadgledanje aplikacije iz okruenja izvan oblaka. Replikacija sistema preko vie cloud-a vezuje trokove i tehnike izazove. Organizacije prilikom prelaska na javni cloud imaju odreena oekivanja u pogledu performansi njihovog sistema, tj. aplikacije na cloud-u. Jedan od rizika je da su performanse loije nego to se oekivalo, npr. stopa takta procesora, U/I i mreni prenos podataka i stope
23
kanjenja. Moe bi biti teko dokazati cloud provajderu da performanse nisu onakve kao to je on obeao u svom SLA ugovoru, jer optereenje servera i mree moe da bude veoma promenljivo u oblaku. To moe dovesti do sporova i parnica. Iz tog razloga organizacije bi trebalo da koriste bencmarking alate za istraivanje performansi cloud-a u fazi istraivanja pre donoenja odluke o izboru provajdera. Ukoliko je provajder ve izabran, a preduzee se suoava sa loim performansama, reenje moe biti zakupljivanje dodatnih virtuelnih maina ili virtuelnih maina sa boljim specifikacijama za one koje se suoavaju sa sporim taktom procesora. Takoe moe se koristiti isporuka fizikog diska da bi se smanjio efekat mrenog kanjenja/transfera. Da bi se nezavisno verifikovale performanse sistema moe se koristiti third party alati za nadgledanje. Optimalno stanje u oblaku je kada preduzee moe u potpunosti da upravlja infrastrukturom i da kreira aplikacije koje se mogu izvravati kad god preduzee eli da ih pokrene, sa to je mogue manje napora. Ali mnoga preduzea strahuju da bi izbor infrastrukture mogao da ih zarobi i sprei da preu kod novog provajdera koji nudi bolje usluge i reenja. Preduzea bi trebalo da uine sve to je u njihovoj moi da bi izbegla zarobljavanje kod jednog provajdera usluga (zakljuavanjem podataka u SaaS/PaaS oblaku ili zakljuavanjem sistema u IaaS-u) [8]. Ako uzmemo u obzir samo infrastrukturu-kao-servis (IaaS), ona je na najniem nivou i nudi itav niz opcija. U sluaju IaaS-a preduzee ima visok stepen fleksibilnosti, jer konkurentski provajderi imaju veoma razliite poglede na oblak. Razvojem open-cloud pristupa, prua se mogunost preduzeima da bez problema promene provajdera ukoliko to ele. Prelazak kod drugog provajdera nije trivijalan zadatak, naroito ukoliko oni pruaju usluge razliitog tipa, ali razvojem open-cloud standarda nee postojati nita sutinski znaajno to bi spreilo prelazak. Meutim, s obzirom na sadanji nivo razvoja cloud-a i nerazvijenog open-cloud pristupa, preduzea bi pri izboru cloud provajdera trebalo da kao stavku razmotre kompatibilnost njegovih servisa sa servisima ostalih cloud provajdera, kao i njegovu zainteresovanost za standardizaciju. Takoe, ukoliko se vri migracija aplikacija na cloud, moe se javiti problem nekompatibilnost aplikacije sa platformom cloud provajdera. To je jedno od prvih pitanja koje menaderi moraju da razmotre prilikom izbora cloud provajdera. Takoe, problem moe nastati i u sluaju IaaS ili PaaS cloud-a, u sluaju kada preduzee za svoj sistem koristi vie cloud provajdera ije su platforme meusobno nekompatibilne, tako da se moe javiti problem interoperabilnosti.
Pravni i administrativni rizici
Menaderi koji upravljaju migracijom bi trebalo da, pre prelaska na cloud, preispitaju sve vaee regionalne, nacionalne i meunarodne zakone koji su vezani za prenos podataka, skladitenje i zatitu, korienje i slino. Preduzee mora na osnovu vaeih zakona da obezbedi odgovarajuu zatitu odreenih podataka. Takoe, mora se voditi rauna i o usaglaenosti sa industrijskim regulativama.
24
Unutar cloud-a teko je fiziki locirati mesto gde se uvaju podaci. Ovaj nedostatak vidljivosti moe izazvati vie sigurnosnih i problema istinitosti. Odreeni propisi zahtevaju da se neki tipovi podataka uvaju u okviru nacionalnih granica. Rizik se moe izbei korienjem datacentra u okviru zahtevane jurisdikcije. Odreeni provajderi ne ele da otkrivaju gde se nalaze njihovi datacentri, to moe biti indikator da se oni nalaze van granica drave i takve provajdere treba izbegavati. Takoe, nepotovanje propisa koji zahtevaju saglasnost korisnika kada su u pitanju lini podaci moe uzrokovati probleme organizacijama, zato se i o ovome mora voditi rauna. Zatita podataka je osnovni princip informacione bezbednosti. Svi bezbednosni propisi i standardi zahtevaju da osetljive informacije budu zatiene na adekvatan nain kako bi se ouvala poverljivost. Tajnost tih podataka se mora ouvati bez obzira gde da se podaci nalaze, ukljuujui i cloud okruenja. Preduzee mora biti svesno da cloud provajder moe neovlaeno pristupiti podacima koje uvamo u cloud-u i zloupotrebiti ih krei propise vezane za tajnost podataka. Kao savet preduzeu u eliminisanju ovog rizika preporuuje se da ono koristi ifrovano skladitenje i prenos podataka. Generalno treba izbegavati provajdere koji ne podravaju ifrovani prenos podataka. Preduzee bi takoe trebalo pre migracije u cloud da proveri vaenje softverskih licenci koje poseduje, jer one mogu biti neupotrebljive na cloud-u zbog korienja tradicionalnih perprocessor2 ili per-seat3 sporazuma o licenciranju.
Ekonomski rizici
Stvarni trokovi migracije mogu se razlikovati od procenjenih. Uzrok ovoga mogu biti pogrene procene potrebnih resursa, promena cena od strane provajdera, ili loije performanse od oekivanih (npr. zbog preteranog korienja servera), to rezultira potrebom za vie resursa nego to je prvobitno predvieno. Zato bi trebalo pratiti postojee korienje resursa i koristiti alate za procenjivanje, kao i proveriti rezultate pokazatelja performansi, kako bi dobili tane procene trokova primene IT sistema u oblaku. Preporuka preduzeima je i da unapred ispitaju pitanja vezana za integraciju sistema i da u poetku izbegavaju da vre migracije sistema koji su dosta meusobno povezani. Ukoliko je sistem dosta sloen i zahteva kompleksne integracije to moe rezultirati poveanim trokovima. Jedna od uteda koju preduzee oekuje od cloud-a jeste smanjenje broja zaposlenih za podrku sistemu, to u sluaju sloenih integracija nije izvodljivo.
Per-processor sporazum o licenciranju je sporazum u kome se serveru moe pristupati neogranien broj radnih stanica ali se mora kupiti onoliki broj procesorskih licenci koliko ima procesora u serverskom raunaru. CAL -ovi nisu neophodni u ovoj implementaciji.
3
Licenciranje per-seat podrazumeva licenciranje svake maine, to znai da svaki raunar mora da ima svoju licencu.
25
Pod sigurnosnim rizicima podrazumevaju se razliite vrste napada na sistem u cilju onemoguavanja njegovog rada, kao i presretanje komunikacija i zloupotreba podataka. DoS (Denial of Service) napadi su naroito opasni jer uzrokuju nedostupnost resursa i poveavaju cenu korienja cloud-a. Kao indikator da je sistem napadnut su sporije performanse od oekivanih, kao i nedostupnost usluga. Zato bi trebalo koristiti alate za nadgledanje mree (mada neki cloud provajderi ovo nedozvoljavaju) ili nadgledati zahteve izvan cloud-a. Pod sigurnosnim rizikom se smatra i presretanje poruka i podataka u tranzitu. Ovo moe imati za posledicu da infrastrukturom manipulie neko tree lice. Zato bi trebalo koristiti sigurne komunikacione protokole i vie-faktorsku autentifikaciju. esto se mala panja posveuje web pretraivau, ali ranjivosti browser-a postaju sve znaajnije. Zato bi se trebalo postarati da se auriranje pretraivaa (browser updates) vri blagovremeno. S druge strane, third party kod je glavni krivac za napade kao to su operacija Aurora, Siemens Stuxnet i druge [10]. Vano je napomenuti da je third-party kod od sutinskog znaaja i brzo rastui deo softverskog portfolia nekog preduzea, koji ini izmeu 30 i 70 procenata interno razvijenih aplikacija. Posebno treba naglasiti da third-party, tj. nezavisni dobavljai u 81% odsto sluajeva nisu uspeli da dostignu prihvatljiv nivo bezbednosnih standarda, prema testovima koje je izvrio Veracode.
biti osposobljena da se lako prebaci u okruenje oblaka. Projektni timovi moraju da znaju generalne karakteristike infrastruktura kako bi najbolje uklopili u ono to im provajderi usluga omoguavaju i kako bi na najbolji nain prilagodili svoje aplikacije eljenoj infrastrukturi. Ocena zastarelosti postojeeg informacionog sistema zavisi od perspektive posmatranja. Zastareli sistemi podloni su aktivnosti reinenjeringa tj. transformacije u novu formu. Reinenjering softvera esto je povezan sa reinenjeringom poslovnog procesa tj. okruenja u kome se koristi softverski sistem. Radi se o ponovnom osmiljavanju i projektovanju poslovnog procesa u cilju poboljanja kritinih pokazatelja performansi kao to su trokovi, kvalitet, servisi i brzina. Opravdavanje reinenjeringa zahteva analizu postojeih aplikacija, procesa odravanja, i poslovne vrednosti aplikacija. Mora se osigurati povratak investicije do kog nivoa e kvalitet softvera porasti, proces odravanja biti poboljan, a poslovna vrednost poveana (analiza trokovi/dobit). Portfolio analiza slui za trijau aplikacija kandidata za reinenjering prema njihovoj pogodnosti za reinenjering nasuprot poslovnoj vrednosti: nastavak odravanja, zamena novim, izmena, ili otpis (Slika 3).
U kontekstu migracije na oblak, nastavak odravanja bi mogao da znai da se aplikacija funkcionalno neizmenjena sa fizike maine (servera) prebaci na virtuelnu, koja se izvrava na fizikom serveru korisnika ili kao deo privatnog oblaka. Zamena novom bi znaila da se postojea aplikacija izbacuje iz upotrebe, a da se umesto toga kupuje pravo na korienje novog servisa (prema SaaS konceptu), pri emu treba reiti pitanje migracije podataka. Ukoliko se donese odluka o reinenjeringu sistema, strateki se ova aktivnost moe sprovesti nad svim komponentama sistema odjednom, ili u inkrementalnoj varijanti, gde se deo po deo sistema prebacuje na novo radno okruenje (oblak), a ostatak ostaje u postojeem radnom okruenju. Prednost migracije odjednom je u tome to se ceo sistem dovodi u novo operativno stanje u istom trenutku. Nedostatak se ogleda u visokom riziku povezanom sa reimplementacijom poslovnih funkcija i korektnou rada novog sistema. Neke od postojeih tehnologija oblaka uzimaju u obzir potrebe inkrementalne migracije sistema, tako da obezbeuje mostove za komunikaciju dela sistema na oblaku sa ostalim delovima van oblaka (na primer, Azure AppFabric Service Bus). Deo aplikacije na staroj platformi trpi minimalne izmene. Na primer, ako se baza podataka prebacuje na oblak i pri tome ne trpi izmene strukture potrebno je
27
samo u starom kodu koristiti odgovarajui (odbc ili slian) konektor obezbeen od strane provajdera. Ako se naprotiv, baza zadrava na postojeoj infrastrukturi, komunikacioni most automatski obezbeuje pristup iz oblaka sa keiranjem podataka radi poveanja performansi. Najvie napora zahteva reimplementacija postojeeg softvera za izvravanje na oblaku. U tom scenariju mora se identifikovati i po potrebi restrukturirati arhitektura softvera. Ona opisuje softverski sistem kao kolekciju arhitekturnih komponenata. Arhitektura definie globalnu kontrolnu strukturu, protokole komunikacije, sinhronizacije i razmene podataka meu komponentama. Isto tako adresira pitanja dodele funkcionalnosti projektnim elementima, fizike distribucije, skaliranja i performansi.
Komunikaciona putanja: predstavlja transfer podataka izmeu bilo kog para vorova; Rasporeivanje: predstavlja rasporeivanje aplikacija na virtuelnim mainama, ili podataka na virtuelnom skladitu;
Jednom kada se osnovni model kreira uz pomo Eclipse-ovog drag & drop GUI-a, korisnici odreuju kog bi cloud provajera eleli da koriste za svaki vor, i koliko raunarskih resursa im je potrebno. Podrani su sledei raunarski resursi: asovi rada virtuelnih maina; skladite; broj U/I zahteva za podacima u skladitu; i koliina podataka u i iz vorova. Mogu postojati i drugi trokovi povezani sa radom sistema u oblaku, npr. trokovi statike IP adrese; meutim, takvi trokovi su obino neznatni. Jedna od kljunih prednosti korienja oblaka je elastinost i razvijena je jednostavna notacija za izraavanje zahteva elastinosti. Alat omoguava korisnicima da definiu osnovnu upotrebu za svaki resurs. Varijacije na ovu osnovnu liniju mogu se definisati korienjem paterna elastinosti koji su izraeni u prirodnom jeziku. Svaki patern moe biti ili privremeni ili trajni. Privremeni patern moe se primeniti samo tokom meseca (meseci) u kome je primenljiv, i moe se koristiti za definisanje privremenih porasta ili smanjenja upotrebe. Nasuprot tome, upotreba resursa koja je izmenjena trajnim paternom je perzistentna. Stoga, trajni paterni se mogu koristiti za definisanje paterna linearnog ili eksponencijalnog rasta ili pada resursa. Patern se definie na sledei nain: [temp/perm]: every [months] on [days] [variation][number] Gde months, days, variation i number mogu biti:
Months month jan-dec Days [empty] Everyday Weekdays weekends 01-31 mon/sun Variation + * / ^ Number float ili integer
Tj. pri definisanju meseca moe se navesti konkretan mesec na koji se patern odnosi (jan, feb,...,dec), period od vie meseci (jan-aug, jun-dec...) ili se moe koristiti predefinisana re month ukoliko se patern odnosi na sve mesece. Pri definisanju paterna mogu se, a i ne moraju, navesti dan/dani u mesecu, u zavisnosti od konkretne potrebe. Patern se moe odnositi na svaki dan u mesecu (kljuna re everyday), radne dane (weekdays), vikende (weekends), tano odreeni dan u mesecu (01, 02,...,31), na period od vie dana (01-15, 25-30), kao i na tano konretan dan u sedmici (mon, tue,,sun). Operacije koje se mogu koristiti, a kojima se izraavaju promene u potrebama za resursima, su + , -, *, / i ^, dok brojevi mogu biti celobrojnog tipa (integer) ili realni brojevi jednostruke preciznosti (float). Na primer, sledei paterni opisuju scenario gde je u poetku neophodno 100GB prostora za skladitenje; svakog meseca ova veliina se poveava sa dodatnih 10 GB koji su potrebni; za
29
vreme vikenda od juna do avgusta, potreban prostor za skladitenje se prepolovi; i svakog decembra, izmeu 25. i 30., on se udvostrui.
Baseline: 100, Patterns: perm: every month +10, temp: every jun-aug on weekends /2, temp: every dec on 25-30 * 2
U zavisnosti od alata koji koristmo sintaksa za definisanje paterna elastinosti se moe razlikovati. Za razliku od standardnog naina plaanja korienja cloud servisa, neki cloud provajderi pruaju mogunost klijentima da za niu cenu unapred rezervisu potrebne resurse. U tom sluaju cloud provajderi obino pruaju mogunost klijentima da definiu paterne elastinosti na rezervisane koliine resursa. Navedenu kupovnu opciju, kao i mogunost definisanja paterna elastinosti nudi i AWS, a njegova sintaksa za definisanje paterna se malo razlikuje od datog primera. [12] Nakon to je kreiran model rasporeivanja oblaka (cloud deployment model), i nakon to su definisani paterni elastinosti, korisnici treba da podese poetno i krajne vreme za simulaciju trokova. Alat zatim poinje simulaciju, predstavljajui model kao usmeren ciklini graf. Upotreba paterna za svaki vor i liniju u grafu obrauje se za svaki mesec izmeu poetnih i krajnjih datuma u simulaciji. Ukupna upotreba resursa svakog vora se zatim mnoi sa jedininim trokovima resursa, u zavisnosti kog cloud provajdera je korisnik naveo. Jedinine cene se preuzimaju iz XML fajla u kome se uvaju cene cloud provajdera. U njemu se trenutno nalazi preko 600 cena iz AWS, MS Azure, FlexiScale, Rackspace, GoGrid, i ReliaCloud-a. Ostali provajderi i njihove cene mogul se lako dodati. Konano, alat generie izvetaj koji prikazuje kako se cena sistema menja tokom vremena. Izvetaj je u vidu web stranice sa ugraenim grafikonima, tabelama i verzijom modela koja se moe zumirati, to je korisno kada su u pitanju veliki modeli sistema. Uz pomo ovog alata takoe se moe izvriti eksportovanje svih detalja kotanja kao CSV tabele u Excel-u za neke budue analize. Svaki model se moe razvrstati u razliite grupe, i napraviti izvetaj koji daje pregled detaljnih trokova za svaku grupu. Grupa moe predstavljati odeljenje, organizaciju, deo sistema ili ceo sistem. Ovo prua mogunost arhitektama da procene razliite opcije rasporeivanja sistema u cloud-u i da vide koja od njih je najpovoljnija.
javna slika, fleksibilnost, poslovni kontinuitet i usklaenost. Stoga, motiv za stvaranje alata za procenu prednosti i rizika je informisanje ljudi koji donose odluke. U poglavlju 8 ve su navedene kljune koristi i rizici upotrebe javnih cloud-a, i donosioci odluka bi trebalo paljivo da ih razmotre pre migracije svog poslovnog sistema. Prednosti i rizici obraeni u poglavlju 8 identifikovani su pregledom preko 50 akademskih radova i industrijskih izvetaja. Donosioci odluka mogu svaku prednost ili rizik oceniti kao nevaan, malo vaan, umereno vaan, vaan ili veoma vaan, iz njihove perspektive. Ovaj tip skaliranja se zove Likertova skala i on se esto koristi u istraivanjima.
9. Studije sluaja
9.1 Studija sluaja: Hipol
Hipol je prvi i jedini domai proizvoa polipropilena i proizvoda od polipripolena. Proizvodi pun asortiman homopolimera, trgovake marke HIPOLEN P. Preduzee je osnovano 1983. U Odacima, u blizini Sombora. Njegovi klijenti su proizvoai plastinih proizvoda na bazi polipropilena, prehrambena industrija (mlekare, pivare), domainstva, ugostitelj ski objekti i sl. Fabrika Hipol-a nije velika, kapaciteta 35.000 t/g, sa 308 zaposlenih.
2006. godine Hipol je privatizovan od strane inostrane firme. Inostrana firma koja je kupila Hipol smatrala je da treba tehnoloki unaprediti IT sektor, tako da je izvrila migriranje IT sredstava u privatni cloud. Pre privatizacije u IT sektoru je bilo zaposleno od 5 do 10 ljudi. Hipol je imao izgraenu lokalnu raunarsku mreu sa oko 100 Windows radnih stanica (NT4, XP). Koriena je Oracle 7.3 baza podataka na ALPHA serverima, NT4. Internet konekcija je bila slaba (modem 56k) i telefonska i raunarska komunikacija su bile razdvojene. Bila je primenjena koncepcija samostalnog i izolovanog RC-a i korieni su vlastiti programi za poslovanje razvijeni unutar firme.[11]
31
Promenom vlasnitva u Hipol-u, IT sektor je modernizovan prebacivanjem sredstava na privatni cloud, to je predstavljalo znaajan tehnoloki napredak. Inostrana firma je ve imala izgraen novi informacioni sistem grupacije i njihova koncepcija se zasnivala na ubacivanju novih firmi u postojii IT sistem grupacije, izmeu ostalog i Hipol-a. Data centar se nalazio u inostranstvu, a koriene su Microsoft Windows 2003 , Microsoft Navision i VmWare platforme, kao i VmWare virtuelne radne stanice. Komunikacija je bila zasnovana na Cisco-vom VPN-u, RDP-u i IP telefoniji, a poboljan je i internet link ( 8 Mb/s optika , Telekom Srbija ). Broj zaposlenih u IT sektoru Hipol-u se smanjio na troje-sistem inenjer, programer i pomodnik. Hipol je uspeno uveo IT i ostalo ( IP telefonija , IP video nadzor , evidencija radnog vremena ). Iako je prelazak u privatni cloud predstavljao znaajan tehnoloki napredak, postojali su izvesni rizici vezani za novi nain poslovanja, naroito to su se svi podaci Hipol-a nalazili u data centru u inostranstvu. S obzirom da je veliki deo poslovanja zavisio od Interneta, veliki problem bi nastao ukoliko bi se prekinula Internet veza, bilo gde. Jo vei rizik predstavljao je mogui prekid privatizacije, to bi za posledicu moglo imati da Hipol u potpunosti ostane bez podataka ukoliko se IT otkai, to se i desilo. 2012. godine ostvario se jedan od moguih rizika, tj. prekid privatizacije Hipol-a. Ubrzo nakon prekida privatizacije (mesec dana) prethodni vlasnik je prekinuo kompletnu informacionu komunikacionu strukturu. Hipol je ostao bez podataka i bez komunikacija. Zaposleni u IT-u u Hipol-u pre samog prekida pokuavali su da izvuku ono to se jo moe izvui (stari potpuni backup iz 2008. g i koritenje copy-paste principa u Excel-u ). Novi menadment je traio od sistem inenjera i programera da naprave brzu stretegiju pronalaenja reenja. Hipol je doneo odluku o izgradnji novog informaciono-komunikacionog sistema na bazi prethodnog (Microsoft Navision, CISCO). U prilog ovom reenju ide to to je Hipol ve imao kompletnu izgraenu infrastrukturu LAN-a, solidnu hardversku opremu (raunari, IP telefoni, ruteri), jak Internet link (optika Telekom Srbija, 8 Mb/s), obuene krajnje korisnike i obueno profesionalno ljudstvo. Meutim, ono to ne ide u prilog ovoj odluci je to to Hipol nije imao potrebnu hardversku infrastrukturu za servere, nije imao kvalitetne podatke, kao ni potrebne Microsoft i CISCO licence. Takoe, broj zaposlenih u IT-u je bio mali i nedovoljan da bi oni samostalno izneli itav problem. Najtea odluka je bila gde staviti virtuelnu serversku infrastrukturu i virtuelne radne stanice, u Hipol ili u oblak. S obzirom na mali broj ljudi u IT-u Hipol-a, na nedovoljno iskustvo u radu sa novim tehnologijama i nemogunosti formiranja kvalitetnih uslova za data centar, doneena je odluka da to bude cloud. U Hipolovom cloud reenju uestvovali su Coming i Telekom Srbija. U cloud su postavjeni serveri infrastrukture (domenski serveri, mail server i dr.) i 80 virtuelnih PC maina. Povezivanje u cloud se iz Hipol-a vri stalnom VPN vezom preko Interneta (ping
32
Hipol Coming 6 ms), a izvan Hipol-a preko client VPN veze. Virtuelnim strukturama Hipolovog cloud-a upravljaju stistem inenjer Hipol-a i sistem inenjeri Coming-a. Cloud je omoguio pristup zaposlenima bilo kad, bilo gde. Cloud je mnogo pouzdanije, kao i jeftinije reenje za Hipol nego da su se pravili vlastiti data centri. Hipol je primer kompanije koja je iskusila i koristi, ali i rizike i probleme cloud okruenja. Ipak, krajnja odluka Hipol-a bio je javni cloud. Hipol je svestan da cloud donosi i koristi i rizike, ali bitno je rizike blagovremeno identifikovati i upravljati njima na pravi nain. Hipol je dobar primer uspene migracije i rezultujueg poboljanja opte poslovne efikasnosti usled prelaska na cloud.
IT odeljenje je testiralo ovo reenje interno unutar svog odeljenja osam meseci pre nego to su ga pustili na korienje. Migracija ka javnom oblaku i cloud raunarskoj tehnologiji vrena je postepeno.
33
Optina Narvik se takoe postarala da postoje naini za dalju migraciju i izlazne strategije od Google-a kao provajdera usluga, ukoliko u budunosti to budu eleli. Google je objavio nekoliko migracionih alata i metoda na web stranici, www.dataliberation.org. Korienjem ovih alata ne stvara se stvarna zavisnost od Google-ove platforme i usluga. Optina je kontaktirala eksternu ekspertizu u procesu migraije od Lotus Notes ka Google-u. Kompanija koju je optina angaovala je bila inenjering kompanija koja je pomogla optini u vezi sa potrebnim prilagoavanjima sistema i procesu prebacivanja podataka. Uz pomo eksterne ekspertize, kao i Google-ovih migracionih alata, izvren je jednostavan prenos starih podataka sa Lotus sistema u Google-ov oblak. Meutim, graani optine Narvik bili su zabrinuti zbog novog reenja IT odeljenja. Graani su smatrali da novo reenje optine o migraciji na cloud, tj Google Apps, nije u skladu sa norvekim zakonom o zatiti podataka. Oni su uloili zvaninu albu norvekom inspektoratu za podatke (Norwegian Data Inspectorate). Norveki inspektorat za podatke je zatim zahtevao od optine Narvik da odgovori zbog ega se informacije uvaju u oblaku, i koji je njihov plan rukovanja osetljivim informacijama. Nakon to je optina predstavila trenutni sporazum i SLA ugovor sa Google-om i objasnila nain na koji se rukuje osetljivim podacima, norveki inspektorat za podatke je bio nezadovoljan. Poetna procena ugovora od strane inspektorata je da on nije usklaen sa norvekim zakonom u vie taaka. Optina nije sprovela odgovarajuu procenu rizika. Nije bilo jasno gde Google skladiti podatke optine, niti ko bi unutar Google-a mogao da im pristupa, kao ni kako se oni razdvajaju od podataka drugih Google-ovih klijenata. Zbog toga je optini naloeno da obustavi korienje Google Apps dok ne obezbedi odgovore na ova pitanja. Optini Narvik dat je rok za ponovno pregovaranje sa Google-om i za predstavljanje boljeg reenja vezano za rukovanje podacima u cloud-u. Kada je optina Narvik kontaktirala Google i zatraila pruanje cloud usluga, Google je predstavio optini standardni predefinisani ugovorni sporazum. Ovo je opti i standardni SLA koji Google alje svim svojim klijentima. Ovi sporazumi, prema miljenju norvekog inspektorata za podatke, nisu dovoljni, tj. nisu u skladu da norvekim zakonom o privatnosti. Meu najvanijim pitanjima koje je trebalo reiti odnosila su se na fiziku lokaciju gde se podaci skladite, kao i pitanja vezana za prava pristupa. Problem sa Google-ovim uslugama je bio taj to Google ne garantuje za tanu fiziku lokaciju podataka klijenata. Google-ove cloud servisi funkcioniu na nain da e podaci kojima se pristupilo biti preneti i nalaziti se na lokaciji gde je podacima poslednji put pristupljeno. Kao primer, ukoliko korisnik optinskog sistema pristupi svom mejlu u Kini, informacije e biti privremeno pod kineskim zakonom o privatnosti. Sklopljen ugovor sa Google-om davao je pravo Google-u da skladiti podatke optine na bilo kom Google-ovom data centu na svetu. Prema podacima sa Google-ovog sajta, pored svojih postrojenja u SAD-u, Google ima i data centre u EU (Finskoj, Belgiji, Irskoj), kao i u Aziji (Honk Kongu, Tajvanu i Singapuru). Takoe, cloud prvajderi mogu vriti balansiranje optereenja svojih data centara meanjem sa podacima u drugim oblastima cloud-a kako bi smanjili/poveali
34
optereenje servera/data centara. Ovo bi moglo da dovede do toga da se podaci nalaze u drugim zemljama sa zakonima i regulativama koje nisu u saglasnosti sa norvekim zakonom i regulativama. Optina Narvik koristi nekoliko Google-ovih usluga i aplikacija. Glavna aplikacija je Google Apps e-mail reenje, ali oni takoe koriste cloud uslugu za dokumenta i alate za prezentaciju i obraun. Neki od ovih alata bi mogli potencijalno da obrauju osetljive informacije, ali optina ne eli da se osetljive informacije koriste ili obrauju u bilo kojoj cloud aplikaciji. Meutim, email reenje je naroito teko kontrolisati. S obzirom da ove aplikacije imaju mogunost da rukuju ovim tipom informacija, neophodno je da rutine, politike i kontrole budu krajnje rigidne. Optina Narvik nije skladitila, niti je imala u planu da skladiti osetljive podatke na cloud-u, kao ni da alje osetljive informacije putem cloud provajdera. U celokupnom korienju razliitih usluga nastojala je da ogranii koliinu obrade linih podataka u vezi sa zaposlenima na ime, broj telefona, e-mail adrese i organizacioni afinitet. Naravno, ne postoji stopostotna garancija da nijedan osetljivi podatak nee biti uskladiten na cloud-u, s obzirom da je glavna aplikacija email usluga, ali optina Narvik je imala nekoliko procedura i rutina kako bi to izbegla. Optina je imala visoku svest u pogledu rukovanja osetljivim linim podacima i pokuavala je da informie svakog korisnika objavljivanjem informacija na svojoj web stranici ili putem email-a. Preporuka stanovnicima je bila da nikako ne alju osetljive i line informacije putem email-a. Ukoliko ipak dobiju email koji sadri osetljive informacije, nikada nee poslati isti emejl sa odgovorom nazad, ve e poslati potpuno novi mejl. Meutim, norveki inspektorat za podatke sumnjao je u sposobnost optine da ogranii stanovnicima slanje osetljivih linih informacija putem email-a. Rukovanje osetljivim podacima zahteva vre politike, rutine i kontrole. Nakon intervencije i upita inspektorata za podatke, Narvik je kontaktirao nekoliko advokata, pre svega advokatsku firmu sa seditem u Oslu. Optina je takoe imala pomo advokata iz Google ovih kancelarija u Londonu i SAD-u. Optina je smatrala da je norveki zakon malo zastareo. Na primer, norveki zakon zahteva da postoji mogunost interne kontrole u rukovanju podacima, to je skoro nemogue kada se koriste autsorsing provajderi ili cloud provajderi koji se nalaze u drugim zemljama. Ovi advokati si pomogli IT odeljenju i optini u ponovnim pregovorima i prilagoavanju SLA sa Google-om, kao i u rukovanju upitima i propisima norvekog inspektorata za podatke. Nakon ponovnog pregovaranja sa Google-om, optina i Google sklopili su novi izmenjen i prilagoen ugovor i optina je dobila dodatne garancije od Google-a. Google je pristao da napravi izuzetak u sluaju Narvika i da podatke optine skladiti samo u zemljama EU ili SAD-a, gde su zakonske regulative u skladu sa norvekim zakonom o privatnosti podataka. Takoe je obeao da e podatke drati logiki odvojeno od podataka drugih korisnika cloud-a. Google koristi otvoren praktian pristup u praenju kvaliteta svojih usluga. Google je objavio nekoliko alata koji mogu pomoi klijentima u praenju kvaliteta usluge koja im se isporuuje. Meutim, kako bi se izbegla mogua pristrasnost alata za nadgledanje, Google je prihvatio da reviziju njihovih data centara
35
izvri trea nezavisna firma, to je omoguilo optini Narvik da potvrdi da se potuje ugovoreni sporazum i u njemu definisan nain za rukovanje podacima koji je u skladu sa norvekim zakonom o zatiti podataka. Nakon izvrenih izmena i prilagoavanja prvobitnog ugovora optine Narvik i Google-a, norveki inspektorat za podatke je izmenio svoju prvobitnu odluku i procenio da su podaci sada bezbedni. Posle viestrukih problema u vezi sa zakonskom regulativom, i sa tim u vezi propratnih napora i neplaniranih uloenih sredstava za reavanje problema, ovaj sluaj zavren je povoljno za optinu Narvik. Ono to se moe zakljuiti je da je faza planiranja i pripreme procesa migracije/prebacivanja trebalo da otkrije da standardni Google-ov SLA nije u skladu sa norvekim zakonom o privatnosti. Ovo se moglo shvatiti mnogo ranije. Trebalo je u ovoj fazi uloiti vie vremena i resursa pre nego to se izvrila migracija. Meutim, optina Narvik i njeno IT odeljenje imalo je ograniene resurse i radnu snagu, i nije posvetila dovoljnu panju problemima koji bi mogli da nastanu. SLA ugovorni sporazum sa Google-om se morao modifikovati i prilagoditi, i nakon ovog procesa bie tee zameniti provajdera zbog injenice da e prebacivanjem resursa kod novog provajdera zahtevati slian proces prilagoavanja.
36
Zakljuak
Ne moe se porei da je cloud computing novi pristup u raunarstvu zbog ega predstavlja izazov mnogim preduzeima. Relativno mali broj objavljenih iskustava iz migracije IT sistema na raunarske oblake ukazuje da je tehnologija oblaka jo u povoju. Zreliju fazu karakterisae ukrupnjavanje provajdera tehnoloke infrastukture oblaka i standardizacija na nivou osnovnih koncepata. Postoje suprostavljeni stavovi vezani za prebacivanje IT sistema u oblak. Mnogi tradicionalni IT strunjaci imaju stav da se tehnoloka reenja moraju praviti u kui. Oni smatraju da neto to je napravilo tree lice ne moe biti dovoljno dobro implementirano kao domai proizvod. Protivnici cloud computinga dalje postavljaju pitanje bezbednosti, zakonskih regulativa i slino, ali ve sada postoji veliki broj reenja kao odgovora na ova pitanja, pa ovi argumenti polako gube na znaaju. Istina je i da veina preduzea ne moe da odrava bezbednost i otpornost koju vei provajderi mogu pruiti. Definitivno je da cloud prua mnoge prednosti organizacijama, naroito malim i srednjim preduzeima kojima se sada prua mogunost da pariraju mnogo veim igraima na tritu. Meutim, on nosi sa sobom i mnoge rizike i pretnje kojima treba upravljati i svesti ih na minimum. Cloud computing se moe posmatrati kao klatno koji organizaciji moe pruiti brojne pogodnosti i koristi, ali da ishod njegove primene ne bi doveo organizaciju u potpuno suprotan kraj klatna vano je u procesu odluivanja razmotriti organizacione rizike i paljivo upravljati njima tokom procesa donoenja odluka. Menaderi bi trebalo da odgovore na kljuna pitanja i da prate smernice, od kojih je jedan deo predstavljen u radu, na putu ka uspenoj tranziciji IT sistema u oblak. Upravljanje migracijom u oblak nije nimalo jednostavan ni lak zadatak, ali je istovremeno neophodan i jako bitan. Ovoj fazi treba posvetiti najveu panju, vreme i resurse jer je ona kljuna za uspeh ili neuspeh migracije. Manja i srednja preduzea obino nemaju dovoljno sredstava za sprovoenje detaljnih analiza koje su neophodne i ele to bre da zavre proces migracije, to moe imati fatalne posledice po itavo preduzee, pre ili kasnije. Istina je da oblak prua brojne prednosti i mogunosti organizacijama, ali nikako ga ne treba shvatati olako i vriti migraciju po svaku cenu. Moda se ba u fazi analize utvrdi da migracija odreenih podataka, aplikacija ili itavog sistema preduzea nikako nije dobra po preduzee i da je bolje da ono nastavi sa standardnim nainom poslovanja. Oblak donosi brojne utede, ali ne uvek i ne u svakom sluaju. Brojni su specifini faktori koji na to utiu, poev od samog tipa aplikacije/ sistema koji se eli autsorsovati, izbora provajdera, zakonskih regulativa itd. Zato se ne moe generalno rei da je cloud dobro ili loe reenje. Ali zato je tu faza upravljanja i analize koja bi trebalo da izvri prevagu na jednu ili drugu stranu. Iako nekad moe delovati da je migracija uspeno zavrena, ukoliko ova faza nije dobro izvrena mogu se naknadno javiti problemi, kao to se desilo i u sluaju optine Narvik koji je obraen u navedenoj studiji sliaja.
37
Da bi se faza upravljanja migracijom uspeno izvrila, preduzea bi trebalo da angauju u itav proces i ljude i eksterne ekspertize specijalizovane za odreene vrste problema, jer preduzea, naroito mala i srednja, nemaju dovoljno kvalifikovane radnike koji bi ispratili sve aspekte migracije. Koliko god preduzeima koja razmiljaju o migraciji investicija u ovu fazu delovala velikom, ona je u potpunosti opravdana i nikako je ne treba zanemarivati.
38
Literatura
[1] D. Boji, Migracija aplikacija na raunarski oblak, http://2010.telfor.rs/files/radovi/TELFOR2010_10_55.pdf, februar 2013. [2] J.Popovi, Implementacija aplikacija u oblacima- problemi i reenja [3]M.Talijan, Prelazak u oblak, http://www.ogledalo.rs/zmag/130/launchpage.html#/037db268/32, februar 2013. [4] D. uri, Bezbednost u cloud computing-u, Beograd 2010. [5] Quest Software, Inc, Migrating Your Applications to the Cloud, How to Overcome the Challenges and Reduce the Costs, http://cdn.scriptlogic.com/w/whitepaper/ChangeBASE-Virtualisation.pdf, februar 2013. [6] Jack McCarthy, CRN, 5 Hidden Costs Of Cloud Migration , http://www.crn.com/slideshows/cloud/240004991/5-hidden-costs-of-cloud-migration.htm?pgno=1, februar 2013. [7] D.Woods, How to Plan Your Cloud Migration, http://www.forbes.com/sites/danwoods/2012/06/11/how-toplan-your-cloud-migration/, mart 2013. [8] A. Khajeh-Hosseini , I. Sommerville, J. Bogaerts, P. Teregowda, Decision Support Tools for Cloud Migration in the Enterprise, http://arxiv.org/ftp/arxiv/papers/1105/1105.0149.pdf, februar 2013. [9] Cloudtweaks , Managing Risk when taking the Public Cloud Route OR Managing Risk in Public Cloud Strategy, http://www.cloudtweaks.com/2012/03/managing-risk-when-taking-the-public-cloud-route-or-managingrisk-in-public-cloud-strategy/, mart 2013. [10] Sankar, Security Risks of Moving to the Cloud Risk Assessment , http://cloudshoring.wordpress.com/2010/10/05/security-risks-of-moving-to-the-cloud-risk-assessment-part-1/, mart 2013. [11] B.Jari, Hipol-Migracija iz privatne u javnu strukturu, http://www.coming.rs/pdf/5prezentacija.pdf, februar 2013. [12] Creating Growth Patterns, http://www.planforcloud.com/pages/docs/patterns.html, april 2013. [13] A.S.Frogner, V.2012., Towards a compliant and secure cloud: Cloud migration, swapping providers and contractual aspects, pp. 49-54.
39