A fost odată o idee: să găsim o modalitate cât mai rapidă prin care să asigurăm conformitatea unui produs software existent, cu noile standarde impuse de către client. În principiu, părea simplu... În realitate, aceasta se întâmpla acum 12 luni și încă nu este gata. Ce am realizat de atunci, ce am învățat și ce am face diferit, vom vedea în continuare.
Ecosistemul existent era compus dintr-un soft dezvoltat în decursul multor ani, infrastructură găzduită în AWS (în mare parte EC2, ECS-EC2, RDS, S3, SQS, SNS...), management al infrastructurii cu Terraform și Ansible și management al configurațiilor cu Chef și Ansible. Atât echipele de developeri, cât și cele de SysOps sunt localizate în România și US.
Principalele cerințe au fost:
În afară de înlocuirea instanțelor cu containere, unde softul trebuia adaptat de către developeri, restul sunt sarcini evidente pentru inginerii SysOps. Astfel, s-a decis crearea unei echipe SysOps specializate.
Proiectul pe care ne-am hotărât să îl realizăm este un wrapper peste Terraform care să ne permită deploymentul selectiv de părți de infrastructură în diferite conturi AWS, care să poată interacționa cu imagini Docker și care să fie utilizat prin instrucțiuni simple în linie comandă.
Practic, ne făceam și nouă viața mult mai ușoară, codul de Terraform fiind foarte vechi și stufos și suferind de câteva desincronizări din cauza aceasta.
Aproximativ o lună a durat până am stabilit o arhitectură a conturilor AWS, apoi am trecut la dezvoltarea propriu-zisă. În primă instanță, am dorit să îl dezvoltăm în Go, dar pentru un Proof of concept am creat scripturi Bash. Demonstrațiile inițiale au mers foarte bine, dar au mai fost solicitate câteva teste pentru a verifica și alte aspecte.
Prima provocare majoră a fost denumirea diferitelor componente din structura tool-ului. Astfel avem "platformă", "serviciu", "componentă", "tip de componentă", "stack". Termeni care, în alt context înseamnă ceva, la noi înseamnă ceva specific.
După aceste teste, am ajuns în situația în care aveam deja multe scripturi scrise în Bash și am hotărât că vom evalua ulterior trecerea la Go.
Toolul este modular, fiecare modul având sarcini precise. După trei luni aveam realizate câteva module și începeam testarea cu codul aplicației. Softul existent avea unele servicii care deja rulau în containere, iar celelalte servicii urma să fie portate pe Docker în "scurt" timp.
A doua provocare a apărut în momentul în care am constatat că developerilor le este destul de incomod să folosească un tool gândit de o echipă de SysOps, pentru operații asupra infrastructurii. A fost nevoie de ceva intervenții în partea de interacțiune cu utilizatorul pentru a avea un tool comod, pentru toată lumea care îl va folosi.
După mai bine de patru luni, începeam integrarea cu softul. Am ales să portăm pe noua infrastructură generată cu toolul nostru, pe rând, serviciile care deja rulau în containere. La fiecare serviciu apăreau câteva noi necesități care erau rezolvate prin completarea modulelor existente sau prin introducerea de module noi.
În paralel, developerii au început modificarea serviciilor care nu rulau încă în containere.
De portarea serviciilor care rulau deja în containere s-a ocupat echipa de SysOps. Pentru a o putea duce la bun sfârșit, a fost nevoie de integrarea unui developer în echipă, softul având și el nevoie de câteva modificări.
Primul serviciu a fost portat și validat după mai bine de șase luni de la începerea proiectului.
Mergând pe aceeași direcție, a fost începută o colaborare foarte strânsă între developeri și echipa SysOps pentru modificarea serviciilor care nu rulau încă în containere Docker.
În acest moment, ne apropiem de pragul de 12 luni de la startul proiectului și mai sunt câteva servicii de portat. Termenul pentru validarea portării este peste o lună.
Ce învățături putem extrage din experiența de până acum?
Iar concluzia tuturor învățăturilor de mai sus este: toolul intern ar trebui să fie tratat ca un software livrat unui client extern.
Chiar dacă nu e o certitudine că dragostea durează doar trei ani, cu siguranță dezvoltarea unui tool intern menit să ne facă viața mai ușoară, ar trebui să dureze mai puțin de un an.
de Vasile Boris
de Ovidiu Mățan
