Come progettare un'architettura hybrid cloud

Nel passato recente, un approccio all'hybrid cloud in genere prevedeva la migrazione di alcuni servizi dall'infrastruttura on-premise a un cloud privato o pubblico e questi servizi comunicavano tra loro. Anche se una nuova applicazione era stata creata per essere ospitata su un cloud pubblico, aderiva a un'architettura tradizionale orientata ai servizi (SOA).

Ma oggi, l'architettura basata sui microservizi è al centro del modello di hybrid cloud. I microservizi sono un approccio in cui un'applicazione è suddivisa in componenti o servizi più piccoli per una facile implementazione. Questi microservizi si differenziano dai servizi nella SOA in quanto dispongono di uno stack tecnologico proprio e sono distribuiti in container, che sono eseguibili leggeri contenenti il microservizio e le librerie di cui dipende.

I container sono leggeri perché condividono il kernel del sistema operativo (SO) della macchina, il che significa che ogni container contiene solo il microservizio e le sue dipendenze. Tutte le dipendenze del sistema operativo sono condivise dall'hardware in cui risiede il container. Questa virtualizzazione consente ai microservizi di essere implementati indipendentemente in qualsiasi ambiente on-premise o cloud. E l'autosufficienza rende i microservizi molto diversi dalla SOA e più adatti alla distribuzione nel cloud, in cui la necessità di elasticità e la flessibilità per ottimizzare le risorse cloud è fondamentale.

La containerizzazione come modello di packaging per isolare i processi in qualsiasi ambiente non è un concetto nuovo, ma l'emergere di Docker nel 2013 come motore di container ha creato una struttura di packaging universale. Inoltre, una piattaforma di orchestrazione dei container come Kubernetes automatizza la distribuzione di Docker, o di qualsiasi altro container che si conforma agli standard Open Container Initiative (OCI), in ambienti hybrid cloud.

L'emergere della containerizzazione ha contribuito a sfruttare davvero i benefici degli hybrid cloud, con l'attenzione rivolta alla facile portabilità dei workload e alla distribuzione automatica dei servizi nel cloud di tua scelta.

Qualche anno fa, le questioni principali in una discussione sull'architettura hybrid cloud riguardavano quale ambiente cloud o on-premise dovesse eseguire ogni workload e come far comunicare tra loro questi diversi ambienti. Essenzialmente, la posizione di hosting e la connettività fisica sono rimaste le considerazioni principali.

Ad esempio, un'applicazione che si occupa di dati sensibili sarebbe ospitata su un cloud privato. Oppure un'app legacy che è difficile da modernizzare continuerebbe a esistere on-premise. Nel frattempo, le organizzazioni trasferirebbero le app che necessitano di scalabilità verso ambienti cloud pubblici. Quindi, creerebbero canali come tunnel di reti private virtuali (VPN) o flussi di messaggi per facilitare la comunicazione tra gli ambienti.

Questi sono ancora fattori importanti da considerare, ma con il paradigma della containerizzazione, l'attenzione si è spostata dalla posizione fisica e dalla connettività alla flessibilità nello spostare senza problemi i workload da un ambiente all'altro. Quindi, se si decide di ospitare un'applicazione in un cloud privato o in un cloud pubblico, non deve essere una decisione rigida. Se la strategia non funziona, è facile spostare i workload confezionati come container tra diversi ambienti, scalare verso l'alto o verso il basso e persino eseguire istanze dello stesso servizio in ambienti differenti.

Tutto ciò ha portato a un'architettura moderna, altamente disponibile e flessibile che offre alte prestazioni, efficienza delle risorse e risparmi sui costi.

La progettazione e l'implementazione di un'architettura hybrid cloud devono tenere conto di molti fattori, tra cui gli obiettivi aziendali di un'azienda, il suo attuale landscape, gli obiettivi di trasformazione digitale e le considerazioni sulla sicurezza. Poiché un'architettura di questo tipo con più soluzioni hybrid cloud potrebbe diventare complessa molto rapidamente, è importante utilizzare gli strumenti operativi per un cloud management centralizzato, senza soluzione di continuità e scalabile. Ecco alcuni fattori da considerare durante la creazione della strategia di hybrid cloud.

Strategia di modernizzazione

Per la maggior parte delle organizzazioni, l'idea dell'hybrid cloud computing inizia con la modernizzazione o con lo spostamento delle applicazioni dall'ambiente on-premise al cloud, e ci sono alcuni modi per farlo:

• Lift-and-shift: uno dei metodi più comuni per avviare la modernizzazione, il lift-and-shift consiste nel trasferire completamente un'applicazione dall'ambiente on-premise al cloud. Ciò comporta la modifica dell'hardware sottostante per utilizzare al meglio le risorse di cloud computing e i servizi di infrastruttura scalabili e sicuri. Si tratta di un'opzione pratica quando non c'è tempo sufficiente per effettuare il refactoring o la riprogettazione.
• Refactoring: piuttosto che spostare l'intera applicazione monolitica nel cloud, che non solo richiede tempo, ma potrebbe anche essere inutile, è meglio identificare uno o due servizi (qualcosa che non ha esigenze di conformità o di miglioramento urgente delle prestazioni), eseguire il refactoring (ad esempio, aggiungendo codice di collegamento per esporre API REST, dato che le interfacce del servizio precedente potrebbero essere strettamente legate alla piattaforma specifica) e implementare nel cloud. Questo spostamento graduale offre la possibilità di indirizzare una piccola quantità di traffico verso nuove istanze sul cloud per opportunità di test e apprendimento e, infine, spostare tutte le istanze del servizio sul cloud.
• Riprogettazione: infine, esiste l'approccio più sofisticato per suddividere tutti i componenti del sistema in microservizi a singola responsabilità, modulari e con un percorso indipendente di produzione e containerizzazione. Ciò comporta una riscrittura completa ed è un processo costoso, ma massimizza anche i rendimenti.

Piano di controllo unificato

I team operativi aziendali gestiscono il proprio cloud landscape tramite un piano di controllo unificato che offre un'esperienza operativa coerente e coesa in tutti gli ambienti. Supporta le funzionalità principali di gestione dei cluster come pianificazione e orchestrazione dei workload, pipeline di integrazione e distribuzione continue (CI/CD), registrazione, telemetria e sicurezza federata.

L'obiettivo è astrarre le complessità sottostanti dei singoli fornitori di cloud service (CSP) e dei tempi di esecuzione dai team applicativi e fornire un'interfaccia comune ai team operativi per gestire i workload nell'azienda. 

Ecco alcuni dei vantaggi di un pannello di controllo unificato:

• Utilizzare strategie dinamiche di allocazione dei workload tra macchine virtuali, container o implementazioni serverless.
• Sfruttare la possibilità di integrare nuovi provider o sedi all'edge con uno sforzo minimo.
• Realizzare funzionalità PaaS, come Function-as-a-Service (FaaS), ad alta disponibilità e compatibili con diverse implementazioni cloud.
• Centralizzare la gestione della conformità.

API gateway e service mesh

Modelli di architettura come API gateway centralizzati e service mesh consentono una gestione trasparente delle funzionalità cloud come routing, comunicazione da servizio a servizio, sicurezza, limitazione della velocità e observability.

L'API gateway funge da porta d'ingresso unificata in tutte le regioni ed è responsabile della gestione delle funzioni di traffico "north-south", tra cui le seguenti:

• Autenticazione e autorizzazione degli utenti
• Throttling e rate limiting
• Gestione del traffico
• Gestione del ciclo di vita API
• Guardrail di sicurezza del cloud
• Edge analytics

Il service mesh, invece, gestisce il traffico "east-west" tra le dipendenze dei servizi:

• Comunicazione sicura tra servizi in un cluster
• Gestione del traffico con bilanciamento del carico, regole di routing, ritentativi, failover, disaster recovery e fault injection
• Telemetria con metriche, log e tracce per tutto il traffico all'interno di un cluster, inclusi l'ingresso e l'uscita del cluster
• Tracciabilità distribuita per monitorare il flusso di una richiesta attraverso i confini dei servizi
• Rilevamento automatizzato dei servizi

Istio, ad esempio, è un livello di service mesh open source che dirige la comunicazione tra i servizi in base a una configurazione predefinita fornita dagli amministratori del cloud. Funge da assistente al livello di orchestrazione di Kubernetes e funziona con container, invisibili a programmatori e amministratori.

Sicurezza

La complessità dell'architettura hybrid cloud richiede un approccio multilivello su diverse componenti per garantire sicurezza e protezione end-to-end. 

CSP come IBM Cloud, Amazon Web Services (AWS), Microsoft Azure e Google Cloud hanno la responsabilità, in base agli accordi sul livello di servizio (SLA), di autenticare e autorizzare qualsiasi chiamata a livello perimetrale, creando un firewall attorno alle applicazioni aziendali. Ciò include la protezione dal denial-of-service e il rispetto delle normative sulla privacy come il Regolamento generale sulla protezione dei dati (GDPR) e l'Health Insurance Portability and Accountability Act.

In un'infrastruttura on-premise, la sicurezza perimetrale può essere ottenuta utilizzando API gateway, che proteggono tutti gli endpoint. Qualsiasi chiamata da un servizio web o da un'applicazione mobile che risiede all'esterno di un data center deve essere convalidata e instradata tramite l'API gateway.

Un ambiente di cloud computing contiene un ulteriore livello di sicurezza sotto forma di politiche di controllo definite nella rete di servizi e nelle API esposte dalla piattaforma di orchestrazione. Queste politiche garantiscono che solo le chiamate sicure vengano inoltrate ai nodi Kubernetes e quindi ai microservizi.

Inoltre, il concetto di microsegmentazione, che divide l'ambiente in diversi segmenti logici di sicurezza per definire le politiche di controllo degli accessi per ogni servizio e workload, può essere utilizzato per creare e delimitare i livelli di sicurezza tra i servizi in esecuzione all'interno di un ambiente. Infine, le politiche di crittografia costituiscono un ulteriore livello di protezione dei dati.

Connettività di rete

In una singola regione cloud, le zone di disponibilità hanno una rete in fibra dedicata che collega tutti i nodi di una rete, consentendo alle aziende di creare architetture ad alta disponibilità in cui la banda è illimitata e le latenze sono basse. Tuttavia, la comunicazione tra regioni e provider di cloud multipli avviene tramite Internet pubblico, con conseguenti latenze maggiori e potenziali rischi di malfunzionamenti.

In un'architettura hybrid cloud, esistono tre modelli per lo scambio di dati tra i provider sottostanti:

• Indirizzi IP pubblici su Internet (alta latenza dovuta alla larghezza di banda condivisa)
• Servizi gestiti come VPN (latenza più prevedibile con maggiore sicurezza)
• Interconnessione dedicata tramite punti di presenza comuni (POP) (opzione costosa offerta dai CSP, ma con la minima latenza e massima sicurezza)

Poiché queste opzioni differiscono in termini di velocità di trasferimento, latenza, affidabilità, SLA, complessità e prezzi, è importante valutare i vincoli e i beneficio prima di progettare il livello di connettività di rete.

Preferenza per l'open source nelle piattaforme di sviluppo

Un hybrid cloud significa la capacità di spostare i workload da un ambiente all'altro e di disporre di una piattaforma di sviluppo di applicazioni che funziona su qualsiasi cloud. Per essere veramente cloud-native, non dovrebbe esserci una stretta dipendenza da alcuna tecnologia, piattaforma o CSP specifici e le aziende dovrebbero essere agili ai cambiamenti del mercato.

Un'architettura open source consente questo approccio unificato allo sviluppo in cui diventa possibile per gli sviluppatori gestire l'infrastruttura sottostante indipendentemente dalla tecnologia utilizzata per la sua implementazione. L'open source non è più alla periferia con un destinatario di nicchia che lo utilizza per ridurre i costi; ora è mainstream ed è al centro della scena grazie alle sue caratteristiche, alla qualità e allo sviluppo basato sulla comunità.

Anche in un'area delicata come la sicurezza, il software open source è ora percepito come un'ottima scelta, come riportato dal Red Hat Report on The State of Enterprise Open Source. Sicurezza, qualità e supporto per l'architettura cloud-native sono i motivi principali per cui le aziende mostrano una predilezione consapevole per l'open source.

Vedi l'articolo di JJ Asghar "Cultivating Careers, Communities and Companies with Open Source" per ulteriori informazioni.

Le soluzioni di cloud ibrido IBM Cloud offrono flessibilità e portabilità sia per le applicazioni che per i dati. Linux, Kubernetes e i contenitori supportano lo stack di cloud ibrido e si combinano con Red Hat OpenShift per creare una piattaforma comune che connette risorse on-premise e cloud.

Maggiori informazioni sulle soluzioni di hybrid cloud create con IBM Cloud.

Per iniziare a creare le tue soluzioni hybrid cloud, registrati per un IBMid e crea il tuo account IBM Cloud.