AWS vs. Azure vs. GCP: guida ai test di competenze su piattaforme cloud
Il problema della selezione per piattaforma cloud
Ti serve un'engineer DevOps senior. Hai cinque ottime candidature. Due molto profonde su AWS; una forte su Azure; una usa GCP; una è cloud-agnostica ma con meno profondità operativa.
Chi assumi? Dipende. Ma la maggior parte dei team sbaglia: o assume per la piattaforma specifica creando rischio di lock-in, oppure assume la generalista e scopre che il gap di conoscenza della piattaforma è più profondo del previsto.
La risposta giusta è valutare entrambe le cose: conoscenza operativa specifica della piattaforma e pensiero di sistema trasferibile.
Quando testare competenze specifiche di piattaforma
Testa la profondità AWS/Azure/GCP se:
- Il tuo stack è bloccato su quella piattaforma
- L'esigenza è approfondire l'expertise su quel cloud
- Requisiti contrattuali o di compliance richiedono un cloud specifico
Testa fondamenta cloud-agnostiche se:
- Sei multi-cloud o potresti migrare
- Selezioni pensiero di sistema oltre alla padronanza dello strumento
- La candidata lavorerà su più piattaforme
La maggior parte dei team dovrebbe testare entrambe: «Sa gestire bene AWS?» E «Sa ragionare di architettura a prescindere dalla piattaforma?»
Framework di valutazione AWS
Competenze da testare
-
IAM e modellazione della sicurezza
- Sa progettare accesso a least-privilege per un'architettura a microservizi?
- Capisce SCP vs. policy inline vs. managed policy?
- Sa spiegare perché non si dovrebbero usare le credenziali root?
-
Rete e connettività
- Design VPC: subnet, routing, NACL, security group
- Quando usare Direct Connect vs. VPN vs. Internet Gateway
- Trade-off di rete cross-account o cross-region
-
Storage e database
- Ottimizzazione EBS: gp3 vs. io2, throughput riservato
- Strategie di failover e backup RDS
- Lifecycle policy e versioning S3 per la retention dei dati
-
Scalabilità di calcolo
- EC2 Auto Scaling Groups vs. Spot Instances
- Trade-off ECS vs. EKS
- Implicazioni del cold start di Lambda per workload di produzione
Esempi di domande
Scenario take-home:
«Progetta un sistema per ingerire 10 GB di log al giorno da 100 istanze EC2, conservarli in modo durevole e interrogarli con latenza sotto il secondo. Hai un budget di 2.000 $/mese. Solo AWS. Spiega le scelte».
Una buona risposta considera:
- CloudWatch Logs per la raccolta (managed) vs. Firehose + S3 + Athena (ottimizzato sul costo)
- Policy di retention dei log per gestire i costi
- Strategia di indicizzazione (partizionamento Athena, oppure Elasticsearch)
- Pattern di query e se la latenza sotto il secondo è reale o presunta
Una risposta debole salta a Elasticsearch senza chiedersi se sia necessario.
Troubleshooting live:
«La tua istanza RDS ha raggiunto l'80 % di CPU e i tuoi task ECS auto-scalati non riescono a connettersi al database per 2 minuti ogni ora, sempre alla stessa ora. Spiegami come faresti il debug».
La candidata dovrebbe pensare a:
- Correlare i picchi di connessione ECS con il carico RDS
- Cercare query lente con Enhanced Monitoring
- Cercare leak di connessione (l'app non chiude le connessioni)
- Considerare se a quell'ora gira altro (backup, report)
Framework di valutazione Azure
Competenze da testare
-
Identità e accessi (Azure AD / Entra)
- Managed identity vs. service principal
- Controllo accessi basato sui ruoli (RBAC) con ruoli personalizzati
- Policy di Conditional Access per la sicurezza
-
Rete e sicurezza
- NSG, UDR e peering
- Azure Firewall vs. NVA
- Private endpoint e service endpoint
-
Storage e calcolo
- Managed disk, premium SSD, ephemeral OS disk
- App Service vs. Container Instances vs. AKS
- Failover group Azure SQL vs. read replica
-
Observability
- Application Insights vs. Azure Monitor
- Query di Log Analytics (KQL)
- Diagnostic setting e retention
Esempi di domande
Scenario take-home:
«Stai migrando un'applicazione on-premise su Azure. L'app richiede IP fisso, ha requisiti stringenti di compliance e deve essere isolata dagli altri tenant. Progetta l'architettura di rete e identità».
Buone risposte includono:
- Subnet dedicata con regole NSG
- Private endpoint per i database
- Managed identity per l'autenticazione dell'app
- Network policy per il controllo del traffico
Conversazione live:
«La tua Azure Web App è lenta ma Azure Monitor mostra CPU normale. La latenza è schizzata dopo il deploy di nuovo codice. Cosa controlli per primo?»
La candidata dovrebbe pensare a:
- Trace e dipendenze in Application Insights
- CPU del piano App Service vs. colli di bottiglia a livello di app
- Modifiche al codice (nuove query, chiamate bloccanti)
- Connection pooling al database
- Latenza delle dipendenze terze
Framework di valutazione GCP
Competenze da testare
-
IAM e gerarchia organizzativa
- Service account e gestione delle chiavi
- Ruoli personalizzati e least privilege
- Organization policy e vincoli
-
Calcolo e orchestrazione
- Zone e regioni di Compute Engine
- Design e autoscaling dei cluster GKE
- Cloud Run per workload serverless
-
Dati e storage
- Bucket Cloud Storage, versioning, lifecycle
- BigQuery per il data warehousing
- Failover di Cloud SQL e Cloud Spanner
-
Observability (Google Cloud Operations)
- Cloud Logging e log routing
- Cloud Trace e profiling
- Cloud Monitoring e metriche personalizzate
Esempi di domande
Scenario take-home:
«Hai un job batch che gira ogni giorno su Compute Engine, processa 1 TB di dati e impiega 2 ore. Vuoi ridurre i costi mantenendo l'SLA. Progetta una soluzione».
Buone risposte potrebbero considerare:
- VM preemptible (economiche, accettabili per batch)
- BigQuery per le query (più veloce del processing su Compute Engine)
- Cloud Run se parallelizzabile
- Spot VM per workload fault-tolerant
Debug live:
«Il tuo servizio Cloud Run va in timeout su alcune richieste. I log sono puliti. La latenza P99 è passata da 50 ms a 2 s dopo un deploy. Tracciala».
La candidata dovrebbe pensare a:
- Controllare le trace per capire quale operazione è lenta
- Indagare nuove dipendenze (database, API esterne)
- Controllare i limiti di connessione al database
- Rivedere l'allocazione di memoria (Cloud Run ne ha bisogno di più?)
- Cercare pattern di cold start
Valutazione cross-piattaforma (platform-agnostic)
Per candidate che hanno usato più cloud, testa competenze trasferibili:
Domanda:
«Hai progettato sistemi su AWS e Azure. Quali pattern di design si trasferiscono? Cosa è fondamentalmente diverso?»
Una buona risposta riconosce:
- I concetti core (VPC, IAM, database gestiti) sono simili
- I dettagli di implementazione differiscono in modo significativo
- I modelli di costo differiscono (reserved instance vs. commitment)
- La curva di apprendimento di ogni piattaforma è breve una volta capita la prima
Questo segnala che non è dogmatica e sa muoversi tra cloud.
Struttura di valutazione per le assunzioni cloud
- Take-home da 30 minuti (scenario specifico di piattaforma con vincoli)
- 30 minuti di troubleshooting live (sulla sua piattaforma di expertise)
- 15 minuti di conversazione di architettura (verifica se capisce i trade-off tra piattaforme)
Quando assumere multi-cloud vs. specialista di piattaforma
Assumi generaliste multi-cloud se:
- Stai migrando tra piattaforme
- Ti serve flessibilità per negoziare con i vendor
- Stai costruendo infrastructure-as-code portabile
Assumi specialiste di piattaforma se:
- La decisione di piattaforma è fissata
- Ti serve conoscenza operativa profonda dei casi limite di quella piattaforma
- Stai ottimizzando i costi su un cloud specifico
La maggior parte delle organizzazioni di engineering sane ne ha bisogno di entrambe: poche specialiste profonde e più generaliste che sanno operare tra cloud.
Costruire valutazioni eque tra piattaforme
Se valuti sia candidate AWS sia Azure, struttura le domande in modo coerente. Chiedi a ciascuna di progettare lo stesso sistema, solo sulla sua piattaforma. Poi confronta: le architetture hanno un pensiero di trade-off equivalente? O una candidata ha tagliato angoli?
Pronta a costruire la tua valutazione per le assunzioni cloud? Esplora le risorse DevOps e Cloud Engineering e come interpretare i risultati.