HAVE A GEEK DAY

Il Blog di ELEVA

Qualche mese fa, è uscito un articolo che ha fatto molto discutere la community Dev. Amazon Prime Video avrebbe deciso di tornare ad usare un’architettura monolitica per il suo servizio di audio/video monitoring, che serve a rilevare e correggere eventuali difetti nella trasmissione dei contenuti in streaming. Quando il numero di stream da gestire ha iniziato a scalare rapidamente, è stato necessario intervenire sull’architettura, per risolvere due problemi principali: 

  • Il primo problema era legato al numero elevato di transizioni di stato che le Step Functions dovevano gestire per ogni secondo di stream, il che portava al raggiungimento dei limiti di account e a costi operativi molto alti. 
  • Il secondo problema era dovuto alla latenza introdotta dalla comunicazione tra le Lambda Functions e i servizi AWS, che influiva negativamente sulla qualità dell’analisi dei difetti. 

Si è molto discusso di un ritorno al monolite e del “fallimento” delle architetture a microservizi basate su tecnologie serverless. In realtà la questione è stata posta in termini impropri e ripresa dai media in modo ancor più approssimativo. 

Passaggio a monolite? No, un refactoring 

Inizialmente la funzionalità di video monitoring era stata progettata come microservizio basato su funzioni serverless (Step Functions e Lambda), mettendo al centro la velocità di esecuzione, di progettazione e di implementazione. Una scelta favorita dal più grande vantaggio del paradigma serverless: non doversi preoccupare dell’infrastruttura e della sua gestione.  

Quando il servizio ha iniziato a scalare, con le problematiche appena evidenziate, la priorità è diventata ridurre i costi. 

Ci siamo resi conto che l’approccio distribuito non portava molti vantaggi nel nostro caso d’uso specifico, quindi abbiamo raggruppato tutti i componenti in un unico processo.” spiegano nell’articolo di Prime.   

Cosa è successo in concreto? Nel suo blog su Medium, Adrian Cockroft (ex VP di AWS), spiega che tutto il dibattito è sterile e altro non è che una scelta semantica.  

Come vediamo dalle immagini che seguono, è stata riutilizzata la maggior parte del codice di lavoro combinandolo in quello che di fatto è un unico microservizio a esecuzione prolungata, scalato orizzontalmente utilizzando ECS e richiamato tramite una funzione lambda. 

Architettura iniziale:

Architettura finale:

Il problema è che hanno chiamato questo refactoring una transizione da microservizio a monolite, quando è chiaramente una fase di refactoring di microservizi, ed è esattamente ciò che consiglio alle persone di fare nei miei discorsi su Serverless First.” 

In casi specifici come questo, quindi, la decisione migliore è inserire un prototipo di servizio funzionante, più rapido da costruire, piuttosto che svilupparlo da zero come microservizio. Non si tratta di un ritorno al monolite, ma di integrare il servizio come container che scala in automatico, in esecuzione continua, in una più ampia architettura a microservizi basata su tecnologie serverless. 

Conclusioni 

Il caso di Prime Video ci porta a una riflessione. Non ha senso ridurre il dibattito a tifoserie (team-monolite o team-microservizi?). In questo frangente specifico, c’era la necessità di gestire grandi volumi di traffico e ridurre i costi. Proprio perché l’architettura è stata pensata a micro-servizi, è stato possibile arrivare velocemente a un punto e al fatto che fosse necessario refattorizzare. 

Un’architettura a microservizi basata su tecnologie serverless offre molti vantaggi in termini di scalabilità, flessibilità, modularità e velocità di sviluppo. Richiede però una maggiore complessità nella progettazione e nell’integrazione dei servizi. Un’architettura monolitica è più semplice da implementare e da gestire, ma presenta anche dei limiti in termini di evoluzione, personalizzazione e affidabilità. 

In questo caso, inserendo questa componente “monolitica”, Amazon Prime ha ridotto per quello specifico servizio il numero di chiamate alle API, ottimizzato l’utilizzo delle risorse e migliorato le prestazioni. Inoltre, ha ottenuto un risparmio del 90% sui costi operativi e una maggiore facilità di manutenzione e debugging del codice. 

Il team non ha fatto altro che seguire le best practice raccomandate proprio dall’approccio Serverless First. Per ottimizzare le performance delle applicazioni serverless la scelta migliore può essere proprio creare e integrare servizi che utilizzano container quando si rincontrano: 

  • problemi di latenza 
  • processi di calcolo a esecuzione prolungata 
  • traffico elevato prevedibile. 

Il merito delle architetture a microservizi resta proprio quello di riuscire a scomporre, individuare e risolvere questo tipo di problemi. 



Vuoi saperne di più sui nostri servizi?

Contattaci ora!

ELEVA Srl
Via Aldo Moro 5
27028, San Martino Siccomario (PV) - ITALIA
Email: info@eleva.it
Website: www.eleva.it

Privacy Policy
Cookie Policy

Codice SDI per la fatturazione elettronica: SZLUBAI