Pilvipalveluiden toteutuksessa kaikkien ympäristöjen sijoittaminen samaan tiliin ja pilviresurssien manuaalinen provisiointi ovat kaksi yleistä kuolemansyntiä, joista mahdollisesti aiheutuvat ongelmat on hankala korjata myöhemmin.

Ensimmäistä pilvipalvelua pystyttäessä opeteltavaa on paljon. Kun projektissa täytyisi saada aikaan näkyvää tulosta, ei välttämättä ole aikaa tutustua kaikkiin parhaisiin käytäntöihin. Tietyt asiat kannattaa kuitenkin tehdä kunnolla alusta alkaen, jotta tulevaisuuden pettymykset, hallitsemattomat jatkokehityskustannukset tai jopa tietomurrot voidaan välttää.

Ohjelmistokehityksen luonteeseen kuuluu se, että jotkin projektin alkuvaiheessa tehdyt ratkaisut lukitsevat asioita. Joitakin teknisiä valintoja on helppo muuttaa jälkikäteen, mutta usein valituista ratkaisuista on vaivalloista siirtyä muihin ratkaisuihin. Tiettyjä infrastruktuuriin liittyviä muutoksia on erittäin hankala tehdä jälkikäteen, joten nämä asiat kannattaa laittaa kuntoon jo kehityksen alussa. Parhaiden käytänteiden vastaisesti toteutettu pilvi-infrastruktuuri voi kerryttää ohjelmistokehitysprojektiin jatkokehitystä häiritsevää teknistä velkaa, jonka purkaminen voi olla erityisen haastavaa.

Näitä eri asiakasprojekteista karttuneita kokemuksia kannattaa hyödyntää etenkin silloin, kun kyseessä on laaja pilvipalvelu, jolla on useita kehittäjiä, ja jonka elinkaari tulee olemaan pitkä. Tekstissä keskitytään antamaan vinkkejä kahden suurimman pilvipalveluntarjoajan (AWS & Azure) käyttöön.

Tee jokaiselle pilviympäristölle oma tili

Usein ohjelmiston kehitystä varten tarvitaan useampi pilviympäristö. Yleinen käytäntö on yksi testiympäristö ja yksi tuotantoympäristö. Testiympäristöä käytetään nimensä mukaisesti testaamiseen ja laadunvarmistamiseen, kun taas tuotantoympäristö palvelee todellisia loppukäyttäjiä. Joskus tarvitaan useampi testiympäristö, esimerkiksi yksi palvelemaan ohjelmistokehityksen tarpeita ja toinen esimerkiksi organisaation testikäyttäjiä varten.

Testiympäristöt tulee säilyttää mahdollisimman samanlaisina tuotantoympäristöön verrattuna. Tällä tavoin toimiessa tuotannossa tapahtuvat ongelmat voidaan toistaa myös testiympäristössä, mikä helpottaa oleellisesti ongelman selvittelyä. Kun testiympäristö ja tuotantoympäristö ovat samanlaisia, voidaan yleensä varmistua siitä, että testiympäristössä varmennettu ohjelmistopäivitys toimii myös tuotannossa.

Testiympäristö halutaan pitää samanlaisena kuin tuotantoympäristö, mutta samalla tulee varmistua siitä, ettei testiympäristö vaikuta tuotannon toimintaan – tai päinvastoin. Tätä varten pilvipalvelun testiympäristön ja tuotantoympäristön pilviresurssit tulee jollakin tapaa eriyttää toisistaan. Oleellista on myös, etteivät ohjelmiston eri ympäristöt jaa mitään pilviresursseja, vaan esimerkiksi testiympäristön tietokanta pyörii eri tietokantapalvelimella kuin tuotantoympäristön tietokanta.

Resurssien eriyttämiseen pilviympäristössä on useita tapoja

Pilvipalveluntarjoajilla on useita eri tapoja hallita ja eriyttää ympäristöjä toisistaan. Suosittu tapa on jakaa pilviresurssit resurssiryhmiin (Resource Groups). Tätä tapaa tukevat niin AWS kuin Azure. Näin toimiessa tuotantoympäristön vaatimat pilviresurssit ovat selkeästi eriteltynä testiresursseista. AWS ja Azure molemmat tarjoavat mahdollisuuden rajoittaa pääsyä resurssiryhmiin, mikä mahdollistaa esimerkiksi tuotantoympäristöpääsyn rajaamisen pienemmälle joukolle kuin testiympäristön. Muita vaihtoehtoja resurssien jaotteluun ovat esimerkiksi tagit, tai pilvipalvelukomponentin sisäisten staging/production -toiminnallisuuden käyttäminen (esimerkiksi Azure App Service staging slot).

Varmin tapa eriyttää ohjelmiston pilviympäristöt toisistaan on tehdä jokaiselle ohjelmiston pilviympäristölle oma tili. AWS-maailmassa tämä tarkoittaa yhtä AWS Accountia per ympäristö ja Azure-ympäristössä omaa tilausta (Subscription) jokaista ympäristöä kohden. Näin tuotantoon liittyviä pilviresursseja hallitaan yhdessä tilissä ja jokaista testiympäristöä omalla tilillään.

Ympäristö per tili tuo verrattomat hyödyt

Kun jokaisella pilviympäristöllä on oma tili, ei pääse syntymään tilannetta, missä testiympäristön pilviresurssit sotkeutuisivat tuotannon pilviresurssien kanssa. Ei ole ollenkaan tavatonta, että väärän konfiguroinnin takia testiympäristö on alkanut käyttämään tuotantoympäristön tietokantaa, mistä voi aiheutua haittaa myös tuotantoympäristölle. Ympäristöjen jakaminen omiin tileihinsä estää – tai ainakin merkittävästi vähentää – riskiä tämän kaltaisille ongelmille.

Pilviympäristöjen sijaitessa samassa tilissä annetaan varsin usein kaikille käyttäjille pääsy kaikkiin tilin pilviresursseihin. Vähimmän käyttövaltuuden periaatteen (least privilege) mukaisesti pääsyoikeus tuotantoresursseihin tulisi kuitenkin rajata vain niille käyttäjille, jotka sitä todella tarvitsevat. Kun pilviympäristöt sijaitsevat selkeästi eri tileissään, vaatii tuotantoympäristön pääsyoikeuksien lisääminen uudelle käyttäjälle tietoista päätöstä.

Ympäristö per tili -malli tuo isolaation lisäksi muitakin hyötyjä. Ympäristökohtainen laskutus on selkeästi saatavilla. Mikäli tarve esimerkiksi testiympäristölle poistuu, voidaan luottavaisin mielin poistaa koko tili ja olla samalla varmoja siitä, ettei tuotannon tai muiden ympäristöjen toiminta häiriinny. Pilvipalveluilla on myös tilirajoituksia (AWS, Azure), joiden rajat eivät tule nopeasti vastaan, kun ympäristöt hajautetaan eri tileihin.

Kun jokaiselle ohjelman vaatimalle pilviympäristölle tehdään oma tili, saattaa ilmetä muutamia haasteita. Käyttäjähallinta voi olla selkeämpää, mutta toisaalta samalle käyttäjälle täytyy antaa pääsyoikeudet useampaan eri paikkaan. Pilvipalveluiden laskutus perustuu tilin resurssien käyttöön, joten lähtökohtaisesti jokaiselle tilille täytyy käydä erikseen lisäämässä luottokortti. Ongelmaa helpottamaan on erilaisia ratkaisuja, kuten esimerkiksi AWS Consolidated Billing.

Provisioi pilviresurssit automaattisesti

Pilvipalveluntarjoajat tarjoavat kauniit käyttöliittymät, joiden avulla haluamansa pilvipalvelut saa nopeasti käyttöön. Näin toimiessasi saatat kuitenkin tehdä karhunpalveluksen itsellesi.

Uuden ohjelmiston kehityksessä rakennetaan yleensä ensiksi tuotantoympäristö. Myöhemmin – ehkä vasta kun ohjelmisto on julkaistu – havahdutaan testiympäristön tarpeeseen. Sen jälkeen saatetaan vielä huomata tarve useammalle eri testiympäristölle. Mikäli ohjelmisto on alunperin rakennettu pilvipalveluntarjoajan käyttöliittymiä hyödyntäen, voi täysin samanlaisen testiympäristön rakentaminen olla vaivalloista. Entäpä jos tuotantoympäristön infrastruktuuriin tehdään myöhemmin muutoksia – muistetaanko samalla päivittää kaikki testiympäristöt?

Isotkin organisaatiot, kuten Visma, ovat havahtuneet siihen, ettei pilvipalveluita enää kannata provisioida ja ylläpitää manuaalisesti. Googlen State Of Devops 2019 -tutkimuksessa todetaan, että suurin osa parhaiten suoriutuvista organisaatioista provisioi pilviympäristönsä automaattisesti. Pilviresurssien automaattinen provisiointi on yksi elementti, joka parantaa ohjelmistokehitystiimin tuottavuutta pitkällä aikajänteellä.

Infrastructure as Code vähentää virheitä ja parantaa tietoturvaa

Pilvipalveluympäristön automaattinen provisiointi ja ylläpitäminen koodaamalla (Infrastructure as Code, IaC) automatisoi pilviympäristön päivitykset, mahdollistaa katselmoinnin, pienentää inhimillisen virheen mahdollisuutta ja parantaa pilvipalvelun turvallisuutta. Mikäli hallinta pilviympäristöön menetetään esimerkiksi tietoturvapoikkeaman takia, voidaan vastaava ympäristö luoda tyhjästä uudestaan. Näin katastrofista toipuminen (Disaster Recovery) on merkittävästi nopeampaa, kuin tilanteessa, jossa pilviympäristöä on manuaalisesti ylläpidetty.

Infrastructure as Code lähestymistavassa määritystiedoston (template) avulla konfiguroidaan ja käynnistetään ohjelmiston tarvitsemat pilvipalvelut. Käynnistettävä palvelu voi olla mikä tahansa pilvipalvelu, esimerkiksi virtuaalikone, virtuaaliverkko, kuormantasaaja tai tietokanta. Kun määritystiedostoon tehdään muutoksia, heijastuvat muutokset pilviympäristöön. Tämä helpottaa oleellisesti toimintaa tilanteessa, jossa hallittavana on useita eri pilviympäristöjä. Parametrisoidun määritystiedoston voi ajaa automaattisesti kaikkiin ympäristöihin, mikä pienentää inhimillisen virheen mahdollisuutta huomattavasti. Pilviympäristön päivittäminen määritystiedoston kautta pitää huolta, että eri ympäristöt ovat mahdollisimman identtisiä. Tästä on erityisesti hyötyä ongelmanselvittelyssä ja tietoturvan kannalta - kaikki ympäristöt ovat lähtökohtaisesti suojattu yhtä vahvasti.

Suosittuja työkaluja pilviympäristön koodaamiseen ovat Cloud Formation (AWS), Azure Resource Manager (Azure), Cloud Deployment Manager (Google Cloud Platform) tai yleispätevä Terraform.

Haluatko tietää Vinctin pilvipalveluista? Aiheesta lisää löydät täältä