Che cos'è Cloud Native?
Suggerimento
Questo contenuto è un estratto di eBook, Architecting Cloud Native .NET Applications for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.
Interrompere le operazioni e chiedere ai colleghi di definire il termine "Cloud Native". C'è una buona probabilità che si otterranno diverse risposte.
Si inizierà con una definizione semplice:
L'architettura e le tecnologie native del cloud sono un approccio alla progettazione, alla costruzione e ai carichi di lavoro operativi compilati nel cloud e sfruttare appieno il modello di cloud computing.
Cloud Native Computing Foundation fornisce la definizione ufficiale:
Le tecnologie native del cloud consentono alle organizzazioni di creare ed eseguire applicazioni scalabili in ambienti moderni e dinamici, ad esempio cloud pubblici, privati e ibridi. I contenitori, le mesh di servizi, i microservizi, l'infrastruttura non modificabile e le API dichiarative esemplificano questo approccio.
Queste tecniche consentono sistemi ad accoppiamento debole che sono resilienti, gestibili e osservabili. In combinazione con l'automazione affidabile, consentono ai tecnici di apportare modifiche ad alto impatto frequentemente e prevedibili con fatica minima.
Il cloud nativo riguarda velocità e agilità. I sistemi aziendali si stanno evolvendo dall'abilitazione delle capacità aziendali alle armi della trasformazione strategica che accelerano la velocità e la crescita aziendale. È fondamentale ottenere immediatamente nuove idee sul mercato.
Allo stesso tempo, i sistemi aziendali sono diventati sempre più complessi con gli utenti che richiedono di più. Si aspettano tempi di risposta rapidi, funzionalità innovative e tempi di inattività pari a zero. I problemi di prestazioni, gli errori ricorrenti e l'impossibilità di spostarsi rapidamente non sono più accettabili. Gli utenti visiteranno il concorrente. I sistemi nativi del cloud sono progettati per adottare cambiamenti rapidi, su larga scala e resilienza
Ecco alcune aziende che hanno implementato tecniche native del cloud. Considerare la velocità, l'agilità e la scalabilità che hanno raggiunto.
| Company | Esperienza |
|---|---|
| Netflix | Dispone di oltre 600 servizi nell'ambiente di produzione. Distribuisce 100 volte al giorno. |
| Uber | Dispone di 1.000 servizi in produzione. Distribuisce diverse migliaia di volte ogni settimana. |
| Dispone di 3.000 servizi in produzione. Distribuisce 1.000 volte al giorno. |
Come si può notare, Netflix, Uber e WeChat espongono sistemi nativi del cloud costituiti da molti servizi indipendenti. Questo stile architettonico consente loro di rispondere rapidamente alle condizioni di mercato. Aggiornano istantaneamente piccole aree di un'applicazione dinamica e complessa, senza una ridistribuzione completa. Ridimensionano singolarmente i servizi in base alle esigenze.
I pilastri del cloud nativo
La velocità e l'agilità del cloud nativo derivano da molti fattori. In primo luogo, l'infrastruttura cloud. Ma c'è di più: cinque altri pilastri fondamentali illustrati nella figura 1-3 forniscono anche il fondamento per i sistemi nativi del cloud.
Figura 1-3. Pilastri fondamentali nativi del cloud
Occorre tempo per comprendere meglio il significato di ogni pilastro.
Cloud
I sistemi nativi del cloud sfruttano appieno il modello di servizio cloud.
Progettato per prosperare in un ambiente cloud dinamico virtualizzato, questi sistemi usano ampiamente l'infrastruttura di calcolo PaaS (Platform as a Service) e i servizi gestiti. Considerano l'infrastruttura sottostante eliminabile , con provisioning in minuti e ridimensionate, ridimensionate o eliminate definitivamente su richiesta, tramite l'automazione.
Si consideri il concetto DevOps ampiamente accettato di Pets vs. Cattle. In un data center tradizionale, i server vengono trattati come Animali domestici: un computer fisico, dato un nome significativo e curato . È possibile ridimensionare aggiungendo altre risorse allo stesso computer (aumento delle prestazioni). Se il server si ammala, viene infermiera alla salute. Se il server diventa non disponibile, tutti notano.
Il modello di servizio Bestiame è diverso. Si effettua il provisioning di ogni istanza come macchina virtuale o contenitore. Sono identici e assegnati un identificatore di sistema, ad esempio Service-01, Service-02 e così via. La scalabilità viene ridimensionata creando più di esse (aumento del numero di istanze). Quando uno diventa non disponibile, nessuno nota.
Il modello bovino abbraccia un'infrastruttura immutabile. I server non vengono riparati o modificati. Se si verifica un errore o richiede l'aggiornamento, viene eliminato definitivamente e ne viene eseguito il provisioning, tutto eseguito tramite l'automazione.
I sistemi nativi del cloud adottano il modello di servizio Cattle. Continuano a essere eseguiti man mano che l'infrastruttura viene ridimensionata o ridotta in base ai computer in cui sono in esecuzione.
La piattaforma cloud di Azure supporta questo tipo di infrastruttura altamente elastica con scalabilità automatica, riparazione automatica e funzionalità di monitoraggio.
Progettazione moderna
Come si progetta un'app nativa del cloud? Qual è l'aspetto dell'architettura? A quali principi, modelli e procedure consigliate si dovrebbe attenersi? Quali sono i problemi operativi e dell'infrastruttura?
Applicazione Twelve-Factor
Una metodologia ampiamente accettata per la costruzione di applicazioni basate sul cloud è l'applicazione Twelve-Factor. Descrive un set di principi e procedure che gli sviluppatori seguono per costruire applicazioni ottimizzate per ambienti cloud moderni. Viene prestata particolare attenzione alla portabilità tra ambienti e automazione dichiarativa.
Anche se applicabile a qualsiasi applicazione basata sul Web, molti professionisti considerano Twelve-Factor una solida base per la creazione di app native del cloud. I sistemi basati su questi principi possono distribuire e ridimensionare rapidamente e aggiungere funzionalità per reagire rapidamente ai cambiamenti del mercato.
La tabella seguente evidenzia la metodologia di Twelve-Factor:
| Fattore | Spiegazione |
|---|---|
| 1 - CodeBase | Una singola codebase per ogni microservizio, archiviata nel proprio repository. Rilevata con il controllo della versione, può essere distribuita in più ambienti (QA, Staging, Production). |
| 2 - Dipendenze | Ogni microservizio isola e inserisce in pacchetti le proprie dipendenze, adottando le modifiche senza influire sull'intero sistema. |
| 3 - Configurazioni | Le informazioni di configurazione vengono spostate all'esterno del microservizio ed esterne tramite uno strumento di gestione della configurazione all'esterno del codice. La stessa distribuzione può propagarsi tra ambienti con la configurazione corretta applicata. |
| 4 - Servizi di backup | Le risorse ausiliarie (archivi dati, cache, broker di messaggi) devono essere esposte tramite un URL indirizzabile. In questo modo la risorsa viene disaccoppiato dall'applicazione, consentendo di renderla intercambiabile. |
| 5 - Build, Release, Run | Ogni release deve applicare una separazione rigorosa tra le fasi di compilazione, rilascio ed esecuzione. Ogni tag deve essere contrassegnato con un ID univoco e supporta la possibilità di eseguire il rollback. I sistemi CI/CD moderni consentono di soddisfare questo principio. |
| 6 - Processi | Ogni microservizio deve essere eseguito nel proprio processo, isolato da altri servizi in esecuzione. Esternalizzare lo stato richiesto a un servizio di backup, ad esempio una cache distribuita o un archivio dati. |
| 7 - Associazione di porte | Ogni microservizio deve essere indipendente con le relative interfacce e funzionalità esposte sulla propria porta. In questo modo viene fornito l'isolamento da altri microservizi. |
| 8 - Concorrenza | Quando la capacità deve aumentare, aumentare orizzontalmente i servizi su più processi identici (copie) anziché aumentare le prestazioni di una singola istanza di grandi dimensioni nel computer più potente disponibile. Sviluppare l'applicazione in modo che sia simultaneamente scalabile in ambienti cloud senza problemi. |
| 9 - Disposability | Le istanze del servizio devono essere eliminabili. Favorire l'avvio rapido per aumentare le opportunità di scalabilità e gli arresti normale per lasciare il sistema in uno stato corretto. I contenitori Docker insieme a un agente di orchestrazione soddisfano intrinsecamente questo requisito. |
| 10 - Parità sviluppo/prod | Mantenere gli ambienti nel ciclo di vita dell'applicazione il più possibile simili, evitando collegamenti costosi. In questo caso, l'adozione dei contenitori può contribuire notevolmente promuovendo lo stesso ambiente di esecuzione. |
| 11 - Registrazione | Considerare i log generati dai microservizi come flussi di eventi. Elaborarli con un aggregatore di eventi. Propagare i dati di log agli strumenti di gestione di data mining/log, ad esempio Monitoraggio di Azure o Splunk e infine all'archiviazione a lungo termine. |
| 12 - Processi di Amministrazione | Eseguire attività amministrative/di gestione, ad esempio la pulizia dei dati o l'analisi del calcolo, come processi occasionali. Usare strumenti indipendenti per richiamare queste attività dall'ambiente di produzione, ma separatamente dall'applicazione. |
Nel libro , Beyond the Twelve-Factor App, l'autore Kevin Hoffman dettaglia ognuno dei 12 fattori originali (scritto nel 2011). Inoltre, illustra tre fattori aggiuntivi che riflettono la progettazione moderna delle applicazioni cloud.
| Nuovo fattore | Spiegazione |
|---|---|
| 13 - API First | Rendere tutto un servizio. Si supponga che il codice venga utilizzato da un client front-end, un gateway o un altro servizio. |
| 14 - Telemetria | In una workstation si ha una visibilità approfondita sull'applicazione e sul relativo comportamento. Nel cloud, non lo si fa. Assicurarsi che la progettazione includa la raccolta di dati di monitoraggio, specifici del dominio e integrità/sistema. |
| 15 - Autenticazione/Autorizzazione | Implementare l'identità dall'inizio. Prendere in considerazione le funzionalità di controllo degli accessi in base al ruolo (controllo degli accessi in base al ruolo) disponibili nei cloud pubblici. |
Ci riferiremo a molti dei 12 fattori+ in questo capitolo e in tutto il libro.
Azure Well-Architected Framework
La progettazione e la distribuzione di carichi di lavoro basati sul cloud possono risultare difficili, soprattutto quando si implementa l'architettura nativa del cloud. Microsoft offre procedure consigliate standard del settore per aiutare l'utente e il team a offrire soluzioni cloud affidabili.
Microsoft Well-Architected Framework offre un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro nativo del cloud. Il framework è costituito da cinque pilastri di eccellenza dell'architettura:
| Principi | Descrizione |
|---|---|
| Gestione costi | Concentrarsi sulla generazione anticipata del valore incrementale. Applicare i principi Build-Measure-Learn per accelerare il time-to-market evitando soluzioni a elevato utilizzo di capitale. Usando una strategia con pagamento in base al consumo, investire man mano che si aumenta il numero di istanze, invece di offrire un grande investimento in anticipo. |
| Eccellenza operativa | Automatizzare l'ambiente e le operazioni per aumentare la velocità e ridurre l'errore umano. Eseguire rapidamente il rollback o l'inoltro dei problemi. Implementare il monitoraggio e la diagnostica fin dall'inizio. |
| Efficienza delle prestazioni | Soddisfare in modo efficiente le richieste dei carichi di lavoro. Favorire la scalabilità orizzontale (aumento del numero di istanze) e progettarla nei sistemi. Eseguire continuamente test di carico e prestazioni per identificare potenziali colli di bottiglia. |
| Affidabilità | Creare carichi di lavoro resilienti e disponibili. La resilienza consente ai carichi di lavoro di eseguire il ripristino da errori e continuare a funzionare. La disponibilità garantisce agli utenti l'accesso al carico di lavoro in qualsiasi momento. Progettare le applicazioni in modo da prevedere errori e ripristinarle. |
| Sicurezza | Implementare la sicurezza nell'intero ciclo di vita di un'applicazione, dalla progettazione e dall'implementazione alla distribuzione e alle operazioni. Prestare particolare attenzione alla gestione delle identità, all'accesso all'infrastruttura, alla sicurezza delle applicazioni e alla sovranità e alla crittografia dei dati. |
Per iniziare, Microsoft offre una serie di valutazioni online che consentono di valutare i carichi di lavoro cloud correnti rispetto ai cinque pilastri ben strutturati.
Microservizi
I sistemi nativi del cloud adottano i microservizi, uno stile architettonico popolare per la costruzione di applicazioni moderne.
Creato come set distribuito di servizi di piccole dimensioni indipendenti che interagiscono tramite un'infrastruttura condivisa, i microservizi condividono le caratteristiche seguenti:
Ognuna implementa una funzionalità aziendale specifica all'interno di un contesto di dominio più ampio.
Ogni viene sviluppato in modo autonomo e può essere distribuito in modo indipendente.
Ognuna è autonoma che incapsula la propria tecnologia di archiviazione dei dati, le dipendenze e la piattaforma di programmazione.
Ogni viene eseguito nel proprio processo e comunica con altri utenti usando protocolli di comunicazione standard, ad esempio HTTP/HTTPS, gRPC, WebSocket o AMQP.
Compongono insieme per formare un'applicazione.
La figura 1-4 contrasta un approccio monolitico dell'applicazione con un approccio basato su microservizi. Si noti che il monolith è costituito da un'architettura a più livelli, che viene eseguita in un singolo processo. In genere utilizza un database relazionale. L'approccio al microservizio, tuttavia, separa le funzionalità in servizi indipendenti, ognuno con la propria logica, stato e dati. Ogni microservizio ospita il proprio archivio dati.
Figura 1-4. Architettura monolitica e microservizi
Si noti come i microservizi promuovono il principio dei processidell'applicazione Twelve-Factor, descritti in precedenza nel capitolo.
Factor #6 specifica "Ogni microservizio deve essere eseguito nel proprio processo, isolato da altri servizi in esecuzione".
Perché usare i microservizi?
I microservizi offrono agilità.
In precedenza nel capitolo è stata confrontata un'applicazione e-commerce creata come monolitica con i microservizi. Nell'esempio sono stati illustrati alcuni vantaggi chiari:
Ogni microservizio ha un ciclo di vita autonomo e può evolversi indipendentemente e distribuirsi di frequente. Non è necessario attendere una versione trimestrale per distribuire nuove funzionalità o aggiornamenti. È possibile aggiornare una piccola area di un'applicazione attiva con un minor rischio di interruzione dell'intero sistema. L'aggiornamento può essere eseguito senza una ridistribuzione completa dell'applicazione.
Ogni microservizio può essere ridimensionato in modo indipendente. Invece di ridimensionare l'intera applicazione come singola unità, si aumentano solo i servizi che richiedono una maggiore potenza di elaborazione per soddisfare i livelli di prestazioni desiderati e i contratti di servizio. La scalabilità con granularità fine offre un maggiore controllo del sistema e consente di ridurre i costi complessivi quando si ridimensionano parti del sistema, non tutto.
Una guida di riferimento eccellente per comprendere i microservizi è .NET Microservizi: Architettura per applicazioni .NET in contenitori. Il libro approfondisce la progettazione e l'architettura dei microservizi. È un complementare per un'architettura di riferimento di microservizi full-stack disponibile come download gratuito da Microsoft.
Sviluppo di microservizi
I microservizi possono essere creati su qualsiasi piattaforma di sviluppo moderna.
La piattaforma Microsoft .NET è una scelta eccellente. Gratuito e open source offre molte funzionalità predefinite che semplificano lo sviluppo di microservizi. .NET è multipiattaforma. Le applicazioni possono essere compilate ed eseguite in Windows, macOS e la maggior parte dei tipi di Linux.
.NET è altamente efficiente e ha ottenuto punteggi elevati rispetto a Node.js e altre piattaforme concorrenti. Interessante, TechEmpower ha condotto un ampio set di benchmark delle prestazioni in molte piattaforme e framework di applicazioni Web. .NET ha ottenuto il punteggio nella parte superiore 10: ben sopra Node.js e altre piattaforme concorrenti.
.NET viene gestito da Microsoft e dalla community .NET in GitHub.
Problemi relativi ai microservizi
Anche se i microservizi nativi del cloud distribuiti possono offrire un'enorme agilità e velocità, presentano molte sfide:
Comunicazione
In che modo le applicazioni client front-end comunicano con microservizi di base supportati? È possibile consentire la comunicazione diretta? In alternativa, è possibile astrarre i microservizi back-end con una facciata gateway che offre flessibilità, controllo e sicurezza?
In che modo i microservizi core di back-end comunicano tra loro? Le chiamate HTTP dirette possono aumentare l'accoppiamento e l'impatto sulle prestazioni e sull'agilità? O si potrebbe considerare la messaggistica disaccoppiata con le tecnologie di coda e argomenti?
La comunicazione è illustrata nel capitolo Modelli di comunicazione nativa del cloud .
Resilienza
Un'architettura di microservizi sposta il sistema da in-process alla comunicazione di rete out-of-process. In un'architettura distribuita, cosa accade quando il servizio B non risponde a una chiamata di rete dal servizio A? In alternativa, cosa accade quando il servizio C diventa temporaneamente non disponibile e altri servizi che lo chiamano vengono bloccati?
La resilienza è illustrata nel capitolo resilienza nativa del cloud .
Dati distribuiti
Per progettazione, ogni microservizio incapsula i propri dati, esponendo le operazioni tramite l'interfaccia pubblica. In tal caso, come eseguire query sui dati o implementare una transazione tra più servizi?
I dati distribuiti sono trattati nel capitolo Modelli di dati nativi del cloud .
Segreti
In che modo i microservizi archivieranno e gestiscono in modo sicuro i segreti e i dati di configurazione sensibili?
I segreti vengono trattati in dettaglio sulla sicurezza nativa del cloud.
Gestire la complessità con Dapr
Dapr è un runtime di applicazioni open source distribuito. Attraverso un'architettura di componenti pluggable, semplifica notevolmente l'impianto idraulico dietro le applicazioni distribuite. Fornisce un'associazione dinamica che associa l'applicazione a funzionalità e componenti dell'infrastruttura predefiniti dal runtime Dapr. La figura 1-5 mostra Dapr da 20.000 piedi.
figura 1-5. Dapr a 20.000 piedi.
Nella riga superiore della figura notare come Dapr fornisce SDK specifici del linguaggio per piattaforme di sviluppo popolari. Dapr v1 include il supporto per .NET, Go, Node.js, Python, PHP, Java e JavaScript.
Anche se gli SDK specifici del linguaggio migliorano l'esperienza di sviluppo, Dapr è agnostico della piattaforma. Sotto la cappa, il modello di programmazione di Dapr espone le funzionalità tramite protocolli di comunicazione HTTP/gRPC standard. Qualsiasi piattaforma di programmazione può chiamare Dapr tramite le relative API HTTP e gRPC native.
Le caselle blu nel centro della figura rappresentano i blocchi predefiniti Dapr. Ogni oggetto espone codice predefinito per una funzionalità dell'applicazione distribuita che l'applicazione può usare.
La riga dei componenti rappresenta un set elevato di componenti dell'infrastruttura pre-definiti che l'applicazione può usare. Si considerino i componenti come codice dell'infrastruttura che non è necessario scrivere.
La riga inferiore evidenzia la portabilità di Dapr e gli ambienti diversi in cui può essere eseguito.
Microsoft offre un ebook gratuito Dapr per sviluppatori .NET per l'apprendimento dapr.
In futuro, Dapr ha il potenziale di avere un impatto profondo sullo sviluppo di applicazioni native del cloud.
Contenitori
È naturale sentire il termine contenitore menzionato in qualsiasi conversazione nativa del cloud . Nel libro Cloud Native Patterns, autore cornelia Davis osserva che "I contenitori sono un ottimo abilitatore del software nativo del cloud". Cloud Native Computing Foundation inserisce la contenitorizzazione di microservizi come primo passaggio della mappa trail cloud-native per le aziende che iniziano il percorso nativo del cloud.
Il contenitore di un microservizio è semplice e semplice. Il codice, le relative dipendenze e il runtime vengono inseriti in un pacchetto binario denominato immagine del contenitore. Le immagini vengono archiviate in un registro contenitori, che funge da repository o libreria per le immagini. Un Registro di sistema può trovarsi nel computer di sviluppo, nel data center o in un cloud pubblico. Docker gestisce un registro pubblico tramite Docker Hub. Il cloud di Azure offre un registro contenitori privato per archiviare le immagini dei contenitori vicine alle applicazioni cloud che verranno eseguite.
Quando un'applicazione viene avviata o ridimensionata, si trasforma l'immagine del contenitore in un'istanza del contenitore in esecuzione. L'istanza viene eseguita in qualsiasi computer con un motore di runtime del contenitore installato. È possibile avere quante istanze del servizio in contenitori in base alle esigenze.
La figura 1-6 mostra tre microservizi diversi, ognuno nel proprio contenitore, tutto in esecuzione in un singolo host.
Figura 1-6. Più contenitori in esecuzione in un host contenitore
Si noti come ogni contenitore gestisce il proprio set di dipendenze e runtime, che possono essere diversi tra loro. In questo caso vengono visualizzate versioni diverse del microservizio Product in esecuzione nello stesso host. Ogni contenitore condivide una sezione del sistema operativo host sottostante, la memoria e il processore, ma è isolata tra loro.
Si noti come il modello di contenitore abbraccia il principio Dipendenzedall'applicazione Twelve-Factor.
Factor #2 specifica che "Ogni microservizio isola e inserisce le proprie dipendenze, abbracciando le modifiche senza influire sull'intero sistema".
I contenitori supportano carichi di lavoro Linux e Windows. Il cloud di Azure abbraccia apertamente entrambi. Interessante, è Linux, non Windows Server, che è diventato il sistema operativo più popolare in Azure.
Sebbene esistano diversi fornitori di contenitori, Docker ha acquisito la quota del leone del mercato. L'azienda ha guidato lo spostamento del contenitore software. È diventato lo standard de facto per la creazione di pacchetti, la distribuzione e l'esecuzione di applicazioni native del cloud.
Perché i contenitori?
I contenitori forniscono la portabilità e garantiscono la coerenza tra ambienti. Incapsulando tutto in un singolo pacchetto, si isolano i microservizi e le relative dipendenze dall'infrastruttura sottostante.
È possibile distribuire il contenitore in qualsiasi ambiente che ospita il motore di runtime Docker. I carichi di lavoro in contenitori eliminano anche le spese per la preconfigurazione di ogni ambiente con framework, librerie software e motori di runtime.
Condividendo il sistema operativo sottostante e le risorse host, un contenitore ha un footprint molto più piccolo di una macchina virtuale completa. Le dimensioni più piccole aumentano la densità o il numero di microservizi, che un determinato host può essere eseguito in una sola volta.
Orchestrazione dei contenitori
Sebbene gli strumenti come Docker creino immagini ed eseguano contenitori, sono necessari anche strumenti per gestirli. La gestione dei contenitori viene eseguita con un programma software speciale denominato agente di orchestrazione del contenitore. Quando si opera su larga scala con molti contenitori in esecuzione indipendenti, l'orchestrazione è essenziale.
La figura 1-7 mostra le attività di gestione automatizzate degli agenti di orchestrazione dei contenitori.
Figura 1-7. Che cosa fanno gli agenti di orchestrazione dei contenitori
Nella tabella seguente vengono descritte le attività di orchestrazione comuni.
| Attività | Spiegazione |
|---|---|
| Pianificazione | Effettuare automaticamente il provisioning delle istanze del contenitore. |
| Affinità/affinità anti-affinità | Effettuare il provisioning di contenitori nelle vicinanze o lontano tra loro, consentendo la disponibilità e le prestazioni. |
| Monitoraggio dell’integrità | Rilevare e correggere automaticamente gli errori. |
| Failover | Eseguire automaticamente il reprovisioning di un'istanza non riuscita in un computer integro. |
| Scalabilità | Aggiungere o rimuovere automaticamente un'istanza del contenitore per soddisfare la domanda. |
| Rete | Gestire una sovrimpressione di rete per la comunicazione tra contenitori. |
| Individuazione dei servizi | Abilitare i contenitori per individuarsi tra loro. |
| Aggiornamenti in sequenza | Coordinare gli aggiornamenti incrementali con una distribuzione senza tempi di inattività. Eseguire automaticamente il rollback delle modifiche problematiche. |
Si noti che gli agenti di orchestrazione dei contenitori adottano i principi di disposbilità e concorrenzadell'applicazione Twelve-Factor.
Factor #9 specifica che "Le istanze del servizio devono essere eliminabili, favorendo le startup veloci per aumentare le opportunità di scalabilità e gli arresti normale per lasciare il sistema in uno stato corretto". I contenitori Docker insieme a un agente di orchestrazione soddisfano intrinsecamente questo requisito".
Factor #8 specifica che "i servizi vengono ridimensionati in un numero elevato di piccoli processi identici (copie) anziché aumentare le prestazioni di una singola istanza di grandi dimensioni nel computer più potente disponibile".
Anche se esistono diversi agenti di orchestrazione dei contenitori, Kubernetes è diventato lo standard di fatto per il mondo nativo del cloud. Si tratta di una piattaforma open source portabile ed estendibile per la gestione di carichi di lavoro in contenitori.
È possibile ospitare la propria istanza di Kubernetes, ma quindi si è responsabili del provisioning e della gestione delle risorse, che possono essere complesse. Il cloud di Azure offre Kubernetes come servizio gestito. Sia servizio Azure Kubernetes (AKS) che Azure Red Hat OpenShift (ARO) consentono di sfruttare appieno le funzionalità e la potenza di Kubernetes come servizio gestito, senza dover installarla e gestirla.
L'orchestrazione dei contenitori è descritta in dettaglio in Ridimensionamento delle applicazioni Cloud-Native.
Servizi di backup
I sistemi nativi del cloud dipendono da molte risorse ausiliarie diverse, ad esempio archivi dati, broker di messaggi, monitoraggio e servizi di gestione delle identità. Questi servizi sono noti come servizi di backup.
La figura 1-8 mostra molti servizi di supporto comuni usati dai sistemi nativi del cloud.
Figura 1-8. Servizi di backup comuni
È possibile ospitare i propri servizi di backup, ma sarà quindi necessario essere responsabili delle licenze, del provisioning e della gestione di tali risorse.
I provider di servizi cloud offrono un'ampia gamma di servizi di supporto gestiti. Invece di possedere il servizio, è sufficiente utilizzarlo. Il provider di servizi cloud gestisce la risorsa su larga scala e si assume la responsabilità di prestazioni, sicurezza e manutenzione. Il monitoraggio, la ridondanza e la disponibilità sono integrati nel servizio. I provider garantiscono prestazioni a livello di servizio e supportano completamente i servizi gestiti: aprire un ticket e risolvere il problema.
I sistemi nativi del cloud favoriscono i servizi di backup gestiti dai fornitori di servizi cloud. Il risparmio nel tempo e nel lavoro può essere significativo. Il rischio operativo di ospitare i propri e riscontrare problemi può diventare costoso veloce.
Una procedura consigliata consiste nel considerare un servizio di backup come risorsa collegata, associato dinamicamente a un microservizio con informazioni di configurazione (URL e credenziali) archiviate in una configurazione esterna. Queste linee guida sono descritte in Twelve-Factor Application, descritte in precedenza nel capitolo.
Factor #4 specifica che i servizi di backup "devono essere esposti tramite un URL indirizzabile. In questo modo la risorsa viene disaccoppiato dall'applicazione, consentendo l'interscambio".
Factor #3 specifica che "Le informazioni di configurazione vengono spostate fuori dal microservizio ed esterne tramite uno strumento di gestione della configurazione al di fuori del codice".
Con questo modello, un servizio di backup può essere collegato e scollegato senza modifiche al codice. È possibile alzare di livello un microservizio dal controllo di qualità a un ambiente di gestione temporanea. Aggiornare la configurazione del microservizio in modo che punti ai servizi di backup nella gestione temporanea e inserire le impostazioni nel contenitore tramite una variabile di ambiente.
I fornitori di servizi cloud forniscono API per comunicare con i servizi di backup proprietari. Queste librerie incapsulano l'impianto idraulico proprietario e la complessità. Tuttavia, la comunicazione diretta con queste API associa strettamente il codice a tale servizio di backup specifico. Si tratta di una pratica ampiamente accettata per isolare i dettagli di implementazione dell'API fornitore. Introdurre un livello intermedio o un'API intermedia, esponendo le operazioni generica al codice del servizio ed eseguindo il wrapping del codice fornitore al suo interno. Questo accoppiamento libero consente di scambiare un servizio di backup per un altro o spostare il codice in un ambiente cloud diverso senza dover apportare modifiche al codice del servizio mainline. Dapr, descritto in precedenza, segue questo modello con il set di blocchi predefiniti predefiniti.
Su un pensiero finale, i servizi di backup promuovono anche il principio di senza statodall'applicazione a dodici fattori, discusso in precedenza nel capitolo.
Factor #6 specifica che ogni microservizio deve essere eseguito nel proprio processo, isolato da altri servizi in esecuzione. Esternalizzare lo stato richiesto a un servizio di backup, ad esempio una cache distribuita o un archivio dati."
I servizi di backup sono descritti in Modelli di dati nativi del cloud e modelli di comunicazione nativi del cloud.
Automazione
Come si è visto, i sistemi nativi del cloud adottano microservizi, contenitori e progettazione moderna del sistema per ottenere velocità e agilità. Ma, questa è solo parte della storia. Come si effettua il provisioning degli ambienti cloud su cui vengono eseguiti questi sistemi? Come si distribuiscono rapidamente le funzionalità e gli aggiornamenti delle app? Come si completa l'immagine completa?
Immettere la pratica ampiamente accettata di Infrastructure as Code o IaC.
Con IaC è possibile automatizzare il provisioning della piattaforma e la distribuzione di applicazioni. Si applicano essenzialmente procedure di progettazione del software, ad esempio test e controllo delle versioni alle procedure DevOps. L'infrastruttura e le distribuzioni sono automatizzate, coerenti e ripetibili.
Automazione dell'infrastruttura
Strumenti come Azure Resource Manager, Azure Bicep, Terraform di HashiCorp e l'interfaccia della riga di comando di Azure consentono di creare script in modo dichiarativo per l'infrastruttura cloud necessaria. I nomi delle risorse, le posizioni, le capacità e i segreti sono parametrizzati e dinamici. Lo script viene sottoposto a controllo delle versioni e archiviato nel controllo del codice sorgente come artefatto del progetto. Richiamare lo script per effettuare il provisioning di un'infrastruttura coerente e ripetibile in ambienti di sistema, ad esempio controllo di qualità, gestione temporanea e produzione.
Sotto il cofano, IaC è idempotente, il che significa che è possibile eseguire lo stesso script su e su senza effetti collaterali. Se il team deve apportare una modifica, modifica ed esegue nuovamente lo script. Sono interessate solo le risorse aggiornate.
Nell'articolo Informazioni sull'infrastruttura come codice, autore Sam Guckheimer descrive come, "Teams che implementa IaC può offrire ambienti stabili e su larga scala. Evitano la configurazione manuale degli ambienti e applicano la coerenza rappresentando lo stato desiderato degli ambienti tramite codice. Le distribuzioni dell'infrastruttura con IaC sono ripetibili e impediscono problemi di runtime causati dalla deriva della configurazione o dalle dipendenze mancanti. I team DevOps possono collaborare con un set unificato di procedure e strumenti per distribuire applicazioni e l'infrastruttura di supporto rapidamente, in modo affidabile e su larga scala".
Automazione delle distribuzioni
L'applicazione Twelve-Factor, descritta in precedenza, richiede passaggi separati quando si trasforma il codice completato in un'applicazione in esecuzione.
Factor #5 specifica che "Ogni versione deve applicare una separazione rigorosa tra le fasi di compilazione, rilascio ed esecuzione. Ogni tag deve essere contrassegnato con un ID univoco e supporta la possibilità di eseguire il rollback".
I sistemi CI/CD moderni consentono di soddisfare questo principio. Forniscono procedure di compilazione e recapito separate che consentono di garantire codice coerente e qualitativo facilmente disponibile per gli utenti.
La figura 1-9 mostra la separazione tra il processo di distribuzione.
Figura 1-9. Passaggi di distribuzione in una pipeline CI/CD
Nella figura precedente prestare particolare attenzione alla separazione delle attività:
- Lo sviluppatore costruisce una funzionalità nell'ambiente di sviluppo, iterando il cosiddetto "ciclo interno" di codice, esecuzione e debug.
- Al termine, il codice viene inserito in un repository di codice, ad esempio GitHub, Azure DevOps o BitBucket.
- Il push attiva una fase di compilazione che trasforma il codice in un artefatto binario. Il lavoro viene implementato con una pipeline di integrazione continua (CI). Compila, testa e crea automaticamente pacchetti l'applicazione.
- La fase di rilascio preleva l'artefatto binario, applica informazioni di configurazione dell'applicazione e dell'ambiente esterne e produce una versione non modificabile. La versione viene distribuita in un ambiente specificato. Il lavoro viene implementato con una pipeline di recapito continuo (CD). Ogni versione deve essere identificabile. Si può dire che questa distribuzione esegue la versione 2.1.1 dell'applicazione.
- Infine, la funzionalità rilasciata viene eseguita nell'ambiente di esecuzione di destinazione. Le versioni non sono modificabili, ovvero qualsiasi modifica deve creare una nuova versione.
Applicando queste procedure, le organizzazioni hanno radicalmente evoluto il modo in cui spediscono il software. Molti sono passati da versioni trimestrali agli aggiornamenti su richiesta. L'obiettivo è rilevare i problemi all'inizio del ciclo di sviluppo quando sono meno costosi da risolvere. Più lunga è la durata tra le integrazioni, i problemi più costosi diventano da risolvere. Con coerenza nel processo di integrazione, i team possono eseguire il commit delle modifiche del codice più frequentemente, con conseguente migliore collaborazione e qualità del software.
L'infrastruttura come codice e l'automazione della distribuzione, insieme a GitHub e Azure DevOps, sono descritte in dettaglio in DevOps