Uploaded byMongoDB
Microservices webinar EMEA Aug. 2017
Il documento discute l'utilizzo di microservizi basati su tecnologie come Docker, Kubernetes, Kafka e MongoDB, evidenziando i vantaggi come la velocità di innovazione e la scalabilità. Vengono presentati esempi pratici di implementazione, l'importanza dei contenitori per il trasporto di applicazioni e l'orchestrazione necessaria per gestire microservizi complessi. Infine, viene sottolineato il motivo per cui MongoDB è particolarmente adatto per architetture di microservizi grazie alla sua flessibilità e capacità di scalabilità.
More Related Content
Similar to Microservices webinar EMEA Aug. 2017
![MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]](https://cdn.slidesharecdn.com/ss_thumbnails/315pminfosysfinalsfoversionvocalpart1-200120221508-thumbnail.jpg?width=640&height=640&fit=bounds)
Microservices webinar EMEA Aug. 2017
- 1. Massimo Brignoli –MongoDB Principal Solutions Architect REALIZZAZIONE DI MICROSERVIZI CON DOCKER, KUBERNETES, KAFKA E MONGODB massimobrignoli
- 2. ARGOMENTI Microservizi Cosa, perché, come? Contenitori Docker, Kafka Orchestrazione Kubernetes, Mesos… MongoDB Perché,come? Quando utilizzarlo Casi d’uso Chi, perché? 1 2 3 4 5 6
- 3.
- 4. PERCHÉ UTILIZZARE IMICROSERVIZI? (RICORDATE LA QUESTIONE WEB-SCALE?) Velocità Cambiamento Manutenzione Scalabilità Efficacia Creazione rapida di prodotti minimi funzionanti Iterazioni rapide Componenti semplici Prodotto Team == Componente Reattività al mercato Impatto isolato Team Commissioni
- 5. PERCHÉ UTILIZZARE IMICROSERVIZI? (RICORDATE LA QUESTIONE WEB-SCALE?) Velocità Cambiamento Manutenzione Scalabilità Efficacia Creazione rapida di prodotti minimi funzionanti Iterazioni rapide Componenti semplici Prodotto Team == Componente Reattività al mercato Impatto isolato Team Commissioni
- 6. PERCHÉ UTILIZZARE IMICROSERVIZI? (RICORDATE LA QUESTIONE WEB-SCALE?) Velocità Cambiamento Manutenzione Scalabilità Efficacia Creazione rapida di prodotti minimi funzionanti Iterazioni rapide Componenti semplici Prodotto Team == Componente Reattività al mercato Impatto isolato Team Commissioni
- 7. PERCHÉ UTILIZZARE IMICROSERVIZI? (RICORDATE LA QUESTIONE WEB-SCALE?) Velocità Cambiamento Manutenzione Scalabilità Efficacia Creazione rapida di prodotti minimi funzionanti Iterazioni rapide Componenti semplici Prodotto Team == Componente Reattività al mercato Impatto isolato Team Commissioni
- 8. PERCHÉ UTILIZZARE IMICROSERVIZI? (RICORDATE LA QUESTIONE WEB-SCALE?) Velocità Cambiamento Manutenzione Scalabilità Efficacia Creazione rapida di prodotti minimi funzionanti Iterazioni rapide Componenti semplici Prodotto Team == Componente Reattività al mercato Impatto isolato Team Commissioni
- 9. PERCHÉ UTILIZZARE IMICROSERVIZI? (RICORDATE LA QUESTIONE WEB-SCALE?) Velocità Cambiamento Manutenzione Scalabilità Efficacia Creazione rapida di prodotti minimi funzionanti Iterazioni rapide Componenti semplici Prodotto Team == Componente Reattività al mercato Impatto isolato Team Commissioni
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. CONTENITORI – ALLABASE DEI MICROSERVIZI Container per il trasporto merci • Strada, ferrovia e mare • Contenuto intatto • Diffusi e standardizzati • Semplici • Contenuto protetto • Vincoli
- 20. CONTENITORI – ALLABASE DEI MICROSERVIZI Contenitori software • 1 immagine -> molti contenitori ‒ Laptop, data center, cloud ‒ Sviluppo, controllo qualità, produzione, assistenza • Semplici, efficienti • Isolamento • Vincoli
- 21. MACCHINE VIRTUALI (VM)E CONTENITORI VM VMVM Bare metal Sistema operativo host Hypervisor SO guest Librerie App Servizio SO guest Librerie App Servizio SO guest Librerie App Servizio Contenitore ContenitoreContenitore Bare metal Sistema operativo host Motore Docker Librerie Librerie App Librerie App Servizio ServizioServizio
- 22. MACCHINE VIRTUALI (VM)E CONTENITORI VM VMVM Bare metal Sistema operativo host Hypervisor SO guest Librerie App Servizio SO guest Librerie App Servizio SO guest Librerie App Servizio Contenitore ContenitoreContenitore Bare metal Sistema operativo host Motore Docker Librerie Librerie App Librerie App Servizio ServizioServizio
- 23. MACCHINE VIRTUALI (VM)E CONTENITORI VM VMVM Bare metal Sistema operativo host Hypervisor SO guest Librerie App Servizio SO guest Librerie App Servizio SO guest Librerie App Servizio Contenitore ContenitoreContenitore Bare metal Sistema operativo host Motore Docker Librerie Librerie App Librerie App Servizio ServizioServizio
- 24. DOCKER • Facile dausare • Oltre 100 mila immagini sull’hub Docker • Creazione di immagini da immagini • Piattaforme ‒ Linux, OS X, Windows ‒ Laptop, macchine virtuali, cloud… ‒ Servizi cloud
- 25. ESECUZIONE DI MONGODB dockerrun -d mongo
- 26.
- 27.
- 28. ARCHITETTURE DI MICROSERVIZI COSTRUITESU CONTENITORI Molti contenitori piccoli e specializzati -> servizi sofisticati • API ben definite • Linguaggi e librerie indipendenti • Modulare: facile manutenzione e riutilizzo • Tolleranza agli errori • Scalabilità
- 29. COLLEGAMENTO DEI MICROSERVIZI– KAFKA Produttore 9 8 7 123... Topic A Consumatore
- 30. COLLEGAMENTO DEI MICROSERVIZI– KAFKA Produttore 9 8 7 123... Topic A Consumatore Produttore Consumatore
- 31. COLLEGAMENTO DEI MICROSERVIZI– KAFKA Produttore 9 8 7 123... Partizione 0 Topic A Consumatore Produttore Consumatore 4 3 5 123... Partizione 1
- 32. COLLEGAMENTO DEI MICROSERVIZI– KAFKA Produttore LEADER Topic A / Partizione 0 Broker 1 FOLLOWER Topic A / Partizione 1 FOLLOWER Topic A / Partizione 0 Broker 2 LEADER Topic A / Partizione 1
- 33. COLLEGAMENTO DEI MICROSERVIZI– KAFKA Produttore Produttore Produttore 9 8 7 123 ... Partizione 0 4 3 5 123 ... Partizione 1 7 3 2 123 ... Partizione N Topic A Topic B 7 6 5 123 ... Partizione 0 Nuovo ß Precedente Consumatore Consumatore
- 34.
- 35. ORCHESTRAZIONE Distribuzione, connessione e manutenzioneautomatizzate di più contenitori • Provisioning degli host • Contenitori ‒ Creazione di istanze ‒ Ripianificazione ‒ Collegamento ‒ Scalabilità in ampliamento e riduzione • Esposizione di servizi
- 36. KUBERNETES Creato da Google,ricco di funzionalità e con ampia base di utenti • Distribuzione e replica • Scalabilità online in ampliamento e riduzione • Aggiornamenti in sequenza • Disponibilità elevata • Persistenza • Porte • Bilanciamento del carico • Google Compute Engine
- 37. APACHE MESOS Decine dimigliaia di server fisici; utilizzato da Twitter, Airbnb ed Apple • Codice (“framework”), non dichiarativo • Meno funzionalità di Kubernetes • Kubernetes come framework di Mesos • Usato come base per sistemi distribuiti ‒ Apache Aurora, Chronos, Marathon
- 38. SCELTA DI UNFRAMEWORK DI ORCHESTRAZIONE • Base di partenza: ‒ Competenze? ‒ Framework DevOps? ‒ Numero di host? ‒ Bare metal, macchine virtuali o cloud? • Ciclo di vita • Funzionalità ‒ Disponibilità elevata automatizzata? ‒ Raggruppamento e bilanciamento del carico? ‒ Come servizio?
- 39.
- 40. PERCHÉ MONGODB ÈPARTICOLARMENTE ADATTO AI MICROSERVIZI Monitoraggio e automazione Modello dati flessibile Ridondanza Scalabilità Semplicità
- 41. PERCHÉ MONGODB ÈPARTICOLARMENTE ADATTO AI MICROSERVIZI Monitoraggio e automazione Modello dati flessibile Ridondanza Scalabilità Semplicità
- 42. PERCHÉ MONGODB ÈPARTICOLARMENTE ADATTO AI MICROSERVIZI Monitoraggio e automazione Modello dati flessibile Ridondanza Scalabilità Semplicità
- 43. PERCHÉ MONGODB ÈPARTICOLARMENTE ADATTO AI MICROSERVIZI Monitoraggio e automazione Modello dati flessibile Ridondanza Scalabilità Semplicità
- 44. PERCHÉ MONGODB ÈPARTICOLARMENTE ADATTO AI MICROSERVIZI Monitoraggio e automazione Modello dati flessibile Ridondanza Scalabilità Semplicità
- 45. PERCHÉ MONGODB ÈPARTICOLARMENTE ADATTO AI MICROSERVIZI Monitoraggio e automazione Modello dati flessibile Ridondanza Scalabilità Semplicità
- 46. UTILIZZO DI MONGODBCON I CONTENITORI Twitter Ingest Snapch at Ingest Unione feed Faceboo k Ingest WhatsAp p Ingest Snapch at Ingest Snapch at Ingest MongoDB Atlas
- 47. UTILIZZO DI MONGODBCON I CONTENITORI Twitter Ingest Snapchat Ingest Unione feed Facebook Ingest WhatsApp Ingest Snapchat Ingest Snapchat Ingest Kubernetes Agente Ops Mgr Agente Ops Mgr Agente Ops Mgr
- 48. UTILIZZO DI MONGODBCON I CONTENITORI Twitter Ingest Snapchat Ingest Unione feed Facebook Ingest WhatsApp Ingest Snapchat Ingest Snapchat Ingest Kubernetes mongod mongod mongod
- 49. ORCHESTRAZIONE DI MONGODBTRAMITE KUBERNETES Applicazione distribuita con stato • Volumi persistenti • Indirizzi IP esterni per comunicazioni interne • Inizializzazione di set di repliche MongoDB • Monitoraggio • Backup
- 52. STATEFULSET Beta in Kubernetes1.5/6 • Identificativi di rete stabili, prevedibili e univoci. ‒ Gli indirizzi IP possono cambiare • Archiviazione stabile e persistente • Distribuzione e ridimensionamento ordinati, con gestione automatica degli errori (0 →N-1) • Eliminazione e risoluzione ordinati, con gestione automatica degli errori (N-1 → 0)
- 53.
- 54.
- 55. QUANDO UTILIZZARE IMICROSERVIZI
- 56.
- 57. USO PRATICO DIMONGODB E MICROSERVIZI
- 58. RIFERIMENTI • Abilitazione deimicroservizi: contenitori e orchestrazione (in inglese) https://www.mongodb.com/collateral/microservices-containers-and-orchestration- explained • Microservizi: l’evoluzione dello sviluppo di applicazioni moderne https://www.mongodb.com/collateral/microservices-the-evolution-of-building-modern- applications • Streaming di dati con Apache Kafka e MongoDB (in inglese) https://www.mongodb.com/collateral/data-streaming-with-apache-kafka-and-mongodb
- 59.
Editor's Notes
- #5 Applicazioni Web e mobili => Aziende Microservizi Web I microservizi sono stati introdotti nel mondo del Web, tanto da essere anche chiamati microservizi Web, e successivamente in quello delle app mobili. Ora anche imprese con interessi diversi cercano di ottenere gli stessi vantaggi. Le architetture a microservizi implementano le applicazioni come una serie di componenti software piccoli, autonomi, con accoppiamento lasco, ognuno dei quali ha un ruolo specifico e ben definito. Vantaggi dei microservizi: - Velocità di sviluppo - Iterazione rapida Evoluzione rapida, distribuzione continua Possibilità di circoscrivere l’impatto delle modifiche alle funzioni esistenti o semplicemente di aggiungerne una nuova Sviluppo reattivo Facilità di manutenzione Team di lavoro indipendenti, dotati di strumenti efficaci
- #11 Codice a spaghetti Reverse engineering? Nessuno capisce l’intera base di codice Il cambiamento di una riga di codice ha un impatto su innumerevoli altre, in punti inattesi Il codice monolitico è come un piatto di spaghetti La modifica di un punto qualsiasi ha un impatto su tutto il resto. Prima degli anni ’90 Prima di SOA (monolitico) Accoppiamento stretto Per modificare un codice monolitico, tutti devono accordarsi su ogni cambiamento. Ogni cambiamento ha effetti imprevisti e richiede attenti test preventivi.
- #12 Aggiungi un nuovo gusto in modo indipendente. Lo chef che prepara il cioccolato lo sa fare bene, ma non ha bisogno di saper preparare gli altri gusti. Il mirtillo non va più di moda? Togliamolo. Servono più dolcetti verdi? Aggiungiamone. La glassa rosa è stata migliorata? Buttiamo quelli con la vecchia e mettiamo quelli nuovi. I microservizi sono come i cupcake. Possiamo aggiungerne di nuovi con gusti diversi, togliere quelli che non ci servono più, aggiungere più dolcetti rosa se sono più richiesti. Uno sviluppatore può creare e attivare nuovi microservizi senza coordinarsi preventivamente con gli altri. L’adesione ai principi dell’architettura a microservizi rende possibile la continuous delivery di servizi nuovi o modificati. Maggiore modularità, accoppiamento più lasco. Inizio nel mondo delle app Web e mobili, passaggio alla realtà d’impresa. Grande diffusione nei media e nelle startup. L’obiettivo è la flessibilità più che il riutilizzo.
- #13 Ogni ovale rappresenta un microservizio. Ogni origine di feed di social media ha il proprio microservizio, con un’interfaccia specializzata verso la relativa API. Ognuno di questi microservizi passa messaggi al microservizio di “unione feed”, che può quindi renderli disponibili ad altri microservizi che devono utilizzarli. La comunicazione tra i microservizi avviene in rete. I microservizi possono trovarsi sullo stesso computer o essere distribuiti. Le best practice suggeriscono che ogni microservizio sia senza stato e disponga di un proprio database o schema.
- #14 Singoli microservizi possono essere aggiornati isolatamente o anche rimossi se il loro ruolo non è più richiesto.
- #15 Quando emerge un nuovo ruolo (o anche una modifica a un ruolo esistente), è consigliabile implementare un nuovo microservizio invece di estenderne uno esistente.
- #16 Quando emerge un nuovo ruolo (o anche una modifica a un ruolo esistente), è consigliabile implementare un nuovo microservizio invece di estenderne uno esistente.
- #17 I microservizi consentono la scalabilità orizzontale. Ogni tipo di microservizio può essere ridimensionato in modo indipendente, limitando l’aggiunta di altre istanze dedicate solo alle funzioni con sovraccarico di lavoro. La creazione di più istanze di ogni servizio consente di ottenere una disponibilità elevata.
- #18 Dimensioni Proprietà Approccio cloud-native di Netflix => crescita aziendale Secondo le best practice, la base di codice di ogni microservizio deve essere abbastanza piccola da poter essere compresa da un solo sviluppatore (le righe di codice devono essere nell’ordine delle centinaia, non delle decine di migliaia). Il codice di un microservizio deve essere di proprietà dell’organizzazione responsabile della relativa funzione: ad esempio, il team di sviluppo del marketing deve essere proprietario del microservizio responsabile dell’invio di e-mail di lead nurturing. Netflix è stata tra i pionieri dei microservizi con il suo approccio ”cloud-native”, che nasceva dall’esigenza di assicurare scalabilità alla propria organizzazione di sviluppo.
- #19 9+9
- #20 Container per il trasporto merci Lo stesso container trasporta merci su strada, ferrovia e mare Il contenuto non viene toccato nei vari spostamenti; nessun reimballaggio necessario Diffusi e standardizzati Facili da usare: apri, riempi, chiudi Il contenuto di ogni container è separato da quello degli altri Lo spazio occupato dal container è noto
- #21 Contenitori software Creazione di un’immagine unica contenente l’intero stack applicativo Creazione di diversi contenitori dalla stessa immagine in più ambienti Laptop, data center, cloud Sviluppo, controllo qualità, produzione, assistenza Facili da usare ed efficienti Il contenuto di ogni contenitore è isolato da quello degli altri Archiviazione, memoria, spazio dei nomi Limitazione delle risorse disponibili per ogni contenitore Archiviazione, memoria, CPU, I/O
- #25 La tecnologia più diffusa per i contenitori Facile da usare, con un ricco ecosistema Oltre 100 mila immagini disponibili dall’hub Docker Compresa quella di mongo hub.docker.com/_/mongo/ Sincronizzazione con i progetti GitHub Definizione di nuove immagini create a partire da immagini base Definizione delle interfacce tra contenitori LINUX, (e ora anche) Windows e OS X Viene eseguito su bare metal, macchine virtuali e cloud. L’infrastruttura per Docker viene messa a disposizione dai fornitori cloud (ad es. Google Container Engine).
- #27 Anche un solo container (o contenitore) può essere interessante e utile. O2 Arena
- #29 Microservizi costruiti combinando più contenitori Creazione di servizi sofisticati a partire da molti processi piccoli e specializzati (contenitori) API ben definite tra i componenti Ogni componente può utilizzare librerie, middleware e linguaggi di programmazione diversi Architettura modulare e disaccoppiata, che semplifica la manutenzione e consente il riutilizzo Tolleranza agli errori Scalabilità
- #30 Per svolgere operazioni utili, i microservizi hanno bisogno di un modo per comunicare: Apache Kafka Kafka offre funzionalità flessibili, scalabili e affidabili per distribuire flussi di dati di eventi da uno o più **produttori** a uno o più **consumatori**. Esempi di **eventi** (o **messaggi**): La lettura di un sensore periodico, come la temperatura attuale L’aggiunta di un articolo al carrello degli acquisti in un negozio online L’invio di un tweet con un hashtag specifico La generazione di una voce di registro per ogni clic in un’applicazione Web I flussi di eventi in Kafka vengono organizzati in **topic**. Un produttore sceglie un topic a cui inviare un determinato evento e il consumatore seleziona da quali topic eseguire il pull degli eventi. Ad esempio, un’applicazione finanziaria può eseguire il pull di titoli azionari NYSE da un topic e di annunci finanziari aziendali da un altro per cercare opportunità negoziali. Kafka conserva tutti i messaggi che trasmette e questo lo rende ideale per le distribuzioni di microservizi in produzione. Un microservizio può venire aggiornato e quindi recuperare tutti i dati non acquisiti O anche applicare la propria logica di business aggiornata all’intera cronologia degli eventi Un nuovo microservizio può essere aggiunto e quindi aggiornato con tutte le informazioni precedenti Se un servizio genera più richieste di quelle che un altro è in grado di gestire, Kafka funge da buffer
- #31 Per svolgere operazioni utili, i microservizi hanno bisogno di un modo per comunicare: Apache Kafka Kafka offre funzionalità flessibili, scalabili e affidabili per distribuire flussi di dati di eventi da uno o più **produttori** a uno o più **consumatori**. Esempi di **eventi** (o **messaggi**): La lettura di un sensore periodico, come la temperatura attuale L’aggiunta di un articolo al carrello degli acquisti in un negozio online L’invio di un tweet con un hashtag specifico La generazione di una voce di registro per ogni clic in un’applicazione Web I flussi di eventi in Kafka vengono organizzati in **topic**. Un produttore sceglie un topic a cui inviare un determinato evento e il consumatore seleziona da quali topic eseguire il pull degli eventi. Ad esempio, un’applicazione finanziaria può eseguire il pull di titoli azionari NYSE da un topic e di annunci finanziari aziendali da un altro per cercare opportunità negoziali. Kafka conserva tutti i messaggi che trasmette e questo lo rende ideale per le distribuzioni di microservizi in produzione. Un microservizio può venire aggiornato e quindi recuperare tutti i dati non acquisiti O anche applicare la propria logica di business aggiornata all’intera cronologia degli eventi Un nuovo microservizio può essere aggiunto e quindi aggiornato con tutte le informazioni precedenti Se un servizio genera più richieste di quelle che un altro è in grado di gestire, Kafka funge da buffer
- #32 Per svolgere operazioni utili, i microservizi hanno bisogno di un modo per comunicare: Apache Kafka Kafka offre funzionalità flessibili, scalabili e affidabili per distribuire flussi di dati di eventi da uno o più **produttori** a uno o più **consumatori**. Esempi di **eventi** (o **messaggi**): La lettura di un sensore periodico, come la temperatura attuale L’aggiunta di un articolo al carrello degli acquisti in un negozio online L’invio di un tweet con un hashtag specifico La generazione di una voce di registro per ogni clic in un’applicazione Web I flussi di eventi in Kafka vengono organizzati in **topic**. Un produttore sceglie un topic a cui inviare un determinato evento e il consumatore seleziona da quali topic eseguire il pull degli eventi. Ad esempio, un’applicazione finanziaria può eseguire il pull di titoli azionari NYSE da un topic e di annunci finanziari aziendali da un altro per cercare opportunità negoziali. Kafka conserva tutti i messaggi che trasmette e questo lo rende ideale per le distribuzioni di microservizi in produzione. Un microservizio può venire aggiornato e quindi recuperare tutti i dati non acquisiti O anche applicare la propria logica di business aggiornata all’intera cronologia degli eventi Un nuovo microservizio può essere aggiunto e quindi aggiornato con tutte le informazioni precedenti Se un servizio genera più richieste di quelle che un altro è in grado di gestire, Kafka funge da buffer
- #33 Per svolgere operazioni utili, i microservizi hanno bisogno di un modo per comunicare: Apache Kafka Kafka offre funzionalità flessibili, scalabili e affidabili per distribuire flussi di dati di eventi da uno o più **produttori** a uno o più **consumatori**. Esempi di **eventi** (o **messaggi**): La lettura di un sensore periodico, come la temperatura attuale L’aggiunta di un articolo al carrello degli acquisti in un negozio online L’invio di un tweet con un hashtag specifico La generazione di una voce di registro per ogni clic in un’applicazione Web I flussi di eventi in Kafka vengono organizzati in **topic**. Un produttore sceglie un topic a cui inviare un determinato evento e il consumatore seleziona da quali topic eseguire il pull degli eventi. Ad esempio, un’applicazione finanziaria può eseguire il pull di titoli azionari NYSE da un topic e di annunci finanziari aziendali da un altro per cercare opportunità negoziali. Kafka conserva tutti i messaggi che trasmette e questo lo rende ideale per le distribuzioni di microservizi in produzione. Un microservizio può venire aggiornato e quindi recuperare tutti i dati non acquisiti O anche applicare la propria logica di business aggiornata all’intera cronologia degli eventi Un nuovo microservizio può essere aggiunto e quindi aggiornato con tutte le informazioni precedenti Se un servizio genera più richieste di quelle che un altro è in grado di gestire, Kafka funge da buffer
- #34 Per svolgere operazioni utili, i microservizi hanno bisogno di un modo per comunicare: Apache Kafka Kafka offre funzionalità flessibili, scalabili e affidabili per distribuire flussi di dati di eventi da uno o più **produttori** a uno o più **consumatori**. Esempi di **eventi** (o **messaggi**): La lettura di un sensore periodico, come la temperatura attuale L’aggiunta di un articolo al carrello degli acquisti in un negozio online L’invio di un tweet con un hashtag specifico La generazione di una voce di registro per ogni clic in un’applicazione Web I flussi di eventi in Kafka vengono organizzati in **topic**. Un produttore sceglie un topic a cui inviare un determinato evento e il consumatore seleziona da quali topic eseguire il pull degli eventi. Ad esempio, un’applicazione finanziaria può eseguire il pull di titoli azionari NYSE da un topic e di annunci finanziari aziendali da un altro per cercare opportunità negoziali. Kafka conserva tutti i messaggi che trasmette e questo lo rende ideale per le distribuzioni di microservizi in produzione. Un microservizio può venire aggiornato e quindi recuperare tutti i dati non acquisiti O anche applicare la propria logica di business aggiornata all’intera cronologia degli eventi Un nuovo microservizio può essere aggiunto e quindi aggiornato con tutte le informazioni precedenti Se un servizio genera più richieste di quelle che un altro è in grado di gestire, Kafka funge da buffer
- #35 18+5
- #36 Distribuzione, connessione e manutenzione automatizzate di più contenitori Provisioning degli host Creazione di istanze dei contenitori Ripianificazione dei contenitori con errori Collegamento dei contenitori attraverso interfacce definite Esposizione dei servizi al mondo esterno Scalabilità in ampliamento e riduzione
- #37 Creato da Google, ricco di funzionalità e con ampia base di utenti Distribuzione e replica automatizzate dei contenitori Scalabilità online in ampliamento e riduzione Aggiornamenti in sequenza Disponibilità elevata: ripianificazione automatica dei contenitori con errori Esposizione delle porte di rete ad app esterne Bilanciamento del carico su gruppi di contenitori che forniscono un servizio Fornito come servizio da Google Compute Engine
- #38 Progettato per la scalabilità su decine di migliaia di server fisici; utilizzato da Twitter, Airbnb ed Apple Lo sviluppatore scrive il codice per trasformare l’applicazione in un framework da eseguire su Mesos Meno ricco di funzionalità rispetto a Kubernetes: molte funzioni come il bilanciamento del carico, la ripianificazione e la scalabilità sono considerate di livello superiore Esiste un progetto per eseguire Kubernetes come framework di Mesos Usato come base per sistemi distribuiti Apache Aurora, Chronos, Marathon
- #39 Non dimentichiamo Docker Compose Fattori da considerare… Integrazione con framework DevOps esistenti? Numero di host? Distribuzione su bare metal, macchine virtuali o cloud? Disponibilità elevata automatizzata? Raggruppamento e bilanciamento del carico? Utilizzo di competenze esistenti? Installazione di un framework di orchestrazione in proprio o uso come servizio?
- #40 23+7
- #50 Kubernetes non progettato per i servizi con stato 3 possibilità: MongoDB all’esterno del contenitore (Atlas?) Kubernetes gestisce MongoDB Kubernetes gestisce l’agente Ops Manager, Ops/Cloud Manager gestiscono MongoDB L’orchestrazione dei contenitori MongoDB richiede un trattamento speciale in quanto si tratta di un’applicazione distribuita con stato… Lo stato deve persistere dopo una ripianificazione: utilizzare l’astrazione dei volumi persistenti di Kubernetes I membri del set di repliche devono comunicare tra di loro: esporre gli indirizzi IP esterni e le porte che persistono dopo una ripianificazione I set di repliche devono essere inizializzati esattamente da un membro Permane comunque l’esigenza di effettuare il monitoraggio e il backup di MongodDB: MongoDB Cloud Manager
- #51 Kubernetes. Singolo pod/contenitore/mongod in un controller di replica. Utilizzare indirizzi IP esterni (altri indirizzi IP e nomi host sono locali del cluster Kubernetes e soggetti a cambiamenti). Per ulteriori informazioni fare riferimento al white paper.
- #55 30+3
- #56 Velocità > Eleganza Sagrada Familia –1882-2026 (144 anni). Modifiche frequenti e localizzate Scalabilità localizzata Aggiornamenti Solo se: È necessario ridimensionare il team La progettazione deve prevedere i cambiamenti La velocità è più importante dell’eleganza. Vi sono frequenti cambiamenti nelle funzionalità e nell’utilizzo dell’applicazione. I cambiamenti avvengono a velocità diverse all’interno dell’applicazione, pertanto l’isolamento funzionale e la semplicità di integrazione sono più importanti della coesione dei moduli. Le funzionalità sono facilmente separabili in componenti semplici e isolabili. Si hanno le competenze da sviluppatore/DevOps. La delimitazione delle unità organizzative di sviluppo coincide con quella dei servizi. Non dimenticate che state creando un sistema distribuito: ciò comporta complessità ma vi sono precedenti su cui documentarsi. Un punto da tenere presente è che è inutile perdere tempo con i microservizi se non si ha l’esigenza di: - Ridimensionare il team - Progettare in vista di cambiamenti Sagrada Familia – progettata da Gaudi; costruzione cominciata il 19 marzo 1882. Completamento previsto nel 2026.
- #57 35+2
- #58 Gap (flessibilità): monolite -> microservizi (75 giorni). Nuovi tipi di ordine di acquisto realizzati in pochi giorni. FuboTV (scalabilità). Cluster singolo per sviluppo, controllo di qualità e produzione. Capacità di gestire picchi di traffico 100 volte più elevato. MongoDB eseguito su Kubernetes. Otto (arch == org). Distribuzione veloce e iterativa. Backcountry (> team di sviluppo distribuito): le modifiche dello schema occupavano il 20% del tempo di sviluppo. Schema flessibile. Compare The Market (uso di Docker, Kafka, MongoDB e Ops Manager). GAP ha trasferito il proprio sistema di ordini di acquisto da un’architettura monolitica ai microservizi. Grazie allo schema flessibile di MongoDB, la realizzazione del nuovo sistema ha richiesto solo 75 giorni. Quando i requisiti sono cambiati ed è stato necessario aggiungere nuovi tipi di ordine di acquisto, il tempo impiegato è stato di qualche giorno, invece di mesi. FuboTV è un servizio nordamericano di streaming di contenuti sportivi. Utilizza i microservizi con Kubernetes, Docker e MongoDB. Grazie all’isolamento, può utilizzare un singolo cluster di computer (in Google Cloud) per sviluppo, controllo di qualità e produzione. Applicazione con carico molto variabile. La scalabilità consente la gestione di picchi di traffico 100 volte più elevato. Otto: l’esigenza chiave era quella di avere un’architettura in linea con la struttura organizzativa. I microservizi consentono la coesistenza di team di sviluppo relativamente indipendenti (amministrazione, gestione progetti, IT). Tutto ciò consente di velocizzare i processi di test e distribuzione e di realizzare una continuous delivery iterativa Backcountry.com è un rivenditore online specializzato in articoli di abbigliamento e accessori per attività all’aperto. Il fattore che ha portato alla scelta dei microservizi è stato la necessità di gestire un team di sviluppo distribuito e in espansione. Con l’aumentare degli sviluppatori che contribuivano alla scrittura del codice, gli schemi diventavano complicati e difficili da mantenere, pesando per il 20% sul backlog Scrum. Grazie al modello dati flessibile di MongoDB, Backcountry è riuscita ad accelerare le iterazioni, ridurre i tempi di sviluppo e mitigare il debito tecnico. Compare The Market: in ambiente cloud, ogni microservizio o raggruppamento logico di microservizi correlati è fornito con il proprio set di repliche di MongoDB in esecuzione nel motore di archiviazione Encrypted per ridurre ulteriormente l’esposizione a rischi di sicurezza. Utilizza Docker, Kafka e MongoDB.