Rakenna pilvipalvelu alusta asti oikein

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ä

Lisätietoja
Tagit
Erikoisosaaminen
![]() |
Ohjelmistokehitys |
![]() |
Pilvipalvelut / SaaS |
Toimialakokemus
![]() |
IT |
Teknologia
![]() |
Amazon Web Services |
![]() |
Azure |
Vincit - Asiantuntijat ja yhteyshenkilöt

Jarkko Järvenpää
Chief Growth Officer
![]() |
|
Experienced in solution selling, sales and marketing in general, and business and organization development. Interested in all things digital and how to create a better world with .. | |
jarkko.jarvenpaa@vincit.fi +358 40 722 9656 |
|
![]() ![]() |
Vincit - Muita referenssejä
Vincit - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Valu Digital Oy - WordPress Developer
- Vaimo Finland Oy - Backend developer
- Rekrytointi.com - C++/C -ohjelmistokehittäjä
- Rekrytointi.com - Tuotetukiasiantuntija (ILS-asiantuntija)
- Rekrytointi.com - Rekrytointi.com tuotepäällikkö
- Fastroi Oy - Henkilöstöpäällikkö
- Experis IT - Graduate-ohjelma .NET Full Stack, Experis Academy
Premium-asiakkaiden viimeisimmät referenssit
- Agenda Helsinki oy - solutos.fi WordPress-verkkosivu
- Digia Oyj - Case Ylva: NetSuite toi ratkaisun Ylvan liiketoiminnan erityispiirteisiin ja automatisointitarpeisiin
- Valu Digital Oy - Haaga-Helia ammattikorkeakoulun julkaisuperhe käyttää Valu Search -hakua
- Nextcon Finland Oy - Mela on valinnut Nextcon Finland Oy:n kumppanikseen käyttöpalveluiden kilpailutuksen konsultoinnissa
- Nextcon Finland Oy - DigiFinland Oy on valinnut Nextcon Finland Oy:n testauspalveluiden kumppanikseen
- Nextcon Finland Oy - Kilpailu- ja kuluttajavirasto valitsivat Nextconin asiantuntijat tukemaan verkkopalvelun kilpailutuksessa
- Visma Software Oy - Case HM-Tilipalvelu: Fivaldi on turvallinen ja kannattava tapa asiakkaiden sähköistämiseen
Tapahtumat & webinaarit
- 20.04.2021 - Mepco-ratkaisulla tarjoat palkkojen lisäksi HR-ominaisuudet loppuasiakkaille
- 22.04.2021 - How to automate vendor bill process in NetSuite?
- 22.04.2021 - Enfo Success Day
- 26.04.2021 - Arrow Late Afternoon Show with Kari Ketonen
- 27.04.2021 - Harness your NetSuite and other data to create insights with Staria BI & Planning
- 28.04.2021 - Valjasta data käyttöösi Staria BI & Planning -ratkaisun avulla
- 06.05.2021 - Virtuaalinen yhteistyö teollisuudessa, huollossa ja kunnossapidossa - Teollisuuden etätukiratkaisu!
Premium-asiakkaiden viimeisimmät bloggaukset
- Lemonsoft Oy - Lue 10 vinkkiä parempaan projektisuunnitelmaan!
- Efima Oy - Ratkaisukonsultti testaa: Microsoft Dynamics 365 Supply Chain Managementin uusi varastonhallintasovellus
- Vaimo Finland Oy - 5 VINKKIÄ, KUINKA OPTIMOIDA DIGITAALINEN ASIAKASKOKEMUS
- Invenco Oy - Osaavissa käsissä Power BI taipuu myös talousraportointiin
- Nextcon Finland Oy - Tekijät töiden takana | Juttusarja Nextconin ammattilaisista
- Vincit - Verkkoasiointi, mobiilimaksaminen ja saavutettavuus – joko nämä ovat yritykselläsi hallussa?
- Vaimo Finland Oy - ASIAKASPITOSTRATEGIAT: 8 TAPAA PITÄÄ ASIAKKAASI
![]() |
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |