Come disse una volta un saggio architetto del cloud: “Ho 99 problemi e il cloud non è uno di questi”. Dopotutto il cloud ha reso molto più semplice l’esecuzione di applicazioni e servizi su vasta scala. Eppure, il cloud computing porta con sé alcuni problemi. Per prima cosa, nei giorni in cui il cloud era on-prem, un codice fuori controllo causava semplicemente un degrado delle prestazioni o un’interruzione. Ora AWS vi svuoterà le tasche, vi capovolgerà e vi scuoterà finché non sarà sparito il vostro ultimo centesimo: il conto per il vostro bug.

Nel frattempo, è fin troppo facile usare Amazon Kinesis o Azure Cosmos DB o Google Cloud Bigtable, ma ognuno di questi è una sorta di Hotel California dove potete fare il check-out in qualsiasi momento ma da non potete mai andarvene. Mentre il prezzo dei servizi di infrastruttura grezza è diminuito nel tempo, i prezzi dei fornitori di servizi cloud in generale sono stati più stabili (e incomprensibili). Ho così voluto chiedere alle persone responsabili della gestione di alcuni dei servizi basati su cloud più critici di Internet quali problemi hanno dovuto affrontare e come poterli risolverli o mitigarli.

Gestione dei costi

Ricordate quando la gente pensava che AWS fosse economico? “Quando si dispone effettivamente di hardware in sede, lo si utilizza. È mio. Ho pagato per questo. Pago l’elettricità, ma poi la uso quanto voglio” mi ha detto Marc Sanfaçon, vicepresidente senior della tecnologia e co-fondatore di Coveo.

“Ma quando si ha una compagnia come la nostra con più di 200 sviluppatori”, ha continuato Sanfaçon, “ci sono alcune policy aziendali per le quali gli sviluppatori devono chiedere l’autorizzazione per acquistare un nuovo telefono, o una scrivania, o una sedia. Ma al tempo stesso possono andare nella nostra console AWS e avviare una nuova macchina che costerà all’azienda 25 dollari l’ora e la lasciano in funzione per un mese. Alla fine del mese sono tanti soldi”.

Ora Coveo disattiva i cluster o le istanze quando nessuno sta lavorando, ad esempio alle 20:00 fino alle 6 del mattino e nei fine settimana. Tuttavia, bisogna anche tenere conto di quello sviluppatore che si sveglia con l’ispirazione giusta alle 2 del mattino e inizia a lavorare. Coveo ha già qualcuno che lavora per il 75% della giornata sull’ottimizzazione dei costi del cloud e Sanfaçon ha citato Cloudability e CloudHealth come esempi di strumenti utili ed efficaci per controllare le spese per il cloud.

Mantenere l’indipendenza dai servizi specifici del cloud

Sanfaçon ha condiviso un altro problema in ambito cloud che la sua azienda ha dovuto affrontare: mantenere i servizi di Coveo funzionanti quando i servizi di Amazon falliscono.

“Poco prima del Black Friday, AWS ha avuto due gravi incidenti con Kinesis, che è uno dei servizi che stiamo utilizzando, ma anche con uno dei servizi che è la spina dorsale di molti altri servizi all’interno di AWS”, ha osservato Sanfaçon. Questa interruzione non ha influito sui servizi principali di Coveo, ma ha influito sulla loro capacità di integrare nuove organizzazioni e registrare alcuni tipi di eventi. Coveo è una società di ricerca e le settimane vicine al Black Friday sono il “momento giusto” per molti clienti di e-commerce.

Sanfaçon ha preso in considerazione l’idea di hostare il servizio di streaming di Coveo, ma per quanto preoccupante fosse l’interruzione di Amazon Kinesis, si è chiesto se Coveo potesse eseguire in modo conveniente un servizio di messaggistica migliore con tempi di attività maggiori rispetto ad AWS. Anche se Coveo fosse stato in grado di farlo, sarebbe stato un uso efficace delle risorse?

sase

Un’altra considerazione: sebbene ci siano molti vantaggi nel consumare solo un servizio da un provider di servizi cloud, ciò significa che non si può semplicemente passare a un altro provider come Google Cloud o Microsoft Azure. Una possibile soluzione è utilizzare Kafka gestito da AWS. Quindi Coveo potrebbe semplicemente passare a Kafka gestito da Azure o Kafka gestito da Confluent su Google Cloud se ci fosse un problema.

C’è davvero un costo per l’indipendenza dal cloud, poiché l’esecuzione di Amazon Kinesis è più economica rispetto all’esecuzione di Kafka gestito da Amazon. Tuttavia, ci sono anche vantaggi, soprattutto quando qualcosa va giù prima del Black Friday, durante una pandemia, e voi siete la spina dorsale di ricerca per molti siti di e-commerce.

Saravana Krishnamurthy, il vice presidente della gestione dei prodotti SkySQL presso MariaDB, ha ugualmente sconsigliato di fare affidamento su qualcosa di specifico per il cloud. “Se avete un’API REST incorporata nella vostra soluzione o in qualsiasi altra API, assicuratevi che tutte le comunicazioni avvengano attraverso quelle API che sono indipendenti dal cloud”, ha affermato Krishnamurthy. “In questo modo, quando passate da Amazon a Google o Azure, avete effettivamente un modo migliore per spostare le vostre applicazioni e i vostri dati.”

Differenze tra provider di servizi cloud per il multicloud

Jim Walker, vicepresidente del marketing di prodotto presso Cockroach Labs, ha fatto il punto sulle sfide poste dai fornitori cloud che fanno le cose in modo leggermente diverso. Cockroach Labs ha sviluppato il proprio servizio di database CockroachCloud sia su AWS che su Google Cloud e ha imparato molto su queste differenze.

“Sono fondamentalmente diversi e non è facile per noi ottenere l’esperienza ‘giusta’ con ciascuno di essi”, ha detto Walker. “I container e Kubernetes ci hanno sicuramente aiutato a semplificare parte della complessità, ma dovevamo comunque pensare alle due piattaforme in modo molto diverso.”

“Ad esempio, il servizio gestito Kubernetes è molto diverso in ogni cloud e le complessità di rete sono totalmente diverse. Il modo in cui lavoriamo con i bilanciatori del carico in ognuno di essi non è lo stesso. Inoltre, uno ci consente di personalizzare e impostare IOPS e l’altro no. Quando forniamo una funzionalità come il peering VPC (Virtual Private Cloud) per i nostri clienti, anche l’approccio all’interno di ciascuno (AWS PrivateLink vs. vanilla) è completamente diverso. I fornitori di servizi cloud hanno un’importanza enorme, ma dobbiamo “faticare” con ciascuno di essi”.

Sicurezza cloud

Krishnamurthy ha anche sottolineato l’importanza della sicurezza della rete nel cloud. “Non vogliamo che il traffico di un cliente interferisca con un altro cliente”, ha affermato. “Pertanto, quando un cliente richiede un cloud privato virtuale, in cui desidera isolare il traffico dalla rete pubblica e da altri clienti, forniamo il VPC come un modo per isolarli”.

Tuttavia, questo può essere complicato quando qualcuno si è standardizzato, ad esempio, su Active Directory e si autentica tra vari VPC. Ciò può richiedere alcune difficili configurazioni e policy di mappatura ai ruoli tra i sistemi.

Complessità, configurazione e conformità

Configurare anche pochi server e mantenerli coerenti è una sfida. Devops ha promesso di semplificare le nostre operazioni e i problemi di distribuzione, ma le configurazioni rimangono un problema. Inoltre, è difficile vedere “chi” ha modificato la configurazione quando questa esiste in una serie di script e si applica potenzialmente a centinaia di server. Per alcuni settori, in particolare i servizi finanziari, questa mancanza di una traccia di controllo è un vero problema ai fini della conformità.

Una nuova serie di tecnologie e metodologie chiamate GitOps fornisce una soluzione. Come suggerisce il nome, GitOps combina lo strumento di controllo delle versioni Git con devops. Tuttavia, GitOps è molto di più; Git mantiene infatti anche un audit trail. Allora chi ha disattivato la sicurezza? Puoi rispondere a questa domanda guardando il repo.

Tirando le somme, potete tenere a bada i costi con FinOps, combattere la complessità con GitOps, impedire al vostro software di soccombere a un’interruzione di un singolo fornitore grazie al multicloud e mantenere la sicurezza e la privacy del vostro sistema isolando i servizi nel vostro VPC. In questo mondo “nuvoloso” abbiamo sicuramente più server e più problemi, ma anche strumenti migliori per uscirne vincitori.