Cloud Computing – AWS pe înțelesul tuturor: interviu cu Ioana Vântu, trainerul cursului

Înainte de startul cursului Cloud Computing – AWS din cadrul FutureReady IT, am stat de vorbă cu Ioana Vântu, trainerul cursului și membră a echipei Evozon, despre cum a gândit cele 30 de ore, ce vor construi participanții și cum arată o seară de curs.

1. Pentru început, cum ai descrie cursul Cloud Computing – AWS unei persoane care este interesată de domeniu, dar nu știe încă exact la ce să se aștepte?

Cel mai simplu așa: e un curs în care înveți să folosești AWS așa cum îl folosesc oamenii la muncă, nu așa cum apare în broșuri. AWS are peste 200 de servicii și, la prima vedere, seamănă cu un mall uriaș în care intri fără hartă. Te pierzi în zece minute și ieși cu lucruri de care nu aveai nevoie. Cursul e harta. Îți arăt care sunt cele 15-20 de „magazine" în care intră toată lumea, cum se leagă între ele și de ce.

Nu trebuie să știi cloud dinainte. Ajută să ai o idee generală despre ce e un server, o bază de date sau o rețea, dar restul construim împreună, cu mâinile pe consolă. Nu e un curs în care stai 30 de ore și te uiți la slide-uri. Promit.

2. Cum ai construit parcursul celor 30 de ore și cum vor evolua participanții de la primele concepte până la finalul programului?

Sunt 10 sesiuni de câte 3 ore și le-am gândit ca pe construcția unei case: fundație, pereți, acoperiș, apoi te muți în ea și vezi ce scârțâie. Primele sesiuni sunt fundația: ce înseamnă cloud, cum funcționează conturile și permisiunile (IAM), cum arată o rețea în AWS (VPC) și cum pornești un server (EC2). Apoi ridicăm pereții: load balancere, auto scaling, baze de date (RDS), stocare (S3), monitorizare și audit (CloudWatch, CloudTrail). Urmează serverless, adică cum faci lucruri fără să mai ai grijă de servere deloc, și o sesiune dedicată arhitecturii, securității și costurilor, ca să pui totul cap la cap fără să primești o factură surpriză. Partea practică o facem pe laboratoare din AWS Skill Builder sau pe conturi AWS de test, individuale sau în echipă, așa că tot ce discutăm se și încearcă pe loc.

Sesiunile 8 și 9 sunt proiectul practic. Participanții primesc un brief de la un „client" fictiv și, în echipe, proiectează arhitectura, estimează costul, o construiesc de la zero și o pun în funcțiune. Sesiunea 10 e recapitulare și evaluare finală. Evoluția e vizibilă cu ochiul liber: în prima sesiune oamenii apasă butoanele cu grija cu care folosești un bancomat în străinătate, iar în sesiunea 9 se ceartă prietenește dacă un NAT Gateway merită banii. Ăsta e momentul în care știu că a mers.

3. Care sunt temele și serviciile AWS pe care vei pune cel mai mult accent și de ce le consideri importante pentru activitatea profesională actuală?

Nucleul e format din IAM, VPC, EC2, load balancing cu auto scaling, RDS, S3, CloudWatch și Lambda. Motivul e simplu: în aproape orice proiect real pe AWS, cea mai mare parte din ce vezi în producție se învârte în jurul acestor servicii. Dacă le stăpânești, restul ecosistemului devine „încă un serviciu pe care îl învăț într-o după-amiază".

Insist mult pe IAM și VPC, deși nu sunt cele mai spectaculoase teme. IAM e despre cine are cheia de la care ușă, iar VPC e planul clădirii: ce camere există, care au ferestre spre stradă și care nu. Majoritatea incidentelor din cloud despre care citim în presă vin de la un bucket S3 lăsat public sau un port deschis „doar pentru test". Al doilea accent e pe costuri. Cloud-ul e ca un robinet: extraordinar de convenabil, dar dacă îl uiți deschis, plătești. Așa că lucrăm cu Pricing Calculator și Cost Explorer până devine reflex să întrebi „și cât costă asta pe lună?".

4. Cum se va împărți cursul între explicații teoretice și activități practice? Ce tipuri de demonstrații, exerciții sau scenarii ai pregătit pentru participanți?

Cam 40% teorie și 60% practică, iar teoria e mereu cu diagrame și exemple, nu cu definiții. O sesiune tipică începe cu o oră de explicații, apoi trecem în consola AWS și facem cu mâna noastră ce am discutat. Lab-urile urmăresc firul cursului: creezi utilizatori și politici IAM, construiești o rețea de la zero și pornești primul server, pui un load balancer în față și vezi cum împarte traficul, configurezi auto scaling și urmărești cum apar servere noi când crește încărcarea, lansezi o bază de date RDS, lucrezi cu S3 și verifici în CloudTrail cine a făcut ce. La serverless construim un mic API cu Lambda și API Gateway, iar în sesiunea de arhitectură desenăm în draw.io și estimăm costuri pentru un scenariu real.

Partea mea preferată vine în proiectul final. După ce echipele au aplicația funcțională, cu monitorizare și backup, urmează o fază de „chaos engineering" controlat. Adică le stric ceva: o regulă de securitate, un target din load balancer, o rută. Ei trebuie să găsească problema urmând o metodologie, nu ghicind. E ca la școala de șoferi, când instructorul trage de frână fără să te anunțe. Nu e cel mai plăcut moment, dar e cel pe care îl ții minte.

5. Cum îți propui să lucrezi cu participanții pe parcursul sesiunilor și ce rol vor avea întrebările, exemplele din proiecte reale și schimbul de experiență?

La grupa anterioară am avut 16 oameni, de la „am auzit de S3" până la „rulez infrastructură în producție". Sună a rețetă de dezastru, dar a fost exact opusul. Cei cu experiență au adus scenarii de la job, iar cei noi au pus întrebările pe care ceilalți se sfiau să le pună. Amândouă categoriile au plecat mai câștigate. Indiferent de nivelul grupului, ce contează pentru mine e ca discuția să fie vie: un chat activ, cu linkuri, întrebări și observații din practică.

Întrebările sunt binevenite oricând, nu la final. Dacă o întrebare deraiază puțin sesiunea, de obicei e semn că e o întrebare bună. Aduc constant exemple din proiectele la care am lucrat: migrări, optimizări de cost, arhitecturi care au mers și, mai ales, greșeli care ne-au învățat ceva. Și țin cont că sesiunile sunt seara, după o zi de muncă. Nu vreau să fie o prelungire a zilei de muncă, ci partea din zi în care ai voie să încerci lucruri și să le strici fără consecințe.

6. La finalul cursului, ce ți-ai dori ca participanții să poată face concret și cu ce perspectivă asupra ecosistemului AWS să rămână?

Concret: să poți lua o cerință de business, de genul „avem o aplicație web, câteva mii de utilizatori, nu vrem să pice și avem bugetul ăsta", și să desenezi o arhitectură AWS rezonabilă, să estimezi costul, să o construiești în consolă și să știi unde te uiți când ceva nu merge. Bonus: să citești o factură AWS fără să te apuce palpitațiile. Cei care trec evaluarea finală primesc și un certificat de absolvire, dar cel mai valoros lucru cu care pleci e încrederea că poți deschide consola la job și spune „hai să încercăm".

Ca perspectivă, aș vrea să rămână cu ideea că AWS nu e nici magie, nici monstru. E o cutie mare de piese Lego cu instrucțiuni bune. Nu trebuie să știi toate cele 200 și ceva de servicii. Trebuie să știi bine cele 15 de bază și să știi cum se caută restul. Dacă la final participanții se uită la un proiect din firma lor, încep instinctiv să deseneze arhitectura pe un șervețel și se întreabă cât ar costa pe lună, eu mi-am făcut treaba.