Netflix, un successo che viene da lontano
Giunto in Italia solo nel 2015, rappresenta uno dei servizi di maggior successo nell’ambito dei nuovi sistemi digitali per la distribuzione di contenuti multimediali. Accanto all’indubbio riscontro avuto presso il pubblico dalle serie prodotte e/o distribuite dall’azienda — si tratti di titoli internazionali come House of Cards o Stranger Things oppure di prodotti realizzati per un preciso territorio, come nel caso di Suburra pensato per gli spettatori italiani — il successo di Netflix non può essere imputato esclusivamente a ciò che viene trasmesso in streaming. Alla base delle attuali fortune del servizio, ci sono sicuramente anche la struttura e l’infrastruttura tecnologica scelte e sviluppate dall’azienda nel corso di circa venti anni.
Netflix, infatti, è un’azienda che, fondata nel 2017, si è sviluppata nel corso di questi due decenni pasando da un modello di business basato sulla distribuzione di DVD a quello attuale che si fonda sulla trasmissione via streaming internet — ormai praticamente in quasi tutto il mondo — di contenuti video prevalentemente, ma non esclusivamente, fiction.
Accanto al sicuro interesse dei contenuti prodotti e/o distribuiti, ha contribuito al successo di questi ultimi anni anche una modalità di abbonamento e disiscrizione molto semplice e funzionale alle esigenze del cliente: niente a che vedere con l’abbonamento alle classiche Pay TV, che risulta più macchinoso e rigido. Non a caso, sono recentemente nati dei servizi di streaming — ad esempio Now TV, Infinity o TIMvision — proprio dalle “tradizionali” TV a pagamento e dalle compagnie telefoniche, che sono volti a competere sullo stesso piano di Netflix con modalità di distribuzione simili seppur non identiche.
Cultura aziendale, infrastruttura tecnologica, pratiche di gestione
Quel che ci interessa qui, però, non è tanto parlare dei servizi in termini di contenuti, quanto affrontare alcuni temi che hanno contribuito a creare il “modello Netflix”. Questa azienda, infatti, in modo molto esplicitio, fornisce costantemente delle riflessioni e dei “resoconti” su quali siano i valori, i principi e le pratiche che le hanno permesso di raggiungere un’audience di circa 100 milioni di iscritti al loro servizio di streaming.
Nei documenti disponibili, nei frequenti interventi a conferenze o eventi dei responsabili di Netflix, anche ai massimi livelli, come vedremo, emergono sempre alcuni aspetti che non vengono vissuti in maniera “separata”, ma che contribuiscono a creare un contesto ampio in cui sono nati e si sviluppano gli attuali successi dell’organizzazione.
In particolare, gli aspetti trattati sono, da un lato quello della cultura aziendale e degli elementi ben precisi che la contraddistinguono, dall’altro, quello dell’infrastruttura tecnologica e delle pratiche di gestione dei sistemi che consentono al servizio di funzionare in modo costante in un panorama veramente globale.
Cultura e risorse umane
Accanto al CEO Reed Hastings, una delle figure che ha maggiormente contribuito a definire e diffondere un certo tipo di cultura aziendale in Netflix è stata Patty McCord, responsabile HR di Netflix fino al 2013.
Il frutto del lavoro di anni è concentrato — chiaramente in modo non esaustivo — in un documento [1] che illustra la “Cultura di Netflix” e sarà dettagliato in un libro di prossima pubblicazione [2] in cui l’autrice illustra cosa significhi costruire una cultura basata sulla libertà e sulla responsabilità.
La rivoluzione nell’ambito HR e di cultura aziendale che ha creato il modello Netflix si è basata su una serie di valori e principi condivisi a tutti i livelli. Ma non è stato un evento immediato: si è trattato di un processo prolungato che tuttora viene continuamente sottoposto a riconsiderazioni e retrospettive.
Di seguito, alcuni punti salienti che contribuiscono a far vivere tale mentalità. Una lettura approfondita di Culture at Netflix [1] merita sicuramente il tempo necessario. Siamo poi curiosi di leggere il libro Powerful: Building a Culture of Freedom and Responsibility non appena uscirà inizi 2018.
Dream team
Uno dei primi concetti su cui in Netflix si insiste è quello di creare dei “dream team” ossia dei gruppi di lavoro in cui le persone si trovino bene fra loro, condividano la visione e l’impegno per gli obiettivi e siano oggettivamente brave a svolgere la loro professione. Ciò che si fa per l’utente finale deve garantire soddisfazione anche a chi questa cosa la fa.
Non si tratta di gratificazioni immediate o “meccaniche” ma di una consapevolezza adulta di stare facendo bene quello che si è scelto di fare. Uno dei “mantra” delle politiche HR in Netflix è di assumere, ricompensare e tollerare solamente adulti pienamente formati, ossia persone in grado di gestire con la massima responsabilità la grande libertà di azione che viene loro garantita.
Come in una squadra sportiva che vince, devono esserci ottimi allenatori — i manager — e giocatori bravi nei diversi ruoli, in grado di amalgamarsi e di “rendere” insieme.
Trasparenza e onestà anche nelle critiche
Un altro pilastro della cultura aziendale in Netflix è quello della critica rispettosa e onesta. Se qualcuno ha problemi, di qualsiasi tipo, con un collega ai vari livelli, ci si aspetta che ne parli in modo diretto, gentile e aperto con l’interessato. A maggior ragione, tutti sono invitati a esprimere eventuali perplessità su decisioni organizzative o scelte tecnologiche se si ritiene che esse possano risultare controproducenti per l’organizzazione.
Non sono ammesse le lamentele alle spalle e le “trame di potere” sono ottima materia per una serie come House of cards ma non per un’azienda che funziona.
Dare e ricevere feedback
È chiaro che tutto questo presuppone l’istituzione di meccanismi efficienti ed efficaci per dare e ricevere feedback, che si allontanano drasticamente dalle pratiche tradizionali che si è soliti adottare in molte aziende. Due principi fondamentali, ad esempio, sono che:
- si discute sul comportamento e non sull’individuo in quanto persona;
- la critica deve fornire indicazioni su cosa si può fare per migliorare.
Dire “Tu sei un incapace” può portare a liti e risentimenti. Dire “Tu sei poco produttivo”, anche se è più gentile come approccio, serve a ben poco. Ma dire “Secondo me l’ordine di priorità delle cose su cui ti concentri potrebbe essere cambiata. Proviamo a dare delle priorità più ragionate a quanto stai facendo e vediamo se questo migliora la produttività” è una critica che affronta il problema e serve a migliorare.
Non si esaurisce tutto qui, anzi. E, chiaramente, sarebbe necessario un discorso molto più ampio. Però è arrivato il momento di parlare anche dell’infrastruttura tecnologica, dell’architettura dei sistemi e delle pratiche di gestione DevOps.
Cloud, DevOps e… scimmie
Semplificando ad alto livello di astrazione, l’infrastruttura tecnologica che consente il servizio di streaming video di Netflix altro non è che un enorme sistema distribuito, i cui diversi componenti sono ospitati in cloud su AWS (Amazon Web Services). Detta così… è facile, ma è chiaro che tutto questo sistema deve garantire disponibilità e affidabilità in maniera continua.
Pensiamo poi che tutto il contenuto via streaming deve essere distribuito da un lato su una diversificata tipologia di dispositivi (tablet, smartphone, PC etc.) e di sistemi operativi. E che questo deve accadere non in un’area geografica — magari esigente ma limitata — ma a livello globale. Pur essendo gli abbonati a Netflix concentrati nelle nazioni economicamente e tecnologicamente più ricche, infatti, il servizio è comunque disponibile in tutto il mondo, se si fa eccezione per la Cina — peraltro potenziale enorme mercato —, la Corea del Nord e la martoriata Siria.
Ridondanza e tolleranza al fallimento
Un sistema come quello appena descritto deve avere un’architettura in grado di garantire al massimo la tolleranza al fallimento: se anche un componente si “rompe”, il sistema comunque non crolla nel suo insieme e, in qualche modo, va avanti.
Sappiamo bene come la fault tolerance sia ottenibile anzitutto con il potenziamento delle macchine su cui girano i nostri servizi, e con l’oramai assodato concetto di ridondanza dei nodi, per cui, se anche uno o più nodi hanno dei malfunzionamenti, altri nodi saranno in grado, magari con un tollerabile degradamento della qualità, di garantire comunque il funzionamento del sistema distribuito, “facendo le funzioni” dei componenti server- e client-side momentaneamente fuori servizio.
Pratiche oltre alle infrastrutture
Hardware più potente e performante, architetture a microservizi, l’affermazione dei container, e il miglioramento delle reti di telecomunicazione hanno sicuramente contribuito a creare sistemi cloud sempre più robusti e affidabili.
Ma accanto agli elementi infrastrutturali, possiamo dire che anche l’approccio e le pratiche DevOps abbiano dato un aiuto consistente a questi miglioramenti. Anche i migliori componenti hardware e software non sono in grado di garantire un uptime del 100% totale, e diventa quindi molto importante non solo che cosa eroga un servizio, ma anche e soprattuto come il sistema che eroga il servizio viene gestito nella quotidianità e nella straordinarietà.
Fallire per imparare
Anche in quest’ambito, Netflix ha confermato i suoi caratteri di azienda innovativa e pronta a rompere gli schemi consolidati. Consapevoli del fatto che, anche con la migliore architettura e i migliori componenti, il gigantesco sistema di streaming avrebbe comunque prima o poi avuto problemi seri, gli ingegneri di Netflix hanno preso di petto la questione e hanno cominciato a… “sabotare” il sistema dall’interno per capire cosa succedeva e come si poteva porre rimedio a situazioni problematiche.
Con un approccio “filosoficamente” DevOps, è stata utilizzata l’automazione di alcune attività Operational in modo tale che il lato Development fosse costretto ad alterare il software prodotto affinché la sua qualità riuscisse ad andare oltre agli impedimenti riscontrati nel sistema.
La “scimmia impazzita”
Così come il personale addetto ai vari tipi di soccorso si addestra costantemente simulando situazioni di emergenza, senza attendere il reale caso limite in cui tutta l’organizzazione sarà messa alla prova, anche a Netflix hanno ben pensato che fosse meglio creare ogni giorno delle situazioni in grado di stimolare soluzioni per l’affidabilità dei sistemi, piuttosto che attendere il crash epocale in grado di mettere in seria difficoltà tutto il servizio di streaming.
In pratica, è stato creato uno script automatizzato, costantemente in esecuzione su tutti gli ambienti dei sistemi Netflix, che crea degli spegnimenti casuali di alcune istanze di server. Questo script è uno strumento che simula quanto in effetti avviene nella realtà. Ma, inglobando queste situazioni di emergenza nella quotidianità, gli sviluppatori Netflix hanno imparato a realizzare fin da subito i loro sistemi tenendo in considerazione la loro resilienza, e realizzandoli quindi in maniera che siano modulari e sottoposti a test regolari.
Sfruttando la metafora di un primate armato di una mazza lasciato libero di sfogarsi all’interno di un data center, questo script è stato chiamato Chaos Monkey. La “scimmia del caos” ovviamente non va in giro per le sale a spaccare fisicamente i server e a strappare cavi, ma disabilita alcune istanze di produzione in maniera randomica. Sta agli ingegneri minimizzare l’impatto dei problemi causati da questo strumento, monitorando attentamente gli effetti che tali inconvenienti e le soluzioni adottate hanno sul servizio fornito all’utente finale.
L’esercito delle otto scimmie
L’impatto che la creazione di questo strumento automatizzato, da collocare intorno al 2010, ha avuto sui sistemi Netflix è stato enorme. Il risultato più DevOps, se così vogliamo dire, è stata la creazione di strumenti automatizzati in grado di contrastare i danni causati dalla Chaos Monkey, il che è un enorme passo in avanti rispetto all’intervento continuo del personale umano. Chiaramente il monitoraggio deve essere attento e continuo, ma i casi in cui occorre intervenire manualmente si sono ridotti, proprio perché tutto il sistema è stato riprogettato in maniera sempre più fault-tolerant.
Il passo successivo è quindi stato quello di creare altri script automatizzati — altre scimmie — in grado di svolgere compiti importanti per migliorare l’architettura del sistema. Come viene spiegato sul blog tecnico di Netflix [3], è nato a poco a poco un vero e proprio “esercito di scimmie” (Netflix Simian Army) composto da otto strumenti diversi, in grado di indurre problemi ma anche di monitorare condizioni anormali o di svolgere attività di manutenzione. Li vediamo di seguito nel dettaglio, riportando quanto spiegato appunto sul blog appena citato.
Chaos Monkey
La “scimmia del caos” è, come detto sopra, quella che crea lo spegnimento di alcune istanze di server, simulando ciò che nella realtà avviene abbastanza spesso.
Chaos Kong
Il “king kong del caos” — inizialmente chiamato Chaos Gorilla — è sostanzialmente simile alla Chaos Monkey, eccezion fatta per le maggiori dimensioni. Infatti lo scopo di questo strumento è di spegnere un’intera zona di disponibilità dell’AWS. Chiaramente è abbastanza improbabile che un’intera regione AWS diventi indisponibile, ma è comunque possibile che succeda. In conseguenza delle azioni del Chaos Kong si deve valutare in che modo i sistemi effettuino automaticamente un ribilanciamento del servizio, senza intervento manuale e senza un percepibile impatto sull’esperienza dell’utente.
Latency Monkey
La “scimmia della latenza” induce dei ritardi artificiali nella comunicazione client-server, e poi misura quanto adeguatamente i servizi riescano a rispondere a questo degradamento. Inoltre, si possono introdurre ritardi molto lunghi su un singolo nodo anche senza effettivamente spegnere la sua istanza.
Conformity Monkey
La “scimmia della conformità” identifica istanze che non si conformano alle buone pratiche e le spegne. Ad esempio, se la Conformity Monkey trova delle istanze che non appartengono a un gruppo “auto-scalante”, le spegne consentendo allo owner del servizio di rilanciare tali istanze in modo corretto.
Doctor Monkey
C’è anche la “scimmia dottore” che effettua dei controlli sulla “salute” delle singole istanze e su altri valori relativi alla salute di tutto il sistema, come ad esempio il carico sulle CPU. Se la Doctor Monkey individua delle istanze “malate”, le elimina temporaneamente dal servizio in attesa della risoluzione del problema; se, dopo un dato lasso di tempo, il problema non è risolto, tali istanze vengono terminate.
Janitor Monkey
La “scimmia delle pulizie” si occupa di ripulire l’ambiente cloud, individuando spazio occupato in modo inutile e ripulendo il tutto, liberando risorse.
Security Monkey
La “scimmia della sicurezza” è di fatto una estensione della Conformity Monkey, che si incarica di individuare le vulnerabilità e le violazioni alla sicurezza — ad esempio dei security group AWS configurati male — terminando le istanze scorrette. La Security Monkey, inoltre, verifica la validità e la scadenza di tutti i certificati SSL e DRM.
10-18 Monkey
C’è anche una “scimmia della localizzazione e internazionalizzazione” il cui nome viene dalle classiche sigle l10n e i18n. La 10–18 Monkey si occupa dei problemi di configurazione e di runtime in istanze localizzate per le diverse aree geografiche, che usano lingue e insiemi di caratteri internazionali.
Esperimenti con il caos
Le esperienze maturate con il Simian Army hanno progressivamente convinto i tecnici e i manager di Netflix che una certa dose di caos, lungi dal distruggere l’intero sistema, finiva per renderlo migliore.
Ci si è resi conto, però, che il concetto di “caos” assumeva svariate sfumature e potenziali applicazioni differenti se visto da parte dei diversi livelli operativi e organizzativi dell’azienda. Perché allora non tentare di sviluppare ulteriormente queste pratiche, nate nell’ambito tecnologico, arrivando a creare un modello che possa applicarsi ai diversi ambiti dell’azienda e a progetti di varia tipologia?
Ne è nata una “ingegneria del caos” basata su ben definiti principi che sono pubblicati in un documento [4] aggiornato di continuo e intitolato, appunto Principles of Chaos Engineering. Una sorta di ulteriore, nuovo “manifesto”, ricco di spunti interessanti e a cui rimandiamo il lettore per eventuali approfondimenti.
Ingegneria del Caos
Qui basti dire che viene definita Ingegneria del Caos la disciplina con cui si compiono sperimentazioni su un sistema distribuito per migliorare la capacità del sistema di superare condizioni turbolente in produzione.
La complessità dei sistemi non può essere ignorata o ridotta, ma occorre accoglierla, migliorando la flessibilità e la rapidità di adattamento. Le sperimentazioni vanno effettuate alla scala più ampia possibile e con condizioni più realistiche possibili, senza però spingersi oltre il limite e mettere a repentaglio l’integrità del sistema. Tutto questo contribuisce alla resilienza del sistema.
In Netflix, la metrica per valutare il successo del modello resta il coinvolgimento del cliente, inteso come numero di riproduzioni video che partono al secondo.
Conclusioni
I casi di successo non nascono per caso e, generalmente, non si sviluppano nel giro di pochissimo tempo. In questo articolo abbiamo visto come il “modello Netflix” sia un’armonica combinazione di cultura aziendale basata su libertà e responsabilità, infrastrutture tecnologica e architetture resilienti, e pratiche DevOps sottoposte a continue sperimentazioni. Questi elementi e un processo di miglioramento continuo hanno portato all’attuale prodotto alle fortune, anche finanziarie, dell’aziend. Che però continua a non perdere di vista una metrica fondamentale: il coinvolgimento dell’utente finale.
Luigi Mandarino ha cominciato ad appassionarsi ai computer con il glorioso ZX Spectrum 48k: una bomba, per l‘epoca 🙂 Dopo gli studi di ingegneria, si è dedicato per diversi anni allo sviluppo di applicazioni Java, specie per la piattaforma Enterprise. Successivamente, ha svolto il ruolo di architetto dei sistemi interessandosi particolarmente alle architetture di integrazione. Attualmente, svolge consulenze a svariate aziende in particolare nel settore bancario, assicurativo e finanziario, principalmente su temi inerenti le architetture Java EE e le dinamiche di processo secondo un approccio Lean/Agile.