Am discutat la evenimentul de lansare TSM 112 cu invitații noștri despre tehnologiile DevOps:
Radu Coțofană - CTO @ Connatix ,
Ciprian Sorlea - CTO @ Nordlogic,
Ovidiu Mățan: Cât de complexe sunt procesele DevOps la voi în companii?
Radu Coțofană: La noi partea de Kubernetes este undeva la 98-99% din toate deploymenturile pe care le avem. Sunt anumite aspecte care ne împiedică să ajungem la 100%: performanță sau faptul că în unele cazuri nu se suportă Kubernetes. Avem trafic la 300-400 de noduri, cu auto-scaling vertical și orizontal. Avem integrare cu Spot pentru lansarea automată de noduri, GPU, labeling diferit pentru diferite tipuri de noduri. Referitor la scalabilitate, lucrăm foarte mult cu KEDA, de exemplu pentru scalarea unor servicii ce au high CPU usage. E o infrastructură mare. Avem trei clustere mari de Kubernetes (Production, Operation, Staging) cu planuri pe termen scurt sau mediu să deschidem mai multe clustere în diferite zone geografice. Dorim îmbunătățiri ale performanței și high availability.
Ciprian Sorlea: Nu mă pot lăuda cu dimensiuni atât de mari la nivel de clustere Kubernetes, deoarece noi nu suntem o companie cu produs propriu care să scalăm până la Lună și înapoi. Suntem o companie ce oferă soluții multiple pentru clienții, fiind la nivel de noduri. Avem momentan un client cu un setup ce are 7 sau 8 clustere distribuite pe diverse regiuni combinate, către 60-70 de noduri. La setupurile noastre am încercat să maximizăm nivelul operațional. Aceste medii se creează dimineața. Se face data provisioning și se începe execuția, iar seara se face phase out, adică se șterge toată infrastructura, ceea ce aduce optimizări de costuri foarte mari.
Iacov Nicolaev: Nu pot vorbi despre toată compania, deoarece mare parte a aplicației se află în Asia. În România, ne ocupăm cu produse geo, hărți, AI, Machine Learning. Folosim clustere Kubernetes pentru AI, Machine Learning și pentru niște servicii pe care le dăm în producție către parteneri și comunitate. Momentan, avem patru clustere, trei fiind pentru producție și având fiecare în jur de 200 de noduri unde se face Machine Learning pe bază de GPU, de noduri scalate automat.
Când vorbim de DevOps, lumea vorbește de Kubernetes. Este aceasta soluția generală?
Iacov Nicolaev: Și în afara Kubernetes există practici DevOps. Istoric vorbind, prin simpla utilizare a GIT sau a unui version-control system, avem deja o etapă de folosire a DevOps. Kubernetes nu e un trend, ci e un fenomen de facto în lume. Kubernetes a adus schimbări în modul de lucru, de exemplu în stilul de monitorizare. De asemenea, înainte aveam un sistem de monitorizare unde adăugam mașini manual. Eram acei ingineri care aveau grijă de o listă de monitorizare. Când a apărut Kubernetes, s-au schimbat și necesitățile. Acesta este motivul pentru care a fost creat Prometheus, anume pentru posibilitatea de a monitoriza sistemele automate pe bază de service discovery. Orice sistem se poate declara individual într-un sistem de monitorizare sau de logging. Această filosofie Kubernetes o observ și în alte tooluri.
Ce procent din munca voastră reprezintă partea de DevOps?
Radu Coțofană: Fiecare companie decide ce face rolul de DevOps. La Connatix partea de DevOps a presupus setup de server, securitate, atribuții ce au revenit echipelor clasice IT. Prin Kubernetes si Prometheus, rolul inginerului DevOps a devenit acela de a crea o infrastructură ce se scalează singură. Partea de development nu ar trebuie să fie interesată de infrastructură, nu că nu ar trebui să știe cum funcționează, dar echipa de DevOps trebuie să fie responsabilă de automatizarea proceselor și reducerea nevoii de feedback între echipe. Echipa de DevOps nu se ocupă de ceea ce face fiecare serviciu sau ce resurse are sau cum comunică. Noi avem undeva de la patru DevOps la 50 de developeri.
Există start-upuri care dezvoltă tooluri DevOps? Sunt interesat de partea de inovație în domeniu.
Ciprian Sorlea: Inovație există peste tot, de exemplu tehnologie care îți permite să folosești un cluster de Kubernetes fără a te interesa procesele din spate ca developer. Nu mai sunt chiar startup, dar Ambassador are inovație în domeniu. În rest, apar multe tooluri pe Cloud Native Computing Foundation.
Radu Coțofană: Există o linie de demarcație subțire când vine vorba de ceea ce trebuie să știe un developer, adică să nu îl intereseze unde rulează aplicația, cum funcționează sau cum comunică cu alte aplicații. Se restrânge expunerea developerului la informații noi, ceea ce duce la neînțelegerea arhitecturii per total. Nici să fii pe partea cealaltă nu este în regulă, adică un developer să știe tot ce știe un DevOps. Nici direcția Platform as a Service nu e chiar optimă.
Ciprian Sorlea: De acord, se cere optimizare, deoarece există o cerere mare și resurse puține. Prin urmare, tendința low-code a intrat și pe zona operațională. Noi avem proiecte cu foarte multe microservicii și configurarea (fie că facem deployment cu Kubernetes, Docker Swarm sau PaaS) implică destul de multă muncă pregătitoare. Deși avem tooluri care generează 99% din setupul pe care trebuie să îl facă un developer, am ținut ca ultimul pas, acel 1%, să nu se facă automat, ci să forțez dezvoltatorul să înțeleagă lucrurile generate. E un low-code pe zona de asistență, ca un auto-complete într-un editor de cod.
Putem vorbi de technical debt în zona de DevOps?
Iacov Nicolaev: Evident că există o formă de technical debt, dar nu trebuie neglijată nici partea de suport. E greu de vorbit de technical debt. În DevOps apar mereu lucruri ce trebuiau făcute ieri. Pentru DevOps, cea mai bună metodă de lucru nu e în sprint, ci în Kanban. Sprinturile se opresc acolo unde începe partea de suport. Trebuie să minimizăm technical debt prin automatizări.
Radu Coțofană: Probleme sunt. Poți avea downtime chiar dacă ai făcut totul perfect. Chiar și pe partea de Kubernetes, trebuie să fii la zi, să faci upgrade-uri, să modifici charturi. Technical debt nu înseamnă neapărat că ai făcut tu ceva greșit.
Cum va evolua DevOps, spre o variantă simplificată pentru oricine sau spre o variantă complexă pentru specialiști?
Ciprian Sorlea: Voi spune ce am spus acum vreo 5-6 ani la primul panel TSM la care m-ai invitat. Vorbeam atunci de o transformare a dezvoltatorilor din zona de full-stack în full life-cycle development. Nu e vorba de un developer care scrie cod, trimite codul spre o platformă și gata, ci de developerul care știe unde rulează codul respectiv, ce end-user îl folosește, cum se monetizează etc. DevOps face parte din acest ciclu. Va mai dura până când se vor reconfigura așteptările la nivel de industrie, poate peste vreo 20 de ani, dezvoltatorii de top vor fi cei care se vor gândi la partea de business, la UX, la securitate, la cerințe non-funcționale, având tot mindsetul de DevOps în mod nativ. E vorba de nivelul de maturitate necesar pentru a rămâne competitivi pe piață. Acum 15-20 de ani, un developer bun era acela care cunoștea o tehnologie foarte, foarte bine. Acum, cerința pieței este să fii generalist. Trebuie cunoscute aspectele operaționale. Mulți dezvoltatori lucrează deja cu Docker, ceea ce îi face mai orientați spre zona de DevOps.
Iacov Nicolaev: Voi aborda problema din două puncte de vedere. Un punct de vedere este al practicilor și al filosofiei DevOps. Puppet face un raport anual al DevOpsului, aceștia definind deja etapele de evoluție a practicilor DevOps într-o companie. Etapa minimă este un GIT. Etapa ultimă, cea mai complicată, la care foarte puține companii au ajuns este aceea la care se apasă un buton și ai un deployment de aplicație. Acolo se termină DevOps, deoarece DevOps se preocupă cu aducerea codului de la programator la server. Un alt punct de vedere ține de ceea ce a spus Ciprian, anume cum se dezvoltă un developer. La Grab încurajăm toți dezvoltatorii să se intereseze de DevOps, de Terraform, de Docker. Entitatea care evoluează nu e o persoană, ci este echipa. Dockerul a fost scris acum ceva timp de un DevOps, dar acum este dezvoltat de programatori. Echipa trebuie să poată citi infrastructura, să beneficieze de toată transparența din practicile DevOps.
Radu Coțofană: Idealul este a avea un developer care să atingă toate punctele menționate din punct de vedere tehnic, arhitectural, structural. Cei ce opun rezistență își vor pierde avantajul competitiv, dar este foarte greu să ai pe cineva cu un nivel ridicat în toate aceste arii. Prin urmare, rolul DevOpsului este de a automatiza anumite procese. De exemplu, să faci un deploy în Kubernetes și să faci ca podurile să nu stea pe același nod s-ar putea să fie dificilă pentru mulți programatori. La Connatix am făcut un chart custom care a transformat aspectele dificile ale Kubernetes în ceva ușor de urmărit pentru programatori. Aceasta nu înseamnă că programatorul nu are acces la detalii sau că îi sunt ascunse. DevOpsul trebuie să ofere tooluri ce să simplifice viața programatorului.
Ar trebuie să se studieze DevOps în școală?
Ciprian Sorlea: Aspectele elementare de DevOps se făceau de când eram eu student. DevOps vine cu o filosofie, cu un mindset, cu niște practici care, până la urmă, automatizează niște procese care erau făcute și înainte manual. Lucrurile de actualitate nu se studiază explicit. Kubernetes și Docker, fiind deja mai vechi pe piață, ar trebuie studiate. În străinătate, există astfel de cursuri.
Radu Coțofană: Nu cred că există, dar ar trebui să existe.
Iacov Nicolaev: Sunt de acord cu ce s-a spus până acum. Universitățile se sincronizează foarte greu cu cerințele de business.
de Ovidiu Mățan
