Čitav zdravstveni sistem se u ovom trenutku suočava sa ogromnim problemima, što znači da se i IT odeljenja u sklopu zdravstvenih ustanova nalaze pred velikim izazovima. Jedan od osnovnih zahteva koji se postavljaju svakoj IT službi jeste da postojeći sistemi funkcionišu bez prekida, ali i da se aktivno radi na njihovom unapređenju. Ponekad ovi zahtevi za unapređenjima mogu biti visokokritični i sa kratkim rokom za realizaciju. Tada je posebno važna podrška iskusnog IT partnera i upotreba pouzdanih tehnoloških rešenja.

COMING rešenja u zdravstvenim ustanovama

COMING – Computer Engineering već duži niz godina uspešno primenjuje svoja tehnološka rešenja i u zdravstvenom sektoru i može se pohvaliti saradnjom sa dve najveće privatne zdravstvene ustanove u Srbiji. Projekti u oblasti zdravstva u kojima učestvuju stručni timovi kompanije COMING podrazumevaju primenu cloud tehnologija i rešenja iz segmenta poslovnog softvera. Takođe, rad na ovim projektima često uključuje i realizaciju nove ili unapređenje postojeće infrastrukture, kako bi ona bila sposobna da funkcioniše sa što višim stepenom raspoloživosti, uz punu redundansu svih kritičnih tačaka i sa nultom tolerancijom na gubitak podataka.

Veliki broj projekata koje COMING izvodi u saradnji sa zdravstvenim ustanovama realizuje se u domenu cloud tehnologija. Primena cloud rešenja oslobađa zdravstvene ustanove od potrebe za investiranjem u hardver, softverske licence za infrastrukturni softver i prateće troškove za adekvatan telehousing opreme. Uz cloud tehnologije, važno polje saradnje je i oblast poslovnog softvera, gde se zdravstvenim ustanovama pomaže u procesu implementacije softverskih rešenja kojima se objedinjuju poslovni procesi unutar jedne ustanove. Naravno, tu su i profesionalne usluge koje COMING-ovi visokokvalifikovani inženjeri i konsultanti pružaju, najčešće sa ciljem da se postojeća infrastruktura ili poslovni procesi optimizuju i unaprede, kako bi sistem funkcionisao u 24×7 režimu rada.

Cloud tehnologije

Među najefikasnija rešenja koja COMING realizuje za potrebe zdravstvenih ustanova spadaju, svakako, moderne cloud tehnologije. Cloud rešenja, sa svim prednostima i koristima koje donose, mogu pomoći ovim organizacijama da se izbore sa aktuelnim i nekim budućim izazovima.

Osnovna premisa na kojoj počiva primena cloud tehnologija je potreba da se lokacija na kojoj je sam servis realizovan izmesti na sigurnije i pouzdanije mesto, ne samo u smislu fizičke lokacije data centra, već i opreme, infrastrukturnih servisa, kao i tehničke podrške koja upravlja sistemom i koja funkcioniše u 24×7 režimu rada. Kroz cloud usluge COMING zdravstvenim ustanovama isporučuje cloud kao primarnu platformu za realizaciju svih servisa, ali se ona može iskoristiti i kao udaljeni bekap i servis za oporavak u slučaju katastrofe, uz korišćenje odgovarajućih infrastrukturnih alata.

Projekti u domenu cloud tehnologija neretko aktiviraju i potrebu za profesionalnim servisima, kroz koje se postojeća infrastruktura dodatno optimizuje i osigurava. Tako COMING često sarađuje sa zdravstvenim ustanovama i na ovom polju, posebno u aktuelnim uslovima, kada su interne IT službe zdravstvenih ustanova opterećene drugim problemima.

Aleksandar Pavlović, Coming

The post Profesionalna rešenja za zdravstveni sektor appeared first on Business&IT.

S AP S/4 HANA predstavlja poslednju generaciju SAP ERP softvera, zasnovanu na SAP HANA inmemory database tehnologiji. U osnovi sistema je SAP HANA database platforma, koja celokupan sadržaj baze čuva u radnoj memoriji fizičkog ili virtuelnog database servera. Zbog ove karakteristike potrebe HANA database servera su značajno veće u odnosu na ostale database platforme, pre svega u pogledu operativne memorije, pa proces realizacije S/4 HANA platforme podrazumeva prethodnu pripremu servera za potrebe database i aplikativnih komponenata servisa.

Sam proces pripreme ovih servera je dosta zahtevan i podrazumeva u osnovi kreiranje virtuelnih servera, instalaciju operativnih sistema i konfiguraciju u skladu sa SAP preporukama, dostupnim u člancima i beleškama iz bogatog izvora podrške za SAP HANA platformu.

Složenija SAP okruženja često imaju veliki broj servera, jer poseduju nezavisno produkciono, razvojno i testno okruženje, pa je proces pripreme novih servera repetitivne prirode. Pored složenosti same pripreme i značajnog utroška vremena, dodatni problem u realizaciji predstavlja i izostanak uniformne konfiguracije između servera, naročito ukoliko su oni napravljeni u različito vreme i od strane različitih timova. Ipak, ovaj proces je moguće olakšati korišćenjem alata za automatizaciju, među kojima se posebno ističe Ansible, kao odlična alternativa manuelnim konfiguracijama.

Ansible Tower

Alat pod imenom Ansible javnosti je prvi put predstavljen 2012. godine. Razvio ga je Michael DeHaan, nakon višegodišnjeg bavljenja platformama za automatizaciju i orkestraciju, kao agentless alat za upravljanje i konfiguraciju namenjen Linux, Unix i Microsoft Windows platformama. Ovaj open source alat za konfiguraciju, upravljanje i orkestraciju unutar IT infrastruktura oslanja se na napredan CLI interfejs, zasnovan na YAML jeziku, preko koga se mogu automatizovati brojni taskovi na svim navedenim platformama.

Ansible se oslanja na IaC (Infrastructure as a Code) principe, zahvaljujući kojima je compute i mrežna infrastruktura definisana, odnosno organizovana kao kod. Osnovna ideja iza ovog pristupa je da se umesto namenskih skripti za konfigurisanje ili manuelne konfiguracije servisa koristi deklarativni programski jezik, kojim je proces konfiguracije definisan. Sa Linux serverima Ansible komunicira preko SSH protokola, dok za Windows servere koristi WinRM protokol.

Za potrebe automatizacije procesa pripreme SAP S/4 HANA servisa optimalna je verzija alata pod imenom Ansible Tower, web-based platforma namenjena upotrebi u većim sistemima, unutar složenijih IT odeljenja različitih profila. Red Hat Ansible Tower platforma omogućava organizacijama da automatizuju većinu zadataka, organizuju proces ažuriranja, pripreme novih okruženja, konfiguracije i upravljanja resursima.

Pored web interfejsa, Ansible Tower poseduje i REST API, preko koga se platforma može integrisati sa ostalim sistemima i alatima. Skup konfiguracionih parametara za SAP S/4 HANA i SAP HANA platformu je dostupan i usklađen sa SAP preporukama.

Ansible alat za konfiguraciju, upravljanje i orkestraciju unutar IT infrastruktura omogućava automatizovanje brojnih taskova na Linux, Unix i Windows platformama

Instalacija SAP servisa

Proces pripreme okruženja započinje dodavanjem playbook-ova i kreiranjem workflow procesa, kojim se određuje tok pripreme servisa, od kreiranja virtuelnih servera pa sve do podešavanja unutar samih servisa koji su predmet instalacije.

Za instalaciju SAP servisa korišćenjem Ansible Tower alata potrebni su:

• instaliran Red Hat Ansible Tower servis sa Automation Platform licencom;
• Red Hat Ansible Tower korisnički nalog sa administratorskim privilegijama, kako bi imao prava da menja Tower inventar i projekte, kao i dozvola za pravljenje Tower templejta i kredencijala;
• SSH konekcija između Red Hat Ansible Tower servera i SAP sistema koji su predmet instalacije i konfiguracije.

Sam proces instalacije i pripreme servera započinjemo kreiranjem projekta, koji u suštini predstavlja skup Red Hat Ansible playbook-ova. Korišćenjem web interfejsa kreiramo novi projekat i popunjavamo konfiguracione detalje.

Naredni korak u konfiguraciji je inventar, koji treba da sadrži hostove koji su predmet konfiguracije. Hostove, odnosno virtuelne servere koji su predmet konfiguracije, treba dodati u ovu sekciju.

Automatizacijom pripreme SAP S/4 HANA platforme postiže se uniformna konfiguracija servera, ubrzavanje samog procesa njihove pripreme i kasnija jednostavna nadogradnja implementiranih servisa

Realizaciju servisa možemo podeliti na dva procesa. Prvi proces podrazumevao bi formiranje virtuelnih mašina i njihovo prilagođavanje potrebama samog projekta, dok bi drugi obuvatao specifične korake, karakteristične za implementaciju S/4 HANA platforme.

Kao primer za prvi proces možemo uzeti pripremu virtuelnih servera za potrebe SAP S/4 HANA instalacije na vSphere platformi i njihovo prilagođavanje. VMware vSphere platforma je uobičajena za realizaciju S/4 HANA servisa, i u virtuelnom okruženju i u on-premises okruženjima. U slučaju vSphere platforme, database i aplikativni serveri su realizovani kao virtuelne mašine, koje se pripremaju korišćenjem templejta na nivou vSphere platforme i taskova za automatizaciju, kojom se vrši priprema i prilagođenje virtuelnih servera.

Drugi proces podrazumeva specifične korake: konfiguraciju virtuelnih servera za potrebe S/4 HANA platforme i instalaciju database i aplikativnih komponenata korišćenjem unapred definisanih playbook-ova, kroz koje se varijablama mogu eksplicitno podesiti konfiguracioni parametri.

Ovakvim pristupom, odnosno automatizacijom pripreme SAP S/4 HANA platforme postižemo uniformnu konfiguraciju servera koji su deo SAP okruženja, ubrzavanje samog procesa pripreme servera i kasniju jednostavnu nadogradnju servisa koji su predmet implementacije.

Aleksandar Pavlović, Coming

The post Brže i lakše do SAP S/4 HANA platforme appeared first on Business&IT.

Trend raščlanjivanja monolitnih aplikacija na više manjih (mikro)servisa dao je vetar u leđa kontejnerima kao tehnologiji za razvoj, testiranje i isporuku aplikacija. Ovaj vid pakovanja i pokretanja aplikacija doneo je nove izazove u infrastrukturnom svetu i potrebu za tzv. kontejner orkestratorima – platformama za izvršavanje aplikacija u kontejnerima. U ovom segmentu rešenja defakto standard danas predstavlja Kubernetes, projekat otvorenog koda inicijalno razvijen od strane kompanije Google.

Cloud native aplikacije i infrastrukturna platforma zahtevaju rešenja za zaštitu podataka nove generacije, koja razumeju mikroservisnu arhitekturu i Kubernetes. Najveći izazov je to što aplikacije i njihove komponente više nisu spakovane u jasno ograničene „kutije“, poput fizičkih servera ili virtuelnih mašina, već se sastoje od većeg broja tesno povezanih elemenata, od kojih se ne moraju svi nalaziti unutar Kubernetes klastera.

Tako se izvan klastera tipično čuvaju perzistentni podaci aplikacija, koji se smeštaju na eksternim storidž platformama integrisanim sa Kubernetes-om. To mogu biti cloud servisi, poput AWS EBS ili Azure Disk Storage, kao i on-premises rešenja, poput VMware vSphere ili tradicionalnih FC/ iSCSI/NFS storidž sistema. Poslednja istraživanja pokazuju da danas više od polovine Kubernetes korisnika u kontejnerima pokreće stateful aplikacije, koje imaju potrebu za čuvanjem perzistentnih podataka.

Zato rešenja za zaštitu podataka u Kubernetes svetu moraju biti aplikativno, a ne infrastrukturno orijentisana, kao što je to tradicionalno bio slučaj. Ona moraju biti u stanju da otkriju sve komponente i zavisnosti jedne aplikacije, bekapuju ih na konzistentan način gde god da se nalaze i omoguće granularni restore podataka i pojedinačnih komponenata. U skladu sa cloud native prirodom okruženja, neophodno je i da poseduju API interfejse za integraciju sa alatima za automatizaciju i CI/CD procesima.

Veeam Kasten K10

Jedno od rešenja koje ispunjava sve navedene kriterijume je Veeam Kasten K10. U pitanju je proizvod koji je akvizicijom tokom 2020. godine postao deo familije Veeam rešenja za zaštitu podataka. K10 je platforma za upravljanje podacima koja je namenski razvijena za Kubernetes.

Prilikom pokretanja procedure oporavka, moguće je izvršiti kompletan restore, kojim se iz bekapa vraćaju svi elementi aplikacije, ili granularni restore, kod koga se mogu birati pojedinačni elementi aplikacije. K10 obezbeđuje granularnost na nivou Kubernetes resursa, a moguće je izvršiti i samo restore perzistentnih podataka aplikacije, čime se efektivno vrši samo oporavak podataka iz kreiranih storidž snepšotova.

Osim bekapa i restore opcije, K10 poseduje podršku za scenarije oporavka od katastrofe i mobilnosti aplikacija, odnosno njihove migracije između različitih Kubernetes klastera i platforsa ciljem da klaster operatorima pruži jednostavno, skalabilno i bezbedno rešenje za bekap, disaster recovery i migraciju mikroservisnih aplikacija.

K10 je mikroservisno organizovana aplikacija, koja se instalira pomoću jedne helm komande i izvršava unutar Kubernetes klastera u kome su aplikacije koje je potrebno bekapovati. Konfigurisanje rešenja može se vršiti preko web interfejsa za upravljanje, kao i pomoću API-ja. K10 proširuje Kubernetes API svojim specifičnim resursima, kao što su bekap polise i destinacije za smeštanje podataka, što omogućava kompletnu konfiguraciju rešenja kroz dobro poznate interfejse za komunikaciju sa Kubernetes klasterom, npr. pomoću YAML koda i kubectl alata komandne linije.

Tehnologija rada zasnovana je na tri ključne integracije. Prva je integracija sa Kubernetes-om koju K10 koristi kako bi otkrio sve elemente i zavisnosti koje poseduje aplikacija koja je predmet bekapa. Sledeća je integracija sa samim aplikacijama koje se izvršaju u kontejnerima, poput servera baza podataka, u cilju kreiranja aplikativno konzistentnih bekapa. I poslednja, ali ne i najmanje važna, jeste integracija sa eksternim storidž platformama na kojima su smešteni podaci, gde K10 u trenutku bekapa kreira snepšot (sliku podataka u određenom trenutku), koji se zatim može kopirati na bekap destinaciju.

Aplikacija za bekap može se selektovati na više načina – definisanjem Kubernetes namespace-a u kome se njene komponente nalaze ili Kubernetes labela koje one poseduju, čime se bekapuju svi Kubernetes objekti sa navedenom labelom, bez obzira na lokaciju. Opciono je u bekap aplikacije moguće uključiti i deljene klaster objekte od kojih aplikacija zavisi, poput storidž klasa i klaster rola.

K10: mogućnosti, integracija i podrška

Za aplikativnu integraciju K10 koristi open source framework pod nazivom Kanister, koji omogućava izvršavanje operacija koje su potrebne za pripremu aplikacija za bekap pre kreiranja storidž snepšota ili čak kreiranje bekapa aplikativnim alatima, bez korišćenja storidž snepšota. Među podržanim aplikacijama su Elasticsearch, različite relacione baze podataka, kao što su PostgreSQL i MySQL, kao i NoSQL rešenja poput MongoDB, Cassandra i Couchbase.

Snepšotovi kreirani za potrebe bekapa mogu ostati smešteni na produkcionoj storidž platformi, a svi ili deo snepšotova dodatno mogu biti i eksportovani na posebnu bekap destinaciju, što je i preporuka. Retencija, tj. vreme čuvanja bekapovanih podataka može se nezavisno definisati za snepšotove na produkcionoj platformi i eksportovane snepšotove, i izražava se u broju jednočasovnih, dnevnih, nedeljnih, mesečnih i godišnjih bekapa koje želimo da čuvamo. Kao bekap destinacije trenutno su podržani NFS i različiti tipovi objektnog storidža – S3, Google Cloud Storage i Azure Storage.

Prilikom pokretanja procedure oporavka, moguće je izvršiti kompletan restore, kojim se iz bekapa vraćaju svi elementi aplikacije, ili granularni restore, kod koga se mogu birati pojedinačni elementi aplikacije. K10 obezbeđuje granularnost na nivou Kubernetes resursa, a moguće je izvršiti i samo restore perzistentnih podataka aplikacije, čime se efektivno vrši samo oporavak podataka iz kreiranih storidž snepšotova.

Osim bekapa i restore opcije, K10 poseduje podršku za scenarije oporavka od katastrofe i mobilnosti aplikacija, odnosno njihove migracije između različitih Kubernetes klastera i platformi. U navedenim scenarijima obično nije moguće aplikaciju oporaviti sa identičnom konfiguracijom sačuvanom u bekapu, već je potrebno prilagoditi je novom okruženju. K10 podržava različite scenarije oporavka i migracije – između različitih namespace-ova unutar jednog klastera, između klastera, između klastera koji se izvršavaju pod različitim cloud nalozima ili projektima, između različitih cloud regiona, pa čak i različitih cloud platformi i Kubernetes provajdera.

Pored open source Kubernetes-a, K10 podržava praktično sve vodeće sertifikovane Kubernetes distribucije i cloud servise, uključujući Red Hat OpenShift, VMware Tanzu, AWS EKS, Azure AKS i Google GKE. Licenciranje rešenja bazira se na broju nodova na kojima se izvršavaju korisničke aplikacije (tzv. worker nodovi) u klasteru, s tim što je K10 potpuno besplatan bez ograničenja u funkcionalnostima za klastere sa do 10 worker nodova. Za demonstraciju K10 mogućnosti u vašem okruženju javite se našem timu Kubernetes inženjera na k8s@coming.rs. Srećno YAML-ovanje!

Nebojša Ilić, Coming

The post Zaštita podataka u Kubernetes okruženju appeared first on Business&IT.

Usponom digitalnih tehnologija dolazi do promene dinamike tržišta, ponajviše jednostavnim pristupom informacijama i olakšanim širenjem ideja na globalnom nivou. Konstantna fluktuacija verovatno je jedna od najbitnijih karakteristika današnjeg tržišta, pa tako u modernom poslovanju osetljivost i brza reakcija na promene dobijaju sve više na značaju.

Dinamika tržišta reflektuje se i na organizaciju celokupnog poslovanja kompanija, pa samim tim i na organizaciju kompanijske IT infrastrukture. Fleksibilnost i skalabilnost sada su nezaobilazni epiteti IT sistema. Samim tim i tehnologija virtuelizacije postaje nezaobilazan način organizacije infrastrukture, ne samo u slučaju velikih kompanija, već i kod onih srednje i male veličine. Dodatno, izmeštanje infrastrukture sa korisničke lokacije u tzv. javni cloud postaje sve popularnija opcija.

A šta sve podrazumevamo pod pojmom cloud i kako svoju infrastrukturu da izmestimo „u oblak“?

Šta je sve cloud?

U današnje vreme gotovo da nema osobe koja ne koristi cloud, bilo u privatne, bilo u poslovne svrhe. Svako od nas privatno ima barem jedan e-mail nalog kod nekog cloud provajdera ili koristi neku web aplikaciju. Cloud znači korišćenje servisa koji nam je potreban bez brige o tome gde i kako on funkcioniše u pozadini. Za nas je to sve „iza oblaka“.

Posmatrano iz perspektive poslovnog okruženja, u nekim kompanijama cloud je zastupljen možda minimalno, kao pojedinačni servis koji koristi nekolicina zaposlenih. U drugim kompanijama, pak, cloud je zastupljen značajno više, kao npr. kod kompanija koje imaju čitave IT sisteme izmeštene u oblak.

Korišćenje infrastrukture pružaoca cloud usluga donelo je mnogim kompanijama pre svega finansijske benefite u pogledu ulaganja u IT. Bez značajnih i dugoročnih investicija, kompanije dobijaju modernu i performantnu infrastrukturu, a resurse mogu povećavati i smanjivati po potrebi. Kako izmeštanje infrastrukture sa korisničke lokacije podrazumeva i izmeštanje odgovornosti njenog održavanja, tzv. javni cloud postaje sve popularnija opcija u modernom poslovanju.

Prvobitni oblik pružanja usluge javnog hostovanja infrastrukture, tzv. managed cloud podrazumevao je angažovanje pružaoca cloud usluga u administraciji na svim nivoima ispod operativnog sistema. Ovaj način pružanja usluga poseduje značajne prednosti u kompanijama čiji zaposleni nemaju iskustva u održavanju same infrastrukture. Korisnici pristupaju udaljeno samom operativnom sistemu ili aplikaciji instaliranoj na serveru i ne moraju da brinu o hardverskim performansama, bekapu, pa nekad čak ni o održavanju domenske infrastrukture.

Sa druge stane, zaposleni mnogih kompanija imaju dosta iskustva u administraciji na nivou virtuelizacione platforme, a ovakav oblik javnog hostovanja obavezuje ih da se po pitanju dodavanja ili oduzimanja resursa, pregleda performansi ili gašenja i paljenja samih virtuelnih mašina moraju obratiti pružaocu cloud usluga. Ovim se unosi nepotrebna komponenta u proces koji bi oni samostalno mogli da izvrše. To je bio jedan od glavnih razloga zbog kojeg su cloud provajderi počeli da omogućavaju administraciju virtuelnih cloud okruženja kroz web portal. Na ovaj način usluga koju cloud provajder nudi postaje transparentna za krajnjeg korisnika, uz dodatni nivo sigurnosti, kao što je kontrola pristupa i pristup logovima.

Korišćenjem infrastrukture pružaoca cloud usluga kompanije bez značajnih i dugoročnih investicija dobijaju modernu i performantnu infrastrukturu, a resurse mogu povećavati i smanjivati po potrebi

Migracija u cloud

A na koji način premestiti servise sa onpremises infrastrukture na cloud infrastrukturu? Migracija u cloud nije jednostavan, već veoma složen proces. Njegova složenost proporcionalna je složenosti IT sistema, a projekat se može podeliti na nekoliko faza.

1. faza Analiza postojećeg sistema i servisa. – Da li su serveri koji su predmet migracije fizički ili virtuelni i ako su virtuelni koji je hipervizor u pitanju? Da li se koristi neki bekap softver? Kako je organizovana mrežna infrastruktura na trenutnoj lokaciji, koji se opsezi koriste, koji serveri su publikovani i kakve su sigurnosne polise primenjene? Odgovori na ova pitanja diktiraju tok i tempo migracije. Recimo, na različit način se migrira fizički od virtuelnog servera. Čak i kada korisnik na primarnoj lokaciji ima virtuelne servere, procedura migracije nije jednosmerna. Ovde nam korišćenje dodatnih softverskih alata omogućava lakšu tranziciju u cloud. Iz ovog razloga su razni proizvođači softvera tokom godina prepoznali proces migracije kao ozbiljan zadatak i razvili alate koji omogućavaju lakši prelazak sa on-premises na cloud infrastrukturu. Takođe, neki alati, iako im to nije primarna funkcija, mogu igrati veliku ulogu pri migraciji, kao što je softver za bekap. Kao primer možemo navesti široko rasprostranjeno softversko rešenje za bekap Veeam Backup&Replication. Uz pomoć ovog alata inženjeri iz kompanije COMING uspešno su izvršili veliki broj migracija za svoje korisnike, bilo da su oni imali fizičke ili virtuelne servere.

2. faza Kreiranje detaljnog plana migracije svakog od servisa. – Nakon analize postojeće infrastrukture i servisa, dolazi na red planiranje same migracije. Trebalo bi početi od procene zaustavljanja u radu – koliko i kada kompanija može da pauzira određene servise. Nisu svi servisi iste kritičnosti i podjednako korišćeni. Određene aplikacije potrebne su nam samo u radno vreme, a neke gotovo uvek, kao što je npr. e-mail servis ili platforma za e-commerce. Pojedini servisi se mogu migrirati na aplikativnom nivou, bez zastoja. Naravno, uz podršku aplikativnih timova koji poznaju aplikaciju koja je predmet migracije. Plan treba napraviti pažljivo, tako da zastoj ne postoji ili bude minimalan. Takođe, treba planirati dežurstvo i potencijalni angažman tehničkih lica koja su nadležna za održavanje servisa. Naravno, osim plana migracije, bitno je napraviti i plan „povratka“, u slučaju da, iz nekog nepredviđenog razloga, migracija ne prođe uspešno.

3. faza Kreiranje korisničkog okruženja u cloud-u i uvezivanje svih potrebnih lokacija. – Nakon analize servisa, tj. celokupne korisničke infrastrukture, potrebno je napraviti arhitekturu cloud okruženja. Posebnu pažnju treba posvetiti mrežnoj arhitekturi i sigurnosnim polisama, koje treba da odgovaraju već postojećim na on-prem infrastrukturi.

4. faza Testiranje migracije. – Pre same migracije, važno je testirati ovaj proces migriranjem nekog testnog servisa. Na ovaj način se mogu identifikovati potencijalni problemi.

5. faza Migracija. – Nakon pažljivo kreiranog plana i testiranja, sam proces migracije predstavlja manji deo posla. Naravno, po migraciji uvek postoje šanse da se dese neke nepredviđene okolnosti, koje mogu zahtevati više vremena i ljudskih resursa.

6. faza Finalizacija i dokumentacija. – Nakon same migracije nastupa period određene adaptacije, što IT lica, što krajnjih korisnika. U ovom periodu bitno je pratiti rad servisa i – ukoliko je potrebno – izvršiti „kalibraciju“ promenom resursa ili nekim drugim izmenama.

Dokumentovanjem procesa migracije i pravljenjem preseka infrastrukture nakon migracije umanjuje se mogućnost da dođe do grešaka u budućim rekonfiguracijama.

Hrabro i analitično

Poslovanje svake kompanije se razlikuje od drugih, specifično je isto koliko i sama delatnost kompanije, njene procedure, politike i zaposleni. Na isti način se i na IT sistem svake od kompanija direktno preslikava specifičnost njenog poslovanja. Ipak, ma koliko sistem bio kompleksan i specifičan, uz detaljnu analizu i planiranje migracija servisa u cloud postaje bezbolan proces. Iako možda na prvi pogled deluje izuzetno izazovno, uz pažljivo planiranje slobodno i hrabro možemo krenuti napred. To the cloud and beyond!

Nevena Krunić, Coming

The post Migracija u Cloudu na bezbedan način appeared first on Business&IT.