‍Serverless è un modello di Cloud Computing che nell’ultimo decennio ha rivoluzionato il modo di concepire le architetture.

Si parla di costruire sistemi distribuiti in grado di offrire alta scalabilità e alta disponibilità ad elevati standard di sicurezza. Il tutto grazie al fatto di delegare ad un cloud provider la gestione dei server. L’architettura viene costruita tramite i servizi gestiti del provider e questo permette di concentrarsi sul prodotto e di arrivare sul mercato molto in fretta. Inoltre, serverless consente di usufruire di modelli di prezzo basati sul consumo, che possono diventare molto interessanti in determinati contesti.

Per approfondire, leggi la nostra introduzione a serverless.

Il caso Prime Video

La premessa è buona, no? Tuttavia, come ogni novità che si rispetti, non possono mancare i detrattori.

Si litiga per Android vs iOS, per Python vs JavaScript, per Angular vs React, perciò perché non anche per serverless vs monoliti?

Ebbene, nel mese di maggio 2023 il dibattito si è acceso particolarmente. Il motivo è un articolo di David Hansson, creatore di Ruby on Rails, che sostiene che persino Amazon non riesce a dare un senso a serverless e microservizi.

Hansson fa riferimento ad un altro articolo, su Prime Video Tech, in cui Amazon annuncia di aver dismesso un’architettura serverless a favore di una monolitica, con un conseguente risparmio del 90% sui costi operativi. Apriti cielo!

Caspiterina, il principale promotore di serverless fa un passo indietro?

Per non ricadere nel trappolone dei titoli e delle chiacchiere da bar, analizziamo meglio il contesto per trarne beneficio.

Si parla un servizio di audio/video monitoring che serve ad individuare e correggere eventuali problematiche (corruzioni di blocchi, mancata sincronizzazione audio/video, ecc.) in real-time.

A monte c’è il MediaConversion Service, che scompone lo stream in frame (immagini) e buffer audio e salva il tutto in una soluzione di storage, S3. A questo punto intervengono i Defect Detector, di cui PrimeVideo definisce 18 tipologie. Ogni Defect Detector è un algoritmo dedicato ad analizzare una certa problematica ed è implementato attraverso Step Function e Lambda. I servizi AWS menzionati saranno illustrati in seguito.

È andato tutto bene finché gli stream da analizzare erano pochi. Tuttavia, nell’ottica dell’utilizzo su larga scala, sono stati evidenziati due problemi che riguardavano il Defect Detector.

I problemi della soluzione serverless

«The main scaling bottleneck in the architecture was the orchestration management that was implemented using AWS Step Functions. Our service performed multiple state transitions for every second of the stream, so we quickly reached account limits. Besides that, AWS Step Functions charges users per state transition.»

Il problema principale è dovuto al numero di transizioni delle Step Function, che comportano il raggiungimento di un limite di account e dei costi operativi molto alti. StepFunction è un servizio di AWS che permette di gestire macchine a stati. Uno stato consente di eseguire un task, come l’esecuzione di una Lambda function, che a sua volta è un servizio per eseguire del codice senza dover gestire server. Il passaggio da uno stato all’altro si chiama transizione.

La cosa interessante è che Step Function consente di definire due tipologie di macchine a stati: Standard ed Express. La Standard pone un limite sul numero di transizioni al secondo in tutto l’account e applica un costo per ogni transizione. Quella di tipo Express, invece, non ha limiti sul numero di transizioni e i costi non dipendono da esse.

Dunque, sembra chiaro che la soluzione di Amazon era basata sulle Step Function di tipo Standard e questo potrebbe essere un errore architetturale! Dato che in questo caso si parla di “diverse transizioni per ogni secondo dello stream”, non si può pensare che una soluzione di quel tipo sia scalabile su grandi numeri.

« The second cost problem we discovered was about the way we were passing video frames (images) around different components. To reduce computationally expensive video conversion jobs, we built a microservice that splits videos into frames and temporarily uploads images to an Amazon Simple Storage Service (AmazonS3) bucket. Defect detectors (where each of them also runs as a separate microservice) then download images and processed it concurrently using AWS Lambda. However, the high number of Tier-1 calls to the S3 bucket was expensive.»

Il secondo problema di costi è dovuto all’altissimo numero di chiamate a S3. Quest’ultimo è un servizio di object storage serverless: in pratica un archivio che ci consente di salvare e leggere qualunque tipo di file attraverso un’interfaccia REST (GET / PUT / DELETE), senza gestire file system o sistemi operativi. In genere S3 è considerato un servizio estremamente economico, ma ecco che, utilizzandolo nel modo sbagliato, si ottiene l’opposto.

La soluzione del monolite

Ad un certo punto qualcuno in casa Prime Video si sarà seduto al tavolo per analizzare meglio la situazione. Avrà constatato che l’accesso al singolo frame deve essere molto più economico ed efficiente, che tutto sommato l’applicazione potrebbe essere un unico processo long-running e che il numero di chiamate di rete potrebbe essere ridotto drasticamente. Ed ecco la soluzione: il Defect Detector può essere un monolite!

« In the initial design, we could scale several detectors horizontally […]. However, in our new approach the number of detectors only scale vertically because they all run within the same instance.Our team regularly adds more detectors to the service and we already exceeded the capacity of a single instance. To overcome this problem, we cloned the service multiple times, parametrizing each copy with a different subset of detectors. »

A differenza di quella precedente, la nuova soluzione consente di scalare solo in modo verticale, cioè aumentando le risorse, come CPU e RAM. Tuttavia, è possibile parametrizzare l’applicativo in modo da eseguirlo su più istanze EC2 (macchine virtuali),cosicché la soluzione complessiva può scalare anche in modo orizzontale, ovvero aumentando il numero di nodi.

‍

Serverless-first: un approccio vincente

Quanto illustrato fino adora sembrerebbe andare a sfavore di serverless, eppure la situazione è ben diversa!

Innanzitutto, è da evidenziare il fatto che Prime Video non ha sostituito un’infrastruttura serverless con un monolite. Ad essere coinvolto nella ri-architettura è solo un piccolo pezzo. Dall’alto Prime Video continua ad avere un’architettura serverless.Inoltre, il monolite integrato nella soluzione non è un “tuttofare”, come lo si intende spesso, ma si tratta di un componente altamente specializzato e disaccoppiato dal resto e inserito nel contesto di un’architettura distribuita.

L’adozione di serverless probabilmente non è stata nemmeno una cattiva scelta. Qualcuno potrebbe sgranare gli occhi a questo punto, ma tra i vantaggi che serverless promette sulla carta c’è un basso time-to-market. Questo viene confermato da Amazon affermando che la prima soluzione serverless ha consentito di costruire il servizio rapidamente:

«We designed our initial solution as a distributed system using serverless components […], which was a good choice for building the service quickly. »

È importante ricordarsi che le dimensioni delle aziende e dei team cambiano di continuo; cambiano le competenze dei professionisti; cambiano gli obiettivi di mercato: può esserci necessità di conquistare una nuova nicchia o di consolidare la propria posizione. Insomma, il mondo evolve e gli strumenti e le strategie che adottiamo devono essere in grado di accogliere il cambiamento.

Quello che si è verificato con Prime Video è il risultato di un approccio iterativo che ha permesso un’alta produttività e che si può riassumere nei seguenti step:+

1. adozione preliminare di serverless per andare sul mercato velocemente;
2. individuazione delle aree di miglioramento;
3. rifattorizzazione delle aree di miglioramento.

Alcune decisioni architetturali non sono sempre scontate. Ad esempio, nel suo articolo Amazon dice che una soluzione "computazionalmente vorace" è risultata essere meno costosa di una basata sul caching, il che è solitamente controintuitivo:

«Some decisions we’ve taken are not obvious but they resulted in significant improvements. For example, we replicated a computationally expensive media conversion process and placed it closer to the detectors. Whereas running media conversion once and caching its outcome might be considered to be a cheaper option, we found this not be a cost-effective approach. »

Trovare l’architettura giusta è questione di lavorare di fantasia, di sperimentare, di osservare e di reagire di conseguenza!

Takeaways

Dunque, cosa possiamo portarci a casa da questa analisi?

• Non si può giudicare la “sensatezza” di un modello da un caso isolato. Ogni progetto deve essere valutato singolarmente perché ci sono tantissimi fattori in gioco;
• Azienda, team, prodotti evolvono nel tempo e quindi anche le esigenze possono cambiare. Pertanto, in qualità di professionisti dell’IT, dobbiamo essere in grado di accogliere il cambiamento;
• Serverless consente di concentrarsi sul prodotto e di andare sul mercato velocemente con soluzioni sicure, scalabili e disponibili; perciò, può essere un ottimo mezzo esplorativo;
• Un approccio serverless-first consente di disegnare architetture disaccoppiate e flessibili, dove un componente può essere scalato e talvolta sostituito senza influenzare il resto.

‍

‍

‍