*Material scris de Cosmin Ilie (foto jos), Software Testing Manager in cadrul Optymyze.

Cosmin Ilie OptymyzeMai multe studii din ultimii ani sugereaza ca utilizarea tipica este intre 6% si 12%, in timp ce, spre exemplu, Google, foloseste intre 20% si 40% din capacitatea disponibila. In acest context, marile companii, incepand cu Google, au observat problema utilizarii scazute si au inceput sa caute solutii. Rezultatul a fost aparitia platformei „Borg”, urmata apoi de proiectul „Apache Messos” si modificarile aduse de Twitter acestuia, publicate sub proiectul „Apache Aurora” .

Pentru eficientizarea utilizarii, modelul propus este similar cu cel prin care limbajele de programare de generatie noua interactioneaza cu resursele hardware. Atunci cand natura actiunilor indeplinite de aplicatie este concurenta, limbajul de programare deleaga sistemului de operare activitatile complexe. Astfel, este responsabilitatea sistemului de operare sa asigure utilizarea eficienta a firelor de executie pe mai multe nuclee de procesor, precum si accesul eficient la I/O ( fie ca vorbim despre accesul la sistemul de fisiere sau prin intermediul retelei), eliberand astfel programatorul de acest efort.

Conceptul de “resource scheduling” poate fi astfel extins si la nivelul unui datacenter prin intermediul acestui tip de platforma, eliminand astfel interventia umana din procesul de lansare, configurare si administrare al aplicatiei. Optimizarea se realizeaza in principal prin cresterea densitatii aplicatiilor care ruleaza pe hardware-ul disponibil. Practic, asa cum intr-un joc de tetris scopul este asezarea blocurilor cat mai eficient, tot asa un “scheduler” asaza aplicatiile pe resursele hardware (de obicei o ferma din sute sau mii de servere) astfel incat nivelul de utilizare a resurselor sa fie optim.

Pentru lucrul cu platforma de „scheduling” sunt oferite un set de primitive care pot fi folosite de utilizatori pentru a putea interactiona cu sistemul. Utilizatorul poate, folosind un limbaj descriptiv, sa specifice parametri de rulare a aplicatiei (de exemplu, memoria necesara aplicatiei, nivelul de acces la alte aplicatii sau servicii, procesor, operatii I/O, etc.) iar rolul platformei de „scheduling” este de a se asigura ca aplicatia ruleaza in conditii optime si primeste resursele descrise. Modelarea conditiilor de rulare poate fi destul de avansata, in ideea in care pot fi specificate si conditiile de eroare, pasii pe care platforma de „scheduling” poate sa ii parcurga in incercarea de rezolvare a erorii, indicatori de performanta la care am dori ca platforma sa reactioneze (de obicei pornind mai multe instante ale aplicatiei care sa suporte traficul generat), indicatori de disponibilitate a aplicatiei pentru utilizatorii ei (platforma incercand astfel sa optimizeze operatiunile din flota de servere, astfel incat sa respecte bugetul de intreruperi ale activitatii aplicatiei specificat de administrator).

Desi pare a fi o solutie magica a tuturor problemelor, in realitate este doar un schimb intre complexitatea la nivelul platformei si crestea agilitatii intr-o maniera care sa mentina costurile la un nivel optim.

O alta problema este faptul ca aplicatia trebuie proiectata pentru a rula in astfel de medii foarte eterogene. Pentru ca platforma de „scheduling” nu ofera garantii asupra locului unde aplicatia va rula, este responsabilitatea arhitectului sase asigure ca dependintele aplicatiei sunt minime, iar aplicatia expune toate mijloacele necesare pentru a putea investiga eventualele probleme de configurare, erori sau probleme de performanta care pot aparea la executie. La fel, aplicatia trebuie sa ofere platformei de „scheduling” un set de indicatori standard, care pot fi folositi pentru a determina daca aplicatia functioneaza corect si in parametri nominali de performanta.

Rezolvarea problemei dependintelor este data de Google in lucrarea publicata pentru platforma lor de „scheduling” („Borg”) si sugereaza crearea unui mediu static, care sa inglobeze toate dependintele aplicatiei, fara a afecta caracteristicile de performanta sau a adauga un cost suplimentar la nivelul resurselor hardware. Solutia lor a fost utilizarea unor concepte popularizate de distributia de Unix FreeBSD, care ofera posibilitatea de izolare a unui proces folosind un mecanism numit “FreeBSD jail” . Aceeasi idee a fost adoptata si in distributiile Linux, fiind mai apoi popularizata de compania Docker prin aplicatia care ii poarta numele.

Devine astfel posibila folosirea acestor tehnici si metode pentru companiile mai mici, in special odata cu aparitia platformei open-source Kubernetes (numele vine din greaca si inseamna carmaci) la care Google este unul dintre cei mai mari contributori. Costurile sunt generate in acest caz de complexitatea sistemului si de nivelul de cunostinte necesar inginerilor care vor administra sistemul. Alternativa este data de oferirea atat de catre Azure cat si de catre Google Cloud a unui model in care acestia furnizeaza Kubernetes ca serviciu in cloud-ul lor.

Beneficiile adoptarii acestei noi paradigme, denumita de unii “cloud native”, sunt destul de mari, iar impactul in piata se simte deja. Majoritatea furnizorilor de platforme „cloud” ofera servicii care permit rularea de Docker “containers”, fie prin intermediul lui Kubernetes (Google Cloud, Azure), fie prin dezvoltarea unei platforme similare (ECS pentru Amazon Web Services), dar migrarea presupune de cele mai multe ori un efort in etapa de dezvoltare a aplicatiilor.

Pentru firmele care dezvolta in principal aplicatii pe platforma Java (cum este si Optymyze), platformele si bibliotecile noi ca Spring Boot ofera o cale simpla de migrare la un model mai potrivit pentru "cloud native" fata de traditionalele servere de aplicatii de dimensiuni mari. Spring Boot nu este singura tehnologie care se adreseaza acestor nevoi, piata fiind in plina dezvoltare atat prin oferta de produse comerciale cat si prin platforme open-source. Tendintele incep insa sa se contureze mult mai clar, iar rezultatul, asa cum zice si Eberhard Wolff in prezentarea “Death of Java Application Servers” , este ca ne indreptam spre un model in care clasicele servere de aplicatie sunt inlocuite cu un alt model de deployment. De altfel, Optymyze recruteaza specialisti interesati sa lucreze cu aceste tehnologii.

Avantajele alegerii unei platforme precum Kubenetes pentru companiile care merg spre arhitecturi bazate pe microservicii sunt mari atat prin cresterea densitatii aplicatiilor, cat si prin externalizarea unei parti importante a administrarii aplicatiilor catre Kubernetes. Printre cei mai mari utilizatori ai platformei se numara compania Niantic, producatoare a jocului Pokemon GO, care ruleaza pe Kubernetes. Cei de la Google au si publicat un articol legat de colaborarea cu Niantic aici.

Un alt exemplu este cel legat de compania Pearson, unul dintre cei mai mari jucatori din piata de e-learning mondial, care si-au migrat platforma pe Kubernetes, reusind astfel sa creasca agilitatea echipelor de development si oferindu-le posibilitatea de a-si administra singure serviciul dezvoltat, fara a mai include si alte echipe in productie.

Sursa foto: Boiko Y_Shutterstock