4. PERCHÉ UTILIZZARE I MICROSERVIZI?
(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 I MICROSERVIZI?
(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 I MICROSERVIZI?
(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 I MICROSERVIZI?
(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 I MICROSERVIZI?
(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 I MICROSERVIZI?
(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
19. CONTENITORI – ALLA BASE DEI
MICROSERVIZI
Container per il trasporto merci
• Strada, ferrovia e mare
• Contenuto intatto
• Diffusi e standardizzati
• Semplici
• Contenuto protetto
• Vincoli
20. CONTENITORI – ALLA BASE 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 da usare
• Oltre 100 mila immagini sull’hub
Docker
• Creazione di immagini da
immagini
• Piattaforme
‒ Linux, OS X, Windows
‒ Laptop, macchine virtuali, cloud…
‒ Servizi cloud
28. ARCHITETTURE DI MICROSERVIZI
COSTRUITE SU CONTENITORI
Molti contenitori piccoli e
specializzati -> servizi sofisticati
• API ben definite
• Linguaggi e librerie indipendenti
• Modulare: facile manutenzione
e riutilizzo
• Tolleranza agli errori
• Scalabilità
35. ORCHESTRAZIONE
Distribuzione, connessione e
manutenzione automatizzate 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 di migliaia 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 UN FRAMEWORK 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?
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 MONGODB CON 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 MONGODB CON 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 MONGODB CON I CONTENITORI
Twitter
Ingest
Snapchat
Ingest
Unione
feed
Facebook
Ingest
WhatsApp
Ingest
Snapchat
Ingest
Snapchat
Ingest
Kubernetes
mongod
mongod
mongod
49. ORCHESTRAZIONE DI MONGODB TRAMITE
KUBERNETES
Applicazione distribuita con stato
• Volumi persistenti
• Indirizzi IP esterni per comunicazioni interne
• Inizializzazione di set di repliche MongoDB
• Monitoraggio
• Backup
50.
51.
52. STATEFULSET
Beta in Kubernetes 1.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)
58. RIFERIMENTI
• Abilitazione dei microservizi: 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
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
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.
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.
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.
Singoli microservizi possono essere aggiornati isolatamente o anche rimossi se il loro ruolo non è più richiesto.
Quando emerge un nuovo ruolo (o anche una modifica a un ruolo esistente), è consigliabile implementare un nuovo microservizio invece di estenderne uno esistente.
Quando emerge un nuovo ruolo (o anche una modifica a un ruolo esistente), è consigliabile implementare un nuovo microservizio invece di estenderne uno esistente.
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.
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.
9+9
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
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
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).
Anche un solo container (o contenitore) può essere interessante e utile.
O2 Arena
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à
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
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
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
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
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
18+5
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
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
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
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?
23+7
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
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.
30+3
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.
35+2
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.
