Microservizi contro applicazioni monolitiche: Prime Video sceglie le seconde

• Amazon

Un’applicazione monolitica (monolith) è un’entità software costruita come un’unica unità, in cui tutte le funzionalità sono integrate all’interno di un unico processo o eseguibile. L’applicazione è costituita da un unico grande blocco di codice che gestisce tutte le funzioni: di base, quindi, risulta complesso (e costoso) separare e scalare le diverse parti dell’applicazione.

Per ovviare a questi problemi, gli sviluppatori tendono ad abbracciare architetture pensate per applicazioni modulari e distribuite, come i microservizi che consentono di separare le diverse funzionalità dell’applicazione in moduli autonomi, a loro volta scalabili e aggiornabili in modo indipendente.

I microservizi consentono di scalare solo le parti dell’applicazione che necessitano di maggiori risorse, invece di dover scalare l’intera applicazione monolitica, sono suddivisibili in moduli autonomi semplificando la gestione e la manutenzione dell’applicazione, permettono di creare e distribuire nuove funzionalità più rapidamente, aiutano a isolare eventuali errori e limitarne l’impatto sull’intero sistema.

Il team di Prime Video, il servizio di streaming video di Amazon, ha spiegato di aver riprogettato completamente la soluzione software che si occupa di verificare eventuali problemi durante la riproduzione dei flussi multimediali passando dai microservizi a un approccio monolitico. Una scelta che può apparire inusuale ma Marcin Kolny, ingegnere informatico senior di Prime Video, ne spiega nel dettaglio le motivazioni.

Kolny racconta che Prime Video utilizza un sistema che permette l’identificazione automatica dei problemi di qualità nella riproduzione audio-video (danneggiamento del flusso, problemi di sincronizzazione del video con la traccia sonora e così via). La soluzione adottata in precedenza su Prime Video poggiava su microservizi responsabili dell’esecuzione delle varie fasi del processo di analisi dello streaming; tali microservizi erano implementati in cima allo stack dell’infrastruttura serverless usata da Amazon.

I microservizi suddividevano i flussi audio/video in frame video o buffer audio decrittografati mentre appositi algoritmi di machine learning elaboravano il materiale raccolto rilevando eventuali difetti in fase di riproduzione.

Per la parte principale della procedura veniva fatto ricorso ad AWS Step Functions ovvero al servizio di orchestrazione serverless dei workflow offerto da Amazon stessa (con le Step Functions, gli sviluppatori possono creare facilmente workflow a passi, ovvero specificare una serie di passaggi da eseguire per completare un’attività o un processo di business complesso).

In questo caso specifico, le Step Functions venivano utilizzate per coordinare l’esecuzione di diverse funzioni AWS Lambda, servizio di elaborazione serverless che consente di eseguire codice senza dover configurare, gestire o scalare un’infrastruttura di server.

Tutti i dati audio/video, inclusi gli elementi utilizzati per le elaborazioni intermedie, venivano archiviati all’interno di bucket AWS S3.

Dopo aver utilizzato la soluzione per un po’, i tecnici di Prime Video hanno iniziato a riscontrare problemi poiché l’architettura ha dimostrato di supportare solo circa il 5% del carico previsto. Inoltre, è stato registrato un elevato costo operativo dovuto all’elevato volume di attività di lettura/scrittura nel bucket S3 e dal cospicuo numero di transazioni predisposte dalle Step Functions.

Il team di Kolny ha quindi deciso di spostare il carico di lavoro sui servizi di elaborazione AWS EC2 ed ECS passando a un approccio monolitico e ottenendo una riduzione del 90% dei costi operativi.

In molti hanno visto nel post a firma di Kolny un vero e proprio autogol di Amazon che rinuncia a un’architettura distribuita per tornare a una più tradizionale soluzione monolith. Non è propriamente così perché vanno attentamente soppesate le caratteristiche di un servizio come Prime Video.

Indubbiamente, i costi da affrontare per muovere i dati vengono spesso sottovalutati quando si parla di microservizi: questo è un dato di fatto che ammette lo stesso Kolny nella sua analisi. Abbracciare un’architettura monolitica non è sinonimo di spaghetti code (con questa espressione viene descritto il codice sorgente estremamente complesso, confuso e difficile da leggere e comprendere): il buon sviluppatore scriverà codice modulare indipendentemente dal modello di distribuzione. “Concettualmente, l’architettura di alto livello è rimasta la stessa. Abbiamo ancora esattamente gli stessi componenti che avevamo nel progetto iniziale“, chiarisce infatti Kolny.

L’intervento dell’ingegnere Prime Video non mette quindi i microservizi contro l’approccio monolith: si tratta di utilizzare lo strumento giusto per lo specifico lavoro da portare a termine: “i microservizi e i componenti serverless sono strumenti che funzionano su larga scala, ma se utilizzarli al posto di un’applicazione monolitica deve essere valutato caso per caso“.

Kolny conclude spiegando che alcuni decisioni assunte dal suo team sono tutt’altro che ovvie ma hanno portato a miglioramenti significativi. Ad esempio, è stato possibile replicare un processo di conversione dei media computazionalmente costoso posizionandolo più vicino ai componenti software che fungono da rilevati e analizzano gli stream multimediali.

Le modifiche applicate consentono adesso a Prime Video di monitorare tutti gli streaming degli utenti del servizio e non solo quelli con il maggior numero di spettatori. Questo approccio si traduce in una qualità ancora più elevata e in un’esperienza del cliente ancora migliore rispetto a prima.