ATK Pöhinää

Edellisessä blogikirjoituksessani kerroin hieman Solenovon teknologian historiasta. Tässä tekstissä siirrymme lähihistoriaan ja tarkastelemme yksityiskohtaisemmin teknologiasiirtymää aina alustasta frontendiin asti.

Alusta

Ennen vuotta 2018 olimme vielä tilanteessa, jossa alustana meillä oli VMWare:lla asennetut virtuaalikoneet. Projektit oli toteutettu monella eri teknologialla ja joka projektilla oli oma CI/CD toteutus, joka vaihteli täysin manuaalisesta asennuksesta hyvin pitkälle vietyihin Jenkins-projekteihin. Tiimien välinen kuormantasaus ja tiedon jakaminen oli siis käytännössä mahdotonta ja turhaa. 2018 oli kuitenkin se vuosi, jolloin siirryimme Nutanix Hyperconverged -konesaliratkaisuun, kohti kontteja. Nutanixiin siirrettiin ensimmäisenä virtuaalikoneet ja samoihin aikoihin aloitettiin ensimmäisen Kubernetes-klusterin rakentaminen. Tämä klusteri rakennettiin brick-by-brick -tyylisesti käsin ja se toimi ensimmäisenä harjoittelu- ja testausalustana noin vuoden verran. Nyt meillä on menossa kolmas Kubernetes klusteri ja se on rakennettu Nutanix palveluita hyödyntäen.

Kehitys

Koodin elinkaari alkaa Git-repositoriosta. Näitä alkaa olla jo melkoinen kasa, sillä jokainen frontend ja backend -projekti on omassa repositoriossaan. Backend-projektit tehdään Loopback 3:lla ja frontendit tehdään moderniin tapaan Reactilla käyttäen hookkeja ja funktionaalisia komponentteja. Ettei jokaisen projektin ja tiimin tarvitse tehdä samoja asioita moneen kertaan, tiimit kehittävät yhteistä React-komponenttikirjastoa, joka julkaistaan npm-pakettina yksityiselle Nexus-alustalle. Samoin toimitaan ESLint sääntöjen kanssa, jotta saamme julkaistua ja jaettua kaikille tiimeille hallitusti yhteiset säännöstöt. Prettier pitää huolen, että koodin kirjoitustyyli on kaikilla sama. Lopulta projekti bundlataan webpackilla.

Julkaisu

Projektit buildataan automaattisesti Bitbucket-pipelineillä ja niistä tehdään Docker image, joka ladataan privaatti docker repositoryyn. Pipelinet tekevät myös automaattisesti jokaiselle pull requestille ja develop branchin commitille Sonar Cloud -analyysin. Sonar Cloud -koodianalyysillä voidaan ehkäistä bugeja, haavoittuvuuksia ja ylipäätään huonoa koodia. Samalla pipeline ajaa myös olemassa olevat testit, jotka on nyt toteutettu Jestillä ja Enzymellä.

Deployment

Seuraavaksi Docker imaget pitäisi saada pyörimään Kubernetes-klusterissa ja sitä varten tarvitaan Kubernetes Deploymentit. Deploymentit ja muut Kubernetes-resurssit säilötään omassa Git-repositoriossa ja ne on toteutettu Kustomize-konfiguraationa. Kustomizen avulla voidaan erottaa ympäristökohtaiset konfiguraatiot omiin tiedostoihinsa, jolloin koko deploymenttia ei tarvitse monistaa. Itse mikropalvelu tai käyttöliittymä julkaistaan Kubernetekseen ArgoCD GitOps -työkalulla. ArgoCD-applikaatio seuraa Kubernetes-resursseja Git-repositoriossa ja ilmoittaa ovatko ne klusterissa ajan tasalla vai tarvitaanko synkronointia.

Takaisin tulevaisuuteen?

Toimiva teknologiauudistus ei ole kertarysäyksellä tehtävä projekti jolla on valmistumispäivämäärä, vaan ajatusmalli, joka johtaa jatkuvaan kehitykseen. Tämä on tärkeää, koska teknologiat kehittyvät jatkuvasti ja jatkuva kehitys mahdollistaa asteittaisen siirtymän, jolloin vaikutus kehitystiimeihin on huomattavasti pienempi. Hyvänä esimerkkinä backendiin valittu Loopback 3 on jo elinkaarensa päässä ja sen korvaaja pitää selvittää.

Mitä tulevaisuus mahtaakaan tuoda tullessaan? Siirrytäänkö seuraavaksi Loopback 4:n tai NestJS:n? Ehkä tarvitsemme skaalautuvia tietokantoja, kuten MongoDB tai Cassandra? Tai kenties tarvitsemme tekoälykirjastoja, jolloin teemme mahdollisesti uuden mikropalvelun Pythonilla ja Tensorflowlla? Mitä ikinä tulevaisuus tuokaan tullessaan, jos laskelmani pitävät paikkaansa tulet näkemään jotain todella rajua, kun tämä klusteri saavuttaa 88 mikroserviceä.

---