Kolme tapaa siirtää sovellus pilveen

Erilaisia digitaalisia sovelluksia siirretään kiihtyvällä tahdilla pilveen. Sovelluksen pilvisiirto voidaan kuitenkin tehdä usealla eri tavalla. Esittelen näistä tavoista kolme yleisintä tässä blogissa. Kerron myös näkemykseni niiden eduista ja haitoista.

Kaikissa tavoissa on omat hyvät ja huonot puolensa ja pilveen siirtäminen voi usein olla järkevää millä tahansa näistä tavoista. Toiset niistä hyödyntävät kuitenkin pilven tarjoamia etuja paremmin kuin toiset.

Tarkastelen tässä kirjoituksessa sekä Amazon Web Servicesin (AWS) ja Google Cloud Platformin tuotteita esimerkinomaisesti, mutta palvelut esimerkiksi Microsoftin Azuressa ovat hyvin samankaltaisia.

Tapa 1: Suoraviivainen pilvimigraatio migraatiotyökaluilla

Palvelun siirto pilveen suoraviivaisimmillaan tapahtuu siirtämällä palvelut palvelin kerrallaan pilvessä ajettaviin palvelimiin. Todellisuudessa kaikki nykyaikaiset hosting-palvelut käyttävät virtuaalipalvelimia myös ns. ei-pilviympäristössä, eivätkä pilvessä pyörivät palvelimet (ns. compute-resurssit) eroa niistä muulla merkittävällä tavalla kuin palvelinten itsepalvelulla ja monitorointi- ja automatisointimahdollisuuksilla. Palvelimella pyörivälle ohjelmistolle nämä asiat eivät pääasiassa näy mitenkään.

Esimerkiksi AWS tarjoaa palvelinresurssien siirrolle AWS Server Migration Servicen, joka siirtää olemassaolevat palvelimet suoraan AWS:n EC2 virtuaalipalvelimiksi. Migraatio on suoraviivainen ja se voidaan tehdä jossain määrin ymmärtämättä täysin mitä palvelussa pyörivä sovellus tekee.

Mikäli palvelut ovat joko suorituskykysyistä tai korkean tavoitettavuuden (HA) takia jaettu useammalle palvelimelle, tarvitsevat ne usein kuormanjakopalveluita ja mahdollisesti jakavat tiedostoja tai tietokantoja palvelinten välillä. Kuormanjakopalvelut saadaan pilvestä palveluna, mutta tietokantojen synkronointi kahden normaalin laskentaresurssin välillä pitää tehdä itse. Tämä toki on epäilemättä jo tehtynä näissä olemassa olevissa palvelimissa, mutta synkronoitujen tietokantojen siirto vaatii silti erityisosaamista.

Palvelinten siirron yhteydessä on aina suositeltavaa rakentaa automaatio palvelinten rakentamiselle pilveen. Kuitenkin migraation yhteydessä ollaan usein tilanteessa, jossa palvelimilla ajettavan ohjelmiston asennus ei ole automatisoitua ja siksi palvelinten luomisen automatisointi ei anna juurikaan hyötyjä.

Suoraviivainen pilvimigraatio migraatiotyökaluilla on hyvin tyypillinen tapa tehdä pilvisiirtoja, mutta lähtökohtaisesti se ei hyödynnä pilven tarjoamia etuja, kuten automatisointia tai infrastruktuuripalveluja.

Hyödyt:

Siirtoon ei vaadita yhden palvelimen yhteydessä paljoakaan erityisosaamista
Siirtoon ei tarvita osaamista palvelimella ajettavasta ohjelmistosta
Halvin tapa siirtää palvelut pilveen
Pilven kustannukset ovat ennakoitavissa

Haitat:

Tapa ei varsinaisesti hyödynnä mitään pilven erityisominaisuuksia tai etuja

Tapa 2: Sovelluksen kontittaminen (containers) konttiorkestraatioon

Ensimmäinen enemmän pilven palveluja hyödyntävä vaihtoehto siirtää palvelu pilveen on kontittaa palvelu, ja rakentaa konteista konttiorkestraation kautta kokonaisuus, johon voidaan tarvittaessa lisätä pilven infrastruktuuripalveluita.

Kontit ovat nykyaikainen virtualisointitapa, jossa sovellus eristetään ilman, että sen yhteyteen tarvitaan kokonaista käyttöjärjestelmää. Se on siis kevyempi tapa virtualisoida ja konttien yhteydessä virtualisoidaan tyypillisesti pienempiin, eristettyihin kokonaisuuksiin, joita ajetaan suurempia määriä kuin virtuaalikoneita samoilla resursseilla.

Kontteja voidaan ajaa erikseen useissa pilvipalveluissa, mutta nykyään järkevintä on kuitenkin rakentaa samassa yhteydessä konttiorkestraatio, eli ohjata kontteja tarkoitukseen kehitetyllä hallintaohjelmistolla. Suosituin näistä on Googlen kehittämä Kubernetes. Kubernetes, kuten kilpailijansa (Docker Swarm, AWS Fargate), hoitaa konttien automaattisen asentamisen, skaalaamisen ja käytönaikaiset palvelut kun käytössä on useita alustakoneita, joilla kontteja ajetaan.

Kontittamisessa nykyisten palveluiden eristettävät palvelut siirretään omiin kontteihinsa. Tyypillisesti yksittäisen palvelimen ajamista palveluista syntyy useampia kontteja. Erillisiksi palveluiksi voidaan katsoa itse sovellusohjelmisto, varusohjelmistot erikseen, sekä mahdolliset kytkentäkontit pilven infrastruktuuripalveluihin, esimerkiksi GCP:n Cloud SQL Proxy, jota käytetään kun halutaan käyttää Kubernetes-ympäristössä GCP:n infrastruktuuripalveluna tarjottua SQL-tietokantapalvelua.

Kontittaminen ei ole täysin suoraviivaista, mutta sen kustannukset ovat ammattilaisten käsissä varsin kohtuulliset. Enemmän mietintää vaatii pilveen rakennettavan kokonaisuuden arkkitehtuuri, jossa olennaisena osana on konttien erottaminen, riittävän alustakapasiteetin valinta, sekä valinta konttien ja pilven infrastruktuuripalveluna tarjottavien välillä.

Kontittamisen jälkeen lopulta koko kokonaisuus automatisoidaan, eli pyritään rakentamaan koko infrastruktuuri koodiksi (IaC, Infrastructure as Code). Tämä vaihtelee hieman eri pilvipalvelujen välillä, mutta noudattaa pääosin samaa kaavaa. Lisäksi tarjolla on ns. pilviagnostisia vaihtoehtoja, kuten Terraform.

Hyödyt:

Kokonaisuus käyttää hyvin pilven erityisominaisuuksia ja etuja
Konttikokonaisuus on kohtuullisesti siirrettävissä eri pilvipalvelujen välillä, hieman riippuen infrastruktuuripalvelujen valinnoista

Haitat

Konttikokonaisuuden luonti ja ylläpito vaatii erityisosaamista
Palveluiden kontittaminen vaatii kohtuullista ymmärrystä sovellusohjelmistojen toiminnasta
Pilvipalvelun käyttökustannusten arviointi voi olla haastavaa etukäteen

Tapa 3: Sovelluksen purkaminen pilvinatiiviksi

Toinen tapa, jossa hyödynnetään pilven tarjoamia palveluja ehkä parhaiten, on sovelluksen purkaminen pilvinatiiviksi. Pilvinatiiviudella tarkoitetaan tässä sovellusta, joka rakennetaan pilven tarjoamista infrastruktuuripalveluista kokonaisuudeksi.

Pilvipalveluiden tarjoamista infrastruktuuripalveluista voidaan katsoa tähän kategoriaan kuuluvan myös erilaiset alusta palveluna -palvelut (PaaS, Platform as a Service), kuten AWS:n Elastic Beanstalk, GCP:n App Engine tai Azuren App Service.

Tyypillisesti pilvinatiivit sovellukset hyödyntävät laajasti pilvien infrastruktuuripalveluita. Paras hyöty pilven käytöstä saadaan ns. mikropalveluarkkitehtuuriin perustuvilla sovelluksilla, jossa erilliset mikropalvelut voidaan toteuttaa jokainen parhaiten tarpeeseen soveltuvalla infrastruktuuripalvelulla ja eri palvelut saadaan liitettyä yhteen esimerkiksi pilven tarjoamalla viestipalveluilla, kuten AWS:n Simple Queue Service.

Mikropalveluiksi purkaminen ei siis ole välttämätöntä, mutta sen voi tehdä vähitellen, jossa palvelu kerrallaan puretaan niitä erillisiksi kokonaan palvelittomasti (serverless, Function as a Service eli FaaS) ajettavaksi serverless-alustalle, kuten AWS:n Lambda tai GCP:n Cloud Functions tai isommissa kokonaisuuksissa aiemmin mainittuihin alusta palveluna -palveluihin (PaaS).

Tässäkin vaihtoehdossa koko ympäristön asentaminen automatisoidaan pilven omilla automatisointityökaluilla (IaC), kuten AWS:n CloudFormation tai pilviagnostisilla työkaluilla kuten Terraform.

Hyödyt:

Hyödyntää täysin kaikkia pilvipalvelujen etuja
Koko järjestelmä voidaan rakentaa on-demand mallille, jolla voidaan tehdä kustannustehokkaita palveluita.
Skaalautuu suoraan pilven tarjoamilla palveluilla

Haitat

Komponentit vaihtelevat pilvipalveluiden välillä, joten palvelun siirtäminen pilvestä toiseen voi olla työlästä
Pilvipalvelun käyttökustannusten arviointi voi olla hyvin vaikeaa etukäteen

Lopuksi

Järkevin vaihtoehto on siis valittava sekä tavoitteiden että siirrettävän palvelun perusteella, eikä kustannuksia tai pilveen sitoutumista kannata jättää pohdinnan ulkopuolelle. Palveluita voi myös ensin siirtää suoraviivaisella migraatiolla ja siitä sitten joko konttiorkestraatioon tai pilvinatiiviin suuntaan myöhemmin.

Riippumatta siirtotavasta, me Exovella autamme mielellämme sinuakin löytämään oikean tavan hyödyntää moderneja pilvipalveluita. Jos mietityttää miten voisimme auttaa juuri sinua, ota yhteyttä kalle.varisvirta@exove.com niin keskustellaan vaihtoehdoista lisää.