Josh Evans parla del mondo caotico e colorato dei microservizi Netflix, partendo dalle nozioni di base: l'anatomia dei microservizi, le sfide associate ai sistemi distribuiti e i loro vantaggi. Basandosi su queste basi, esplora le pratiche culturali, architettoniche e operative che portano alla padronanza dei microservizi.
A differenza della deriva operativa, l’introduzione di nuovi linguaggi per l’internazionalizzazione dei servizi e di nuove tecnologie come i container sono decisioni consapevoli per aggiungere nuova complessità all’ambiente. Il mio team operativo si è standardizzato sulla migliore roadmap tecnologica per Netflix, che è stata integrata in best practice predefinite basate su Java ed EC2, ma con la crescita dell'azienda, gli sviluppatori hanno iniziato ad aggiungere nuovi componenti come Python, Ruby, Node-JS e Docker.
Sono molto orgoglioso di essere stati i primi a sostenere che il nostro prodotto funzionasse perfettamente senza attendere i reclami dei clienti. Tutto è iniziato in modo abbastanza semplice: avevamo programmi operativi in Python e alcune applicazioni di back-office in Ruby, ma le cose sono diventate molto più interessanti quando i nostri sviluppatori web hanno annunciato che avrebbero abbandonato la JVM e avrebbero spostato il web applicazione alla piattaforma software Node.js. Dopo l’introduzione di Docker le cose sono diventate molto più complesse. Abbiamo seguito la logica e le tecnologie che abbiamo ideato sono diventate realtà quando le abbiamo implementate per i clienti perché avevano molto senso. Ti dirò perché è così.
API Gateway ha effettivamente la capacità di integrare ottimi script che possono fungere da endpoint per gli sviluppatori dell'interfaccia utente. Hanno convertito ciascuno di questi script in modo tale che, dopo aver apportato le modifiche, potessero distribuirli alla produzione e quindi ai dispositivi degli utenti, e tutte queste modifiche sono state sincronizzate con gli endpoint eseguiti nel gateway API.
Tuttavia, ciò riproponeva il problema della creazione di un nuovo monolite in cui il servizio API era sovraccarico di codice in modo tale da provocare vari scenari di errore. Ad esempio, alcuni endpoint sono stati rimossi oppure gli script hanno generato in modo casuale così tante versioni di qualcosa che le versioni hanno occupato tutta la memoria disponibile del servizio API.
Era logico prendere questi endpoint ed estrarli dal servizio API. Per fare ciò, abbiamo creato componenti Node.js che venivano eseguiti come piccole applicazioni in contenitori Docker. Questo ci ha permesso di isolare eventuali problemi e crash causati da queste applicazioni dei nodi.
Il costo di questi cambiamenti è piuttosto elevato e comprende i seguenti fattori:
- Strumenti di produttività. La gestione delle nuove tecnologie richiedeva nuovi strumenti perché il team dell'interfaccia utente, utilizzando ottimi script per creare un modello efficiente, non doveva dedicare molto tempo alla gestione dell'infrastruttura, doveva solo scrivere script e verificarne la funzionalità.
Analisi e ordinamento delle opportunità: un esempio chiave sono i nuovi strumenti necessari per scoprire informazioni sui driver delle prestazioni. Era necessario sapere quanto era occupato il processore, come veniva utilizzata la memoria e la raccolta di queste informazioni richiedeva strumenti diversi. - Frammentazione delle immagini di base: la semplice AMI di base è diventata più frammentata e specializzata.
- Gestione dei nodi. Non sono disponibili architetture o tecnologie standard che consentano di gestire i nodi nel cloud, quindi abbiamo creato Titus, una piattaforma di gestione dei container che fornisce distribuzione di container scalabile e affidabile e integrazione del cloud con Amazon AWS.
- Duplicazione di una libreria o piattaforma. Per fornire alle nuove tecnologie le stesse funzionalità principali della piattaforma è stato necessario duplicarla negli strumenti di sviluppo Node.js basati su cloud.
- Curva di apprendimento ed esperienza industriale. L’introduzione di nuove tecnologie crea inevitabilmente nuove sfide che devono essere superate e da cui imparare.
Pertanto, non potevamo limitarci a una “strada asfaltata” e dovevamo costruire costantemente nuovi modi per far avanzare le nostre tecnologie. Per contenere i costi, abbiamo limitato il supporto centralizzato e ci siamo concentrati su JVM, nuovi nodi e Docker. Abbiamo dato priorità all’impatto efficace, informato i team sul costo delle loro decisioni e incoraggiati a cercare modi per riutilizzare le soluzioni ad alto impatto che avevano già sviluppato. Abbiamo utilizzato questo approccio durante la traduzione del servizio in lingue straniere per consegnare il prodotto a clienti internazionali. Gli esempi includono librerie client relativamente semplici che possono essere generate automaticamente, in modo che sia abbastanza semplice creare una versione Python, una versione Ruby, una versione Java, ecc.
Eravamo costantemente alla ricerca di opportunità per utilizzare tecnologie collaudate che si erano dimostrate efficaci in un luogo e in altre situazioni simili.
Parliamo dell'ultimo elemento: cambiamenti o variazioni. Guarda come il consumo del nostro prodotto varia in modo disomogeneo in base al giorno della settimana e all'ora nell'arco della giornata. Si potrebbe dire che le 9 del mattino siano l'orario più difficile per Netflix, quando il carico sul sistema raggiunge il massimo.
Come possiamo raggiungere un'elevata velocità di implementazione delle innovazioni software, ovvero apportare costantemente nuove modifiche al sistema, senza causare interruzioni nell'erogazione del servizio e senza creare disagi ai nostri clienti? Netflix ha raggiunto questo obiettivo attraverso l'uso di Spinnaker, una nuova piattaforma globale di gestione e distribuzione continua (CD) basata sul cloud.
Fondamentalmente, Spinnaker è stato progettato per integrare le nostre migliori pratiche in modo che, quando distribuiamo i componenti in produzione, possiamo integrare l'output direttamente nella nostra tecnologia di distribuzione multimediale.
Siamo stati in grado di incorporare due tecnologie nella nostra pipeline di fornitura che apprezziamo molto: analisi canary automatizzata e implementazione graduale. L'analisi Canary significa che indirizziamo una piccola quantità di traffico alla nuova versione del codice e passiamo il resto del traffico di produzione attraverso la vecchia versione. Quindi controlliamo come il nuovo codice affronta l'attività, meglio o peggio di quello esistente.
Un'implementazione scaglionata significa che se un'implementazione in una regione presenta problemi, si passa a un'implementazione in un'altra regione. In questo caso la suddetta checklist dovrà essere inserita nel percorso produttivo. Ti farò risparmiare un po' di tempo e ti consiglio di dare un'occhiata al mio discorso precedente, Engineering Global Netflix Operations in the Cloud, se sei interessato ad approfondire questo argomento. La registrazione video dell'intervento è visionabile seguendo il link in fondo alla slide.
Alla fine del discorso parlerò brevemente dell’organizzazione e dell’architettura di Netflix. All'inizio avevamo uno schema chiamato Electronic Delivery, che era la prima versione dello streaming multimediale NRDP 1.x. In questo caso è possibile utilizzare il termine "backstream" perché inizialmente l'utente poteva solo scaricare contenuti per riprodurli successivamente sul dispositivo. La prima piattaforma di distribuzione digitale di Netflix, nel 2009, assomigliava a questa.
Il dispositivo dell'utente conteneva l'applicazione Netflix, che consisteva in un'interfaccia utente, moduli di sicurezza, attivazione e riproduzione del servizio, basata sulla piattaforma NRDP - Netflix Ready Device Platform.
A quel tempo l'interfaccia utente era molto semplice. Conteneva quello che veniva chiamato Queque Reader e l'utente andava sul sito per aggiungere qualcosa a Queque e quindi visualizzare il contenuto aggiunto sul proprio dispositivo. L'aspetto positivo è che il team front-end e quello back-end appartenevano alla stessa organizzazione di consegna elettronica e avevano uno stretto rapporto di lavoro. Il payload è stato creato in base a XML. Allo stesso tempo, è stata creata l'API Netflix per il business dei DVD, che ha incoraggiato le applicazioni di terze parti a indirizzare il traffico verso il nostro servizio.
Tuttavia, l'API Netflix era ben preparata per aiutarci con un'interfaccia utente innovativa, contenente metadati di tutti i contenuti, informazioni su quali film erano disponibili, che ha creato la possibilità di generare liste di controllo. Aveva una API REST generica basata sullo schema JSON, HTTP Response Code, lo stesso utilizzato nelle architetture moderne, e un modello di sicurezza OAuth, che era quello richiesto all'epoca per un'applicazione front-end. Ciò ha reso possibile il passaggio da un modello pubblico di distribuzione dei contenuti in streaming a uno privato.
Il problema con la transizione era la frammentazione, poiché ora il nostro sistema gestiva due servizi basati su principi di funzionamento completamente diversi: uno su Rest, JSON e OAuth, l'altro su RPC, XML e un meccanismo di sicurezza dell'utente basato sul sistema di token NTBA. Questa è stata la prima architettura ibrida.
C'era essenzialmente un firewall tra i nostri due team perché inizialmente l'API non si adattava molto bene con NCCP e questo ha portato ad attriti tra i team. Le differenze riguardavano servizi, protocolli, circuiti, moduli di sicurezza e gli sviluppatori spesso dovevano passare da contesti completamente diversi.
A questo proposito, ho avuto una conversazione con uno degli ingegneri senior dell’azienda, al quale ho posto la domanda: “Quale dovrebbe essere la giusta architettura a lungo termine?” e lui ha posto la contro domanda: “Probabilmente sei più preoccupato sulle conseguenze organizzative: cosa succede se integriamo queste cose e queste rompono ciò che abbiamo imparato a fare bene? Questo approccio è molto rilevante per la Legge di Conway: "Le organizzazioni che progettano sistemi sono vincolate da un progetto che replica la struttura comunicativa di quell'organizzazione". Questa è una definizione molto astratta, quindi ne preferisco una più specifica: “Qualsiasi pezzo di software riflette la struttura organizzativa che lo ha creato”. Ecco la mia citazione preferita di Eric Raymond: "Se hai quattro team di sviluppatori che lavorano su un compilatore, ti ritroverai con un compilatore a quattro passaggi". Bene, Netflix ha un compilatore a quattro passaggi, ed è così che lavoriamo.
Possiamo dire che in questo caso è la coda che scodinzola. La nostra prima priorità non è la soluzione, ma l'organizzazione; è l'organizzazione che guida l'architettura di cui disponiamo. Piano piano, da un miscuglio di servizi, siamo passati a un'architettura che abbiamo chiamato Blade Runner, perché qui parliamo di servizi edge e della capacità di NCCP di essere separato e integrato direttamente nel proxy Zuul, nel gateway API e nelle corrispondenti funzionalità I “pezzi” sono stati trasformati in nuovi microservizi con funzionalità più avanzate di sicurezza, riproduzione, ordinamento dei dati, ecc.
Si può quindi affermare che le strutture dipartimentali e le dinamiche aziendali svolgono un ruolo importante nel modellare la progettazione del sistema e sono un fattore che promuove o impedisce il cambiamento. L’architettura dei microservizi è complessa e organica e la sua integrità si basa sulla disciplina e sul caos introdotto.
Qualche pubblicità
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com