Uusi ohjelmistoprojekti alkaa. Tiimiläisillä ja asiakkaalla on kova kiire saada julkaistua jotakin valmista toimivan sovelluksen muodossa. Projektin alussa päädyttiin käyttämään AWS-pilviympäristöä. Syynä tähän on muun muassa sen laaja Managed Services -palveluvalikoima, josta sovelluksen tarvitsemia arkkitehtuurin osia voitiin valita käyttöön. Alkuvaiheen dev- ja test-ympäristöjä on pystytetty yrityksen ja erehdyksen kautta ja ne ovat toimineet riittävän hyvin projektin aikana.
Ensimmäinen tuotantoon meno lähestyy kovaa vauhtia. Koska projektin kehitysympäristöt ovat olleet jo hetken aikaa pystyssä ja stabiileja, kukaan ei enää muista tarkalleen, mitä kaikkea ympäristöihin on alun alkaen konfiguroitu ja asennettu. On vain muistissa, että pari kolme ongelmaa oli matkassa ja ne saatiin jotenkin ratkaistua.
Toivottavasti yllä kuvattu tilanne ei enää nykyään tule vastaan, ainakaan usein. Edellä kuvaillun ongelmallisen tilanteen ratkaisemiseksi on olemassa monenlaisia tapoja käsitellä infraa aivan samalla tavalla kuin muutakin sovelluskoodia. Tästä käytetään usein termiä Infra as Code eli IaC. Tavoitteena tässä menetelmässä on, että infran luomiseen ja päivittämiseen liittyvä dokumentaatio käy läpi samanlaista jatkuvaa prosessointia kuin itse sovelluskoodi.
Ideaalitilanteessa (kuva 1)
Jo vuodesta 2011 alkaen AWS on tarjonnut mahdollisuuden hallita pilvi-infraa kuvauskielellä CloudFormation-palvelun kautta. CloudFormation tarjoaakin hyvän pohjan sille, että infra dokumentoidaan rakenteellisessa muodossa ja se mahdollistaa myös hallitut muutokset ympäristöstä toiseen. Aivan ongelmaton CloudFormation ei kuitenkaan ole.
Kuvauskielen luonteesta johtuen CloudFormation templatet ovat hyvin monisanaisia (verbose), koska CloudFormation palveluna ei oleta mitään. Siksi kaikki käyttäjän haluamat toiminnallisuudet on kuvattava täsmällisesti. Näin ollen yksinkertaisimmatkin templatet kasvavat helposti usean sadan rivin tiedostoksi aiheuttaen sen, että kokonaisuus on vaikeasti hahmotettavissa. Alla on rivimäärät pienestä projektista, joka sisältää infran pienelle kotiautomaatioprojektille (kuva 2):
59 00-S3.yml
31 01-EBS.yml
375 02-VPC.yml (verrokkina sama JSON-formaatissa: 625 riviä)
63 03-SNS-SQS.yml
198 04-Distribution.yml 726 total
CloudFormation-palvelun alkuvaiheessa käytettävissä oli ainoastaan JSON-formaatti. Formaatti toimii hyvin tiedon välittämiseen eri palveluiden välillä, mutta se on hyvin raskas ihmisen käsin käsiteltäväksi ja analysoitavaksi, joten kuvauksessa olevan infran arviointi on erittäin haastavaa. JSON-formaatissa on myös kielen omia rajoituksia, joista ehkä rajoittavin on kommentointimahdollisuuden puuttuminen.
Vuonna 2016 julkaistu YAML-pohjainen dokumentointimahdollisuus paransi tilannetta huomattavasti. Formaatin tavoitteena on mm. olla helppolukuinen ihmiselle. Lisäksi se tarjoaa mahdollisuuden kommenttien lisäämiseen kuvauksen sekaan. Hyvä esimerkki YAML:n ja JSON:n eroista voidaan nähdä esim. katsomalla EC2-instanssille annettavaa UserDataa (kuva 3). UserData on käytännössä shell-skripti, joka ajetaan osana EC2-instanssin alustusta. JSON-formaatissa yksinkertaisen shell-skriptin arviointi ja kirjoitus on erittäin hankalaa (kuvassa vasemmalla) verrattuna YAML:n huomattavasti suoraviivaisempaan notaatioon (kuvassa oikealla).
Toinen CloudFormation-palvelun rajallisuus on ollut valmiiden työkalujen puute ympäristöjen päivitykseen. AWS:n komentorivityökalu tarjoaa kyllä valmiita metodeja templaten päivittämiseen, mutta metodit ovat yksittäisiä ja niiden pohjalta pitää itse rakentaa esim. shell-skriptien avulla logiikka, jolla ympäristöä päivitetään (AWS CLI cloudformation update, cloudformation wait jne).
Muutoshallinnan avuksi CloudFormation tarjoaa mahdollisuuden luoda ChangeSetin, joka kuvaa olemassa olevan ympäristön ja halutun ympäristön erot ja vaikutukset, joita ChangeSetin ajaminen aiheuttaa. Tämän tekemiseen löytyy myös erilliset komentorivityökalut, mutta näidenkin käyttö vaatii erillisten skriptien tekemistä (create-change-set, execute-change-set).
Loppuvuodesta 2018 AWS julkaisi beta-version AWS Cloud Development Kit -frameworkista. Tämä versio tarjoaa ratkaisun edellä kuvattuihin ongelmiin. Työkalun versio 1.0 julkaistiin heinäkuussa 2019. AWS CDK on työkalu, joka mahdollistaa infran hallinnan käyttäen tuttuja ohjelmointikieliä, kuten TypeScriptia, Pythonia, Javaa tai C#:ia siinä missä puhtaan CloudFormation templaten avulla ympäristöjen käsittely vaatii uuden ”kielen” opiskelun.
Yksinkertaistettuna CDK on framework, joka tarjoaa työkaluja aiemmin kuvailtujen CloudFormation templatien luomiseen kehittäjälle tutumman formaatin, ohjelmakoodin, kautta. CDK:n on tarkoitus olla intuitiivinen kehittäjälle: se kääntää devaajan tahdon koneellisesti ymmärrettävään muotoon kuvauskielelle.
Käytännössä CDK tarjoaa siis korkeamman abstraktiotason ympäristöjen hallintaan. CDK:n tarkoituksena on kääntää kirjoitettu koodi CloudFormation-palvelun ymmärtämään muotoon. Tämä mahdollistaa myös sen, että frameworkin sisään voidaan piilottaa ympäristölle sopivia oletuksia, joiden avulla kehittäjä pääsee helposti etenemään.
Otetaan esimerkiksi edellä mainittu VPC. CDK mahdollistaa VPC:n luomisen yhdellä koodirivillä (kuva 4). Tällä yhdellä rivillä CDK luo taustalla yli 400 riviä JSON-muotoista (n. 250 riviä YAML-muotoista) CloudFormation templatea.
Kuva 4: VPC:n luominen CDK:ssa.
Mitä tämä yksi rivi koodia sitten taustalla luo?
Framework tarjoaa siis oletuksia, joilla pystyy luomaan AWS-ympäristöön resursseja, jotka ovat heti käyttökelpoisia ja joilla pääsee alkuun. Jos emme halua private subnetille NAT-palvelua, voimme vain kertoa VPC:lle lisätietoja siitä, mitä haluamme (kuva 5). Lisäksi kun nyt kirjoitamme koodia, IDE pystyy ehdottamaan olemassa olevia konfiguraatioita ja CDK pystyy validoimaan kirjoittamaamme koodia ennen kuin yritämme luoda resurssit AWS-ympäristöön. Tässä tapauksessa CDK vaatii, että mikäli emme halua NAT:ia, joudumme tarkemmin kertomaan millaiset subnetit haluamme VPC:n sisälle (kuva 5).
Edellä tulikin jo mainituksi toinen keskeinen asia, jonka CDK tarjoaa CloudFormationin tilalle: komentorivityökalun. Komennot deploy, diff, synth voidaan ottaa mukaan esim. automaattiseen code pipelineen suoraan, eikä omia viritelmiä tarvitse tehdä.
CDK tarjoaa myös kehittäjälle tutun tavan jakaa erilaisia valmiita palikoita (Constructeja) ympäristöjen pystytystä varten. Esimerkiksi TypeScriptiä käytettäessä S3 bucket construct voidaan paketoida npm-paketiksi ja tarjota esimerkiksi yrityksen sisäisesti artifaktipalvelusta. Kuva 6 sisältää esimerkin constructista, joka luo S3 bucketin tietyillä parametreillä ja tarjoaa bucketin nimen ja ARN:n, joiden avulla kyseiseen luotuun bucketiin voidaan viitata.
Kuva 6: Esimerkki paketoitavasta CDK Constructista.
Olen käyttänyt CloudFormation templateja oletuksena viimeiset 3 vuotta pystyttäessäni AWS-ympäristöjä. Noin kuukausi sitten päätin tutustua AWS CDK:hon osana uutta alkavaa projektia ja voin jo nyt todeta, että paluuta puhtaaseen CloudFormation templateen ei ole. CDK on vielä nuori, eikä aivan kaikkia AWS:n palveluita vielä tueta CDK-natiivisti*, mutta jo noin viikon aktiivisen käyttämisen jälkeen työkalu alkoi tuntua omalta. Todellinen testi CDK:n osalta tulee kuitenkin vasta siinä vaiheessa, kun projekti pyörii tuotannossa ja ympäristöön tarvitaan muutos. Onneksi ympäristöstä on kuitenkin olemassa kuvaus, jota on helppo lukea.
* Kaikille CloudFormation-tuetuille palveluille löytyy kuitenkin CFN-konstruktiot, joilla voi koodina kirjoittaa CloudFormation templatea vastaavat tiedot. Kun CDK:hon lisätään palvelun tuki, voidaan nämäkin CFN-konstruktiot korvata vastaavilla natiiveilla konstruktioilla.