Vältä kaaos pilvimigraatiossa! Näillä ohjeilla laadit selkeän migraatiostrategian ja migraatiopolut jokaiselle tietojärjestelmällesi.
Uusien tietojärjestelmien rakentamisessa pilvipalvelut ovat monelle jo se ensisijainen vaihtoehto. Mitä enemmän pilven reunalla on liiketoimintalogiikkaa ja dataa, sitä suurempi alkaa olemaan paine siirtää myös olemassa olevat tietojärjestelmät pilveen. Paineen kasvaessa monessa yrityksessä nousee ilmoille kysymykset siitä, missä järjestyksessä ja miten yksittäiset tietojärjestelmät kannattaa pilveen siirtää?
Tässä artikkelissa käydään läpi priorisointikeinoja pilvimigraation suunnitteluun ja kuusi suosituinta tapaa edetä yksittäisten sovellusten migroinnissa. Artikkeli nojaa AWS:n 6R -migraatiostrategiaan, mutta on sellaisenaan hyödynnettävissä myös muiden pilvipalveluiden yhteydessä.
Strategia pilvimigraatiolle
Mitkä sovellukset ja missä järjestyksessä?
Kaksi suurinta tekijää, jotka vaikuttavat siihen, miten helposti tietojärjestelmät ovat siirrettävissä pilveen, ovat tietojärjestelmien ja niiden välisen arkkitehtuurin monimutkaisuus sekä tietojärjestelmiin liittyvät lisensointikiemurat.
Tietojärjestelmäkokonaisuudet, jotka on toteutettu palveluarkkitehtuuria noudattaen, ovat usein helpohkoja siirrettäviä. Tällöin kullakin tietojärjestelmällä on tyypillisesti selkeästi rajatut roolit/tehtävät kokonaisuudessa, ja järjestelmät on integroitu toisiinsa selkeän palveluväylän kautta. Tiedossa on esimerkiksi järjestelmien väliset rajapintakuvaukset ja ymmärrys siitä, mitkä integraatiot ovat reaaliaikaisia ja synkronisia, ja mitkä tietojärjestelmät keskustelevat keskenään esim. asynkronisten jonojen kautta.
Parhaimmillaan tietojärjestelmäkokonaisuus on kuin palapeli, jonka liitokset ovat näkyvissä, ja josta yksittäiset palat voidaan irrottaa ja korvata toisilla samanlaiset liitokset tarjoavilla osilla.
Spektrin toisessa päässä taas ovat esimerkiksi monoliittiset mainframe-tietojärjestelmät, joissa eri toiminnallisuuksien ja ominaisuuksien väliset integraatiot ovat piilossa koodien syövereissä ja kokonaisuuden toimintalogiikka on pitkälti vain kehittäjiensä ja heidän laatiman dokumentaation varassa.
Lisensoinnin osalta on hyvin tärkeä ymmärtää lisenssihinnoittelun peruslogiikka sekä vaatimukset lisenssinmukaisen käytön todentamisesta. Eli kertyykö lisenssikustannukset sisäisten ja/tai ulkoisten käyttäjämäärien mukaisesti, rajapintakutsujen määrien mukaan, vai onko lisenssi hinnoiteltu palvelimella olevan suorituskyvyn - esim. prosessoriydinten pohjalta. Lisäksi lisenssiehtoja tulee lukea kuin se kuuluisa piru raamattua sen osalta, mitä ehdot sanovat lisensoidun ohjelmiston ajamisesta pilvialustalla. Se kun voi olla eksplisiittisesti kiellettyä, tai asiakkaalla voi olla todentamisvelvollisuus siitä, kuinka monta prosessoriydintä palvelua on ajanut minäkin ajanhetkenä.
Kun nämä tekijät on selvitetty tietojärjestelmittäin, on aika sijoittaa palvelut seuraavaan nelikenttään:
Ja kuten arvata saattaa, kannattaa migraation suoritusjärjestystä lähteä edistämään oikean ylänurkan kautta.
Huom: Suosittelen kuitenkin parin ensimmäisen migraatiokohteen valitsemista oikeasta alareunasta. Migraatioprosessi on myös oppimisprosessi ja ensimmäisten migraatiotöiden kautta saat arvokasta tietoa, jonka pohjalta kunkin tietojärjestelmän migroimisen helppous kannattaa vielä uudelleenarvioida ennen laajempimittaista siirto-operaatiota.
Mihin pilveen?
Oikean pilven valintaan vaikuttaa useat näkökulmat:
Mitä pilvi on syönyt sisäänsä ja miten se vastaa yrityksemme käyttötarvetta?
Pilvipalveluiden tarjoamista kyvykkyyksistä löytyy paljon informaatiota, mm. NordHeron aiemmista artikkeleista. Pilvipalveluilla on toistaiseksi ihan oleellisia eroja sekä kyvykkyyksien lukumäärässä, yksittäisten kyvykkyyksien käyttömahdollisuuksissa, kyvykkyyksien yhteiskäyttömahdollisuuksissa sekä kyvykkyyksien teknisessä kypsyydessä/virheettömyydessä. Suosittelen siis perehtymään eri pilvipalveluiden syövereihin myyntimateriaalia syvemmällä tasolla asiantuntijan avustuksella. Ja hyvä pohdittava kysymys on, olisiko järkevä valita useampi kuin yksi pilvipalvelualusta.
Mitä pilvipalvelut maksavat?
Pilvipalveluiden hinnoittelussa on eroja ja hinnoitteluun perehtyminen kannattaa. Rohkenisin kuitenkin sanoa (ammatillista uskottavuuttani uhaten), että pilvialustan valinnassa pilvipalveluiden lisenssihintaa ei kannata tuijottaa liian tiukkaan eikä pitää sitä suurimpana valintakriteerinä. Miksi ihmeessä??
Tässä muutamia perusteluja:
- Pilvipalveluiden hinnat muuttuvat. Todennäköisesti hinnan muutoksia tulee useita kertoja vuodessa. Ja hinnoittelut ovat olleet ainakin edellisen kymmenen vuoden aikana lähes poikkeuksetta laskusuuntaisia.
- Et todennäköisesti osaa nyt kertoa, mitä kyvykkyyksiä tulet pilvestä käyttämään viiden vuoden kuluttua. Lähdet liikkeelle tietyllä setillä. Osaamisesi kasvaa vuosien myötä, samoin liiketoimintatarpeesi muuttuvat. Ja pilven kyvykkyydet kehittyvät.
- Pilvipalveluiden kustannustehokkuus on vain vähän etukäteissuunnittelua ja hyvin paljon jatkuvaa monitorointia ja optimointia.
Mihin meillä riittää osaaminen?
Tätä kysymystä miettiessä täytyy pitää jatkuvasti mielessä, katsotaanko ulos taustapeilistä vai tuulilasista. On oltava sinut itsensä kanssa siinä, että aiemmin tehdyillä investoinnillta osaamiseen ei välttämättä rakenneta tulevaisuutta. Oleellisempaa on siis katsoa henkilöstöään sillä silmällä, kenellä on kyky omaksua uutta ja ottaa vastuuta uuden rakentamisesta. On oltava avoin sille, että edessä on täysin uudenlaista maastoa, ja henkilöstö täytyy kouluttaa siihen. Antaa mahdollisuus irtautua vanhoista toimintamalleista ja fysiikan laeista.
Mitä kehittäjät arvostavat?
Tämä on mielestäni ehkä se oleellisin kysymys pilvialustaa valittaessa. On mahdollista ja jopa todennäköistä, että siirryttäessä omasta konesalista pilvipalveluihin myös ympärillä olevat it-kumppanit vaihtuvat. Pilvipalveluiden kanssa kehitystyö ei ole sellofaaniin pakattujen it-järjestelmien kilpailuttamista ja vesiputousmaisia toimitusprojekteja, vaan operaatiota voisi verrata matkaan valtameren yli purjelaivalla. Laiva tarjoaa erikokoisia ja eri ominaisuuksilla varustettuja purjeita, köysiä ja tykkejä (merirosvojen varalta tietysti). Silti miehistö hyvin pitkälle määrittää sen, miten perille päästään nopeiten ja turvallisesti. Kannattaa siis haastatella tekijöitä laajasti ja avoimesti, jotta saat mielikuvan siitä, minkä tyyppinen laiva kannattaa valita ja miten miehistö uskoo tulevan tarvetta erilaisille purjeille, köysille ja ammuksille.
Valitse laivaksesi sellainen alus, johon paras ja osaavin miehistö haluaa pestautua töihin. Haluat ehdottomasti palkata miehistön, joka tietää mitä on tekemässä.
Pilvimigraation 6R
Kun pilvimigraatiostrategiasi on siinä pisteessä, että olet valinnut pilvialustan ja olet alustavasti priorisoinut siirrettävät tietojärjestelmät siirron helppouden ja liiketoimintakriittisyyden näkökulmista, on aika lähteä arvioimaan yksittäisten tietojärjestelmien ja niiden sisällä olevien komponenttien (yksittäiset sovellukset, tietokannat, jne) migraatiovaihtoehtoja. Seuraavassa kuusi tyypillisintä polkua palvelujen migroimiseksi. Listaus tunnetaan AWS:n R6 -migraatiostrategiana (julkaistu 2016), joka puolestaan pohjautuu Gartnerin 5R -strategiaan (julkaistu 2011).
1. Rehosting - eli lift and shift
Tämä on yksinkertaisin migraatiostrategioista. Mikäli omassa konesalissa olevan tietojärjestelmän lisenssit on mahdollista siirtää käytettäväksi julkisella pilvialustalla, eikä järjestelmän arkkitehtuuriin ole tarvetta tehdä oleellisia muutoksia, voidaan palvelu siirtää pilvialustalle sellaisenaan. Migraatiotyössä voidaan käyttää pilvialustan tai kolmansien osapuolten tarjoamia valmiita migraatiotyökaluja, tai migraatio voidaan tehdä myös käsityönä konfiguroimalla uudet palvelimet itse pilveen. Jälkimmäisessä lähestymistavassa on se etu, että konfiguroimalla itse myös oma osaaminen kasvaa.
Rehostingilla voidaan saavuttaa parhaimmillaan kymmenien prosenttien kustannussäästöt verrattuna aiempaan palvelun tuotantomalliin, vaikka palvelun arkkitehtuuria ei optimoitaisikaan pilvialustalle. Toinen oleellinen hyöty rehostingissa on migraation nopeus - kokonaisarkkitehtuurin kehitys on tulevaisuudessa sitä helpompaa, mitä nopeammin kriittinen massa dataa ja liiketoimintalogiikaa on siirretty pilveen.
2. Replatforming
Tämä strategia on Rehostingin lähisukulainen. Palvelut migroidaan pilveen arkkitehtuurillisesti yksi-yhteen, mutta migraatiopolun aikana yksittäiset tietojärjestelmän komponentit voidaan korvata pilvioptimoiduilla tai kustannustehokkaammilla vaihtoehdoilla. Tyypillinen esimerkki on korvata tietojärjestelmän tietokantataso pilvipalvelun tarjoamalla natiivilla ja tarpeen mukaan skaalautuvalla tietokantaratkaisulla - esimerkiksi AWS:n pilvessä Amazon RDS:llä, tai sovelluspalvelinkerroksen korvaaminen open source -vaihtoehdolla, jotta palvelun logiikkakerrosta voidaan tarvittaessa skaalata pilvessä merkittävästi alhaisemmilla kustannuksilla.
3. Repurchasing
Tämä migraatiopolku tarkoittaa omassa konesalissa olevan tietojärjestelmän korvaamista pilvestä ostettavalla SaaS-ratkaisulla. Eli esim. CRM:n korvaaminen Salesforce-ratkaisulla, contact center -ratkaisun korvaaminen Amazon Connectilla, jne.
4. Refactoring/Re-architecting
Tässä migraatiovaihtoehdossa tietojärjestelmä rakennetaan uusiksi pilviarkkitehtuurin best practiceja noudattaen eli otetaan kaikki hyödyt irti pilvipalveluiden tarjoamista kyvykkyyksistä ja elastisuudesta. Tämä migraatiopolku on poluista usein se kallein vaihtoehto, mutta voi hyvinkin olla pitkässä juoksussa järkevin etenemismalli.
Tämä etenemismalli valitaan tyypillisesti silloin, kun järjestelmään kohdistuu paljon uusia liiketoimintavaatimuksia ja kehittämisen tarvetta tietojärjestelmältä vaaditaan aiempaa merkittävästi parempaa skaalautuvuutta, vikasietoisuutta tai suorituskykyä tietojärjestelmä on teknisesti tai muusta syystä elinkaarensa loppupäässä ja liiketoimintavaatimuksena on varmistaa palvelun elinkaaren jatkuvuus
Tätä migraatiomallia käytetään usein Rehosting- ja Replatforming -migraatiopolun kanssa, eli tietojärjestelmä nostetaan ensimmäisenä pikatoimenpiteenä pilveen ja tehdään kenties samalla yksinkertaisia sovelluspalvelin- tai tietokantatason muutoksia kustannusten tai suorituskyvyn takia, ja pilveen siirretystä “monoliitistä” aletaan tämän jälkeen pala palalta nakertamaan liiketoimintalogiikkaa irti ja korvaamaan esim. pilvinatiivilla mikropalveluarkkitehtuurilla.
5. Retire
Laajoissa tietojärjestelmäkokonaisuuksissa on usein ajan mukana kertyneitä sedimenttikerroksia, ja kun palveluita käydään läpi, voi useinkin löytyä yksittäisiä tietojärjestelmiä ja jopa niihin liittyviä business caseja, joiden tarve tulevaisuudessa voidaan kyseenalaistaa. Tällaisten tietojärjestelmien määrä voi olla jopa 10-20% kokonaisuudesta.
Hyvä periaate onkin jatkuvasti miettiä uuden tekemisen ja olemassaolevan laajentamisen lisäksi myös sitä, mitä voisimme vähentää tai jättää kokonaan tekemättä. Harjoituksessa voi käyttää esim. seuraavaa nelikenttää - periaatteena se, että aina kun luot tai lisäät asioita johonkin laatikkoon, on syytä miettiä, että voisitko poistaa tai vähentää jotain koordinaatiston vastakkaiselta puolelta.
6. Retain
Tässä vaihtoehdossa päätetään, että tietojärjestelmää ei migroida vaan se jatkaa toimintaansa nykyisellään. Syynä päätökseen voi olla esimerkiksi järjestelmän tai sen migroimisesta saavutettavan hyödyn vähäpätöisyys, tai vaikkapa järjestelmän elinkaaresta tai lisensseistä johtuva syy.
–
Pilvimigraatiokin on elefantti, joka pitää syödä paloissa. Ensin tulee laatia kunnollinen priorisoitu migraatiopolku, ja sen jälkeen oikeat ratkaisut yksittäisten tietojärjestelmien migroimiseksi. NordHero on pilviteknologioiden, sovellusarkkitehtuurin ja pilvitransformaatioiden asiantuntija - ota yhteyttä meihin, niin rakennetaan yhdessä yrityksellesi paras pilvimigraatiopolku!