Cloud Strategy - Parte III: Architetture per il Cloud

L’architettura cloud non significa solo eseguire applicazioni su infrastruttura esterna, ma progettare sistemi basati su automazione, elasticità, servizi gestiti, resilienza e sicurezza. Questo articolo esplora principi come Infrastructure as Code, applicazioni stateless, defense in depth, shift-left, serverless, container e strategie di migrazione.

Questa serie offre una sintesi con annotazioni del libro di Gregor Hohpe, Cloud Strategy, disponibile su leanpub.com/cloudstrategy.

Indice

• Executive summary
• Principi di architettura cloud
• Strategie di migrazione
• Componenti dell'architettura cloud
• Budgeting del cloud
• Fasi della migrazione
• Conclusione

Executive summary

L'architettura cloud non consiste semplicemente nell'eseguire applicazioni sull'infrastruttura gestita da terze parti. I sistemi cloud-ready sono progettati intorno ad automazione, elasticità, servizi gestiti, resilienza, sicurezza e miglioramento continuo.

Questa parte conclusiva della serie esplora i principi architetturali che permettono alle organizzazioni di ottenere un valore reale dal cloud: Infrastructure as Code, applicazioni stateless, servizi gestiti, defense in depth, approccio shift-left, serverless, container e strategie moderne di migrazione.

La migrazione non dovrebbe essere misurata solo contando il numero di server o applicazioni migrate. Il vero criterio è capire se il cloud porta a migliorare metriche di business e a vantaggi per il cliente: velocità di rilascio, affidabilità, resilienza, sicurezza, costo per transazione, time-to-market e capacità di innovare.

Principi di architettura cloud

Una strategia cloud efficace richiede un cambiamento di prospettiva. Il cloud non deve essere trattato come un altro data center, ma come una piattaforma programmabile, elastica e continuamente evolutiva. Questo cambia il modo in cui le applicazioni vengono progettate, distribuite, gestite, monitorate e finanziate.

Automazione

L'automazione è uno dei principali motivi per cui il cloud può aumentare la velocità dei processi all'interno dell'organizzazione. Ogni cloud provider espone i propri servizi tramite API pubbliche; di conseguenza, molti strumenti possono essere usati per implementare l'automazione e Infrastructure as Code.

La forma più semplice di automazione passa da CLI e script Bash. Questo approccio è utile per attività limitate o ripetitive, ma ha grossi limiti in termini di scalabilità, controllo degli errori, riusabilità e portabilità. Per sfruttare davvero il cloud servono strumenti più completi, anche se più complessi.

Le opzioni più comuni includono:

La differenza principale rispetto al modello tradizionale è che l'infrastruttura diventa versionata, ripetibile, revisionabile e ricreabile. Reti, subnet, regole del firewall, ruoli IAM, database, istanze EC2, bucket, allarmi e pipeline possono essere definiti come codice e aggiornati automaticamente.

L'automazione ha diversi obiettivi:

• Velocità: accelerare innovazione e rilascio.
• Ripetibilità: ridurre errori umani e aumentare la qualità.
• Fiducia: rendere i deployment più frequenti e meno stressanti.
• Resilienza: ridurre il tempo di ripristino dopo un disservizio.
• Trasparenza: sapere cosa è cambiato, quando e da chi è stato fatto.
• Miglioramento continuo: ottimizzare un processo automatizzato e molto più semplice che correggere un processo manuale.
• Compliance: incorporare controlli di sicurezza e qualità nel processo di deployment.

Applicazioni stateless

Nel contesto cloud, un'applicazione stateless non conserva le informazioni di stato sul server, container o funzione che elabora la richiesta. Ogni istanza può gestire qualsiasi richiesta perché lo stato è salvato in servizi esterni condivisi come database, cache, object storage o session store.

Questo non significa che l'applicazione non abbia uno stato. Significa che lo stato non vive nel processo applicativo o nel disco locale dell'istanza. Questa distinzione è fondamentale: se un server può essere eliminato e sostituito senza perdita di dati o interruzioni significative, l'applicazione può scalare e aggiornarsi molto più facilmente.

Per molte applicazioni monolitiche è possibile spostare progressivamente lo stato fuori dal server. Per esempio, un monolite che memorizza sessioni su disco locale può usare ElastiCache o DynamoDB; un'applicazione che salva file sul filesystem locale può salvarli in S3 o EFS; processi batch interni possono essere trasformati in lavori asincroni basati su code.

Il risultato è che qualsiasi istanza, container o funzione può gestire qualsiasi richiesta. Questo abilita autoscaling, bilanciamento del carico, blue/green deployment, rolling update e sostituzione automatica delle istanze malfunzionanti.

Usare servizi gestiti

Uno dei principali vantaggi del cloud è la disponibilità di servizi gestiti. In un ambiente on-premises l'organizzazione deve spesso operare gran parte dello stack: sistemi operativi, database, middleware, backup, monitoring, code, data warehouse e strumenti di sicurezza.

Nel cloud molte di queste capacità sono disponibili come servizi gestiti. Il provider gestisce l'infrastruttura sottostante e parte della piattaforma, mentre il cliente si concentra su configurazione, dati, sicurezza applicativa e logica di business.

Questo riduce il "undifferentiated heavy lifting": il lavoro operativo necessario ma non specifico del business. Tuttavia, i servizi gestiti aumentano anche la dipendenza dal provider e dalle sue API. La scelta deve quindi essere consapevole, non automatica.

Molti servizi gestiti sono basati su tecnologie open source o compatibili con standard diffusi, ma la portabilità non deve essere sopravvalutata. Compatibilità non significa assenza di lock-in. Spesso il valore maggiore del cloud nasce proprio dall'uso di servizi specifici del provider, quindi il punto non è evitare ogni dipendenza, ma scegliere le dipendenze in modo ragionato.

Defense in depth

La sicurezza on-premises tradizionale tende a partire dal perimetro di rete: firewall, segmentazione, VPN e reti interne considerate più affidabili. Nel cloud questa distinzione è più sfumata. Le applicazioni sono distribuite, comunicano tramite API, usano servizi gestiti e possono essere esposte a utenti, sistemi e pipeline distribuite.

Le applicazioni e i loro componenti dovrebbero adottare lo stesso principio: non fidarsi implicitamente della rete interna, ma autenticare, autorizzare, cifrare e monitorare ogni comunicazione significativa.

In AWS questo può tradursi in un'architettura con IAM least privilege, security group restrittivi, VPC endpoint, cifratura con KMS, Secrets Manager, log centralizzati, AWS WAF, API Gateway, CloudTrail, GuardDuty, Security Hub e controlli automatici tramite policy as code.

La defense in depth non è un singolo prodotto. È una combinazione di identità, rete, cifratura, logging, monitoraggio, configurazione sicura, automazione e risposta agli incidenti.

Architettura in evoluzione

Nel modello on-premises l'evoluzione dell'infrastruttura avviene spesso tramite cicli di refresh: nuovo hardware ogni tre o cinque anni, aggiornamenti pianificati, investimenti anticipati e lunghi periodi di ammortamento.

Nel cloud, invece, la piattaforma evolve continuamente. AWS introduce regolarmente nuove famiglie di istanze, nuovi processori, nuovi servizi gestiti, nuove regioni, nuove opzioni di storage, nuove funzionalità di sicurezza e nuovi modelli di prezzo.

Questo crea un vantaggio importante: le applicazioni possono beneficiare di infrastruttura migliore senza che l'azienda debba acquistare nuovo hardware. Ma crea anche una responsabilità: l'ottimizzazione cloud non è un'attività una tantum. Le architetture devono essere riviste periodicamente per verificare se nuovi servizi o nuove istanze possono ridurre costo, migliorare performance o semplificare le operazioni.

Guardando solo ai prezzi nominali, il passaggio da circa 0,133 USD/ora a circa 0,077 USD/ora rappresenta una riduzione di circa il 42%. Considerando l'inflazione, la riduzione reale è più vicina al 60%. Il messaggio strategico è che il costo per unità di calcolo tende a migliorare nel tempo, ma solo le organizzazioni che riesaminano periodicamente le proprie architetture riescono a catturare questo valore. 

Naturalmente, una parte di questo miglioramento riflette il progresso generale della tecnologia CPU e hardware. Anche il rapporto prestazioni/prezzo delle CPU server è migliorato in modo significativo nell’ultimo decennio, probabilmente nello stesso ordine di grandezza dei miglioramenti del compute grezzo di EC2.

Tuttavia, il rapporto prezzo/prestazioni della CPU è solo una parte del costo reale. In un data center on-premises, il costo totale include anche facility, alimentazione, raffreddamento, networking, storage, licenze software, contratti di supporto, personale operativo, capacità di riserva e cicli di refresh hardware. Questi costi aggiuntivi fanno sì che il costo complessivo per unità utile di calcolo non diminuisca necessariamente alla stessa velocità del semplice benchmark-per-dollar della CPU.

AWS beneficia inoltre di enormi economie di scala, di un’elevata utilizzazione distribuita su una base globale di clienti, di hardware custom come Nitro e Graviton, e dell’ottimizzazione continua della propria piattaforma infrastrutturale. Un singolo data center aziendale di solito non può eguagliare quella scala o quel ritmo di refresh. Per questo motivo, anche se i miglioramenti hardware avvantaggiano sia i provider cloud sia gli ambienti on-premises, le piattaforme cloud spesso riescono a trasformare quei miglioramenti in minori costi, maggiori prestazioni e capacità utilizzabile più rapidamente.

Approccio application-centric

Un approccio orientato all'infrastruttura parte da server, storage, reti e firewall. Un approccio application-centric parte invece dalla domanda corretta: che cosa serve a questa applicazione per creare valore per il business?

Questo cambia il processo decisionale. Non si chiede solo come spostare tre server in EC2, ma se l'applicazione deve essere mantenuta, ritirata, sostituita, spostata su una nuova piattaforma o rifattorizzata. Si valutano disponibilità, performance, dati, sicurezza, costo, frequenza di rilascio, dipendenze, proprietà applicativa e metriche di valore.

Approccio shift-left

Negli ambienti tradizionali, sicurezza e operations vengono spesso coinvolte dopo la progettazione o poco prima del rilascio. Questo produce colli di bottiglia, revisioni sequenziali e correzioni tardive.

Nel cloud, grazie a template pre-approvati, moduli IaC, pipeline CI/CD e policy as code, molti controlli possono essere eseguiti prima che l'infrastruttura venga creata. Un pull request può verificare se un bucket è cifrato, se una porta di rete è aperta, se un ruolo IAM è troppo permissivo o se mancano tag obbligatori.

Lo shift-left non elimina governance e sicurezza. Le sposta all'inizio del processo, dove gli errori sono meno costosi da correggere.

Robustezza

La robustezza è la capacità di un sistema di continuare a funzionare correttamente anche in presenza di input inattesi, carichi elevati, errori parziali o condizioni operative non ideali. Un sistema robusto evita che piccoli problemi diventino rapidamente guasti gravi.

Nel cloud la robustezza include validazione degli input, gestione corretta degli errori, timeout, retry controllati, circuit breaker, limiti di carico, isolamento dei componenti, configurazioni sicure e monitoraggio adeguato.

La reliability viene spesso misurata con indicatori come Mean Time Between Failures (MTBF), anche se i sistemi cloud moderni usano normalmente più metriche di disponibilità, errore e performance.

Resilienza

La resilienza è diversa dalla robustezza. Un sistema robusto resiste ai problemi; un sistema resiliente accetta che i guasti avverranno e si riprende rapidamente, spesso in modo automatico.

Nel cloud la resilienza è progettata tramite l'uso di più Availability Zone, load balancing, autoscaling, servizi gestiti, code, retry, idempotenza, backup testati, disaster recovery, deployment immutabili e osservabilità.

Serverless

Serverless non significa che non esistono server. Significa che il cliente non gestisce direttamente i server necessari per eseguire il codice o fornire il servizio. Il provider gestisce provisioning, scaling, alta disponibilità e gran parte dell'operatività della piattaforma.

In AWS, esempi serverless includono Lambda, API Gateway, DynamoDB, S3, EventBridge, Step Functions, SQS, SNS, Fargate e servizi analytics a consumo come Athena.

Il serverless è particolarmente adatto a workload intermittenti, event-driven, API, automazioni, elaborazioni asincrone e integrazioni. Il vantaggio economico deriva spesso dal fatto che si paga per l'uso effettivo, non per capacità sempre accesa.

I trade-off includono limiti di runtime, cold start, debugging più complesso, dipendenza dal provider, vincoli di servizio e necessità di progettare bene osservabilità, sicurezza e gestione degli errori.

Container

I container offrono un modo standardizzato per impacchettare applicazioni e dipendenze. In AWS possono essere eseguiti su ECS, EKS o Fargate. ECS offre orchestrazione gestita dei container; EKS fornisce Kubernetes gestito; Fargate permette di eseguire container senza gestire i server sottostanti.

I container sono utili per modernizzare applicazioni, standardizzare deployment, migliorare portabilità operativa e supportare architetture a microservizi. Tuttavia, introducono anche complessità: immagini, registry, networking, sicurezza, osservabilità, scheduling, aggiornamenti e gestione della piattaforma.

Strategie di migrazione

Prima della migrazione

Prima di migrare, l'organizzazione deve costruire un inventario applicativo affidabile. Migrare senza sapere quali applicazioni esistono, chi le possiede, da quali sistemi dipendono, quali dati trattano e quanto costano significa trasformare la migrazione in un esercizio rischioso e spesso costoso.

Inventario applicativo

Metriche di migrazione

La strategia cloud dovrebbe migliorare metriche visibili e significative per il business o il cliente. Per questo le metriche di migrazione devono includere non solo progresso tecnico, ma anche valore operativo e business.

Le sette R della migrazione applicativa

A questo punto deve essere definita una strategia generale per ciascuna applicazione. Nel contesto AWS si usa spesso il framework delle "7 R" della migrazione cloud, anche se la maggior parte dei provider usa metodologie molto simili.

Criteri di migrazione

Per molte organizzazioni, una componente centrale della cloud strategy è decidere quali applicazioni migrare, modernizzare, mantenere o ritirare. Spostare semplicemente asset IT spesso produce solo un altro data center, più costoso e meno controllabile.

Per definire le priorità di migrazione, Hohpe propone un framework di criteri per valutare quali asset on-premises spostare per primi.

Tier

Dirigere il traffico Internet verso il front-end in cloud può ridurre latenza e congestione sulla rete on-premises. I componenti front-end possono scalare più facilmente nel cloud, a condizione che il back-end riesca a sostenere il carico. Un possibile problema è l'aumento della latenza tra front-end e back-end.

Generazione

Le applicazioni moderne tendono ad adattarsi meglio alle architetture cloud: microservizi, orchestrazione container, integrazione continua e automazione. I componenti più vecchi probabilmente richiederanno refactoring più complessi.

Criticità

Migrare prima applicazioni meno critiche crea un terreno di apprendimento controllato. I team sviluppano competenze cloud prima di affrontare workload più complessi, riducendo il rischio complessivo.

Ciclo di vita

Portare in cloud ambienti di sviluppo e test può ridurre costi e rischi, soprattutto usando Infrastructure as Code per creare e distruggere risorse temporanee. Il limite è il rischio di testare in ambienti troppo diversi dalla produzione.

Classificazione dati

Migrare dati e applicazioni non sensibili riduce la complessità iniziale. Tuttavia, mantenere dati sensibili on-premises non elimina automaticamente i rischi: anche gli ambienti on-premises richiedono controlli robusti.

Freschezza dei dati

Il cloud è adatto ai backup grazie a storage economico, classi di archiviazione, servizi gestiti, cifratura e automazione. Dati storici raramente consultati possono essere archiviati in servizi come Amazon S3 Glacier. Backup immutabili possono essere realizzati con Amazon S3 Object Lock o AWS Backup Vault Lock.

Gestione operativa

Il disaster recovery in cloud può essere molto efficace perché sfrutta automazione e scalabilità: costi bassi durante il normale funzionamento e ripristino relativamente rapido in caso di outage on-premises.

Backup and Restore — mantenere backup di dati e definizioni infrastrutturali; ripristinare i sistemi dopo un disastro. Costo più basso, RTO/RPO più alti.

Pilot Light — mantenere in AWS solo i componenti critici minimi, come database o infrastruttura essenziale, e scalare il resto durante il recovery.

Warm Standby — mantenere una versione ridotta ma funzionante dell'ambiente di produzione e scalarla durante il disastro.

Multi-site Active/Active — eseguire workload di produzione in più sedi contemporaneamente. Costo più alto, RTO/RPO più bassi.

Carico del workload

L'elasticità cloud è particolarmente adatta a workload caratterizzati da picchi improvvisi o periodici. Evita di mantenere infrastruttura on-premises sovradimensionata per picchi occasionali. AWS offre anche Spot Instances, che possono generare risparmi fino al 90% rispetto ai prezzi On-Demand.

Applicazioni con traffico irregolare, cicli giorno-notte, comunicati stampa o eventi stagionali come Black Friday possono scalare dinamicamente in base a metriche come richieste, CPU o schedule predefinite.

Altri criteri di migrazione

Localizzazione degli utenti

Applicazioni usate da utenti globali con requisiti di bassa latenza possono beneficiare delle regioni e Availability Zone distribuite del cloud.

Livello di sicurezza

Applicazioni storicamente esposte ad attacchi, come DDoS o server-side injection, possono beneficiare della scalabilità globale e di servizi come AWS Shield e Web Application Firewall. Gli ambienti cloud possono offrire un livello di sicurezza più robusta rispetto a molti ambienti on-premises, se configurati e governati correttamente.

Data analytics

Applicazioni basate su data analytics, machine learning o AI traggono vantaggio da storage a costo variabile e servizi gestiti come Athena, Bedrock e SageMaker. Replicare questi sistemi su infrastruttura on-premises può essere complesso e costoso.

Componenti dell'architettura cloud

Creare una strategia per un cloud application-centric richiede più della semplice costruzione ed esecuzione del software. Una architettura production-ready dovrebbe includere almeno:

• Applicazione
• Comunicazione
• Delivery pipeline
• Monitoring/operations
• Piattaforma runtime

Delivery pipeline

L'obiettivo è stabilire una pipeline che abiliti Continuous Integration e Continuous Delivery (CI/CD): build, test, packaging e deployment del codice, integrando controlli di qualità e sicurezza lungo tutto il ciclo di vita.

Piattaforma runtime

Eseguire software richiede un ambiente che gestisca distribuzione del carico, recovery dai guasti e routing del traffico. Questo include virtualizzazione, macchine virtuali, container e runtime serverless.

Monitoring/operations

Applicazioni complesse richiedono visibilità su performance e salute. Il monitoring aiuta a rilevare picchi di carico, consumo di memoria o aumento della CPU prima che causino un downtime. Include log processing, database time-series e dashboard.

Comunicazione

Applicazioni e servizi devono comunicare in modo sicuro, dinamico e trasparente con altri sistemi e con il pubblico tramite API. API gateway, proxy e service mesh aiutano a gestire protezione dei messaggi, versioning e visibilità delle dipendenze.

Applicazione

Le applicazioni sono l'aspetto centrale. La loro struttura e performance devono essere ottimizzati per l'ambiente cloud.

Le applicazioni cloud-ready dovrebbero seguire le caratteristiche FROSST: frugali nell'uso delle risorse, rilocabili tra ambienti, osservabili in produzione, aggiornabili senza interruzioni significative, sicure internamente e tolleranti ai guasti.

Budgeting del cloud

I risparmi cloud devono essere guadagnati; non arrivano automaticamente. I costi devono essere rivisti regolarmente per identificare errori, sprechi e opportunità di resize, ottimizzazione o re-architecting. Il controllo dei costi è una responsabilità condivisa tra engineering, operations, finance e business, ma spesso è utile creare un gruppo dedicato di esperti cloud e financial management: il team FinOps.

Quando un'applicazione monolitica viene migrata per la prima volta in cloud, possono emergere costi inattesi. Questo non significa necessariamente che il cloud sia più costoso per natura. Un'infrastruttura cloud gestita ha sicuramente un costo significativo, nonostante le economie di scala del provider. Costi iniziali elevati sono spesso il segnale che architettura e dimensionamento della soluzione devono essere rivisti.

Gli ambienti on-premises sono comunemente progettati per la capacità di picco, perché l'hardware deve essere acquistato in anticipo. Nel cloud, dove la capacità può aumentare e diminuire con la domanda, le stesse ipotesi portano a sovradimensionamento e spreco. L'opportunità è usare elasticità, servizi gestiti e dimensionamento corretto per allineare il costo all'uso reale.

Il cloud fornisce billing trasparente e dettagliato, rendendo possibile capire dove viene speso il denaro e dove esistono opportunità di ottimizzazione. Il primo, e spesso più semplice, parametro da ottimizzare è la dimensione delle risorse: di calcolo, memoria, storage o database sovradimensionati possono essere ridotti o adattati tramite autoscaling.

Un altro parametro importante è il runtime: per quanto tempo un ambiente deve rimanere attivo. Ambienti di sviluppo e test di solito non devono funzionare fuori dall'orario lavorativo. Possono essere spenti, ridotti o ricreati quando servono. Un ambiente che opera solo durante le ore lavorative invece che 24/7 può ridurre sensibilmente il costo mensile, in alcuni casi fino a circa un quarto della spesa originale.

L'architettura è uno dei fattori più importanti nell'ottimizzazione dei costi cloud. I risparmi maggiori non derivano sempre da piccoli aggiustamenti infrastrutturali, ma dalla scelta di un modello più adatto al comportamento reale del workload.

Il data analytics è un buon esempio. Workload analitici possono richiedere molta potenza di calcolo, ma solo per brevi periodi. Nel datacenter questo implica lasciare hardware costoso inattivo per gran parte del tempo. In cloud, un servizio pay-as-you-go come Amazon Athena può ridurre questo spreco pagando solo in base alle query eseguite.

L'ottimizzazione deve considerare il quadro completo, non solo il costo infrastrutturale. Un confronto significativo include sia i costi delle risorse cloud sia i costi di engineering e amministrazione. Kubernetes, per esempio, può sembrare più costoso a livello infrastrutturale, ma può essere giustificato se standardizza i deployment, migliora l'automazione, riduce lavoro manuale, aumenta affidabilità e riduce il tempo necessario per rilasciare e gestire applicazioni.

La domanda corretta non è solo: "Quale opzione ha il costo infrastrutturale mensile più basso?", ma:

Quale opzione offre affidabilità, velocità, sicurezza e manutenibilità richieste al minor costo totale di ownership?

Nel modello on-premises tradizionale, l'infrastruttura viene acquisita tramite investimenti e impegni fissi di lungo periodo. Una riduzione del 10% nell'utilizzo non produce automaticamente una riduzione del 10% nel costo. Server, storage, licenze, impianti e contratti di supporto restano spesso in essere anche quando la domanda diminuisce.

Questa rigidità rende più difficili i periodi in cui l'azienda deve ridurre l'attività o reagire ad un crollo della domanda. Il cloud non elimina la necessità di gestione dei costi, ma il modello a consumo può rendere più semplice allineare progressivamente la spesa all'uso.

Fasi della migrazione

Il modello "crawl, walk, run" (andare a carponi, camminare, correre) è una metafora comune di maturità e adozione, non uno standard IT formale unico. Nella cloud strategy descrive un approccio a fasi: prima stabilire capacità di base, poi standardizzare, validare e scalare, infine ottimizzare e industrializzare l'uso del cloud.

Crawl

Per un'azienda senza presenza o esperienza cloud, la fase Crawl riguarda soprattutto apprendimento, sperimentazione e costruzione delle fondamenta. L'obiettivo non è una migrazione su larga scala, ma ridurre l'incertezza, sviluppare competenze, validare ipotesi e stabilire la governance minima necessaria per operare in sicurezza.

Attività chiave:

• Definire la strategia cloud iniziale e gli obiettivi business.
• Creare processi iniziali di governance per sicurezza, cost management e ownership operativa.
• Impostare sandbox cloud dove i team possano sperimentare senza impattare la produzione o generare costi eccessivi.
• Costruire competenze tramite training, certificazioni, workshop ed esercizi pratici.
• Formare un Cloud Center of Excellence iniziale o un gruppo di lavoro cloud.
• Distribuire demo, proof of concept o workload interni per acquisire esperienza pratica.
• Stabilire visibilità di base sui costi, standard di tagging, budget e report.
• Implementare controlli fondamentali: identity management, logging, cifratura e least privilege.
• Valutare come il cloud potrebbe abilitare nuovi prodotti, servizi, modelli di business o modelli operativi.
• Iniziare a creare template riusabili, pattern di automazione e pratiche Infrastructure as Code.

Risultati tipici: strategia e roadmap documentate, landing zone sandbox con governance di base, primi team competenti, ambienti dev/test in cloud, esperienza operativa iniziale e migliore comprensione di opportunità, rischi, costi e valore.

Maturità secondo il AWS Cloud Adoption Framework (CAF): Not Started — Start.

Walk

Nella fase Walk l'organizzazione supera la sperimentazione e inizia ad adottare il cloud in modo strutturato e ripetibile. L'obiettivo è stabilire standard comuni, validare il modello operativo con workload reali e preparare migrazioni più ampie.

A questo punto dovrebbe essere pronta o in fase di completamento una landing zone completa, evoluta dalla sandbox precedente o costruita da zero.

Attività chiave:

• Raffinare ed espandere la landing zone sulla base delle lezioni della fase Crawl.
• Stabilire pattern, template, moduli IaC riusabili.
• Standardizzare automazione per provisioning, deployment, controlli di sicurezza e task operativi.
• Implementare monitoring, logging, alerting, backup e cost management centralizzati.
• Definire standard di tagging e modelli di ownership delle risorse.
• Formalizzare il modello operativo del cloud: governance, sicurezza, supporto e change management.
• Creare team di piattaform cloud, team applicativi e funzioni di governance con ruoli chiari.
• Eseguire migrazioni pilota di applicazioni reali, iniziando da sviluppo, test o produzione a basso rischio.
• Valutare ogni applicazione e definire una strategia appropriata: rehost, replatform, refactor, replace, retain o retire.
• Definire architetture target e opportunità di modernizzazione.
• Continuare lo sviluppo delle competenze tramite esperienza pratica, mentoring e training avanzato.

Risultati tipici: landing zone matura, pratiche di deployment e operations standardizzate, librerie IaC riusabili, responsabilità chiare, pilot migration riuscite, roadmap di migrazione e maggiore fiducia nella gestione del cloud su scala.

Maturità secondo il AWS Cloud Adoption Framework (CAF): Start — Advance.

Run

Nella fase Run l'adozione cloud diventa una capacità core dell'organizzazione, non solo un programma di migrazione. Il focus passa dal test allo spostamento dei workload di produzione e al miglioramento continuo di delivery, operations, sicurezza e governance su scala.

La piattaforma, il modello operativo e le pratiche di governance stabilite nelle fasi precedenti sono ora abbastanza mature da supportare l'adozione ampia con automazione e self-service.

Attività chiave:

• Completare migrazione e modernizzazione delle applicazioni di produzione secondo la roadmap.
• Espandere il self-service per permettere ai team il provisioning di risorse approvate con minimo intervento manuale.
• Implementare policy as code e guardrail automatici per sicurezza, compliance e governance.
• Maturare pratiche FinOps: allocazione costi, forecasting, ottimizzazione, attribuzione dei costi e tracking del valore.
• Migliorare continuamente piattaforma, pattern riusabili, automazione e developer experience.
• Eseguire test regolari di resilienza, disaster recovery, failover e game day.
• Misurare e migliorare la frequenza del deployment, tempo di recupero da guasti, disponibilità, postura di sicurezza e adozione della piattaforma.
• Rivedere regolarmente le architetture per sfruttare nuovi servizi, capacità e opportunità di ottimizzazione.
• Mantenere programmi di apprendimento continuo su cloud, sicurezza, platform engineering e FinOps.
• Valutare l'adozione cloud rispetto a obiettivi business e risultati per il cliente, non solo metriche tecniche.

Risultati tipici: piattaforma cloud matura, self-service, automazione, governance automatizzata, FinOps maturo, resilienza provata, modernizzazione continua e risultati business misurabili come rilascio più rapido, migliore customer experience, maggiore efficienza operativa e agilità organizzativa.

Maturità secondo il AWS Cloud Adoption Framework (CAF): Advance — Excel.

Conclusione

Una cloud adoption di successo richiede molto più che spostare server in un data center diverso. Le organizzazioni devono ripensare architettura, operations, governance, sicurezza, gestione dei costi e perfino il modo in cui i team collaborano.

I maggiori benefici del cloud raramente arrivano dalla sola migrazione. Emergono quando l'organizzazione adotta automazione, servizi gestiti, resilienza ingegnerizzata, miglioramento continuo e un approccio si sviluppo basato sul prodotto.

La cloud strategy non è quindi una destinazione, ma un processo in continua evoluzione. Le organizzazioni che ottengono più valore dal cloud sono quelle che continuano ad adattarsi, imparare ed evolvere insieme alle piattaforme che utilizzano.