Pole kahtlust, et kümme aastat tagasi väga hästi töötanud tarkvara loomise protsesside ja monoliitse arhitektuuriga enam kiiresti arenevaid ja muutuvaid ärivajadusi ei rahulda ning sellest tulenevalt on tarkvaraarenduse tsüklid muutunud kordades kiiremaks. Kiire tempo töötab muidugi ennekõike tarbijate huvides – nad saavad aina uusi funktsionaalsusi üha kiiremini –, kuid ka arendajatele avab see uusi võimalusi võimaldades neil olla aina kiiremini innovaatiline.

Nii nagu kiirem ja võimsam auto on välja vahetanud hobuse, ei ole ka vanade tööriistadega võimalik tarkvara arendada nii kiiresti kui uute lähenemistega. Kuidas siis kiirendada ja lihtsustada tarkvaraprojektide elluviimist nii, et klient, arendaja ja ka lõpptarbija oleks rahul? Nagu ikka, on abi agiilsest lähenemisest, kuid mitte ainult. Üks tööriistadest on mikroteenused ehk inglise keeles microservices, mille kasutamine viib tarkvaraarenduse kiiruse ja kvaliteedi uuele tasemele. Pikas perspektiivis ei ole enamus äritarkvara projektidel sellest pääsu, sest keskkond ja sellega koos klientide nõudmised muutuvad kiiresti. Kuidas aga mikroteenustele sujuvalt üle minna?

Mikroteenused on arhitektuuristiil, mis jagab rakenduse vabalt ühendatud teenuste kogumiks, kus igal teenusel on oma vastutusala (nt isikuandmete töötlemine, arveldus, autentimine) ja teistest sõltumatu reliisitsükkel. Nii saab pidevalt tarnida ja kasutusele võtta suuri ja keerukaid rakendusi, tehes seda komponentide kaupa ning kasutajatele märkamatult.

Mõtteviisi muutus

Kuna uue strateegia rakendamine ei eelda ei uute arendajate palkamist ega suuri väljaminekuid, siis on kõige mugavam minna üle mikroteenustele orgaaniliselt arenedes ja kasvades. Olenemata sellest, kas initsiatiiv tuleb kliendi poolt või mitte, peab ennekõike muutuma arendusmeeskonnades valitsev mõtteviis – tarkvara loojad peavad erinevalt senisest tegelema ka analüüsi, testimise, tootekeskkonna toetamisega ning lõpuks ka oluliselt rohkem oma töö eest vastutama. Mõtteviisi muutus ei tule ega saagi tulla kiiresti, sest kunagi selgeks õpitud töövõtted on mugavad.

Meie otsustasime vana mentaliteeti muuta eeskuju ja motiveerimisega – muutustega kiiremini kaasa minevad inimesed hakkasid evangelistideks populariseerides mikroteenuseid kõigepealt oma meeskonnas ning sealt edasi ka teistes tiimides. Tänu sellele on paljud meie arendusmeeskonnad agiilsed kasutades nii mikroteenuseid kui ka tarkvara pidevat kasutuselevõttu ehk Continuous Deploymenti. Oleme uhked, et saame ennast nimetada DevOps meeskonnaks.

Uuele mõtteviisile üleminekuga kasvas arendajate arusaam klientide ärist: nad said võimaluse panustada ideede arutamisse, nägid suurt pilti ning adusid enda vastutuse suurust. Sellega kaasnes küll arendajate otsesuhtlus kliendiga, enda kirjutatud koodi analüüsimine, testimine ja tootekeskkonda tarnimine, kuid loodud kood ja töö tulemus muutus selgelt kvaliteetsemaks. Seda seepärast, et arendajad ei töötanud enam analüütikute ja projektijuhtide jaoks, vaid tarkvara lõpptarbijate heaks. Muide, ka meie koodikontroll (code review) muutus tõhusamaks, sest enam ei vaadanud arendajad lihtsalt, kas koodijupp töötab, vaid kas see töötab koos teiste komponentidega ja teeb seda, milleks see loodi.

Parem kvaliteet

Eelmise põlvkonna monoliitsete süsteemide ehitamise ja täiendamise asemel uute praktikate, sh mikroteenuste kasutamine annab kindlustunde, et koormuse suurenedes, uue funktsionaalsuse lisamisel või ka arenduspartneri vahetusel töötab kogu süsteem endiselt kvaliteetselt. See on tagatud sellega, et teenused ei ole omavahel nii tihedalt seotud ehk ühe teenuse katki minemine ei pruugi takistads kogu süsteemi tööd. See omakorda tähendab, et ka vigade leidmine ning parandamine on oluliselt kiirem ja lihtsam.

Lisaks sellele on uusi mikroteenuseid lihtne kasutusse anda. Nii saavad arendusmeeskonnad tegutseda üksteisest sõltumatult ning meeskonnaga liituvad uued arendajad saavad kiiremini tööle asuda. Lihtne sisseelamine toimub ka meeskondade tasemel, sest uuele meeskonnale võib eraldada uue vastutusala ja vähemate riskidega jõuda tulemuseni ilma tervet süsteemi detailideni teadmata.

Mikroteenustel põhinevates süsteemides erinevate programmeerimiskeelte paralleellne kasutamine on lihtne ja võimaldab iga ülesande jaoks valida õigeid tööriistu. Concise’is arendatud süsteemides elavad edukalt koos Java, Kotlin ja JavaScript.

Tänasel päeval saavad kõik koodi ümberkirjutamise ja ajakohastamise (refactoring) vajadusest aru. Mikroteenused on siingi abiks, sest üks teenus elab teistes teenusest sõltumatut elu ja tema liides on alati tagasiühilduv. Seda viimast saab jätkusuutlikult tagada automaattestidega, kus meie oleme edukalt rakendanud näiteks Pact raamistikku.

Tehniline lahendus

Mikroteenustele üleminekuks ei piisa siiski ainult mõtteviisi muutusest, sest oluline on ka süsteem, kus seda tehakse. Kümnete võimaluste hulgast parima valimine võib alguses tunduda keeruline, kuid kui pidada silmas õppimiseks kuluvat aega, skaleeritavust, ressursside planeerimist, sõltumatust taristust (pilveteenus või oma server) ning tehnilist tuge, siis muutub valimine palju kergemaks. Meiegi testisime erinevaid süsteeme ning jäime lõpuks kindlaks avatud lähtekoodiga konteinerpõhisele virtualiseerimislahendusele Kubernetes, mille kasuks rääkis kõige rohkem argumente, sh see, et Kubernetes annab konteineritele omaenda IP-aadressid ja üheainsa DNS-i konteinerite komplekti jaoks (Service Discovery).

Mikroteenustele ülemineku eelduseks on ka automatiseerimine, sest ilma selleta ei ole võimalik tarkvara pidevalt tarnida – nii testimine kui deployment peavad käima välkkiirelt.

See original post HERE