Osallistuin tällä viikolla Lontoossa järjestettyyn DevOps-konferenssiin. Valitsin striimi-lipun, niin sain käytettyä tehokkaammin tauot, joita ohjelmaan oli rakennettu. Ja kun aikaerokaan ei ollut paha, osallistuminen ei olisi voinut olla helpompaa.
Tässä kirjoituksessa kerron joitakin tärkeimpiä asioita, joita puheenvuoroista jäi käteen.
Moderni arkkitehtuuri pilvessä 2023
Ensimmäinen varsinainen luentosessio käsitteli pilviarkkitehtuureja. Esityksen piti Société Générale -pankissa työskentelevä Marius Zaharia, joka on myös Microsoft Azure MVP.
Marius puhui pilvinatiiveista sovelluksista ja erilaisista tavoista tuottaa niille alustoja. Esitys käsitteli hyvin laajasti erilaisia asioita, mutta tässä joitain tapoja ajaa kontitettuja sovelluksia:
- Azure Kubernetes Services (AKS) on Azuren Kubernetes-palvelu, jonka alla käytetään asiakkaan virtuaalikoneita. AKS:n avulla voi ajaa konttipohjaisia sovelluksia. AKS:ssä asiakas maksaa palvelimista, joita käytetään kuormien ajamiseen.
- Azure Container Instances (ACI) mahdollistaa yksittäisten konttien ajamisen ilman omia palvelimia. Azure siis tarjoaa alla olevat palvelimet ja asiakas maksaa vain käyttämästään CPU:sta, RAMista jne.
- Azure Kubernetes Serviceä voi ajaa Azure Container Instanssien päällä. Tässä voi ajaa kokonaista Kubernetes-klusteria, mutta ei tarvitse varata tähän omia palvelimia, vaan palvelinkapasiteetti tuotetaan ACI-palvelun avulla.
- Azure Container Apps on kokonaan Microsoftin hallinnoima alusta konttipohjaisten sovellusten ajamiseksi.
Ajoalustojen lisäksi hän puhui paljon pilvinatiivien sovellusten eduista, mutta myös yleisestä huolesta jäädä vendor-lockiin eli käytännössä nalkkiin kyseisen pilvitoimittajan ympäristöön. Vendor-lockinhan syntyy, koska sovelluksen toteuttamiseen on käytetty kyseisen pilvitarjoajan, esim. Azuren tarjoamia palveluita, jonka vuoksi siirtyminen vaikka AWS:n palveluihin osoittautuukin hankalaksi.
Marius Zaharia tarjosi tähän lääkkeeksi kolmea asiaa:
- Käytä deploymenteissa kontteja
- Hyödynnä verkon rakentamisessa Service Meshiä, esim. ISTIOta.
- Hyödynnä sovelluksissa hajautettua sovelluksen ajoympäristöä (Distributed app runtime), esim. dapr-frameworkia.
Eräs toinen luento käsitteli ISTIOta, joten kerron siitä lisää myöhemmin tässä kirjoituksessa. Marius käsitteli esityksessään jonkin verran dapr-frameworkia, joka siis tarjoaa apeja sovelluksille ja piilottaa siten niiltä ajoalustan. Näin sovelluksia voi ajaa hyvin erilaisissa ajoympäristöissä. Lue lisää daprista täältä.
Esityksen jälkeen käydyssä keskustelussa hän ehdotti myös kahden pilvitoimijan ympäristön käyttöä, esim. Azure ja AWS, edellyttäen, että asiakkaalla on riittävän paljon resursseja ottaa haltuun kaksi ekosysteemiä. Kahden ekosysteemin käyttö mahdollistaa kuormien tasaisemman jaon toimijoiden välillä. Näin pienennetään riippuvuutta yhdestä ekosysteemistä.
Ydinviesti oli:
- Pilveä voi hyödyntää parhaiten rakentamalla pilvinatiiveja sovelluksia
- Jos on viemässä perinteisiä sovelluksia pilveen, on tärkeää olla suunnitelma, miten pilveä hyödynnetään.
- Moderni arkkitehtuuri on osin tekniikkaa, mutta onnistuminen riippuu paljon myös organisaatiosta ja työn uudelleen organisoimisesta
Seuraava mielenkiintoinen luento käsitteli pilvimigraatioiden ongelmia.
Yleisiä pilvimigraation kipupisteitä
Tämän esityksen piti Patrick Koch, joka työskentelee AVL:llä. AVL on itävaltalainen autojen testaukseen erikoistunut yritys. Moni autovalmistaja testauttaa moottorinsa ja nykyään myös akkunsa AVL:llä. AVL tarjoaa testipenkkisoftia, jonka avulla testattavasta kohteesta saadaan väännettyä raportti, jonka asiakas tarvitsee.
Patrickin mukaan monet heidän softansa ovat hyvin vanhoja Windows-sovelluksia, joiden vieminen pilveen ei tulisi ihan heti mieleen. Kuitenkin testaamisen määrä on räjähtänyt, jonka vuoksi testaamisen kulut olisivat liian korkeita ilman automatisointia.
Automatisoinnin ansiosta testisofta voidaan käynnistää tarpeen mukaan, kohde voidaan mitata ja mittausdatasta rakennetaan raportti. Tämä loi business casen pilvelle.
Ongelma 1: Vääränlainen pilvistrategia
Osa työntekijöistä halusi refaktoroida sovellukset pilvinatiiveiksi ja osa vain siirtää ne sellaisenaan pilveen. Refaktorointiin ei lähdetty, vaikka se olisikin pidemmällä aikavälillä järkevää, koska pelättiin homman jäävän työäyden takia kesken.
Siksi AVL päätyi kontittamaan vanhan sovelluksensa ja siirtämään sen sellaisenaan pilveen. Windows-sovellus siis laitettiin Windows-kontin sisään ja siirrettiin pilveen.
Patrick toi esille, että ongelma voi olla liian monimutkaisen tai vaativan pilvistrategian valitseminen.
Ongelma 2: Valittiin liian monimutkainen arkkitehtuuri
Aluksi AVL yritti käyttää alla Azure Kubernetes -palvelua, mutta törmäsi erilaisiin yhteensopimattomuusongelmiin. Heillä oli mm. apunaan Microsoftin konsultti, mutta tällä oli kokemusta enemmän Linux-konteista, kun heidän kontit olivat Windows-pohjaisia ja tästäkin seurasi omia haasteita, koska kaikki opit eivät ole siirrettävissä alustalta toiselle.
Lopulta he päätyivät käyttämään Azure Container Instanssia, joka on paljon yksinkertaisempi yhden kontin ajoympäristöksi, ja tämän he saivatkin toimimaan.
Ongelma 3: Manuaalinen provisiointi
Kun he olivat saaneet tunkattua toimivan ympäristön, kukaan ei uskaltanut koskea siihen, koska sen pelättiin hajoavan. Jos ympäristö hajoaa, miten pystyttää samanlainen ympäristö uudelleen?
Ratkaisuksi osoittautui tietenkin Infrastructure as Code (IaS). AVL päätyi skriptaamaan asennuksen käyttämällä Terraformia. Kun he nyt pystyttävät ajoympäristöjä asiakkailleen, heidän viestinsä on varata Terraform-asennuksen rakentamiseen runsaasti aikaa, jotta asennus sen jälkeen voidaan automatisoida ja jatkossa asennukset tapahtuvat virheettömästi ja nopeasti.
Ongelma 4: Kustannuksista tuli sanomista
Kun AVL lähti projektiin, kukaan ei miettinyt kustannuksia, koska kaikki pohtivat vain sitä, miten saada homma toimimaan pilvessä. Ja koska asennus oli aluksi manuaalinen, ei siihen uskallettu koskea. Tämä kaikki johti pilvikustannusten kasvuun ja siitä siis tuli sanomista.
Viesti oli, että kustannuksia kannattaa seurata koko ajan ja myös arvioida etukäteen.
Lopputulemana AVL päätyi siis Terraform-konfiguraatioon, jolla Azure-ympäristö pystytetään Azure DevOps Pipelinen avulla. Ja seuraavassa vaiheessa heidän tarkoituksenaan on hieman re-factoroida monoliittista sovellusta.
Mitä tehdä kun pelikaani joutuu turbiiniin
Tämän esityksen piti Christian Seifert Pixumista. Pixum tarjoaa palvelua, jonka avulla omista valokuvista voi rakentaa kuvakirjan.
Christianin mukaan kyse ei ole siitä, tapahtuuko meille jotain, vaan ennemmin siitä, kun jotain tapahtuu.
Me kaikki käyttäydymme eri tavoilla stressaavissa tilanteissa. Jos olemme stressaavassa tilanteessa, teemme sen, mitä tiedämme, emme välttämättä sitä, mikä olisi järkevää. Siksi meidän pitää treenata aivot tekemään oikeita asioita.
Christian käsitteli asiaa kolmen vaiheen kannalta:
- Ennen katastrofia
- Kun katastrofi on päällä
- Katastrofin jälkeen
Ennen katastrofia
- Ennen katastrofia kannattaa laatia ohje, minkä mukaan toimitaan, kun katastrofi sattuu. Kannattaa siis miettiä etukäteen erilaisia tilanteita ja mitä niissä tehtäisiin.
- Järjestä harjoituksia. Pixiumin kokemuksen mukaan ihmisistä tulee paljon nopeampia ja he tekevät vähemmän virheitä, kun tilanteita harjoitellaan. Tässä voidaan oppia paljon hävittäjälentäjistä, jotka harjoittelevat kerta toisensa jälkeen erilaisia tilanteita, jotta oikeassa tilanteessa aivoissa olisi jälki siitä, miten kannattaa toimia.
- Kerää järjestelmistä lokia ja mittaustietoa. Lisäksi Christian kehotti keräämään järjestelmistä lokia ja mittaustietoa ja laittamaan se paikkaan, johon pääsee käsiksi myös ongelmatilanteissa. Tämä auttaa selvittämään ongelman syytä siinä vaiheessa, kun tilanne on päällä ja varsinainen järjestelmä ei toimi normaalisti.
Kun katastrofi on päällä
- Kun katastrofi on päällä, pitää hidastaa. Tällä Christian tarkoitti sitä, että katastrofitilanteessa ihmisillä on taipumus alkaa juoksemaan ja tekemään ”jotain”. Tässä kohtaa pitää lopettaa hötkyily ja aletaan seuraamaan etukäteen tehtyä prosessia. Kaikkien ei tarvitse tehdä koko ajan jotain, vaan annetaan työrauha niille, jotka selvittävät ongelmaa.
- Tiedä ”ydinpommivaihtoehto”. Sodassa voi voittaa yhden taistelun käyttämällä ydinasetta, mutta siitä voi seurata vain entistä enemmän ongelmia. IT-maailmassa tällainen ydinpommivaihtoehto voi olla viikon vanha tietokannan backup, joka palauttamalla kanta saadaan kuntoon, mutta menetetään viimeiset transaktiot.
- Anna ihmisille aikaa ratkoa ongelma. Katastrofitilanteessa voi olla vaikea keskittyä, kun koko ajan on joku kyselemässä miten menee. Ratkaisu voisi olla worker ja reporter -malli, jossa ”worker” saa keskittyä ongelman ratkaisuun ja ”reporter” on eri henkilö, joka hoitaa kommunikointia.
Katastrofin jälkeen
- Kerää opit. Kerää ihmiset yhteen ja käy läpi, mikä meni hyvin, mikä huonosti. Pixiumilla myös harjoituksista kerätään oppeja ja prosessia kehitetään sen avulla.
- Paranna dokumentaatiota. Kenenkään dokumentaatio ei ole täydellinen. Kun huomaa, että dokumentaatio ei ole kunnossa, se kannattaa päivittää. Myös prosesseja kannattaa dokumentoida.
- Harjoittele pikkukaaosten kanssa. Christian kertoi Netflixin pikkuvikoja aiheuttavista skripteistä. Kun on pakko harjoitella pikkuvikojen kanssa, ajattelu kehittyy. Kun tietää, että ongelmia on tiedossa, alkaa miettimään, mitä tehdä, jos ja kun jotain käy tai miten ongelman voi estää.
- Palaa alkuun. Lopuksi Christian muistutti, että katastrofin jälkitila on aina jonkun seuraavan katastrofin ennakkotila. Eli koko homma alkaa taas alusta.
Multi-Mesh – seuraava looginen askel multi cloud -ympäristöissä
Tämän esityksen piti itsenäinen konsultti Michael Hofman. Hän käsitteli luennossaan mm. multi cloud -toteutuksia. Nykyään halutaan usein mahdollisuus vaihtaa pilvitoimittajaa eikä sitoutua yhteen. Tämän toteutus ei ole käytännössä ihan helppoa.
Esitys käsitteli useamman Kubernetes-klusterin yhdistämistä. Miksi joku haluaisi yhdistää useamman Kubernetes-klusterin? Ainakin seuraavista syistä:
- Jos yhdessä klusterissa tulee ongelmia, ongelmat rajautuvat pienemmälle alueelle
- Pienempi vendor lockin -ongelma
- Mahdollisuus kustannusten optimointiin
Teknisesti useamman Kubernetes-klusterin yhdistäminen on kuitenkin haastavaa. Ratkaisuna on Istio, open source -pohjainen service mesh -tuote, jonka avulla voidaan yhdistää useita klustereita.
Istiolla voidaan toteuttaa erilaisia kokoonpanoja:
- Klusterit voivat olla yhden regioonan sisällä kahdella eri Availability zonella
- Klusterit voivat olla eri regioonissa
- Klusterit voivat olla eri pilviekosysteemeissä
Istion toiminnan ymmärtäminen on niin monimutkainen juttu, että en edes yritä selittää sitä tässä. Kannattaa tutustua tekniikkaan, jos asia kiinnostaa.
DevOps ja Serverless – Ystäviä vai vihollisia?
Yksi mielenkiintoisimmista sessioista oli paneelikeskustelu, joka velloi aika laajasti DevOpsin ja serverless-ajattelun ympärillä.
Tässä joitakin ajatuksia, joita keskustelusta jäi mieleen:
Kubernetes vs Serverless
- Ei kannata rakentaa Kubernetes-klusteria, jos sitä ei välttämättä tarvitse. Se voi osoittautua pilvessäkin aika monimutkaiseksi.
- Serverlessin idea on, että sovelluskehitystiimin ei tarvitse miettiä alustoja vaan se voi keskittyä koodin tuottamiseen
- Serverless ei oikein toimi korkean regulaation ympäristöissä. On vaikea sanoa, mitä funktion käsittelyssä oikeasti tapahtuu, jos ei näe pinon sisään.
Onko olemassa Fullstack-kehittäjiä?
- Kukaan ei voi hallita täysin kaikkea. Siksi oikeasti kukaan ei pärjää yksin eli puhdasoppisia Fullstack-ihmisiä ei ole olemassa.
- Toinen osallistuja määritteli fullstackin toisin. Idea on ymmärtää mahdollisimman laajasti asioita oman erikoisosaamisalueen ympäriltä.
- Nykyään devaajat ymmärtävät infrasta enemmän kuin aiemmin, koska he joutuvat ottamaan kantaa ajoalustoihin
- Myös entiset server adminit ymmärtävät koodauksesta enemmän kuin aiemmin, kun työ muuttuu enemmän skriptaamiseksi
Kannattaako välttää vendor-lockinia?
- Yleensä riippumattomuuteen pyrkivät toteutukset eivät ole kovin hyviä
- Toteutus on lähes aina todella kallis
- Suurin lockin muodostuu omasta koodista
- Data gravity eli sovellusten ja datan muodostama kokonaisuus aiheuttaa suuremman lockin-tekijän kuin ekosysteemi itse
- Yhden ekosysteemin sisällä päästään suurempaan tehokkuuteen kuin yrittämällä rakennella asioita moneen ekosysteemiin
Serverless-palvelun rakentaminen (kurkistus kulissien taakse)
Tämän esityksen piti Allen Helton Momentolta. Allen kertoi heidän tarjoaman cache-palvelun rakenteesta. Kyse on siis cachesta, jota muut ohjelmat voivat käyttää. He veloittavat palvelusta vain datamäärien perusteella.
Mikä on serverless?
Allen määritteli serverless-palvelun seuraavasti:
- Käyttäjän ei tarvitse provisioida mitään palvelua (tai ylläpitää sitä)
- Hinnoittelu perustuu täysin käyttöön. Ei mitään minimimaksuja.
- Toimii heti yhden api-kutsun avulla
- Palvelulla ei ole suunniteltuja käyttökatkoja
Tämähän kuulostaa varsin hyvältä, jos cache on vain osa isompaa kokonaisuutta. Ei ihme, jos serverless kiinnostaa kehittäjiä.
Mitä löytyy konepellin alta?
Toimiiko serverless-palvelu ilman palvelimia? No ei tietenkään. Momento lupaa 5ms SLA:n palvelulleen, joten se vaatii paljon palvelimilta, joille kyselyitä tulee. Palvelu perustuu siis tehokkaisiin palvelimiin, jotka Momento on vuokrannut AWS:ltä. Asiakkaan ei kuitenkaan tarvitse tietää niistä mitään.
Esityksessä käytiin läpi palvelun arkkitehtuuria:
- Cache Admin ohjaa muuta infraa. Se tietää, millaisia cacheja on luotu
- MR2, joka reitittää ja autentikoi sisään tulevia kyselyitä
- Cache nodet sisältävät varsinaisen datan.
Kaikkien alta löytyi AWS:n EC2-instansseja, joten kyllä kaikki tietysti palvelimia tarvitsee, mutta kyse on siitä, miten paljon haluaa rakentaa itse ja milloin kannattaa vain käyttää jonkun toisen rakentamaa palvelua.
Let's go Hybrid! Is it better? No. Is it cheaper? Yes.
Tätä luentoa odotin itse aika paljon, koska oma tekeminenkin on liittynyt paljon erilaisten arkkitehtuurivaihtoehtojen vertailemiseen.
Esityksen piti italialainen Roberto Freato, joka on mm. Azure MVP. Hän aloitti esityksensä kyselemällä tavallisen virtuaalipalvelimen hintaa pilvessä. Pointti oli siinä, että virtuaalikone on kalliimpi ostaa isosta pilvipalvelusta kuin toteuttaa itse.
Hän jakoi esityksessään vinkkejä, joista toistan osan tässä:
- Kaikki firmat eivät ole startupeja. Pilvi toimii erityisen hyvin startupeille, koska pilven saa heti käyttöön ja se skaalaa kasvun mukana. Perinteisille sovelluksille pilvi ei kuitenkaan tarjoa välttämättä mitään erityistä. Siksi pelkkien virtuaalikoneiden siirto pilveen ei ole itsessään kovin järkevää.
- Keskity lisäarvoa tuottaviin palveluihin. Pilven arvo on Roberton mukaan softastackissä, jonka saa käyttöönsä ja josta pilvitarjoaja vastaa. Mielenkiintoinen detalji oli se, että kun Azure aloitti palvelujen tarjoamisen, aluksi tarjooma ei sisältänyt virtuaalipalvelimia, koska Microsoft ajatteli, että ne eivät tuota riittävästi lisäarvoa asiakkaille.
- Ota oppia pilvestä. Pilvessä kaikki on multi-tenant-toteutuksia ja automatisoitua. Kannattaa opetella automatisoimaan mahdollisimman paljon ja hyödyntämään valmiita komponentteja, jotka yksinkertaistavat omia sovelluksia.
- Tunnista lockin-kohdat. Roberto käsitteli erilaisia data-tiereja, joille voi tallentaa dataa ja niiden erilaista hintakäyttäytymistä. Pointti oli siinä, että vaikka esim. kylmä arkistolevy on tosi halpaa, datan vieminen siltä pois tulee todella kalliiksi. Hän mainitsi mm. seuraavia lockin-syitä:
- Palvelusta lähteminen maksaa liikaa
- Palvelun toteuttaminen ilman kyseistä pilveä tekisi siitä liian monimutkaisen
- PaaS/SaaS-toteutus vaati räätälöintiä
- Palvelu on niin uniikki, että vastaavaa ei saa mistään eli kannata vaihtaa.
- Toisaalta jotkut palvelukomponentit voivat olla pilvessä niin halpoja, että siitä ei kannata luopua.
- Keskity nopeaan korjaamiseen. Jos data on muualla kuin kyseisessä sovelluksessa, on usein nopeampaa korjata tilanne asentamalla sovellus uudelleen.
- Usein voi olla järkevää toteuttaa osa palveluista perinteisempään ympäristöön ja käyttää pilveä siellä, missä lisäarvo on riittävän suuri.
Kokonaisuutena viestinä oli, että pitäisi ymmärtää, mitä on tekemässä ja tutkia erilaisia vaihtoehtoja, mitä ne tarkoittavat. Tämä vaatii aika paljon tiimiltä ja yksi viesti olikin, että oma tiimiä kannattaa kouluttaa.
Olin ehkä hieman pettynyt luennon sisältöön, koska se jäi aika periaatteelliselle tasolle. Olisin toivonut enemmän esimerkkejä toteutuksista, joissa on yhdistelty julkipilveä privaatti-ympäristöihin.
Yhteenveto
Esityksiä oli tietysti paljon muitakin. Osa oli niin teknisiä, että niistä on hankala kirjoittaa lyhyesti ja osa hyvinkin filosofisia.
Kokonaisuutena seminaari oli minusta hyvä ja olen tyytyväinen, että osallistuin siihen.
Yksi rohkaiseva oppi varmasti oli, että meitä varmasti vaivaa riittämättömyyden tunne sen suhteen, että pitäisi aina tietää asioista enemmän. Vaikka on tärkeää opiskella jatkuvasti lisää, toisaalta pitää hyväksyä se, että näitä asioita ratkotaan tiiminä, jossa jokaisella on oma roolinsa.
Toinen keskeinen oppi käsitteli DevOps-mallin rakentamista. DevOps vaatii paljon tiimiltä ja johtamiselta. Sitä ei kannata yrittää rakentaa alhaalta ylös, vaan se jos joku vaatii kokonaisuuden johtamista. Mutta ehkä siinä onkin aihe jollekin tulevalle kirjoitukselle.