Antipattern di preparazione al cloud

Articolo
03/22/2023

Spesso i clienti spesso affrontano gli antipattern durante la fase di preparazione dell'adozione del cloud. Questi antipattern possono causare tempi di inattività imprevisti, problemi di ripristino di emergenza e problemi di disponibilità.

Antipattern: presupporre che i servizi rilasciati siano pronti per la produzione

Poiché il cloud computing è in rapida evoluzione, le aziende spesso rilasciano versioni di anteprima dei nuovi servizi. I clienti tendono a presupporre di poter usare qualsiasi servizio cloud disponibile in un ambiente di produzione. Possono tuttavia verificarsi problemi per i motivi seguenti:

I servizi di anteprima in genere non prevedono contratti di servizio per il tempo di attività.
I nuovi servizi spesso non sono pronti quanto i servizi cloud già disponibili.

Esempio: usare un servizio in anteprima nell'ambiente di produzione

Un istituto di ricerca usa un servizio cloud in anteprima nell'ambiente di produzione. Il servizio sembra essere una buona opzione per il caso d'uso. L'istituto, tuttavia, non esegue la due diligence sul servizio e non segue i requisiti e le linee guida dell'architettura di riferimento.

Il servizio in anteprima causa problemi che portano a tempi di inattività imprevisti. L'istituto inizia a pensare che i servizi cloud in generale non siano pronti o resilienti come annunciato.

Risultato preferito: nell'ambiente di produzione usare servizi cloud pre-approvati

Quando si valutano nuovi servizi disponibili in anteprima, usarli solo in scenari di modello di verifica. Non usarli in ambienti di produzione, perché non hanno contratti di servizio. Trovare il giusto equilibrio tra funzionalità e maturità quando si approvano i servizi cloud. Vedere l'Elenco di controllo per due diligence dei servizi cloud per un framework consolidato che è possibile usare per valutare rapidamente i servizi cloud.

Antipattern: presupporre una maggiore resilienza e disponibilità

Il cloud computing offre spesso vantaggi rispetto al computing locale. Tra gli esempi sono inclusi:

Maggiore resilienza: ripristino in caso di errore.
Disponibilità: esecuzione in uno stato di integrità senza tempi di inattività significativi.

Poiché la maggior parte dei servizi cloud offre questi vantaggi, molte aziende presuppongono che tutti i servizi cloud offrano, per impostazione predefinita, resilienza e disponibilità elevata. In realtà queste funzionalità sono spesso disponibili solo a costi aggiuntivi e con un ulteriore impegno tecnico.

Esempio: presupporre disponibilità elevata

Una start-up implementa un'applicazione cruciale nei servizi IaaS (infrastruttura distribuita come servizio). Gli sviluppatori della start-up hanno esaminato una macchina virtuale con un contratto di servizio relativo al tempo di attività del 99,9%. Poiché vogliono ridurre i costi, usano una sola macchina virtuale e un'archiviazione Premium.

Quando la macchina virtuale si blocca, l'applicazione non può eseguire il ripristino. Di conseguenza si verificano tempi di inattività imprevisti. Gli sviluppatori avevano presupposto che il cloud offre la disponibilità elevata per impostazione predefinita. Non sapevano che le garanzie di prestazioni possono differire tra:

Modelli di servizio quali piattaforma distribuita come servizio (PaaS) e software come un servizio (SaaS).
Architetture tecniche come set di disponibilità con bilanciamento del carico e zone di disponibilità.

Risultato preferito: ridurre gli errori bilanciando la resilienza e i costi

Per informazioni sulle procedure consigliate per l'architettura che possono ridurre l'ambito degli errori vedere le risorse mature e affidabili:

Identificare il giusto equilibrio tra costi e funzionalità come resilienza e disponibilità elevate. L'aumento della resilienza e della disponibilità in genere porta a un aumento dei costi. Ad esempio:

Una singola macchina virtuale potrebbe avere un contratto di servizio con un tempo di attività garantito del 99,9%.
Due macchine virtuali che eseguono lo stesso carico di lavoro prevedono un contratto di servizio con un tempo di attività compreso tra il 99,95 e il 99,99%.

Durante la progettazione di una soluzione basata sul cloud, è consigliabile partecipare al processo essenziale di progettazione dei requisiti. Usare una stima del contratto di servizio per calcolare il contratto di servizio end-to-end dell'applicazione.

Antipattern: diventare un provider di servizi cloud

Alcune aziende tentano di trasformare il proprio reparto IT interno in un provider di servizi cloud. L'IT diventa quindi responsabile delle architetture di riferimento e deve anche garantire IaaS e PaaS alle business unit. Poiché questo tipo di lavoro non fa in genere parte delle attività principali dell'IT, le offerte di servizio risultanti possono essere carenti di utilizzabilità, resilienza, efficienza e sicurezza.

Esempio: garantire servizi cloud con gestione monolitica

Il reparto IT di un'azienda stabilisce un Centro di eccellenza cloud che funge da intermediario tra IT e business unit. Per garantire che l'azienda sia conforme al cloud, il consiglio di amministrazione assegna al Centro di eccellenza cloud il compito di garantire servizi end-to-end monolitici. Il Centro di eccellenza cloud configura un portale di approvvigionamento cloud interno che le business unit possono usare per ordinare una macchina virtuale cloud completamente gestita come servizio. L'IT controlla, tuttavia, gli utenti che possono accedere e usare l'intera piattaforma. Di conseguenza, l'IT impedisce attivamente alle business unit di sfruttare l'intera gamma di servizi offerti da Azure. Le business unit non possono accedere al portale cloud. Ottengono l'accesso tramite Secure Shell (SSH) e Remote Desktop Protocol (RDP) solo al server che ordinano.

Per diversi motivi, il Centro di eccellenza cloud ha quindi problemi a garantire un servizio gestito monolitico che includa tutti i servizi disponibili nel cloud:

Il cloud offre un numero elevato di servizi in più aree della soluzione. Rispetto allo sviluppo delle soluzioni IaaS, la progettazione di soluzioni Internet delle cose (IoT) e di intelligenza artificiale richiede esperienze e set di competenze diversi.
I servizi cloud cambiano di frequente.
Il tentativo di offerta dei servizi monolitici aumenta la sostenibilità del tempo di immissione sul mercato e il processo viene gestito dal settore IT, non delle business unit.

Risultato preferito: offrire protezioni

Quando si adottano le tecnologie cloud, il reparto IT deve acquisire direttamente l'esperienza con il cloud iniziando con i carichi di lavoro IT. Usare Microsoft Cloud Adoption Framework per Azure per identificare il primo progetto di adozione.

Usare un modello operativo cloud maturo, ad esempio operazioni centralizzate che rendono l'IT responsabile della definizione di protezioni per la piattaforma come la governance. Le business unit possono quindi adottare progetti cloud in modo sicuro e coerente, grazie alle protezioni definite dall'IT.

All'inizio prendere in considerazione l'adozione di un solo importante provider di servizi cloud pubblici, perché tutte le principali piattaforme differiscono in modo significativo per la configurazione, la gestione e l'utilizzo.

Usare il più possibile soluzioni SaaS per gli strumenti IT, ad esempio:

Repository di codice.
Integrazione continua e recapito continuo (CI/CD).
Sistemi di collaborazione.

Per i carichi di lavoro cloud, consigliare all'IT di usare procedure note che funzionino in modo sicuro e protetto su larga scala.