Pohdintoja huoltovarmuudesta pilvipalveluiden keskellä

Viimeisen vuoden aikana olen törmännyt useammin keskusteluun ja pohdintoihin huoltovarmuudesta. Tämä toki jo ennen Venäjän hyökkäystä Ukrainaan ja sodan aiheuttamia huolia ja muutoksia turvallisuustilanteeseen. Kevään mittaan maailman turvallisuustilanteen muutosten myötä keskustelut toki ovat vakavoituneet ja ehkä myös hieman konkretisoituneet. 

Huoltovarmuudella tässä kontekstissa viitataan usein hieman holistisemmin kahteen asiaan: organisaation tarjoamien palveluiden jatkuvuuteen poikkeustilanteissa, ja operatiivisen toiminnan takaamiseen ja sen myötä poikkeustilojen ennakointiin. Pohdin huoltovarmuutta aktiivisesti nimenomaan pilven infrastruktuuripalveluiden osalta, ja pyrin tähän artikkeliin tiivistämään olennaisia havaintoja matkan varrelta. 

Lähdetään siitä, että yrityksellä tai organisaatiolla on usein käytössä nyt jo klassinen hybridimallin arkkitehtuuri: paikallinen Microsoftin Active Directory ja tavalla tai toisella pilvi-identiteetit replikoituna Azure Active Directoryyn. Identiteettien federointi alkaa jo (osin) olla taustapeilissä, mutta toki valikoiduissa tilanteissa yhä asiallinen vaihtoehto. Huoltovarmuus-huolet ja aprikoinnit kumpuavat usein muutamasta selkeästä näkökulmasta: 

1. Kykeneekö yritys tarjoamaan (yhteiskunnalle, asiakkaille tai muille sidosryhmille) kriittisiä palveluita, jos nykyiset konesali- ja alustapalvelut ovat Suomen ulkopuolella?
2. Tarvitaanko standby-tilaan infrapalveluita odottamaan yliheittoa pilvestä ’takaisin’ paikalliseen konesaliin? Tämä siis sellaisessa poikkeustilanteessa ennakoitu toimenpide, että datat ja palvelut on pakko saada kotimaan maaperälle.
3. Riittääkö paikallinen vara-Active Directory huoltovarmuuden saavuttamiseksi?
4. Miten oikeastaan pitäisi palvelut rakentaa huoltovarmuuden huomioimiseksi?
5. Vaikuttaako multicloud-strategia (tai sen puute) tähän?

 Usein keskustelun voi hahmottaa kahdelta puolelta – puhtaasti teknisenä demarkaatio-ongelmana, tai hallinnollisena ja mahdollisten direktiivien tai ohjeistusten kautta tapahtuvana velvoitteena. En ole tarpeeksi kykenevä ottamaan syvällisesti kantaa jälkimmäiseen. Sen sijaan tekniseen, arkkitehtuurilliseen ja kustannustekniseen hahmotteluun isosti kyllä. Ja mikä ettei, molemmat puolet täytyy kokonaisuudessa huomioida. 

Huoltovarmuuspohdinnoissa on teknisessä implementaatiossa käytännössä neljä alustapalveluun soveltuvaa vaihtoehtoa: Amazon Web Services, Google Cloud, Microsoft Azure tai ”joku oma” hosting-ympäristö – joka toki voi olla paikallinen konesalikumppani Suomesta.

Azurea ei toistaiseksi saa Suomesta suoraan – lähin datacenter löytyy Ruotsista. Googlelta löytyy Suomesta kohtuullisen hyvin kyvykkyyksiä tänä päivänä. AWS:n osalta vastaavaa mahdollisuutta ei ainakaan vielä löydy. Azure on tulevina vuosina tulossa paikallisesti saataville, mutta tarkkaa aikataulua ei vielä ole tiedossa. Karkeasti ennakoisin tällä hetkellä suunnilleen vuotta 2025.

Raaka infra, kuten Active Directory, mahdolliset virtuaalipalvelimet ja näiden pyörittämät liiketoimintapalvelut ja sovellukset on semi-helppoa replikoida lämpimäksi odottelemaan huoltovarmuuden puitteissa kotimaahan. Ei toki triviaalia, ja jokainen ympäristö on aina uniikki, mutta sinänsä tämä tekninen ongelma on jo ratkaistu useaan otteeseen. Nyt tulee huomioida identiteettien hallinta – Azure Active Directory on todennäköisimmin lähivuosina näiden master. Sen sijaan huoltovarmuuden puitteissa rakennettu Active Directory tuskin on replika missään merkittävässä mittakaavassa. Identiteettien ja mahdollisten salaisuuksien replikointi kannattaakin huomioida ja testata etukäteen – eikä yliheittotilanteessa harjoitellen. 

Sovellukset ja niiden tarvitsemat muut tukipalvelut ja datat tulee jotenkin huolehtia tähän paikalliseen ympäristöön. Siinä missä Active Directory on luontevaa pyörittää virtuaalikoneilla, sovellukset voivat vaatia hyvinkin moderneja ajoympäristöjä joita omassa konesalissa on teknisesti mahdotonta toteuttaa. Paikallispilvessä tilanne on yleensä selkeämpi – ehkä replikoidaan konfiguraatiot automaation ja skriptien avulla, ja datat sun muut voidaan replikoida hissukseen taustalla määräajoin. Olen ilahtunut siitä, että usein container-pohjaisten ratkaisujen yhtenä huomioitavana asiana arkkitehtuuria suunniteltaessa ei ole unohdettu siirrettävyyttä. 

Ja sitten se tärkein – tietoturva. Se mikä on suojattu pilvialustalla, tulee suojata myös paikallisesti – tai yliheiton jälkeen vikatilanteessa paikallisemmassa pilvessä. Kun on kiire, tästä usein tingitään ensimmäisenä. ”Jos nyt nopeasti loggaan domain adminina sisään tästä kahvilasta..” ei varmasti murenna kaikkea, mutta antaa jo hyvän lähtöponnistuksen tuleville ongelmille.Lopuksi huoltovarmuutta pohtiessa kannustan kriittisesti miettimään ja määrittelemään mitkä palvelut, teknologiat ja tiedot on välttämätöntä pilven vikaantuessa saada takaisin käyttöön. Aika usein kymmenistä virtuaalipalvelimista tai tusinasta kontteja koostuva ratkaisu onkin ihan asiallista ajaa mini-versiona tylsästi ilman Kubernetes-klustereita.

Heräsikö ajatuksia tai kysymyksiä? Sparraamme mielellämme aiheen tiimoilta!