TL;DR – Helsinkiin tuleva Local Zone tarjoaa lähinnä matalampia viiveitä, eikä ratkaise datan sijainnin ongelmia. Valitettavasti GCP Haminakaan ei tätä tarjoa ja Microsoftin tulevan Suomi-regioonan kanssa menee useampi vuosi. Kiinnostavin ratkaisu onkin ehkä jakaa sovellus ympäristötasojen mukaan, eikä hakata päätänsä seinään jakamalla sovelluksen osia eri hosting-ympäristöihin.
—
Viime vuoden lopulla kuulimme kiinnostavia uutisia AWS:lta heidän vuosittaisessa re:Invent -konferenssissaan. AWS julkisti rakentavansa 32 uutta AWS Local Zonea ympäri maailmaa ja yksi niistä avautuisi Suomeen; ja tämä tapahtuisi jo vuoden 2022 aikana, eli melko pian.
Eli muutaman kuukauden päästä pääsemme siis käyttämään AWS:n pilvipalveluita Suomessa ja pitämään datan kotimaassa? Hmm, valitettavasti ei… Local Zone ei ole regioona ja ne tarjoavat hyvin rajatut palvelut, jotka rajoittuvat lähinnä virtuaalipalvelinten ja konttien ajamiseen.
Mikä AWS Local Zone sitten oikeastaan on ja mitä se tarjoaa erityisesti suomalaisille julkisen sektorin toimijoille?
Mikä on AWS Local Zone (LZ)?
AWS itse jaottelee Local Zonet reunalaskennan (Edge Computing) alle. Tärkeimpinä hyötyinä mainostetaan lyhyttä latenssia palvelun ja loppukäyttäjän välillä. Zonen sijoituspaikaksi on julkistettu Helsinki, joten pääkaupunkiseudulla pitäisi päästä arviolta noin 3-6 millisekunnin viiveisiin.
Pieni latenssi mahdollistaa esimerkiksi hyvän käyttökokemuksen nopeatempoisissa peleissä, ja esimerkiksi Supercell on ollut esillä yhtenä Local Zone -hyödyntäjänä. Toinen mainittu hyödyntämiskohde ovat ohjelmistot, jotka vaativat nopean yhteyden tietokantaan tai taustajärjestelmään. Näitä voivat olla esimerkiksi suunnitteluohjelmistot tai jotkin vanhemmat ”puheliaat” ohjelmistot nk. legacy-sovellukset.
Fyysisesti Local Zone tulee olemaan muutama räkki AWS:n omistamia ja hallinnoimia palvelimia jonkin paikallisen hosting-kumppanin konesalissa pääkaupunkiseudulla. Kapasiteetti tulee siis olemaan melko rajallinen ja etenkin poikkeustilanteissa se tulisi varmasti loppumaan, eli uusia työkuormia sinne ei saisi käyntiin, jos kapasiteetti loppuisi.
Local Zone kytkeytyy aina pääregioonaan, joka Helsingin tapauksessa on Tukholma. Paikallinen Local Zone (eu-north-1-hel-1a) luodaan osaksi Tukholman regioonan resursseja ja sitä hallinnoidaan sieltä.
Listaus tarjotuista palveluista löytyy tuotesivuilta (https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) ja sieltä kannattaa tarkastella rajallisempaa vaihtoehtoa. Laajemmat palvelut tarjoava Los Angelesin Zone on ymmärtääkseni jonkinlainen poikkeus tarjonnassa ja tukee alueen filmituotantoyrityksiä melkein mini-regioonan tyyliin.
Joudumme siis tyytymään pariin eri EC2-instanssityyppiin, EBS-levyihin (gp2), konttiajoalustoihin (ECS ja EKS) sekä kuormantasaajiin (vain ALB). Lisäksi verkkopuolella luvataan hyvät yhteydet pääregioonaan eli Tukholmaan, sekä mahdollisuus paikallisiin Direct Connect -yhteyksiin, joiden avulla saadaan yhteys esimerkiksi omiin on-prem -konesaleihin.
Local Zonet ja datan sijainti (Data Residency -vaatimus)
Helsingin Local Zone siis mahdollistaa laskennan Suomessa, mutta tallennuspuolella ollaankin isompien haasteiden edessä. Sekä objektitallennuspalvelu S3 että tietokantapalvelu RDS puuttuvat Zonejen palveluvalikoimasta. Näiden osalta ajatus tuntuu olevan nojata pääregioonan palveluihin, jolloin data olisi tallennettuna Ruotsissa. Ja jos sovelluksen data on jo rajojen ulkopuolella, niin helposti nousee mieleen, että siinä tapauksessa helpointa olisi sijoittaa koko sovellus Tukholmaan.
Sovelluksen tietokantaa olisi toki mahdollista ajaa itse joko virtuaalikoneessa (EC2) tai kontitettuna (ECS/EKS). Tämä lisäisi ylläpitotyötä, kun vastuu kannan saatavuudesta ja päivityksistä jäisi itselle hoidettavaksi. Lisäksi pitäisi ratkaista kannan varmistukset, jotka pitäisi viedä joko pääregioonaan tai johonkin on-prem -ympäristöön, sekä mahdollisesti kannan korkea saatavuus (englanniksi ”high availability” eli HA). Vielä ei ole tiedossa tuleeko Helsinkiin alkuun vain yksi saatavuusalue (1a) vai kaksi (1b), jolloin Suomessa tapahtuva HA-arkkitehtuuri onnistuu vain, jos alueita on kaksi.
Toinen vaihtoehto olisi rakentaa tilaton sovellus, jonka front-end ajetaan Local Zonessa, ja kaikki data tallennetaan on-prem -tietokantaan paikallisen Direct Connect -yhteyden taakse. Tässä hyödyt jäisivät ehkä kuitenkin puolittaisiksi ja olisi todennäköisesti vaivattomampaa viedä koko sovellus on-premiin. Toki frontendin skaalausta voisi parantaa LZ:n avulla, mutta vastavuoroisesti sovellus jakautuisi kahteen hosting-ympäristöön – mikä ei ainakaan helpottaisi sovelluksen kehittämistä ja ylläpitoa.
Miten sitten ratkaista ”datan pitää pysyä Suomessa” -vaatimus pilvessä?
Jos vaatimus on pitää data Suomessa joka tilanteessa, julkipilven hyödyntäminen on tällä hetkellä melko haastavaa.
Ensimmäisenä kannattaa pysähtyä pohtimaan voisiko vaatimusta kyseisen sovelluksen kohdalla laventaa pitämään data EU-alueella. Toki tämä ei aina ole mahdollista, esimerkiksi turvaluokitellun datan kanssa.
AWS:n palveluvalikoimasta löytyy myös toinen reunalaskentamahdollisuus, eli AWS Outposts. Nämä ovat fyysisiä laitteita, 2U-servereistä aina kokonaisiin räkkeihin, jotka sijoitetaan asiakkaan vuokraamaan konesalisijaintiin. Laitteiden vuokraamiseen täytyy kuitenkin sitoutua useaksi vuodeksi ja vuokrahinnat ovat sen verran kalliita, että investoinnin perustelu voi olla haastavaa. Kukaan Suomessa ei ole ainakaan julkisesti mainostanut hankkineensa Outposteja, joten niitä tuskin on käytössä testilaitteita lukuunottamatta.
Googlen Haminan palvelinkeskusta on myös mainostettu kotimaisena vaihtoehtona. En ole varsinaisesti Google Cloud Platform (GCP) -asiantuntija, mutta kuulemani mukaan tilannetta tarkemmin selvittäneet ovat joutuneet pettymään. Useampi palvelu on kai rakennettu globaaliksi, eli data liikkuu myös Haminan ulkopuolelle, ja ”Suomesta tulee saari” -skenaariossa palvelut puolestaan lakkaavat toimimasta kun yhteydet globaaliin hallintakerrokseen katkeavat. Lisäksi ylläpidon henkilöstöä on ympäri maailmaa (”follow the sun” -malli) ja heitä ei ole voitu turvaselvittää suomalaisten tai eurooppalaisten mallien mukaan; mikä toki taitaa olla haaste kaikkien julkipilvien kanssa.
No, Microsoft sentään julkaisi alkuvuonna, että saamme Suomeen oman paikallisen Azure-regioonan. Regioonan muodostavat kaksi datakeskusta ovat vielä kuitenkin kaavoitusvaiheessa ja avaamisen jälkeenkin, korkeamman tason palveluja uusiin lokaatioihin on yleensä saanut odottaa vielä vuoden verran. Arviolta 3 vuoden päästä Suomi-regioonaa pääsisi siis kunnolla hyödyntämään. Tässäkin tapauksessa ylläpitohenkilöstöä olisi varmasti myös Suomen ulkopuolella.
Yhteenveto
Helsingin Local Zone tuo siis kyllä uutta AWS:n tarjontaan, mutta ei valitettavasti kuitenkaan ratkaise julkisen sektorin haastetta – pilven joustavuutta haluttaisiin hyödyntää, mutta datan pitäisi – ainakin osassa sovelluksista – pysyä joka tilanteessa Suomessa.
En myöskään usko, että AWS tekisi päätöstä rakentaa paikallinen AWS-regioona Suomeen lähivuosina. Enemmänkin Local Zonet laajentavat nykyisten regioonien kattavuusaluetta, mutta hyödyt ovat viiveiden laskussa eivätkä datan sijainnin rajoittamisen mahdollistamisessa.
Ehkä järkevimmäksi vaihtoehdoksi täyttää vaatimukset ja kuitenkin hyödyntää julkipilveä, jää jakaa sovellus ympäristötasojen eikä sovelluksen osien hosting-lokaatioiden näkökulmasta. Käytännössä tämä tarkoittaa Dev- ja Test-ympäristöjen ajamista julkipilvessä ja tuotantodataa käsittelevien QA- ja Prod-ympäristöjen jättämistä on-premiin. Työkuormien siirrettävyyden voi toteuttaa ne Docker-kontteina Kuberneteksen päällä ja DevOps-automaatiota voi hakea sekä pilvessä että on-premissä toimivilla työkaluilla.
Me Goforella olemme paljon tekemisissä julkisen sektorin pilvitekemisen kanssa ja kerromme mielellämme vaihtoehdoista tarkemmin. Kerro, jos jokin jäi askarruttamaan aiheen tiimoilta tai jätin jonkin relevantin vaihtoehdon käsittelemättä.
