Pilvistrategian laatiminen lähtee sovelluksista

Pilvistrategia
Sovellukset vaikuttavat pilvistrategian laatimiseen.

Nykyään lähes kaikilla yrityksillä alkaa olla kokemusta pilvipalveluiden käytöstä. Tosin suurin osa kokemuksista on SaaS-palveluista ja syystäkin. SaaS-palvelun ostaminen on paljon helpompaa ja nopeampaa kuin sovelluksen pystyttäminen omaan On premises -ympäristöön: Palvelun saa heti käyttöön ja kustannuksia syntyy vain sen mukaan, kuinka paljon käyttäjiä palvelulla on. Yhä harvempi yritys näkee lisäarvoa siinä, että omistaa sovelluksen. Arvoa on siitä, että sovelluksen saa nopeasti käyttöön ilman käyttöönottomaksuja ja siitä, että sovelluksesta maksetaan käytön mukaan. Jos käyttöä ei ole, palvelun voi irtisanoa.

Viime aikoina myös PaaS- ja IaaS -palveluiden kysyntä on kasvanut. Microsoft myy asiakkailleen Azure commitmentia, ja monessa organisaatiossa mietitään, mitä sillä oikein tehdään. Käsittelen tässä kirjoituksessa sitä, miksi pilvistrategian ja -arkkitehtuurin suunnittelussa pitää ottaa sovellusnäkökulma vahvasti huomioon. Olen käsitellyt pilvistrategian laatimista aiemmin yleisellä tasolla.

Lue vinkit pilvistrategian laatimiseksi

 

IT-ympäristöä voi analysoida monesta suunnasta. Yksi keskeinen näkökulma on järjestelmän saatavuus, eli kuinka varmasti laite, ohjelma tai palvelu on tarvittaessa käytettävissä. Perinteisessä yhdessä konesalissa sijainneessa konesalissa saatavuuden varmistaminen on lähtökohtaisesti helpompaa kuin erilaisiin SaaS-palveluihin hajautuneessa ympäristössä. Saatavuutta joudutaan miettimään viimeistään siinä vaiheessa, kun valitaan ostettavan pilvipalvelun palvelutasoa. Käytännössä pilvipalveluihin liittyvä problematiikka on monitahoisempi ongelma, kuin pelkkä saatavuustarkastelu. Yksi haaste liittyy hybridiympäristöön.

 

Lue  lisää jatkuvuussuunnittelusta

 

Hybridiympäristön haasteet

Jokaisessa organisaatiossa on sekä vanhoja On premises -sovelluksia, jotka on asennettu omaan tai palveluntarjoajan konesaliin sekä erilaisia SaaS-palveluihin perustuvia sovelluksia. Yhä useammin kokonaisuuteen liittyy myös useita erilaisia pilviekosysteemejä, kuten Microsoftin O365, Azure AD, ehkä jotain Azure, Amazonin AWS-palvelun komponentteja tai Googlen palveluita. Kun laaditaan pilvistrategiaa, pitää ottaa huomioon millaisia sovelluksia on käytössä. Siitä, että siirretään On premises -ympäristössä ajettava perinteinen sovellus julkiseen pilveen IaaS-ympäristön päälle, ei seuraa välttämättä mitään hyötyjä. Sovellus tarvitsee edelleen alleen palvelimen, käyttöjärjestelmän ja omat dedikoidut resurssit. Aiempaan arkkitehtuuriin verrattuna mukaan on vain tullut tietoliikenneyhteys pilveen ja vaikeammin hahmotettava tietoturvaympäristö.

Toteutus, jossa vain osa perinteisistä sovelluksista siirretään pilveen, saattaa lisätä lähinnä ympäristön monimutkaisuutta. Sovellukset juttelevat edestakaisin pilvi- ja On premises -ympäristöjen välillä. Tämä lisää latenssia, joka saattaa näkyä käyttäjille huonompana toimivuutena. Lisäksi sovellusarkkitehtuuri muuttuu haavoittuvammaksi, koska vikaantuvia kohteita on enemmän ja kokonaisuudessa on enemmän toimijoita ja rajapintoja. Perinteisiä sovelluksia kannattaa silti joskus viedä pilveen. Kun perinteisiä sovelluksia viedään pilveen, saavutetaan esimerkiksi seuraavia etuja:

  • IaaS-palvelussa palvelinalustat saadaan nostettua pystyyn sekunneissa tai minuuteissa ilman välikäsiä. Jos omassa tai palveluntarjoajan konesalissa joudutaan asentamaan virtuaalikoneita käsin, hidastaa se väkisin toimintaa. Aidossa pilvipalvelussa on aina automaattinen provisiointi, jonka avulla halutut palvelut nostetaan automaattisesti pystyyn. Tämä nopeuttaa uusien palveluiden pystytystä.
  • IaaS-palvelun komponenttipohjainen hinnoittelu mahdollistaa sovellusten todellisten kustannusten tarkan seuraamisen sen sijaan, että niitä ajetaan yrityksen sisäisessä infrassa, jossa kustannusten jakautumisen seuranta on hyvin vaikeaa. Kalliin IT-infran kustannusten kohdentaminen käytön mukaan onkin yksi selkeistä pilvipalveluiden hyödyistä.
  • Sovellusten kapasiteettia voi kasvattaa ja pienentää automaattisesti lisäämällä ja vähentämällä palvelun noodeja kuorman mukaan. Tästä puhutaan Scale out -arkkitehtuurina. Käytännössä esimerkiksi Windows Azuressa virtuaalikoneita voi nostaa pystyyn automaattisesti kun palveluun kohdistuu ennalta määritelty kuorma. Sama toimii toisin päin, eli palvelun vaatimaa kapasiteettia ja samalla sen aiheuttamia kustannuksia voidaan pienentää automaattisesti. Toinen vaihtoehto on aloittaa sovelluskehitys ja -testaus pienitehoisilla palvelimilla ja lisätä palvelinten muistia ja prosessoritehoa parantaa levykonfiguraatiota sitä mukaa, kun varsinainen käyttö lisääntyy. Tällöin puhutaan Scale up -arkkitehtuurista. Tämä saattaa olla realistisempi vaihtoehto sovelluksille, jotka eivät tue monien noodien käyttöä.

Niin kauan kun sovellukset asennetaan IaaS-palvelun päälle, pitää niitä ylläpitää kuten On premises -ympäristössä olevia sovelluksia. Käyttöjärjestelmien ja sovelluskomponenttien ylläpito on asiakkaan vastuulla. Pilven hyödyt lisääntyvät, jos sovellukset on rakennettu toimimaan pilvessä.

 

Pilvessä viihtyvät sovellukset

Pilvinatiivit sovellukset hyödyntävät monia uusia teknologioita.

Pilvipalveluista saatavat hyödyt kasvavat merkittävästi, kun sovellusarkkitehtuuria muutetaan. Rakentamalla sovellukset PaaS-palvelun (Platform-as-a-Service) päälle, saadaan sovelluksia julkaistua todella nopeasti. Esimerkiksi Azure Web App -palvelu hoitaa Azure käyttöjärjestelmän ja sovelluksen päivitykset, eikä loppuasiakkaan tarvitse tehdä muuta kuin keskittyä valmiin Web-sovelluksen käyttöön. Pilvestä voi ottaa käyttöön myös valmiiksi asennetun SQL-serverin tai sovelluskehitysympäristön.  PaaS-palvelu nopeuttaa kehitystä ja helpottaa ympäristön hallintaa huomattavasti, koska kaikki alemmat kerrokset (rauta, käyttöjärjestelmä, palvelinohjelmisto, verkot jne.) ovat pilvipalveluntarjoajan vastuulla. Asiakas konfiguroi vain suoraan itseään kiinnostavaa osuutta.

Microservicet eli mikropalvelut ovat perinteistä käyttöjärjestelmää kevyempi tapa toteuttaa palvelin. Mikropalveluiden idea on eriyttää palvelun toimintoja (prosesseja) omille mikropalvelimille. Näin yksittäisiä palvelimia on helppo päivittää ja nostaa pystyyn tarpeen mukaan. Microsoft-maailmassa Windows Server 2016 tuo mukanaan Nano Server -arkkitehtuurin, jossa palvelin on n. 90% kevyempi kuin perinteinen palvelin. Se nousee pystyyn huomattavasti nopeammin kuin perinteinen palvelin.

Containerit eli suomeksi kontit ovat toinen perinteistä arkkitehtuuria kevyempi tapa toteuttaa sovelluksia. Containerit jakavat käyttöjärjestelmän eli ne eroavat virtuaalipalvelimista, jossa jokaisella palvelimella on oma käyttöjärjestelmä. Vastineeksi saadaan hyvin kevyt yksikkö, joka nousee salamana pystyyn. Tämä mahdollistaa joustavat palveluiden päivitykset ja kuorman mukaan skaalaamiset. Containerien tietoturva taas poikkeaa olennaisesti virtuaalipalvelinten tietoturvasta. Tämän ja muiden tietoturvavaikutusten vuoksi pilvistrategiaa laadittaessa pitää tietoturva ottaa tarkastelussa vahvasti huomioon.

Deployment- ja/tai orkestrointi-työkalut, kuten Chef ja Puppet ovat kotonaan pilvimaailmassa. Ylipäätään ympäristön rakentaminen valmiilla templateilla ja koodilla tuo valtavasti etuja verrattuna perinteiseen käyttöliittymän kliksutteluun. Asennuksen skriptaamisen tuoma toistettavuus nopeuttaa ja yhtenäistää asennuksia. Tämän vuoksi ongelmatilanteissa riittää, että ympäristöön ajetaan viimeinen toimiva konfiguraatio. Tämän ansiosta IT-ympäristöjen hallinnan vaatima aika ja ihmistyö vähenee reilusti verrattuna  perinteiseen malliin. Tämä liittyy läheisesti DevOps-maailmaan, jossa sovelluskehitys ja infra-kaverit tekevät läheistä yhteistyötä. Toinen liittyvä alue on ns. Continuous Delivery, jossa sovelluksiin tehdään jatkuvasti pieniä päivityksiä harvoin tapahtuvien massiivisten päivitysten sijaan.

Pilviympäristöjen sovelluksille suomat mahdollisuudet ovat melkein loputtomat. Mutta kuten nähdään, suurimpien etujen saaminen ei onnistu vain asennuksen siirtämisellä pilveen, vaan vaatii usein sovelluksen uudelleen suunnittelun. Koska sovelluksia ei rakenneta uudelleen vain sen vuoksi, että sitä voisi ajaa pilvestä, tapahtuu muutos sovellusten luonnollisen kehityksen mukaan.

 

Sovellusarkkitehtuurin analyysi

Sovellusten kriittisyysanalyysi on osa kokonaisarkkitehtuurityötä.

Koska jokaisessa perinteisestä maailmasta tulevassa IT-ympäristössä on sekä perinteisiä sovelluksia, SaaS-sovelluksia, että jatkossa yhä enemmän uusia, pilviteknologioihin perustuvia sovelluksia ja komponentteja useista eri ekosysteemeistä, on sovellusten rakenteen, riippuvuussuhteiden ja roadmapin arviointi keskeinen osa pilvistrategian laatimista.

Sovellusarkkitehtuurin analyysissa arvioidaan sovelluksen kriittisyyttä liiketoiminnalle, kuvataan sovellusten välisiä riippuvuussuhteita, sekä niiden riippuvuuksia IT-infran suhteen. On tärkeää kuvata ketjuja loppukäyttäjistä perimmäiseen IT-infran komponenttiin. Tällaisen analyysin avulla voidaan nähdä, mitä sovelluksia kannattaa siirtää pilveen ja mitä kannattaa ajaa perinteisessä konesalissa. Samalla analyysi antaa arvokasta tietoa myös ICT-varautumisen näkökulmasta. Analyysin voi tehdä joko EA-työkaluun (Enterprise Architecture) tai Vision ja Power pointin yhdistelmällä, jos kokonaisarkkitehtuurityö ei ole lähtenyt isosti liikkeelle.

Sovellusten kriittisyysanalyysi on osa kokonaisarkkitehtuurityötä, jossa määritellään liiketoiminta-arkkitehtuurin lisäksi sovellusarkkitehtuuria ja tietoarkkitehtuuria. Liiketoimintatarpeet määrittelevät millaisia sovelluksia yrityksessä tarvitaan, ja sovellukset määrittelevät sen, millainen IT-arkkitehtuuri on paras ja millainen pilvistrategia palvelee parhaiten yrityksen liiketoimintatavoitteita. Tämän vuoksi voidaan sanoa, että pilvistrategian laatiminen lähtee sovelluksista.

 

Jos pidit tästä artikkelista, myös seuraavat artikkelit voivat olla kiinnostavia:

Tilaa uutiskirjeeni

Saat tiedon uusista artikkeleista suoraan sähköpostiisi.

Annan luvan tallentaa tietoni ja hyväksyn tietosuojakäytännön.