AWS vs. Azure vs. GCP: ghid de evaluare a competențelor pe platforme cloud

Problema angajării pe platformă cloud

Ai nevoie de un inginer DevOps senior. Ai cinci candidați excelenți. Doi sunt profund pe AWS; unul e puternic pe Azure; unul folosește GCP; unul e cloud-agnostic, dar cu mai puțină profunzime operațională.

Pe cine angajezi? Depinde. Dar majoritatea echipelor greșesc: fie angajează pentru platforma specifică și creează risc de blocare la furnizor, fie angajează generalistul și descoperă că lacuna de cunoaștere a platformei e mai adâncă decât se așteptau.

Răspunsul corect e să evaluezi ambele: cunoaștere operațională specifică platformei și gândire sistemică transferabilă.

Când să testezi competențe specifice platformei

Testează profunzimea AWS/Azure/GCP dacă:

• Stack-ul tău existent e blocat pe acea platformă
• Nevoia ta de angajare e să adâncești expertiza pe acel cloud
• Cerințele contractuale sau de conformitate impun un cloud specific

Testează fundamente cloud-agnostice dacă:

• Ești multi-cloud sau ai putea migra
• Angajezi gândire sistemică în detrimentul stăpânirii uneltelor
• Candidatul va lucra pe mai multe platforme

Majoritatea echipelor ar trebui să testeze ambele: „Poate opera AWS bine?" ȘI „Poate raționa despre arhitectură independent de platformă?".

Cadrul de evaluare AWS

Competențe de testat

1. IAM și modelare de securitate

   • Poate proiecta acces cu privilegii minime pentru o arhitectură de microservicii?
   • Înțelege SCP-urile vs. politicile inline vs. politicile gestionate?
   • Poate explica de ce nu trebuie folosite credențialele root?

2. Rețea și conectivitate

   • Proiectare VPC: subrețele, rutare, NACL-uri, security groups
   • Când să folosești Direct Connect vs. VPN vs. Internet Gateway
   • Compromisuri de rețea cross-account sau cross-region

3. Stocare și baze de date

   • Optimizare EBS: gp3 vs. io2, throughput provizionat
   • Strategii de failover și backup pentru RDS
   • Politici de ciclu de viață și versionare S3 pentru retenția datelor

4. Scalare a calculului

   • EC2 Auto Scaling Groups vs. Spot Instances
   • Compromisuri ECS vs. EKS
   • Implicații ale cold start-ului Lambda pentru sarcini de producție

Exemple de întrebări

Scenariu take-home:

„Proiectează un sistem care să ingereze 10 GB de logs pe zi de la 100 de instanțe EC2, să le stocheze durabil și să le interogheze cu latență sub-secundă. Buget de 2.000 $/lună. Doar AWS. Explică alegerile".

Un răspuns bun ia în calcul:

• CloudWatch Logs pentru colectare (gestionat) vs. Firehose + S3 + Athena (optimizat la cost)
• Politici de retenție a logurilor pentru gestionarea costurilor
• Strategie de indexare (partiționare Athena sau Elasticsearch)
• Tipare de interogare și dacă latența sub-secundă e reală sau presupusă

Un răspuns slab sare la Elasticsearch fără a întreba dacă e necesar.

Diagnosticare live:

„Instanța ta RDS a ajuns la 80 % CPU, iar task-urile ECS auto-scalate nu se pot conecta la baza de date timp de 2 minute pe oră, mereu la aceeași oră. Spune-mi cum ai depana".

Candidatul ar trebui să gândească:

• Corelarea vârfurilor de conexiune ECS cu sarcina RDS
• Verificarea interogărilor lente prin Enhanced Monitoring
• Căutarea scurgerilor de conexiune (aplicația nu închide conexiunile)
• Considerarea dacă altceva rulează la acea oră (backup-uri, rapoarte)

Cadrul de evaluare Azure

Competențe de testat

1. Identitate și acces (Azure AD / Entra)

   • Managed identity vs. service principals
   • Control de acces bazat pe roluri (RBAC) cu roluri personalizate
   • Politici Conditional Access pentru securitate

2. Rețea și securitate

   • NSG-uri, UDR-uri și peering
   • Azure Firewall vs. NVA
   • Private endpoints și service endpoints

3. Stocare și calcul

   • Managed disks, premium SSD, ephemeral OS disks
   • App Service vs. Container Instances vs. AKS
   • Azure SQL failover groups vs. read replicas

4. Observabilitate

   • Application Insights vs. Azure Monitor
   • Interogări Log Analytics (KQL)
   • Diagnostic settings și retenție

Exemple de întrebări

Scenariu take-home:

„Migrezi o aplicație on-premises către Azure. Aplicația cere IP fix, are cerințe stricte de conformitate și trebuie izolată de alți tenanți. Proiectează arhitectura de rețea și de identitate".

Răspunsuri bune includ:

• Subrețea dedicată cu reguli NSG
• Private endpoint pentru baze de date
• Managed identity pentru autentificarea aplicației
• Politici de rețea pentru controlul traficului

Conversație live:

„Azure Web App-ul tău e lent, dar Azure Monitor arată CPU normal. Latența a sărit după implementarea unui cod nou. Ce verifici primul?".

Candidatul ar trebui să gândească:

• Trasee și dependențe în Application Insights
• CPU plan-ului App Service vs. blocaje la nivel de aplicație
• Schimbări la nivel de cod (interogări noi, apeluri blocante)
• Pooling de conexiuni la baza de date
• Latență a dependențelor de la terți

Cadrul de evaluare GCP

Competențe de testat

1. IAM și ierarhie organizațională

   • Service accounts și gestionarea cheilor
   • Roluri personalizate și privilegii minime
   • Organization policies și constrângeri

2. Calcul și orchestrare

   • Zone și regiuni Compute Engine
   • Proiectarea și autoscaling-ul cluster-elor GKE
   • Cloud Run pentru sarcini serverless

3. Date și stocare

   • Bucket-uri Cloud Storage, versionare, ciclu de viață
   • BigQuery pentru data warehousing
   • Failover Cloud SQL și Cloud Spanner

4. Observabilitate (Google Cloud Operations)

   • Cloud Logging și rutare a logurilor
   • Cloud Trace și profiling
   • Cloud Monitoring și metrici personalizate

Exemple de întrebări

Scenariu take-home:

„Ai un job batch care rulează zilnic pe Compute Engine, procesează 1 TB de date și durează 2 ore. Vrei să reduci costurile menținând SLA-ul. Proiectează o soluție".

Răspunsuri bune ar putea lua în calcul:

• VM-uri preemptible (eficiente la cost, acceptabile pentru batch)
• BigQuery pentru interogare (mai rapid decât procesarea pe Compute Engine)
• Cloud Run dacă e paralelizabil
• Spot VM-uri pentru sarcini tolerante la erori

Depanare live:

„Serviciul tău Cloud Run face timeout pe unele cereri. Logurile sunt curate. Latența P99 a sărit de la 50 ms la 2 s după un deploy. Urmărește-i traseul".

Candidatul ar trebui să gândească:

• Verificarea traseelor pentru a vedea ce operațiune e lentă
• Investigarea dependențelor noi (baze de date, API-uri externe)
• Verificarea limitelor de conexiune la baza de date
• Revizuirea alocării memoriei (are nevoie Cloud Run de mai multă?)
• Căutarea tiparelor de cold start

Evaluare cross-platformă (agnostică)

Pentru candidații care au folosit mai multe cloud-uri, testează competențe transferabile:

Întrebare:

„Ai proiectat sisteme pe AWS și Azure. Ce tipare de design se transferă între ele? Ce e fundamental diferit?".

Un răspuns bun recunoaște:

• Conceptele de bază (VPC-uri, IAM, baze de date gestionate) sunt similare
• Detaliile de implementare diferă semnificativ
• Modelele de cost diferă (rezervate vs. angajament)
• Curba de învățare a fiecărei platforme e ușoară odată ce o înțelegi pe prima

Asta semnalează că nu e dogmatic și se poate mișca între cloud-uri.

Structura de evaluare pentru angajări cloud

1. Take-home de 30 de minute (scenariu specific platformei cu constrângeri)
2. 30 de minute de depanare live (pe platforma sa de expertiză)
3. 15 minute de discuție de arhitectură (testează dacă înțelege compromisurile între platforme)

Când să angajezi multi-cloud vs. specialist pe platformă

Angajează generaliști multi-cloud dacă:

• Migrezi între platforme
• Ai nevoie de flexibilitate în negocierea termenilor cu furnizorii
• Construiești infrastructură-ca-cod portabilă

Angajează specialiști pe platformă dacă:

• Decizia ta de platformă e fixată
• Ai nevoie de cunoaștere operațională profundă a cazurilor limită ale platformei
• Optimizezi costurile pe un cloud specific

Majoritatea organizațiilor de inginerie sănătoase au nevoie de ambele: câțiva specialiști profunzi și mai mulți generaliști care pot opera între cloud-uri.

Construirea unor evaluări corecte între platforme

Dacă evaluezi candidați și pe AWS și pe Azure, structurează întrebările consecvent. Cere-i fiecărui candidat să proiecteze același sistem, doar pe platforma sa. Apoi compară: arhitecturile au gândire echivalentă de compromis? Sau un candidat a luat scurtături?

Gata să-ți construiești evaluarea de angajare cloud? Explorează resurse de DevOps și Cloud Engineering și cum să interpretezi rezultatele.