Completare il passaggio al cloud aiuta i clienti a realizzare le promesse incompiute della virtualizzazione. Il provisioning on demand di rete, computing, storage, database e altre risorse in un modello pay-as-you-go fornisce agilità senza precedenti e contribuisce ad accelerare la velocità dei team di sviluppo. Ma anche nel cloud, questa trasformazione non è istantanea: al contrario, la velocità dei team di sviluppo accelera man mano che il cliente prosegue nelle diverse fasi di adozione.
Adozione del cloud – il progetto passa attraverso vari livelli di migrazione Nel corso dei primi tre livelli di adozione del cloud, in cui le aziende 1) iniziano con pochi progetti per apprenderne i benefici, 2) basano la trasformazione aziendale su un centro di eccellenza cloud (CCOE) e 3) eseguono mass migration, iniziano a verificarsi numerosi fattori chiave che accelerano direttamente la velocità dei builder. Infrastructure as Code: all’inizio della fase di progettazione, i clienti possono svolgere alcune azioni manualmente. Mano a mano che si muovono verso le fasi di Fondazione e Migrazione, tuttavia, iniziano ad adottare l’Infrastructure as Code. Questo significa che tutta l’infrastruttura non viene semplicemente automatizzata tramite script, ma sviluppata e mantenuta come codice (ad esempio, CloudFormation). Questi modelli possono poi essere riutilizzati per implementare interi ambienti e stack in pochi minuti. Cloud COE: il team Cloud COE sviluppa e mantiene i modelli base dell’infrastruttura, progetta le architetture di referenza, istruisce i team di sviluppo e li aiuta a migrare le applicazioni sul cloud. Questi team sfruttano l’infrastruttura come stringhe di codice e iniziano a sviluppare stringhe di integrazione continua per le loro applicazioni. Adozione dei servizi AWS: durante queste fasi iniziali, assistiamo a un elevato livello di adozione dei servizi di base AWS, tra cui Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS), Amazon Elastic Load Balancing (ELB), Amazon Simple Storage Service (S3), AWS Identity and Access Management (IAM), AWS Key Management Service (KMS), AWS CloudFormation, e Amazon CloudWatch. I clienti iniziano anche a scollegare le loro applicazioni monolitiche e a trarre vantaggio dai servizi gestiti AWS quando possibile. A questo punto, il grado di adozione di un livello di servizi più alto generalmente dipende dalla strategia di migrazione del cliente, da quale percentuale di applicazioni è cloud native e da che percentuale deve avere un altro host, deve essere riprogrammata o rifattorizzata per trarre pieno vantaggio dalla piattaforma AWS. Sicurezza: per quanto la sicurezza possa normalmente essere un grande ostacolo all’agilità, se implementata correttamente, su AWS può portare un livello di trasparenza, verificabilità e automazione molto più alto di quello che può essere ottenuto on premise.
Adozione del cloud – fase di reinvenzione Non c’è dubbio che la velocità dei team di sviluppo migliori significativamente dopo che il cliente intraprende le prime fasi di adozione. Ma nella maggior parte dei casi, l’opportunità di ottimizzare non finisce con la fase della Migrazione: qui, infatti, i clienti raramente hanno l’opportunità o le risorse per riprogettare tutte le applicazioni e farle diventare cloud native (v. Cloud-Native vs Lift-and-Shift), e questo crea un’opportunità di reinvenzione costante per aumentare ulteriormente la velocità dei builder. Riprogettare le applicazioni spesso implica scollegare o scomporre le applicazioni monolitiche in servizi più piccoli con API, massimizzando al contempo la riusabilità. All’interno di questo processo, i clienti stanno cercando di scaricare le porzioni non differenziate delle applicazioni sulla piattaforma AWS, per focalizzarsi invece sulla logica di business.
Durante la fase di Reinvenzione, le aziende tipicamente preferiscono optare per servizi completamente gestiti come Amazon Kinesis per l’ingestione dei dati, AWS Lambda per un processing in tempo reale, Amazon Aurora e Amazon DynamoDB per i database relazionali e NoSQL, e Amazon Redshift per lo stoccaggio dei dati, in modo che i builder possano investire quanto più tempo possibile sui differenziatori del business. Sviluppare la miglior soluzione di queuing, messaggistica o gestione API difficilmente sposterà l’ago delle attività: al contrario, sono gli algoritmi, i flussi di business e le analitiche in tempo reale a conquistare i clienti e a contribuire a far crescere il business. In questa fase, vediamo anche uno sforzo più focalizzato a trasformare le Operation in un vero modello DevOps. Il team Cloud COE si concentra più sullo sviluppo di architetture di riferimento, governance e framework di conformità, dando al team di sviluppo più autonomia per implementare sia l’infrastruttura, sia le applicazioni attraverso una procedura CI/CD unificata. Inoltre, i team di sicurezza stanno aumentando la loro velocità adottando metodologie DevSecOps e mostrando capacità di sicurezza attraverso gli API.
Evoluzione del computing e Big Data Per metterla nella giusta prospettiva, si deve guardare come questa evoluzione abbia avuto luogo nelle aree del computing e dei big data nel cloud. La più grande evoluzione in ambito computing in tempi recenti si è avuta con il passaggio dai server fisici ai server virtuali nei data center. Questa fase ha portato a un utilizzo più alto, ad ambienti uniformati, a indipendenza dell’hardware e nuove capacità DR. La fase successiva ha visto i server virtuali nel cloud. Questo ha portato a risorse on-demand, maggiore scalabilità e agilità, disponibilità e tolleranza agli errori migliorate. Ma dalla prospettiva della velocità dei builder, c’è ancora spazio di miglioramento: c’è bisogno di preoccuparsi di DR e disponibilità, di gestire le golden images, di aggiornare i server e di dimensionare correttamente le instance rispetto al carico di lavoro. Dal punto di vista dei builder, tutto ciò che bisogna fare è concentrarsi sulla logica di business e farla funzionare in modo programmato o in risposta a un evento.
È qui che AWS Lambda e la transizione al serverless computing entrano in gioco. Con AWS Lambda, non ci sono più server da gestire o aggiornare. Il builder scrive semplicemente la sua funzione mentre il servizio Lambda gestisce automaticamente esecuzione, alta disponibilità e scalabilità. VidRoll, ad esempio, utilizza AWS per alimentare la sua logica di business per offerte in tempo reale e per transcodificare i video in tempo reale. Con Lambda, VidRoll può far fare a 2-3 ingegneri il lavoro di 8-10, come risultato diretto della riusabilità del codice e senza dover comprendere o preoccuparsi dell’infrastruttura. Un altro esempio simile è l’evoluzione dei servizi di big data su AWS. Gli utenti possono lanciare un cluster Hadoop autogestito su EC2 ed EBS. In effetti, possono iniziare a vedere alcuni benefici iniziali in termini di provisioning on-demand di risorse, modello pay-as-you-go, tipi diversi di istanze e altro. Eppure, molte delle sfide di questo tipo di architetture on-premise può persistere anche sul cloud. Per esempio, a causa della natura doppia di computing e storage, il cluster sarà iperutilizzato durante le ore di picco e utilizzato poco negli altri momenti. Non si può spegnere il cluster facilmente lontano dai momenti di picco per la necessità di persistere i dati in HDFS e si ha costantemente bisogno di spostare grandi quantità di dati su HDFS locali prima di poter anche solo lanciare una query.
Amazon EMR fa fronte a questi problemi scollegando computing e storage e sfruttando S3 come data lake persistente. Per esempio, rispetto ai due giorni di cluster autogestito EC2, FINRA è in grado di lanciare un nuovo cluster HBase su EMR e di accettare le query in meno di 30 minuti poiché i dati risiedono su S3. Sfruttare S3 per il data storage ha anche ridotto i costi consentendo di proporzionare il cluster in base al carico di lavoro. I builder e gli ingegneri dei dati, inoltre, non sono più bloccati da decisioni a lungo termine, ma possono evolvere la piattaforma di analisi e sperimentare nuovi strumenti mano a mano che il business lo richiede. E se i data scientist non volessero gestire nessun cluster? Amazon Athena offre un’opzione completamente Serverless. Con uno spin time pari a zero e aggiornamenti trasparenti, i data scientist possono semplicemente scrivere una query SQL e ottenere immediatamente l’esecuzione del motore Presto. In ogni trasformazione, può essere difficile sapere come misurare il successo e non perdere di vista l’obiettivo finale. Concentrarsi sulla velocità dei team di sviluppo fornisce un ottimo parametro per il successo del cloud e può aiutare a guidare le decisioni quando si diventa un Business Partner, per continuare ad evolversi e reinventarsi con AWS.
