ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 92
Abonament PDF

Expert panel – Microservices

Ovidiu Mățan
Fondator @ Today Software Magazine



INTERVIU


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).

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects