Test multi-cloud come unico modo che la programmazione ha per assicurare che un’implementazione multi-cloud soddisfi gli obiettivi previsti in condizioni reali. Più che su strumenti nuovi e costosi o pratiche complesse, quest’attività di QA richiede agli sviluppatori di concentrarsi su determinati aspetti relativi ai cicli di sviluppo e di distribuzione delle app. Gli esperti prendono in considerazione tutti gli aspetti per cui i test multicloud svolgono un ruolo così importante.
Dove il multi-cloud complica le cose
Quando si parla di multicloud, la complessità dello sviluppo e della distribuzione aumenta per 4 motivazioni principali.
#1 Implementazione su più cloud
Sebbene ci sia un denominatore comune di funzionalità in tutti i tipi di cloud, la loro implementazione varia leggermente dall’uno all’altro. Se gli sviluppatori devono preparare un singolo componente per l’implementazione distribuita su più cloud sono necessarie versioni software diverse.
#2 Componenti ampiamente diffusi
Le prestazioni applicative e la qualità dell’esperienza si differenziano a seconda di come i componenti di un flusso di lavoro sono distribuiti tra i vari cloud. Questo rende difficile il monitoraggio e la possibilità di assicurare le prestazioni.
#3 Ottimizzazione delle implementazioni per ogni cloud
Gli sviluppatori devono anche considerare che gli stessi strumenti operativi potrebbero non essere disponibili in tutti i cloud. Analogamente, i programmatori potrebbero non utilizzare allo stesso modo determinati strumenti all’interno di ogni cloud. Di conseguenza, i membri del team applicativo potrebbero dover ottimizzare le distribuzioni e le ridistribuzioni in modo diverso per ogni tipo cloud. Inoltre, la ridistribuzione da un cloud all’altro potrebbe dover essere convalidata per ogni possibile combinazione di cloud.
#4 Garantire la connettività
Considerando utenti Internet, i vari cloud pubblici e il data center in loco, anche il livello di connettività rappresenta una serie di variabili da gestire. Di conseguenza, l’indirizzamento di rete e le pratiche di gestione del traffico dovranno tener conto delle differenze di connettività che sussistono in tutto l’ecosistema.
Dove affrontare i rischi multi-cloud
Qualsiasi aumento della complessità crea un rischio a livello di prestazioni, della disponibilità delle applicazioni, della sicurezza ma anche della conformità, il che spesso porta a uno sforamento dei costi del cloud. Questi rischi derivano da due fattori:
- Il primo è che il multi-cloud potrebbe richiedere la distribuzione della stessa logic,a mentre gli sviluppatori potrebbero dover codificare la logica in modi diversi per adattarsi alle differenze delle API cloud, il che moltiplica il numero delle pipeline applicative.
- Il secondo è il rischio che i flussi di lavoro tra i cloud in questa configurazione varino in modi non previsti o adattati nella progettazione delle applicazioni. È questa variabilità che la strategia di test multi-cloud deve affrontare.
Test multi-cloud: come funziona
Introducendo specifici test multi-cloud, i programmatori possono gestire meglio il rischio di un moltiplicarsi di applicazioni durante i cicli di sviluppo e i test unitari. Tuttavia, questo tipo di test multi-cloud richiede la netta separazione dei componenti software che necessitano di personalizzazione per ogni cloud. Il disaccoppiamento garantisce che il codice non passi mai a un cloud in cui servizi e funzionalità non sono compatibili. Il che significa anche che il processo di sviluppo e test multi-cloud, fino al momento del test di carico, dovrebbe trattare ogni variante specifica del cloud come un’applicazione o un progetto separato e con la propria pipeline di sviluppo.
In questo tipo di configurazione, la relazione tra ciascuna variante cloud e la logica di base per i componenti deve essere mantenuta in modo che la manutenzione parallela sia efficiente. Alcune organizzazioni possono mantenere un set con il codice di base per ogni componente, diramandolo a versioni specifiche del cloud, garantendo che le modifiche alla logica si applichino a tutte le versioni cloud in modo coordinato.
Quando una modifica della logica a un componente software (che in precedenza non richiedeva codice specifico per il cloud) crea la necessità di personalizzare uno o più cloud, gli sviluppatori devono eseguire il fork della versione di base singola per ogni cloud che deve essere adattato. In tutto questo, l’elaborazione di una documentazione accurata è fondamentale per garantire la trasparenza del codice a supporto dei futuri interventi di sviluppo.
Dove i flussi di lavoro diventano un fattore distintivo
Se il team di sviluppo partiziona il codice specifico del cloud utilizzando una pipeline per cloud, le pratiche di sviluppo e test multi-cloud sono le stesse di un cloud singolo o ibrido. Tuttavia, anche a livello di test multi-cloud sono richieste pratiche speciali e persino strumenti per i test di carico. Dopotutto, i test di carico devono simulare le condizioni che creano variazioni nel flusso di lavoro tra i cloud. I cambiamenti nel flusso di lavoro esporranno una nuova logica, che i professionisti del QA devono testare.
Test multi-cloud: quali sono i motivi di una variazione dei flussi
Ci sono due ragioni per cui i flussi di lavoro potrebbero variare. In primo luogo, potrebbero esserci caratteristiche o capacità migliori da gestire per uno specifico provider di servizi cloud. Questo significa che il lavoro deve fluire da e verso quel fornitore quando queste caratteristiche/capacità sono richieste. In secondo luogo, un’applicazione può utilizzare selettivamente un cloud per eseguire il backup di un altro o per supportare il ridimensionamento sotto carico:
- Nel primo caso, è importante concentrarsi sull’input dei dati di test che esercita questa logica specifica per funzionalità/capacità.
- Nel secondo caso, è necessario creare le condizioni di disponibilità o carico di lavoro che modifichino i flussi di lavoro multi-cloud e il posizionamento dei componenti per garantire che la logica funzioni e la QoE non diventi inaccettabile.
Non è necessario utilizzare strumenti di generazione dei dati di test speciali per i test multi-cloud. Ma se il QA decide di usarli, è importante usarli correttamente.
Attenzione anche a presidiare le geografie
L’utilizzo corretto inizia assicurando l’iniezione di dati di test contemporaneamente su tutti i cloud in cui è supportato l’accesso degli utenti. Tale accesso è sempre il caso in cui è stata presa una decisione multi-cloud per accogliere una base di utenti distribuita. È importante assicurarsi che l’iniezione di dati di test per ciascun cloud sia locale a quel cloud, ovvero generata nella stessa zona geografica in cui gli utenti si connetteranno.
L’importanza del monitoraggio nel test multi-cloud
Un altro requisito fondamentale è enfatizzare il monitoraggio incentrato sul flusso di lavoro del test e, a sua volta, estendere la stessa visione ai problemi scoperti in fase di controllo. È importante identificare situazioni con rischi multi-cloud esclusivi e mappare le risposte a flussi di lavoro specifici per il ridimensionamento, il failover o quando l’applicazione richiama l’accesso alla logica specifica del cloud. Queste situazioni speciali dovranno essere attivate dai dati di test e quindi misurate in modo specifico attraverso la gamma di componenti e attraverso tutti i confini del cloud.
I dati di test casuali da soli non attiveranno sempre le situazioni speciali che si stanno cercando di testare, quindi è opportuno sequenziare test multi-cloud coordinati e sincronizzati su tutti i cloud in cui gli utenti si connettono sono essenziali. È bene controllare l’intero flusso di lavoro per assicurarsi di aver affrontato completamente il problema.
