DevOps? Microservices? Iată o explicație simplă pentru aceste concepte

Locurile de la festivalul de tehnologie #INGlovesIT s-au ocupat în timp record, aș spune eu, având în vedere că suntem în 23 martie și evenimentul are loc pe 7 aprilie. Workshop-urile s-au dat primele, pe 20 martie erau deja fully booked, cum se zice, iar acum și toate locurile de la prezentări au fost ocupate. Sper că ați apucat unul, dacă vi-l doreați.

#INGlovesIT este un festival internațional aflat la prima ediție (care are loc în România) și aduce, pentru o zi – 7 aprilie, la Deschis Gastrobar, zona Timpuri Noi –, mai mulți vorbitori internaționali pentru a le prezenta dezvoltatorilor niște lucruri destul de avansate și nișate precum machine learning, TensorFlow, planuri post-lansare pentru aplicații, securizare prin containere și niveluri multiple de protecție, modularizare și microservicii și alte asemenea. Agenda este aici.

Sunt patru teme mari:

• big data
• cyber-security
• microservicii
• DevOps

Big data și cyber-security sunt deja destul de cunoscute, măcar la nivel de concept, chiar dacă la implementare ar mai fi mult de lucru în toate companiile. Cel puțin, în ultimele luni, se vede că la securitate cibernetică nu-i ceea ce ar trebui să fie, indiferent că vorbim de servicii mari sau mici. Cred că nu este lună în care să nu aflăm de încă un hacking serios pe la cine știe ce companie, iar dacă afectează un  start-up sau o firmă de mici dimensiuni, e ca și închisă.

Pentru celelalte două, însă, am căutat și eu explicații suplimentare.

Microservices se referă, de fapt, la un tip de arhitectură software în care o aplicație este construită din bucăți mici, independente (acele servicii din nume), această modularitate venind cu multe avantaje: serviciile pot fi testate individual, pot fi actualizate individual dacă se descoperă buguri, pot fi dezvoltate de echipe diferite. Singura condiție este ca acele echipe să vorbească din când în când între ele pentru a pune la punct modul în care aceste microservicii se îmbină unitar în aplicația respectivă, dar de obicei genul acesta de lucruri se stabilesc încă din faza de concept.

Un exemplu bun poate fi o aplicație de mobile banking. Opțiunea de a vedea pe hartă ATM-urile din zonă nu are nimic de-a face cu opțiunea de a plăti, direct în telefon, facturile de la furnizorii de utilități. Cele două sunt microservicii separate, pot fi dezvoltate separat, trebuie doar avut grijă ca design-ul să fie unitar și meniul principal să afișeze toate opțiunile.

Poate că veți spune că așa este normal să se dezvolte orice aplicație, pentru că sună logic. Eu am văzut însă și companii mari care, la jumătate de an după ce plecase dezvoltatorul unei aplicații, încă îl mai chemau din când în când pe acolo ca să le arate ce și cum făcuse, pentru că, lipsind modularitatea, noii programatori abia se prindeau cum se îmbina o treabă cu alta și cum funcționau ele.

Mie arhitectura de microservicii mi se pare foarte avantajoasă, iar părțile negative sunt minore. Modularitatea asigură o dezvoltare paralelă mai eficientă și o testare mai eficientă, plus un dinamism în organizarea echipelor în funcție de cât de dificile sunt acele servicii.

Partea cu DevOps este și mai interesantă. Este un concept ceva mai abstract despre un mod de lucru ce presupune o colaborare mult mai strânsă între dezvoltatorii de software și cei din departamentele operaționale (development și operations).

DevOps presupune modificări în structura organizațională a unei companii. Într-un model tradițional, dezvoltatorii sunt niște oameni de la un etaj care fac programe sau unelte IT pentru oamenii de la alt etaj, care se trezesc cu ele și trebuie să le utilizeze. Țin minte o astfel de implementare în companie a unui software ERP. Producătorii ERP-ului făcuseră noul soft după procedurile oficiale și după ce le-au zis șefii de departamente că ar trebui făcut, dar cei care urmau să utilizeze ERP-ul, angajații care chiar lucrau cu el, ar fi avut nevoie de tot felul de scurtături sau rapoarte mult mai de actualitate pentru afacerile curent.

Nu i-a întrebat nimic, nu a existat exact colaborarea pe care conceptul DevOps o introduce. Rezultatul? A durat câteva luni tranziția la noul soft, s-a muncit mult mai lent până l-au învățat, iar companiile s-au judecat un an și jumătate pe acuzația că softul prost făcut le-a adus pierderi de bani, de eficiență și de oameni.

DevOps introduce această colaborare mult mai strânsă între dezvoltator și utilizator (să-i zicem așa), practic formând echipe mixte. Dezvoltarea este mai dinamică, testarea mai rapidă, reacția “clientului” se vede imediat.

Cea mai bună analogie pe care o pot face este cu uneltele clasice. Dacă-i ceri cuiva o unealtă cu care să bați un șurub, îți va face întâi o cărămidă, să lovești cu ea. Dacă ar colabora strâns cu utilizatorul uneltei, acesta îi va spun că ar avea nevoie și de un mâner, nici gros și nici subțire, că un grip cauciucat ar fi binevenit și că lungimea totală ar fi bine să fie sub 45 cm, că atât de lungă îi este trusa de scule și trebuie să încapă acolo. Iese un ciocan mai bun.

DevOps este genul de lucru pe care afli că l-a implementat o companie și, după un an, și-au redus cheltuielile cu 8% și timpul de dezvoltare cu 23% (cifre scoase din burtă, probabil că la INGlovesIT se vor prezenta studii de caz reale, poate chiar de la organizatorul ING Software Development Center), ceea ce a dus la o economie de bani și un team-building care a rămas legendar, la finalizarea proiectului.

Lumea IT-ului este într-o continuă schimbare, sper că cei care lucrează în ea, indiferent de nivel sau dimensiunea companiei, sunt la curent cu aceste schimbări. Ar trebui să fie, pentru dezvoltarea personală.