Sfide e opportunità nella realizzazione di una soluzione ibrida o multicloud con Google Cloud
Sempre più aziende scelgono soluzioni ibride e multicloud basate su Google Cloud. Alcune sono startup che ampliano la propria base clienti andando incontro ai loro utenti; altre sono grandi imprese che cercano lo strumento migliore per risolvere problemi, garantire alta disponibilità o diversificare i provider per ridurre i rischi. Prima di avviare la realizzazione di una soluzione ibrida/multicloud (di solito parte di un più ampio percorso di modernizzazione applicativa), è bene conoscere sfide e opportunità potenziali.
In questo articolo approfondiremo questi temi per chiarire chi sia un buon candidato per questa scelta, quali sfide è bene tenere presenti, quali soluzioni sono disponibili e in quali situazioni questa strada andrebbe evitata, almeno nel breve termine.
Definizioni
Partiamo da alcune definizioni:
- Public cloud – servizi e infrastrutture di calcolo on-demand gestiti da un provider terzo e condivisi tra più organizzazioni tramite Internet pubblico.
- Private cloud – infrastruttura dedicata a una singola organizzazione, ospitata nel data center dell'organizzazione stessa o presso una struttura di colocation di terze parti.
- Hybrid cloud – combina servizi on-premises, private cloud e public cloud di terze parti, orchestrandoli tra le diverse piattaforme.
- Multicloud – combina più servizi di cloud computing e storage in un'unica architettura eterogenea; indica anche la distribuzione di asset cloud, software, applicazioni, ecc. tra più ambienti di hosting cloud.
- Legacy application – sistema informativo eventualmente basato su tecnologie obsolete ma critico per l'operatività quotidiana; tipicamente applicazioni monolitiche a tre livelli, fragili e difficili da mantenere e aggiornare.
- Modern application – di norma un'applicazione composta da microservizi in un'architettura N-Tier. È affidabile quanto serve e può essere aggiornata più volte al giorno senza impatti sulla produzione (per una definizione più ampia, si veda la Twelve Factor app).
Casi d'uso
Quello che segue non è un elenco esaustivo:
- Fase intermedia di migrazione di un'infrastruttura IT con difficoltà al massimo moderate: ad esempio, un cliente con un numero significativo di server on-prem (di solito Linux o Windows) configura una connessione tramite VPN o interconnect e migra al cloud gruppi di VM (suddivisi in base ai confini dei workloads applicativi). I clienti dell'azienda vengono serviti da una soluzione hybrid cloud, con alcune applicazioni in esecuzione on-prem e altre nel cloud, finché tutti i workloads non sono migrati al public cloud (Hybrid cloud).
- Il cliente vuole modernizzare la propria soluzione ma ha applicazioni e database molto difficili da spostare nel cloud: ad esempio, un cliente con un mainframe o un Oracle DB (oggi non più così complesso) nel proprio ambiente private cloud che vuole portare l'applicazione su un'architettura moderna come Kubernetes (Hybrid cloud).
- Requisiti normativi: ad esempio, vincoli di regionalità del dato possono imporre che determinate informazioni non escano dai confini nazionali.
- Cloudbusting: in questo scenario, capacità aggiuntiva può essere automaticamente provisionata nel cloud e scalata quando l'ambiente on-prem è sovraccarico. Capita tipicamente nel retail durante eventi come Black Friday/Cyber Monday (Hybrid cloud).
- Alta disponibilità e disaster recovery (Hybrid cloud e multicloud).
- Usare il cloud giusto per il caso d'uso giusto: ad esempio, ambienti Kubernetes e di data analytics su Google Cloud Platform (GCP) e applicazioni basate su Microsoft su Azure.
- Evitare il vendor lock-in.
Stack tecnologico e capacità richieste
Vediamo ora lo stack tecnologico e le capacità da possedere o costruire, e le sfide che ciò può comportare per le aziende nelle varie fasi del loro percorso:
Compute:
- Conoscere l'ambiente private cloud – VM e le varie tecnologie a livello di hypervisor: per chi è già in private cloud, ovviamente non è un problema. Per le aziende digital native, che non hanno mai dovuto confrontarsi con lo stack tecnologico né con la complessità organizzativa di implementare una soluzione cloud in un ambiente private cloud, può rappresentare una sfida significativa.
- Conoscere l'ambiente public cloud: non è un problema per le aziende digital native, ma può sollevare questioni rilevanti di sicurezza e di equilibri interni per le aziende che oggi operano on-premises. Dovranno imparare un nuovo stack con nuove modalità di gestione di VM, autoscaling, ecc.
Database e storage:
- Per chi è oggi in private cloud, la sfida è imparare a conoscere e selezionare un database cloud-native adatto. Le opzioni più semplici prevedono il passaggio a SQL Server/PostgreSQL/MySQL gestiti, ma, in funzione degli obiettivi di business e tecnici, alcune aziende potrebbero voler o dover adottare tecnologie come Spanner, BigTable e BigQuery. Un percorso che può rivelarsi impegnativo.
- Gestire due stack tecnologici in parallelo non è semplice: un'azienda con un'applicazione on-prem basata su Oracle che vuole migrare a PostgreSQL ha due opzioni, in base alla complessità e alle funzionalità in uso. La prima è un lift and shift verso un'opzione bare-metal, seguito dalla modernizzazione. L'altra è lasciare il sistema dov'è, modernizzarlo nel private cloud e poi migrarlo al cloud. In entrambi i casi, l'azienda dovrà gestire due tipologie di DB in parallelo fino al completamento della modernizzazione e alla disattivazione di uno dei due.
Networking:
- Esistono differenze significative tra il networking nei public e nei private cloud, e persino tra i diversi cloud. La Global VPC di Google Cloud, ad esempio, è un grande vantaggio per semplificare il networking. Molte aziende abituate al private cloud devono imparare come funzionano questi meccanismi e fanno fatica a decidere consapevolmente di non replicare nel public cloud le modalità operative del private cloud.
- Configurare VPN, partner-interconnect e interconnect può essere semplice in alcuni scenari, ma può richiedere settimane o mesi a seconda della collocazione del private cloud del cliente.
Sicurezza:
- Implementare misure di sicurezza unificate e production-ready in ambienti ibridi e multicloud può diventare complicato. Ogni cloud vendor adotta misure di sicurezza diverse, implementate in modi diversi. Il modo in cui si rilascia il software e lo si testa per individuare vulnerabilità durante il processo di deployment può diventare un progetto a sé stante.
- Anche implementare sistemi di monitoraggio della sicurezza su più cloud è una sfida.
CI/CD:
- Costruire in modo affidabile una pipeline di Continuous Integration e Continuous Deployment (CI/CD) per compilare, testare, mettere in sicurezza e distribuire sia infrastruttura (IAC – come Terraform o Pulumi) sia applicazioni su più ambienti è una sfida importante. Richiede team di Engineering altamente sofisticati e capaci, oltre a un tooling adeguato.
Modernizzazione:
- Decidere cosa modernizzare e come, sia lato applicazioni sia lato DB, non è banale e richiede fasi importanti di valutazione e pianificazione. Possono volerci mesi o persino anni, oltre a un significativo change management organizzativo, perché i clienti private-cloud imparino a conoscere K8s e il modo migliore di lavorarci.
Autenticazione:
- La sfida è gestire SSO Federation, AD Federation, ecc. su più piattaforme attraverso un'unica fonte di verità.
Team:
- È difficile trovare engineer/architect competenti su più piattaforme: occorre quindi investire nella formazione dei propri team.
- L'alternativa è restare aggiornati su più ambienti in un mondo cloud in rapida evoluzione, costruire team distinti con competenze diverse e definire un processo di business che permetta loro di collaborare in modo efficiente.
Costi:
- Come accade nella configurazione di un ambiente multi-region ad alta disponibilità (HA), realizzare una soluzione multicloud o hybrid cloud può costare fino a dieci volte di più. Non si tratta solo di configurare un'altra VM o un altro database e pagarli in più: le operazioni Day 2 — orchestrazione, replica, costi di network egress e supporto a persone e meccanismi che reggono questi sistemi — fanno lievitare il conto.
- Le aziende devono ragionare in ottica FinOps e costruire una cultura in cui i team gestiscano i propri costi cloud, ognuno si assuma la responsabilità del proprio utilizzo, un gruppo centrale di best practice fornisca supporto e si arrivi a una visione a 360° del costo hybrid/multicloud.
Definire una soluzione
A questo punto starà probabilmente pensando che multicloud e hybrid cloud siano davvero complessi: poiché però è la direzione verso cui si sta muovendo il settore, è necessario trovare una soluzione.
È fondamentale comprendere che progetti di questo tipo richiedono tempo, e procedere poi secondo questa metodologia:
- Valuti la cultura aziendale, le pratiche DevOps, lo stack tecnologico, ecc.
- Pianifichi sulla base degli obiettivi di business e tecnologici dell'azienda e dei risultati della valutazione. Tenga presente che le curve di apprendimento sono significative, sia all'interno dell'azienda sia per i clienti, di fronte ai cambiamenti del sistema. Serve tempo: occorre dare alle persone la possibilità di adattarsi alle nuove metodologie di lavoro e alla nuova tecnologia.
- Migrare/effettuare il refactoring: parta in modo graduale e su scala ridotta, lasciando alle persone la possibilità di sbagliare in fretta, imparare dagli errori e migliorare. Iniziando lentamente, la velocità aumenterà in modo incrementale. Non provi a ottimizzare mentre cambia piattaforma, codebase, ecc.
- Ottimizzare una volta apportata la modifica iniziale e ottenuto un nuovo sistema funzionante. Lavori sull'ottimizzazione sia in termini di prestazioni sia di costi.
Costruire lo stack tecnologico ibrido ottimale
Nessuna soluzione tecnologica sul mercato risolve tutto. È necessario valutare il proprio stack e combinare diverse soluzioni per realizzare uno stack tecnologico ibrido completo.
Application layer:
GCP Anthos è un'ottima soluzione che copre buona parte di ciò che serve per gestire il livello codice/applicazione. Comprende i seguenti livelli, che permettono di orchestrare ed eseguire cluster Kubernetes e persino VM (in private preview) su GCP, AWS, Azure, private cloud e bare metal.
Livelli applicativi di Google Cloud Anthos
Gli Anthos clusters, il livello Kubernetes gestito alla base dello stack, rendono le operazioni Day 2 molto più semplici rispetto alla gestione di cluster Kubernetes open source autogestiti.
Anthos Ingress è un controller Ingress multi-cluster cloud-hosted per cluster GKE.
Anthos Service Mesh è una suite di strumenti che aiuta a monitorare e gestire una service mesh affidabile on-premises o su Google Cloud.
Anthos Config Management è un servizio di gestione di configurazione e policy che combina tre componenti: Policy Controller, Config Sync e Config Controller. Insieme, permettono ad Anthos Config Management di proteggere e configurare in modo continuo le risorse Google Cloud e Kubernetes.
Anthos fleets (in precedenza noti come environs) sono un concetto di Google Cloud per organizzare logicamente cluster e altre risorse, consentendo di utilizzare e gestire funzionalità multi-cluster e di applicare policy coerenti tra i sistemi.
Limitazioni: è importante notare che il servizio è limitato al controllo e al monitoraggio delle sole parti della soluzione che vengono eseguite all'interno dell'ambiente Anthos.
Database e storage layer:
- Se gestisce i livelli di storage e DB al di fuori del cluster, può sfruttare servizi DB gestiti come CloudSQL o RDS.
- Se gestisce il DB all'interno del cluster Kubernetes (ad esempio MySQL o MongoDB), aggiunge un overhead operativo significativo rispetto all'utilizzo delle versioni gestite dal cloud provider.
Sicurezza + monitoraggio:
- SIEM + monitoraggio: cerchi strumenti che offrano una soluzione multicloud/hybrid cloud, come Splunk, Datadog o PagerDuty.
- Security & Secrets Management: tra gli esempi, HashiCorp Vault e AWS Secrets Manager.
CI/CD:
- Soluzioni come Gitlab e Jenkins funzionano in ambienti diversi e permettono di costruire e distribuire sia container sia VM.
Se non ha bisogno di costruire e distribuire VM, dia un'occhiata a spinnaker.
Provisioning dell'infrastruttura:
- Tra le opzioni: HashiCorp Terraform, Red Hat Ansible e Pulumi.
In sintesi:
- Realizzare una soluzione hybrid/multicloud è molto difficile e molto costoso, sia dal punto di vista delle persone e dei processi sia da quello tecnologico.
- Tecnologie come GCP Anthos supportano una soluzione multicloud, ma nessuna singola tecnologia offre una soluzione end-to-end. È un aspetto da considerare nella progettazione dell'architettura.
- Il percorso sarà più semplice per le aziende che già eseguono Kubernetes in produzione su larga scala, sia on-prem sia nel cloud.
- Sarà invece più complesso per:
Aziende che eseguono applicazioni monolitiche legacy on-prem. La realizzazione di una soluzione ibrida e la trasformazione richiesta a livello di processi di business, abilitazione delle persone e cambiamento dello stack tecnologico possono richiedere da due a dieci anni, in funzione della complessità e della portata del cambiamento.
È in questa direzione che si muove il mercato, e le aziende che intraprendono questo percorso ottengono un ROI significativo. Tuttavia, nell'imbarcarsi in un viaggio del genere, è bene calibrare le aspettative comprendendo l'entità della sfida.
Startup con team ridotti: Kubernetes è interessante e affascinante, e la sua startup vorrebbe servire ogni cliente in ogni ambiente, ma le risorse sono limitate ed è necessario disporre di un prodotto funzionante con il minor overhead operativo e di costo possibile. Date le sfide intrinseche, si concentri prima su un prodotto valido (mantenendo la portabilità del workflow come bussola) e su una base clienti su un singolo cloud, sfruttando il maggior numero possibile di servizi completamente gestiti. Quando il team sarà sufficientemente ampio e la soluzione sufficientemente stabile, inizi a esplorare come fare refactoring e gestire una soluzione multicloud.
Se desidera approfondire l'argomento e vedere anche una demo di come Anthos funziona in un ambiente multicloud, si iscriva al nostro evento il 22 febbraio 2022, alle ore 13:00 GMT.
Non esiti a contattarci per qualsiasi domanda o per discutere il proprio percorso verso un'applicazione moderna in un ambiente hybrid o multicloud.