Tecnologie di Azure per il processo di compilazione

Completato

In questa unità, verrà illustrata la relazione tra il processo di innovazione e alcune delle tecnologie del settore che consentono di creare nuove funzionalità nelle applicazioni.

DevOps

Dopo aver avviato la fase di creazione per convalidare l'ipotesi di innovazione, è consigliabile snellire al massimo i cicli di sviluppo, integrazione e distribuzione necessari. In questa fase interviene DevOps. DevOps può essere definito come "processi e strumenti per distribuire le funzionalità software in modo rapido e affidabile". Di seguito viene illustrata la definizione in dettaglio:

• Processi e strumenti: DevOps, e il processo di innovazione nel suo complesso, si basa su modelli culturali che incoraggiano il cambiamento. Azure e GitHub offrono strumenti di alto livello per DevOps, ma l'acquisto di una licenza non è sufficiente. I processi e la cultura dell'organizzazione devono evolversi per abbracciare il cambiamento e l'innovazione.

• Distribuzione rapida di funzionalità software: i processi e gli strumenti DevOps adottano il concetto di fallimento e risposta immediata agli errori. La creazione di MVP o di prototipi per convalidare rapidamente se la funzionalità su cui si sta lavorando va nella giusta direzione è di fondamentale importanza per il concetto di DevOps.

• Distribuzione affidabile di funzionalità software: le organizzazioni poco inclini ai cambiamenti spesso associano le modifiche rapide ai tempi di inattività. DevOps, invece, si prefigge esattamente l'opposto: una frequenza di modifica elevata con un livello elevato di affidabilità. Questa affidabilità è resa possibile dall'integrazione di test nelle prime fasi del ciclo di sviluppo, in un processo denominato "spostamento a sinistra".

  Se lo sviluppo di una funzionalità nel tempo viene visto come una linea da sinistra a destra. Allora un processo di sviluppo legacy eseguirà la convalida utente e il controllo qualità alla fine del ciclo di sviluppo. Alla fine "destra" di tale riga. Secondo la metodologia DevOps, è consigliabile testare e convalidare la funzionalità prima possibile, all'estremità "sinistra" della linea temporale.

DevOps incorpora gli stessi concetti di base di una sana cultura dell'innovazione. L'adozione della sua metodologia è fondamentale per arrivare a un ciclo di innovazione agile.

Architetture di microservizi

La modularità è una tecnica nota per ridurre la complessità nella progettazione delle architetture di sistemi complessi. Se un sistema è un'interazione complessa di molti componenti che non possono essere separati (spesso chiamati "monolito"), le strette interdipendenze tra i componenti rendono difficoltoso introdurre miglioramenti al sistema. Ogni modifica deve essere convalidata rispetto al resto del sistema, quindi il processo di test è complesso.

Un sistema modulare, invece, può essere separato in sottosistemi più piccoli che interagiscono tra loro tramite interfacce ben definite. L'introduzione di modifiche in uno di questi sottosistemi risulta più semplice, perché, fintanto che la sua interfaccia con gli altri moduli rimane invariata, il sistema complessivo continua a funzionare.

Le architetture basate su microservizi sono modelli di applicazione che sfruttano la modularità. Le applicazioni sono suddivise in piccoli componenti separati che possono essere sviluppati in modo indipendente l'uno dall'altro, potenzialmente anche usando linguaggi di programmazione diversi. Ogni componente, o microservizio, può funzionare da solo. È possibile ridimensionarlo in base alle esigenze, risolverlo come singola unità e modificarlo in modo indipendente dagli altri microservizi.

Una domanda che le organizzazioni spesso si pongono è cosa fare se un'applicazione è monolitica. È consigliabile riprogettare l'applicazione in un'architettura di microservizi prima di introdurre l'innovazione oppure si possono eseguire i processi di innovazione e riprogettazione in parallelo? Non esiste una sola risposta a questa domanda. Dipende dalla complessità dell'applicazione e dalla rilevanza che ha per l'azienda.

Tailwind Traders si è trovata di fronte a questa domanda quando ha voluto modernizzare la sua piattaforma di e-commerce. L'azienda ha deciso di avviare la riprogettazione dell'applicazione di e-commerce in un'architettura di microservizi, perché la criticità dell'applicazione per l'azienda giustificava questo sforzo. Se Tailwind Traders non disponesse di un'applicazione modulare, la sua capacità di reagire alle tendenze in evoluzione sul mercato online risulterebbe compromessa.

Tuttavia, Tailwind Traders ha deciso di affrontare alcune delle principali lacune nella piattaforma contemporaneamente. Attendere il completamento del progetto di riprogettazione dell'applicazione significherebbe perdere una quota importante di mercato a favore delle nuove startup che stanno già cambiando il mercato dell'e-commerce.

I progetti devono interagire tra loro, guidati dal valore aziendale delle innovazioni. Le attività di riprogettazione devono essere incentrate sulle aree più critiche dell'applicazione, dove la necessità di modifiche per migliorare l'esperienza dei clienti è massima.

Contenitori

La tecnologia di containerizzazione non è esclusiva delle architetture di microservizi, ma i concetti funzionano insieme. I contenitori sono un modo per incapsulare il codice dell'applicazione e le relative dipendenze, in modo che possano essere distribuiti senza difficoltà in qualsiasi piattaforma.

Nelle distribuzioni di applicazioni tradizionali l'organizzazione deve installare prima il software, ad esempio il runtime dell'applicazione, le librerie di programmazione o i componenti esterni. Da questo approccio spesso nasce il problema di un'applicazione che funziona su un computer ma non su altri. È difficile replicare lo stesso ambiente nelle fasi di sviluppo, test, staging e produzione. Piccole differenze nel modo in cui vengono installate le dipendenze dell'applicazione possono far sì che l'applicazione funzioni correttamente durante i test, ma non quando viene distribuita nell'ambiente di produzione.

I contenitori cambiano le regole del gioco. Le dipendenze dell'applicazione vengono inserite insieme al codice dell'applicazione in un'unità di distribuzione autonoma denominata immagine del contenitore. Sia che il contenitore dell'applicazione venga distribuito nel computer portatile di uno sviluppatore sia che venga distribuita in un cluster di produzione con centinaia di nodi, la gestione delle dipendenze è la stessa. Il contenitore funziona esattamente nello stesso modo, quindi il test delle applicazioni è più affidabile e attendibile.

I contenitori si sono evoluti molto da quando Docker ha rilasciato il proprio codice come open source nel 2013. Ora i contenitori supportano sia Linux che Windows e architetture di CPU diverse. Azure offre molte soluzioni che consentono di eseguire carichi di lavoro basati su contenitori. In questa unità, vengono fornite informazioni su alcuni di essi.

Kubernetes e Red Hat OpenShift

Un runtime di contenitori è la tecnologia che avvia i contenitori in un computer, ma in un ambiente di produzione serve più logica. Chi distribuisce più contenitori, se sono richieste prestazioni più alte? Chi riavvia i contenitori in caso di problemi? Se sono disponibili più computer, chi decide su quale di essi deve essere avviato un determinato contenitore? Queste e altre attività spettano a una piattaforma di orchestrazione dei contenitori.

La prima versione di Kubernetes è stata rilasciata nel 2015 e presto è diventata lo standard di fatto per l'orchestrazione dei contenitori. I cluster Kubernetes sono costituiti da molti nodi di lavoro. Ogni nodo di lavoro ha un runtime di contenitori, quindi può eseguire contenitori dove il piano di controllo di Kubernetes programmerà la distribuzione di applicazioni in contenitori. Questo piano di controllo viene in genere eseguito in un set di nodi principali. Il piano è responsabile del corretto funzionamento dell'applicazione, del suo ridimensionamento e dell'esecuzione di tutti gli aggiornamenti necessari.

Uno dei principali motivi alla base della popolarità di Kubernetes è l'indipendenza dall'hardware offerta dai contenitori. Poiché le applicazioni basate su contenitori possono essere distribuite in modo affidabile in qualsiasi runtime di contenitori, è possibile eseguire Kubernetes in cloud che usano vari hypervisor. Le applicazioni distribuite devono comportarsi in modo simile (ammesso che anche le risorse hardware sottostanti siano simili). Molte organizzazioni hanno adottato Kubernetes come livello di astrazione che consente di eseguire processi di distribuzione delle applicazioni coerenti, sia in locale che nei cloud pubblici.

Eseguire Kubernetes in Azure è facile. Il servizio Azure Kubernetes è semplice da distribuire e conveniente in termini di costi, perché al cliente viene addebitato solo il costo dei nodi di lavoro. Microsoft si assume i costi e l'operazione del piano di controllo che contiene i componenti principali. Microsoft applica le patch ed esegue gli aggiornamenti del sistema operativo dei nodi di lavoro, riducendo ulteriormente la complessità operativa della gestione di un cluster Kubernetes per l'esecuzione di contenitori Linux e Windows.

OpenShift è una piattaforma di distribuzione di applicazioni basata su Kubernetes sviluppata e supportata da Red Hat. Incorpora molte altre funzionalità. Alcune organizzazioni scelgono di eseguire le proprie applicazioni in OpenShift proprio per usufruire di queste funzionalità aggiuntive e del supporto offerto da Red Hat. Anche l'esecuzione di OpenShift in Azure è semplice. Azure Red Hat OpenShift è costituita da un cluster OpenShift di cui Microsoft gestisce molti aspetti, incluso l'intero ciclo di vita del cluster.

Servizio app di Azure

Servizio app di Azure è una piattaforma in cui le organizzazioni possono eseguire i carichi di lavoro basati sul Web senza dover gestire alcun agente di orchestrazione o il sistema operativo sottostante. L'unico requisito è il caricamento del codice dell'applicazione nel servizio attraverso una delle tante modalità di distribuzione disponibili. Azure si occupa del resto: ridimensionare le risorse e le prestazioni dell'applicazione, applicare patch e gestire le macchine virtuali sottostanti e molto altro ancora, in modo molto più facile che con Kubernetes.

Servizio app di Azure supporta carichi di lavoro basati su contenitori, quindi è possibile caricare l'immagine del contenitore invece del codice dell'applicazione. Supporta inoltre i carichi di lavoro Linux e Windows e vari runtime di applicazioni.

Servizio app di Azure è disponibile con vari modelli tariffari, tra cui un'opzione serverless denominata Funzioni di Azure. In Funzioni di Azure viene addebitato solo l'utilizzo dell'applicazione. Non vi sono costi fissi.

Il modello serverless è interessante per l'innovazione perché consente di distribuire nuovi microservizi senza incorrere in alti importi mensili in fattura se il mercato non accetta i nuovi servizi. Questo modello è un altro esempio della strategia di risposta immediata agli errori, in cui l'innovazione non implica necessariamente costi elevati.

Servizio app di Azure offre anche funzionalità che supportano distribuzioni orientate a DevOps, ad esempio gli slot di app Web. Gli slot sono aree di gestione temporanea in cui è possibile distribuire nuove funzionalità senza influenzare l'ambiente di produzione. Gli slot sono ideali dal punto di vista dell'innovazione perché consentono di reindirizzare un numero contenuto di clienti a questa nuova versione dell'applicazione. È quindi possibile verificare se l'ipotesi di innovazione è corretta. Infine, se si vuole portare il nuovo codice nell'ambiente di produzione, è possibile "scambiare" gli slot in modo che l'ambiente di gestione temporanea diventi la versione di produzione.

Riepilogo

In questa unità è stato illustrato in che modo la tecnologia può supportare l'innovazione:

• Grazie ai processi e agli strumenti DevOps, i team di sviluppo e operativi sono in grado di fornire nuove funzionalità in modo rapido e affidabile.
• È possibile riprogettare le applicazioni in microservizi per abilitare l'innovazione sui singoli componenti, senza influire sul resto.
• I contenitori consentono la distribuzione affidabile delle applicazioni in più piattaforme e ambienti.
• Kubernetes è una piattaforma di orchestrazione indipendente dal cloud per l'esecuzione di applicazioni in contenitori.
• Servizio app di Azure può eseguire carichi di lavoro basati sul Web con costi di gestione minimi. Il servizio offre molte funzionalità, ad esempio il modello serverless o gli slot di applicazioni, volte ad accelerare il ciclo di innovazione.

Tailwind Traders ha deciso di iniziare a riprogettare l'applicazione di e-commerce in un'architettura basata su microservizi. Il primo sottosistema dell'applicazione che viene separato dal "monolito" è il servizio di pagamento, in quanto è stato identificato come area critica in cui la concorrenza offre un valore maggiore ai clienti.

Dopo il sottosistema di pagamento, altri componenti dell'applicazione verranno trasformati in microservizi indipendenti. I microservizi possono comunicare tramite le API REST. Il codice dell'applicazione per ogni microservizio deve essere containerizzato e le organizzazioni di sviluppo e operative devono adottare le procedure consigliate per DevOps.

Non volendo dipendere da un cloud pubblico specifico, Tailwind Traders ha deciso di sviluppare competenze Kubernetes internamente e di distribuire l'applicazione in cluster del servizio Azure Kubernetes. Qualora fosse necessario sviluppare nuovi microservizi, l'azienda ha scelto di considerare Funzioni di Azure come piattaforma per la distribuzione di MVP per ridurre i costi dello sviluppo.

Risorse utili

Molti dei concetti esposti in questa unità sono illustrati in modo più dettagliato negli articoli di Cloud Adoption Framework Migliorare l'adozione con l'invenzione digitale e Kubernetes in Cloud Adoption Framework.