Se si trascorre abbastanza tempo nell'IT, si iniziano a riconoscere i cicli della conversazione. Viene proposta una nuova cosa, tutti si entusiasmano; qualcuno fa notare che la nuova cosa non è ancora in grado di fare tutto, tutti si disilludono; le persone capiscono a cosa serve la nuova cosa - e a cosa non serve - e la discussione si sposta sulla nuova cosa successiva.
In questo momento nel barile abbiamo architetture serverless.
L'istigatore dell'attuale tornata di critiche a serverless è David Heinemeier Hansson, meglio conosciuto come DHH, della fama di Basecamp. DHH ha pubblicato una polemica intitolata Nemmeno Amazon riesce a dare un senso ai serverless o ai microserviziin cui ha citato un caso di studio del team di Amazon Prime Video sulla propria infrastruttura.
Il rapporto entra nel dettaglio delle caratteristiche interne del servizio Prime Video. DHH cita un passaggio sui limiti di scala, ma questa nota è stata la più informativa per me:
Le due operazioni più onerose in termini di costi erano il flusso di lavoro di orchestrazione e il passaggio dei dati tra i componenti distribuiti. Per risolvere questo problema, abbiamo spostato tutti i componenti in un unico processo per mantenere il trasferimento dei dati all'interno della memoria del processo, semplificando anche la logica di orchestrazione.
DHH
Il punto è questo: come ha sottolineato Adrian Cockroft (famoso per Netflix), nulla nel rapporto originale metteva in discussione il modello serverless. Tutto ciò che il team di Amazon ha detto è che il servizio, e la sua comprensione, è maturato e le sue esigenze sono cambiate:
Quando si sta esplorando come costruire qualcosa, costruire un prototipo in pochi giorni o settimane è un buon approccio. Poi hanno cercato di scalarlo per far fronte a un traffico elevato e hanno scoperto che alcune transizioni di stato nelle loro funzioni a gradini erano troppo frequenti e che c'erano alcune chiamate eccessivamente chiacchierate tra le funzioni lambda di AWS e S3. Sono riusciti a riutilizzare la maggior parte del loro codice di lavoro combinandolo in un unico microservizio di lunga durata [...]
Adrian Cockroft
Quando si inizia a costruire un nuovo servizio, per definizione non si conoscono le sue caratteristiche interne di prestazione o i modelli di carico a cui gli utenti lo sottoporranno. Pertanto, è una buona idea scegliere la cautela e una maggiore flessibilità. Dopotutto, questa era la promessa iniziale di cloud, che è stata decisamente mantenuta. Mentre il boom originario delle dot-com richiedeva alle startup promettenti di spendere milioni di dollari di capitale d'investimento per l'acquisto di hardware per server, licenze software, spazi colo e così via prima di poter iniziare a sviluppare realmente il servizio proposto, nell'era di cloud è possibile iniziare con una carta di credito. È anche molto più veloce: la creazione dell'infrastruttura, che prima richiedeva settimane o mesi di lavoro di esperti 24 ore su 24, ora avviene automaticamente in pochi minuti.
Cloud è molto più flessibile che possedere il proprio hardware, ma il suo modello di prezzo tradizionale è ancora rigido, richiede agli utenti di stimare le proprie esigenze in anticipo e la scalabilità potrebbe non essere così reattiva o granulare come si vorrebbe. Se il vostro provider offre solo un dimensionamento a maglietta, e vi trovate tra una piccola e una media, ma potreste aver bisogno di una grande se le cose vanno bene, potreste trovarvi di fronte a decisioni difficili da prendere. Serverless invece promette di far scalare il vostro servizio da zero a qualsiasi dimensione sia necessaria, e vi permette di pagare man mano.
Qui entrano in gioco le avvertenze: molte cose che dicono di essere serverless... non lo sono. Il vero serverless scala a zero: se nessuno usa il vostro servizio, non pagherete nulla. Questa è una garanzia importante quando si lancia un nuovo servizio: se gli utenti non sono ancora sul vostro servizio, non avete entrate, quindi sapere che i vostri costi sarebbero pari a zero anche in questo scenario vi dà la tranquillità di non dover pagare per una tonnellata di capacità che non state utilizzando.
L'altra faccia della medaglia è che la natura puramente basata sul consumo dei prezzi serverless scala all'infinito, e quindi c'è un punto di passaggio in cui ha più senso impegnarsi per una quantità definita di capacità piuttosto che continuare con il modello pay-as-you-go. Questa flessibilità finanziaria ha anche un costo in termini di complessità architettonica, e anche questo fattore influisce su quale sarà il punto di passaggio per ogni architettura di servizio.
Al team di Amazon Prime Video è successo proprio questo: hanno raggiunto il punto di passaggio e hanno scoperto che non avevano più bisogno di pagare il costo di questa estrema flessibilità. Essendo all'interno di Amazon, presumibilmente non c'è stato un costo diretto come per un cliente esterno di AWS, anche se probabilmente è lecito pensare che Amazon tenga conto di questa capacità in modo piuttosto granulare. Tuttavia, ciò che il team descrive nel suo rapporto è il costo per loro in termini di complessità architettonica e prestazioni del servizio. Avendo dedicato del tempo a comprendere le esigenze specifiche del loro servizio, non hanno più bisogno di pagare quel pedaggio: hanno semplificato la loro architettura e ottenuto prestazioni migliori cablando i percorsi specifici di cui avevano bisogno.
L'aspetto fondamentale, tuttavia, è che stiamo assistendo alla fase finale del processo. Se gli architetti di Amazon Prime Video avessero dovuto elaborare tutto questo senza la flessibilità di un'architettura distribuita, non sarebbero mai arrivati a questo punto. Invece, sono riusciti a far decollare rapidamente il loro servizio, a perfezionarlo rapidamente in risposta all'evoluzione dei modelli di utilizzo e, ora che il ritmo dei cambiamenti si è raffreddato fino a raggiungere un livello gestibile, hanno rivisto i loro requisiti architettonici alla luce dell'esperienza duramente acquisita.
Questo è il modo in cui le cose dovrebbero essere fatte. Questa storia non è un fallimento di serverless: è proprio a questo che serve!
SnapLogic permette di fare qualcosa di molto simile, con un tocco in più: è possibile collegare qualsiasi cosa a tutto, e tutti possono essere coinvolti. Gli esperti del settore possono sfruttare la nostra interfaccia grafica low-code/no-code per progettare integrazioni di dati e applicazioni senza bisogno di conoscenze di programmazione. Se l'integrazione decolla e diventa popolare, può essere rifinita da esperti per eliminare i colli di bottiglia delle prestazioni, evitare duplicazioni e garantire la conformità. Si tratta comunque di un'asticella molto alta da superare nelle fasi iniziali di un progetto, quando l'obiettivo è quello di consentire alle persone di iniziare a costruire le funzionalità di cui hanno bisogno.
A questo proposito, SnapLogic può anche integrarsi con tutti i tipi di servizi serverless e unirli in un insieme unificato. Il nostro approccio commerciale e tecnologico consiste nel lavorare con le architetture dei nostri utenti, senza imporre o limitare le loro scelte. Per questo motivo lavoriamo sia con infrastrutture on-premises che con cloud , sia autogestite che fornite come servizio, o addirittura completamente serverless per la massima flessibilità.
Il vantaggio per l'azienda delle architetture serverless e dello sviluppo low-code/no-code è la facilità di far decollare un nuovo progetto. Se si punta troppo sulla purezza architettonica nelle fasi iniziali, non si riuscirà mai a concludere nulla. Viceversa, una volta che si ha una buona idea di ciò che si deve fare, si deve assolutamente raddoppiare il lavoro e incorporare ciò che si è imparato. Sembra che Amazon si stia comportando bene su questa base. Dovremmo tutti imparare dal loro esempio.
