ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 113
Abonament PDF

Experts panel: DevOps

Ovidiu Mățan
Fondator @ Today Software Magazine



EVENIMENTE


Am discutat la evenimentul de lansare TSM 112 cu invitații noștri despre tehnologiile DevOps:

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.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

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

INTERVIURI VIDEO