Am discutat la evenimentul de lansare a revistei de luna trecută[^1], ianuarie 2020, despre cum a apărut conceptul de microservicii, în ce proiecte sunt folosite de obicei, arhitectura software a acestora dar și cum se realizează deployment-ul. Invitații la panel au fost:
Ovidiu Mățan: Vă rog să vă prezentați.
Máté Láng: Experiența mea este în migrarea datelor și a serviciilor, în procese de infrastructură și îmbunătățirea proceselor. Am fost și CTO la un start-up din Marea Britanie, care era o platformă de micro-learning, la care am lucrat cu o echipă de 14 oameni din Cluj. Din păcate, nu am prins runda a doua de finanțare, dar produsul este încă în cloud, este live și trăiește. Pentru mine este o surpriză având în vedere că nici măcar un developer nu a mai lucrat la produs de un an. La Connatix lucrez pe infrastructură și microservicii.
Daniel Tătar: Eu lucrez de zece ani la msg. Am început cu testare pe web, desktop, mobile. Acum lucrez la un proiect bazat pe microservicii și testez partea de integrare, partea de end-to-end. Facem ambele tipuri de testare, dar prepoderentă este testarea automată.
Cum au apărut microserviciile? Existau microservicii și înainte de trendul Agile sau au apărut din neant?
Máté Láng: Cu siguranță existau. Este suficient să ne uităm la cum au apărut Linux și Unix. Putem să ne uităm și la utilitarele care sunt, de fapt, niște microservicii. Interesul este, pe de altă parte, mult mai nou. Microserviciile sunt rezulatul logic al dorinței de a folosi în mai multe locuri același business logic. Conceptul de microservicii este destul de vechi. Ca buzz word este destul de nou.
Daniel Tătar: Pentru mine, microserviciile există de când am început testarea de microservicii. Au apărut ca o necesitate: arhitectura cloud e foarte răspândită iar scalarea este foarte importantă. Pentru mine partea de microservicii este destul de transparentă pentru că eu văd endpointurile. Testele trec sau cad în funcție de cum se comportă acel microserviciu.
Care sunt proiectele pentru care utilizați microservicii? Ce tehnologii folosiți și cum funcționează?
Máté Láng: Cunosc microserviciile de la Connatix mai puțin la nivel de business și mai mult la nivel de disponibilitate, cerințe tehnice. Din punctul meu de vedere, microserviciul reușește să rezolve o problemă de business la nivel reutilizabil și generic. Microserviciile pot fi destul de independente de businessul, pe care dorim să îl facem. De exemplu, am lucrat cu un microserviciu de learning board. Putem vorbi despre acest microserviciu chiar și fără să știți ceva despre micro-learning, deoarece un learning board poate fi folosit și în alt context, de exemplu gaming, concurs sau olimpiadă. Putem vorbi despre acest microserviciu fără a ști multe despre contextul în care acesta este utilizat. Şi la Connatix avem foarte multe microservicii și bineînțeles că luând în calcul cele câteva zeci de milioane de eventuri pe minut care trebuie să aibă o latență deosebit de mică, avantajul microserviciilor este că putem gestiona separat partea de scalare, putem gestiona mai bine failure scenarios. Un avantaj al microserviciilor este că pot fi scrise în orice limbaj. Totuși, există câteva tendințe. GoLang vine puternic din spate, fiind extraordinar de light-weight. La Cluj încă nu vedem acest lucru, aici fiind mai răspândit limbajul Java. Noi folosim preponderent .NET pe partea de backend. Folosim și Python în partea de Machine Learning.
Daniel Tătar: Echipele pot fi distribuite, pot lucra din locuri diferite, pe limbaje diferite. Acest lucru permite dezvoltarea în paralel a microserviciilor, deci aplicația poate merge mult mai repede. Un alt avantaj al microserviciilor este scalarea, cu alte cuvinte în cloud putem încărca aplicația cu alte avantaje și metode față de o aplicație monolit. Putem folosi GetLink pentru load testing și pe baza logurilor obținute din Kibana pentru cloud se pot configura containerele pentru microservicii, astfel încât să se facă un load balancing pentru microserviciile de care avem cea mai mare nevoie. Ştiu ce trebuie făcut cu microserviciile din perspectiva loadului. Un alt avantaj este că această soluție în cloud permite accesul a zeci de mii de utilizatori. Microserviciile noastre se bazează pe Java și nu neapărat pe SAP. Faptul că un microserviciu oferă o interfață API permite ca cererile de resurse sau modificarea resurselor respective să fie făcute independent de limbajul de programare în care au fost scrise microserviciile și transparent pentru resursele de care avem nevoie. De exemplu, o soluție este generarea de resurse pe baza de fișiere YAML, adică o resursă este descrisă într-un format foarte asemănător cu JSON, iar pe baza acestei resurse, se generează alte resurse care ne dau practic metode Java, pe care le putem folosi pentru a accesa microserviciul.
Cum faceți deployment când aveți sute sau mii de servicii?
Máté Láng: Trebuie să definești niște primitive cu care poți lucra, apoi orice fel de automatizare este necesară pentru că mai multe persoane se ocupă de microservicii. Interacțiunea dintre servicii este cea mai complexă chestiune care trebuie rezolvată. Putem scala orizontal. Monitorizarea dependințelor se face prin versionare semantică. Pentru dependințe putem folosi consumer-driven contract tests, care mă asigură pe mine, echipă care fac mentenanță, că nu voi face schimbări majore (breaking changes) din punctul de vedere al consumatorului. Acest lucru este util când avem echipe distribuite care nu comunică direct și periodic. Echipele distribuite încearcă să-și transpună procesele de comunicare în automatizare.
Daniel Tătar: Partea de deployment revine celor de la DevOps. Se folosește Helm, iar în secțiunea de automatizare și de rulare de servicii se poate rezolva problema scalării orizontale. Pentru testare, folosim JUnit și REST Assured (folosit pentru representation state transfer, adică pentru cererea de resurse prin HTTP sau pentru modificarea resurselor care există tot prin intermediul resurselor normale de HTTP).
de Daniel Tatar
de Ovidiu Mățan
de Diana Oniga
de Mihai Talpoș
