5 sfide per diventare nativi del cloud e come risolverli

Viviamo in un mondo nativo del cloud. Riesci a malapena a leggere un blog tecnico o andare a una conferenza senza conoscere tutti i vantaggi delle tecnologie o architetture native del cloud, come container, microservizi e funzioni senza server.

Tuttavia, nonostante tutta l'eccitazione di diventare nativi del cloud, può essere facile trascurare le sfide che sorgono quando si passa da applicazioni legacy monolitiche a una strategia nativa del cloud. Queste sfide possono essere superate, ma solo se le affronti come parte della tua strategia di migrazione nativa del cloud.

A tal fine, diamo un'occhiata a cinque delle più comuni sfide native del cloud, insieme alle strategie per superarle.

Che cos'è il cloud nativo?

Per prima cosa, una parola su cosa significhi effettivamente cloud-native.

Con l'hype intorno al "cloud", il "cloud-native" viene talvolta utilizzato dalle persone per indicare qualsiasi tipo di tecnologia o strategia che considerano moderna. Da quel punto di vista, il cloud nativo finisce come solo un'altra parola d'ordine relativamente insignificante.

D'altra parte, quando investito con significato specifico e limitato, cloud-native è un termine e un concetto utili. Ci piace la definizione del CNCF, che enfatizza i "sistemi debolmente accoppiati" e la resilienza come caratteristiche del cloud-native computing. La definizione di CNCF indica anche un elenco specifico e limitato di tecnologie e architetture - "container, mesh di servizio, microservizi, infrastruttura immutabile e API dichiarative" - ​​come esempi di tecnologie native del cloud.

Ai fini di questo articolo, ci atterremo alla definizione di cloud-native di CNCF. Ora, discutiamo delle sfide specifiche che si presentano quando si utilizzano tecnologie e strategie come quelle sopra descritte.

Sfide per l'adozione del cloud nativo

1) Memorizzazione dei dati persistente

Una sfida comune con molte tecnologie native del cloud è l'archiviazione persistente dei dati. I contenitori, le funzioni senza server e le applicazioni distribuite utilizzando un modello di infrastruttura immutabile non hanno in genere un modo per archiviare i dati permanentemente al loro interno perché tutti i dati interni vengono distrutti quando l'applicazione viene chiusa.

Per risolvere questa sfida è necessario ripensare gli approcci alla memorizzazione dei dati disaccoppiandoli dalle applicazioni e dagli ambienti host. Invece di archiviare i dati all'interno dell'ambiente applicativo, i flussi di lavoro nativi del cloud li archiviano esternamente ed espongono i dati come servizio. Quindi, i carichi di lavoro che devono accedere ai dati, si connettono ad esso proprio come si collegherebbero a qualsiasi altro servizio.

Questo approccio - che è abilitato da vari strumenti, come i volumi in Kubernetes - ha due vantaggi. Oltre a consentire l'archiviazione persistente di dati per applicazioni che non sono progettate per essere persistenti, semplifica anche la condivisione di un singolo pool di archiviazione tra più applicazioni o servizi.

2) Integrazione del servizio

Le applicazioni native del cloud sono in genere composte da una serie di servizi diversi. Questa natura distribuita è ciò che aiuta a renderli scalabili e flessibili, rispetto ai monoliti.

Ma significa anche che i carichi di lavoro nativi del cloud hanno molti più elementi mobili che devono essere collegati senza soluzione di continuità per raggiungere il successo.

In parte, l'integrazione dei servizi è un problema che gli sviluppatori devono affrontare mentre creano app native per il cloud. Devono garantire che ogni servizio sia dimensionato correttamente; una procedura consigliata consiste nel creare un servizio distinto per ogni tipo di funzionalità all'interno di un carico di lavoro, anziché cercare di fare in modo che un singolo servizio faccia più cose. È anche importante evitare di aggiungere servizi solo perché è possibile. Prima di introdurre una maggiore complessità nella tua app sotto forma di un altro servizio, assicurati che il servizio faccia avanzare un determinato obiettivo.

Oltre all'architettura dell'applicazione stessa, un'efficace integrazione del servizio dipende anche dalla scelta delle giuste tecniche di distribuzione. I contenitori sono probabilmente il modo più ovvio per distribuire più servizi e unificarli in un singolo carico di lavoro, ma in alcuni casi, le funzioni senza server o le app non containerizzate collegate dalle API potrebbero essere metodi migliori di distribuzione del servizio.

3) Gestione e monitoraggio

Più servizi hai in esecuzione come parte di un'applicazione, più diventa difficile monitorarli e gestirli. Questo è vero, non solo per il semplice numero di servizi che devi tenere traccia, ma anche perché garantire l'integrità delle applicazioni richiede il monitoraggio delle relazioni tra i servizi, non solo i servizi stessi.

Quindi monitorare e gestire con successo i servizi in un ambiente nativo nel cloud richiede un approccio in grado di prevedere in che modo un guasto in un servizio avrà un impatto sugli altri, oltre a comprendere quali guasti sono i più critici. Anche il baselining dinamico, che significa sostituire le soglie statiche con quelle che riesaminano continuamente gli ambienti delle applicazioni al fine di determinare ciò che è normale e ciò che è un'anomalia, è anche fondamentale.

4) Evitare il blocco del cloud

I rischi di blocco non sono univoci per il cloud; possono derivare da quasi ogni tipo di tecnologia e sono stati una minaccia all'agilità per decenni. Tuttavia, nel caso di applicazioni o architetture native del cloud, la minaccia di diventare troppo dipendente da un determinato fornitore o servizio cloud può essere particolarmente grande, a causa della facilità con cui i carichi di lavoro possono essere distribuiti in modo tale da richiedere un particolare servizio da un cloud particolare.

Fortunatamente, mitigare questo rischio di blocco del cloud è abbastanza facile purché si pianifichi in anticipo. Attenersi agli standard di comunità (come quelli promossi dall'OCCI) farà molto per garantire che sia possibile spostare facilmente i carichi di lavoro da un cloud all'altro. Allo stesso modo, mentre pianifichi quali servizi cloud utilizzerai per diventare nativi del cloud, considera se uno qualsiasi dei servizi che stai prendendo in considerazione ha funzionalità veramente uniche e non disponibili da altri cloud. Se lo fanno, evita quelle funzionalità, perché possono bloccarti.

Ad esempio, i linguaggi e i framework specifici supportati dalle piattaforme di elaborazione senza server di vari cloud pubblici variano leggermente. AWS Lambda supporta Go, ad esempio, ma Azure no. Per questo motivo, saresti saggio evitare di scrivere le tue funzioni senza server in Go. Anche se prevedi di utilizzare AWS per ospitarli inizialmente, questa dipendenza renderebbe difficile migrare verso un cloud diverso in futuro. Stick con un linguaggio come Java, che puoi scommettere in modo sicuro sarà supportato ovunque.

5) Creazione di app per pipeline di consegna native del cloud

Per definizione, le app native del cloud vengono eseguite nel cloud. Mentre il cloud può essere cloud pubblico o runnnig cloud privato, on-prem o ibrido negli ambienti dell'organizzazione, significa infrastruttura immutabile e processi di gestione del cloud. Tuttavia, molte pipeline di distribuzione delle applicazioni continuano a funzionare in gran parte in ambienti locali tradizionali che potrebbero non essere stati parzialmente danneggiati o ingombranti se integrati con applicazioni e servizi in esecuzione su cloud pubblici o container.

Questo crea una sfida sotto diversi aspetti. Uno è che la distribuzione di codice da un ambiente locale a un locale può causare ritardi. Un altro è che lo sviluppo e il test a livello locale rendono più difficile emulare le condizioni di produzione, il che può portare a comportamenti imprevisti delle applicazioni, dopo la distribuzione.

Il modo più efficace per superare questi ostacoli è spostare la pipeline CI / CD in un ambiente cloud, non solo per beneficiare dell'infrastruttura immutabile, della scalabilità del cloud e di altri vantaggi, ma anche per imitare le condizioni di produzione e avvicinare la pipeline - tanto quanto il più possibile - alle tue app. In questo modo, il codice viene scritto più vicino a dove viene distribuito, rendendo la distribuzione più veloce. Inoltre, diventa più semplice creare ambienti di test identici a quelli di produzione.

Mentre lo sviluppo completamente basato su cloud non è per tutti e alcuni sviluppatori preferiscono la familiarità e la reattività degli IDE locali rispetto a quelli basati su cloud, cerca di assicurarti che le tue pipeline CI / CD siano in esecuzione su un ambiente cloud, per quanto possibile.

Conclusione

Non importa come lo giri, diventare cloud-native è difficile. Rispetto alle applicazioni legacy, le applicazioni native del cloud sono più complesse e hanno molti più luoghi in cui le cose possono andare storte. Detto questo, è possibile superare le sfide informatiche native del cloud e l'implementazione di strategie in grado di affrontare le sfide è la chiave per sbloccare l'agilità, l'affidabilità e la scalabilità che solo le architetture native del cloud possono offrire.