Trendid Java-maailmas 2016 – vaade Devoxxilt

Mattias Tiitson, Proeksperdi tarkvaraarendaja

11 – 13. novembrini toimus Belgias, Antwerpenis 3500 osalejaga Java konverents Devoxx, kus sain osa esitusest kaheksal paralleelsel rajal. Millised trendid valitsevad Java maailmas? Ilmselgelt on mu nägemus pisut kallutatud ja suuresti mõjutatud ettekannete valikust, kuid mõned mustrid joonistusid välja üsna selgesti.

Selle, 2015. aasta kindel hitt on Docker. Docker on vidin, mis võimaldab rakenduse koos igasuguste sõltuvustega pakkida konteinerisse. Miks see hea on? Sest rakendus töötab nüüd, kus iganes Dockeri põhi all on. Mingisugust keerukamat seadistust polegi vaja. Konteinereid on lihtne luua, hävitada ja taasluua. Järele proovides selgub üsna kiiresti, millest selline vaimustus.

Loomulikult on endiselt äärmiselt populaarsed pilvetehnoloogiad. Teenused nagu AWS pakuvad lihtsalt skaleeritavat infrastruktuuri. Huvitava kõrvalmõjuna võimaldavad nad mõelda infrastruktuurist kui commodityst. Sellega kaasnevad omakorda uued võimalused tarkvara tarnimiseks ja sellele eelnevaks ettevalmistuseks.

Continuous Delivery on teema, mis mind isiklikult on viimasel ajal väga huvitanud. Selle peamiseks eesmärgiks on hoida rakendust pidevalt reliisitavas seisundis, mis on järgmine loogiline samm pärast Continuous Integrationit. Üsna üllatav oli näha, et tegelikult juba aastaid vana idee paistab just praegu väga tugevalt esile kerkivat printsiibina, mille kogukond on vastu võtnud kui hea tava – midagi, mille poole vähemalt pürgida. Võib-olla on teema aktuaalne just varem mainitud tehnoloogiate võidukäiguga seoses. Nii Docker kui ka erinevad platvormiteenused, millele viidatakse lühendiga PaaS võimaldavad tunduvalt hõlbustada automatiseeritud deployd.

Metoodikate valdkonnas kerkivad esile kaks tegijat: Lean ja DevOps. Lean on üldisem metoodika, mille eesmärk on vähendada väärtust mitteloovate tegevuste hulka. Eriti omab see mõtet startupide kontekstis, kus välditakse näiteks põhjalike turu-uuringute ja äriplaanide koostamist traditsioonilisel aeganõudval viisil. DevOps on spetsiifilisem metoodika, mida kasutatakse just tarkvaraarenduse kontekstis. Selle ülesanne on edendada koostööd tarkvaraarendajate ja operatsioonide üksuste vahel, millega avanevad uued võimalused, sealjuures ka eelpool mainitud tehnoloogiad. Kumbki neist meetoditest ei ole konkurendiks meile hästi tuttavale agiilsele lähenemisele, kuid pigem täiendavad seda.

Devoxxil räägiti ka Java järgmisest versioonist, mis toob meile kauaoodatud moodulihalduse. Endiselt olid teemaks ka käesoleva Java versiooni 8 pakutavad lisavõimalused, kus klassikalise objektorienteeritud programmeerimise kõrval otsitakse lahendusi teiste paradigmade kaudu, muuhulgas funktsionaalse programmeerimise võtete kasutamisega. Palju räägitakse ka Reactive programmeerimisest vahendite nagu näiteks RxJava, Akka, Vert.x ja NodeJS abil. Viimane on abstraktsioon, mis võimaldab andmetest mõelda kui striimidest, mida on võimalik transformeerida ja kombineerida.

Mitmeid neid tehnoloogiaid ja metoodikaid reklaamitakse kui võluvitsa, mis pühivad kõik mured. Kuid on ka neid, kes hoiatavad tormakaid otsuseid tegemast. “Shit happens when you put network between your classes,” ütles üks esineja tabavalt microservicete kohta, viidates sellega kaasnevale paratamatule lisakeerukusele.

Microservices

Microservice on mõiste, mida ei saa enam väga uudseks nimetada. Sisuliselt on see moodus rakenduse modulariseerimiseks, millega jagatakse rakendus väikesteks autonoomseteks teenusteks, mis omakorda suhtlevad omavahel üle võrgu. Tavaliselt paljastavad need REST-liidese, mille abil teenused üle võrgu üksteisega suhtlevad. Sellega võimaldame süsteemi erinevatel osadel areneda erineva kiirusega. Muudatus ühes teenuses ei mõjuta tingimata teiste teenuste tööd. Microservicite kontekstis pakub palju kõneainet ka süsteemide resilience ja rikete käsitlemine.

Et viia teenuste piire ületavate muudatuste hulga miinimumini, jagatakse süsteem teenusteks vertikaalset. Jagades süsteemi äridomeenide alusel saame stabiilsemad teenuste liidesed. Süsteemi kasvades võib tekkida vajadus töö jagamiseks erinevate meeskondade vahel. Vertikaalne jaotus võimaldab tiimidel saada spetsialistiks ka oma hallatavas äridomeenis. Mõnes mõttes erandina võib vaadata front-endi, mis moodustab õhukese horisontaalse kihi teiste teenuste peale.

Hea mustrina ei jaga teenused andmebaase. Jagatavad andmed peaksid teenused paljastama liideste kaudu. See on vajalik teenuste implementatsiooni detailide peitmiseks avalikkuse eest, mis omakorda hõlbustab muudatuste tegemist teenuste sees ilma seotud teenuseid mõjutamata. Kui andmebaas on jagatud mitme teenuse vahel, võib ka pisem muudatus selles nõuda mitme erineva teenuse üheaegset muudatust. Need teenused võivad aga olla erinevate tiimide arendada ja nõuda keerukat koordineerimist. Seepärast tuleks vältida tsentraalsete punktide tekkimist.

Kuid ka uuendused teenuste liidestes võivad tekitada vajaduse mitme teenuse üheaegse muutmise järgi. Selliseid olukordi saame vältida liideste versioniseerimisega. Oluline on meeles pidada, et meie eesmärk on võimaldada teenuste iseseisvat arengut.

Mitte alati ei toimi kõik teenused õlitatult. Microservicite kontekstis muutub äärmiselt oluliseks rikete leviku piiramine. Ka ebatavaliselt aeglaselt vastav teenus võib temast sõltuvate teenuste töö täielikult halvata. Vastust ootavate päringute kuhjudes ammenduvad rakendusele saadaval olevad threadid ja teenus võib hanguda. Kogu lisakoormus jaotub ülejäänud klastrile ja võib ka teised noded üle koormata. Selline stsenaarium illustreerib hästi vajadust rikete läbimõeldud käsitlemise järgi. Hystrix on teek, mis võimaldab just selliseid olukordi vältida. Nö circuit breakerite implementeerimine aitab rikkis funktsionaalsust välja lülitada ja minimeerida negatiivseid mõjusid. Teenuse arendudes tuleb alati lähtuda eeldusest, et kõik taustasüsteemid võivad maha kukkuda. Kõiki halbu stsenaariume saab muuseas simuleerida ja testida vahenditega nagu Mockwire.

Teenuste arvu kasvades muutub kiiresti oluliseks automatiseerimine. Skaleerumiseks on hädavajalik automaatne testimine ja hõlbus muudatuste deploymine. See nõuab aga investeeringut infrastruktuuri ja protsessidesse nagu Continuous Delivery. Samuti muutub keeruliseks logide haldamine. Tööriistad nagu Kibana või Splunk võimaldavad logid agregeerida ühte kohta. Huvitava trikina võib juurutuda praktika, kus igale äriloogilisele tegevusele genereeritakse oma korrelatsiooni identifikaator. See identifikaator märgitakse maha iga seotud logikande juures. Nii on lihtsalt leitavad kõik omavahel seotud, kuid erinevatest süsteemidest pärinevad logikanded.

Paljud neist printsiipidest kehtivad ka monoliitse rakenduse juures. Kuid tõeliselt kriitiliseks saavad need just microservice arhitektuuri puhul. Kui suur on sellise arhitektuuri valimise hind? Kindlasti sõltub see ümbritsevast ökosüsteemist. Hästi juurdunud DevOps metoodika võimaldab lihtsamini taolist arhitektuuri üles seada. Korporatiivses maailmas, kus asjad liiguvad suurema inertsiga, võib see aga päris raskeks ülesandeks osutuda. Nii ei pruugi potentsiaalne tulu üldsegi üle kaaluda muudatusega kaasnevat vaeva ja lisakeerukust ja seetõttu on ilmselt hea strateegia hoida valikuid avatuna võimalikult kaua viljeledes modulaarset disaini monoliitse rakenduse sees. Hüpe microservicitele on mõistlik teha alles tungiva vajaduse tekkides. Pühendumise edasilükkamine on muuseas ka üks Lean metoodika printsiipidest.

Principles Of Microservices

Six principles for building fault tolerant microservices on the JVM

Microservices and Modularity or the difference between treatment and cure!

Code Review

Code Review on praktika, kus enne koodi mainline commitimist vaatab selle üle mõni tiimikaaslane. Eesmärgiks on koodi kvaliteedi parandamine, koodibaasi tutvustamine tervele meeskonnale ja õppimine arutelude kaudu. Praktika juurutamiseks tasub aga silmas pidada mõndasid põhitõdesid. Code Review ei tohi omandada negatiivset alatooni. See ei ole meetod töötulemuste hindamiseks ega tohiks panna hinnatava koodi autorit liiga suure pinge alla. Samuti ei tohiks see panna liigset koormust hindaja õlule. Eesmärk ei ole koodile vaadates kõik vead leida, kogu hindamine ei pea kestma üle 10 minuti. Küll aga võiks hindamine toimuda aegsasti, muudatused ei tohiks selle taha takerduda. Põgus ülevaatus tekitab loodetavasti arutelusid ja ideede jagamisi, mis lõpptulemusena parandavad koodi kvaliteeti ja aitavad kaasa ka osaliste isiklikule arenemisele. Code Review aitab meeskonna liikmeid kursis hoida teiste tegemistega koodibaasis ning rakenduse erinevate osade arenguga. Tagasiside jagamise juures on äärmiselt oluline emotsionaalne intelligentsus. Arendaja suhtub alati oma koodi teatava isiklikkusega. Kriitika peab seepärast olema konstruktiivne ja mõistvalt serveeritud. Vastasel juhul ei saavuta me loodetud hüvesid vaid tekitame vaid lisatüli.

How to stop wasting your time and start performing useful code reviews

“Make jar not war” – Twelve-Factor App

Rakenduse war arhiivi pakendamine on muutumas mõnes mõttes antipatterniks. Traditsiooniliselt pakitakse veebirakendus war faili, millele tuleb seejärel leida koht mõnes aplikatsiooniserveris. Tihti sisaldab selline aplikatsiooniserver veel teisi ware. Wari uuendamine serveris aga ei pruugi olla triviaalne. Halvimal juhul tuleb server taaskäivitada häirides sellega kõigi sisalduvate rakenduste tööd. Samuti ei ole rakendusserveri automatiseeritud üles seadmine lihtne. Seepärast on populaarseks muutunud jar arhiivi pakendatud rakendused, mis sisaldavad oma enda embedded serverit. Populaarseim näide sellisest lahendusest on ilmselt Spring Boot.

Serverit sisaldava ja .jar-i pakendatud rakenduse käivitamiseks on vaja vaid Javat. Lahendus sobib eriti hästi pilvetehnoloogia konteksti, kuid on oluline ka traditsioonilisel platvormil Continuous Delivery praktika juures. Idee poolest võiks infrastruktuur olla ühekordselt kasutatav. Rakenduse keskkonna võib ära visata ja taasluua. Kuna .jar arhiiv on käivitatav kus iganes on olemas Java virtuaalmasin, teeb see keskkonna loomise tunduvalt lihtsamaks. Jar eemaldab ühe muutuja mängust – rakendusserveri. See suurendab paarsust production ja arenduskeskkondade vahel. Kaovad serverist tulenevad erinevused ja suureneb kindlus, et rakendus töötab erinevates keskkondades samamoodi.

Need põhimõtted ja mitmed teised on koondatud metoodikasse, mida nimetatakse Twelve-Factor Appiks. Pean tunnistama, et polnud sellist mõistest varem kuulnud. Midagi täiesti revolutsioonilist ei paista see mängulauale toovat. Ometi pakub see üsna head kokkuvõtet headest praktikatest, mida arhitektuuri valimisel järgida. Täpsema kirjelduse leiab 12factor.net. Saab näha, kui palju kõlapinda metoodika tulevikus saavutab.

The Twelve Factor app: Best Practices for Java Deployment

Kõigi muudatustega kaasneb teatav hind, vahel ei pruugi see hind üle kaaluda mõne uuendusliku vahendi kasutuselevõtust loodetud tulu. Vahel võib ka juhtuda, et uus asi lahendab suuresti meie tänased mured, kuid tekitab hoopis uusi muresid. Oma üsna lühiajalisele kogemusele tuginedes tundub mulle siiski, et tarkvaraarenduse maailmas on toimumas üsnagi suured muutused, millel tasub vähemalt silma peal hoida.

Leave a Reply

Your email address will not be published. Required fields are marked *