La rivoluzione dei microservizi
Il nuovo paradigma di progettazione architetturale che cambierà i vostri sistemi IT
rendendoli più flessibili e più dinamici
Meeting On Microservices - Bologna, 20/12/2016
Ricerca Tecnologia
Affiancamento
Consulenza
Prodotti
Cliente
Il Sistema Informativo al centro
Processi Organizzativi Dati Organizzativi
Organizzazione
Contesto economico
Strategie di Business
Serve capacità di adattamento
Contesto economico
1)Riduzione della visibilità
a lungo termine.
2) Internet come piazza abilitante
al commercio
1) Aumento della pressione esterna
2) Richiesta di maggiore capacità
di adattamento in tempi brevi
Interveniamo qui
Com'è il sistema ora…
Sistema amministrativo
Web
Dati Specifici di
Applicazioni terze
Il sistema amministrativo è spesso il cuore dell'IT
I processi ed i dati organizzativi IT
si trovano sparsi in diverse
porzioni del sistema:
1) Dentro il sistema amministrativo
2) Nei processi di integrazione
3) Dentro applicativi di terze parti
I processi ed i dati organizzativi IT
si trovano sparsi in diverse
porzioni del sistema:
1) Dentro il sistema amministrativo
2) Nei processi di integrazione
3) Dentro applicativi di terze parti
La gestione dei processi
organizzativi così come la gestione
dei dati, richiede impegno in termini
di:
1) Tempo
2) Risorse umane
3) Risorse economiche
(Consulenze, prodotti,...)
Come dovrebbe essere?
Un sistema altamente adattivo e flessibile dovrebbe essere composto da tanti
componenti interdipendenti ciascuno dei quali offre funzionalità ben delineate
Architettura logica a strati
Sorgenti di dati
Processi base
Processi di business
API
Applicativi
La scalabilità?
Un sistema flessibile dovrebbe essere in grado di scalare linearmente rispetto al
carico a cui è sottoposto così da essere in grado di scalare linearmente anche i
suoi costi.
utilizzatori
costi
I Microservices
Applicativo monolitico
Lib A Lib B Lib C
μS A
μS B
μS C
μS MainApplicativo monolitico
Lib A Lib B Lib C
μS A
μS B
μS C
μS MainApplicativo monolitico
Lib A Lib B Lib C
μS A
μS B
μS C
μS Main
MONOLITICO vs DISTRIBUITO
Microservices - Riusabilità
Applicativo monolitico A
Lib A Lib B Lib C
Applicativo monolitico B
Lib A Lib B Lib C
Lib A Lib B Lib C Sorgenti μS A μS B μS C
μS Main A μS Main B
Microservices - Scalabilità
μS A
μS B
μS C
μS Main
Applicativo
monolitico
Lib A Lib B Lib C
Applicativo
monolitico
Lib A Lib B Lib CApplicativo
monolitico
Lib A Lib B Lib C
μS B
μS C
μS Main
μS B
μS B
Microservices - Deployment
μS A
μS B
μS C
μS Main
Applicativo
monolitico
Lib A Lib B Lib C
Microservices
Resistenza agli errori
Applicativo monolitico
Lib A Lib B Lib C
μS A
μS B
μS C
μS Main
μS C'
Microservices - Monitoring
Applicativo monolitico
Lib A Lib B Lib C
μS A
μS B
μS C
μS Main
LOG
Logger
I microservizi come soluzione
Sorgenti di dati
MICROSERVIZI
MICROSERVIZI
API
Applicativi
Jolie
Java Orchestration Language Interpreter Engine, nasce come alternativa al
linguaggi di orchestrazione per web service WS-BPEL
● Semplificandone la gestione
● Non richiede la presenza di motori di esecuzione dedicati
● La definizione non è definita mediante xml ma è scritta in linguaggio nativo
eseguito dall’interprete
● Estendendone le funzionalità
● Possibilità di integrare logica applicativa Java
● Possibilità di utilizzare il linguaggio per implementare microservizi
● Orchestrazione di Web Service Soap, Rest, Jolie
Perché un linguaggio?
ANNO 2016
Ho comprato uno smartphone nuovo con
sistema operativo Android e connessione
ad internet
Perché un linguaggio?
ANNO 1800?
Ho comprato uno smartphone nuovo con
sistema operativo Android e connessione
ad internet
Perché un linguaggio?
ANNO 1800?
Ho acquistato un oggetto grande quanto un libro di
piccole dimensioni la cui copertina straordinariamente
lucida e variopinta è in grado di mostrare immagini così
ben definite da apparire quasi rappresentazioni della
realtà, ma questo è nulla poiché è sufficiente sfiorare
tale oggetto con un dito per innescare un meccanismo
quasi diabolico in grado di fare udire la mia voce ad una
persona all'altro capo del mondo in tempo reale così che
io possa comunicare con lei una volta acquisito un
numero che mi permette di riconoscerla tra tutti.
L'oggetto è nuovo con sistema operativo Android e
connessione ad internet
Il linguaggio fa guadagnare
TEMPO e SPAZIO
oggetto grande quanto un libro di
piccole dimensioni la cui copertina
straordinariamente lucida e
variopinta è in grado di mostrare
immagini così ben definite da
apparire quasi rappresentazioni della
realtà, ma questo è nulla poiché è
sufficiente sfiorare tale oggetto con
un dito per innescare un meccanismo
quasi diabolico in grado di fare udire
la mia voce ad una persona all'altro
capo del mondo in tempo reale così
che io possa comunicare con lei una
volta acquisito un numero che mi
permette di riconoscerla tra tutti.
smartphone
Il linguaggi di programmazione
01010100010100010010
01001001010001010000
10100100100101001010
10100101001001010010
01010100010100010010
01001001010001010000
10100100100101001010
10100101001001010010
01010100010100010010
01001001010001010000
10100100100101001010
10100101001001010010
01010100010100010010
01001001010001010000
10100100100101001010
10100101001001010010
01010100010100010010
01001001010001010000
MACCHINA
ORG 2050H
MOV DPTR,#CNT
MOV A,#INIT
MOVX @DPTR,A
MOV SP,#2FH
CLR RS0
CLR RS1
ACALL SERIAL
MOV
DPTR,#HEADING
ACALL STRING
ORG 2050H
MOV DPTR,#CNT
MOV A,#INIT
MOVX @DPTR,A
MOV SP,#2FH
CLR RS0
ASSEMBLER C
MENO ERRORI UMANI
int main()
{
int n, sum = 0, c, value;
printf("Enter the number of integers ");
scanf("%d", &n);
printf("Enter %d integersn",n);
for (c = 1; c <= n; c++)
{
scanf("%d",&value);
sum = sum + value;
}
printf("Sum of entered integers = %dn",sum);
return 0;
}
Un vantaggio concreto
● Il primo compilatore completo fu creato
dall'equippe di John. W. Backus presso i
laboratori IBM nel 1957. Era un compilatore
FORTRAN. Ci vollero ben
● 18 anni uomo per realizzarlo.
● Al tempo non era stata ancora sviluppata la
teoria dei linguaggi.
● Oggi in molte università, viene data la creazione
di un compilatore come esercizio d'esame. John. W. Backus
I tre vantaggi competitivi di Jolie
1)1) ParadigmaticitàParadigmaticità:: il programmatore scrive e pensa
direttamente a microservizi.
2)2) Autosufficienza:Autosufficienza: non sono necessari tool aggiuntivinon sono necessari tool aggiuntivi
per la messa in esecuzione di un microservizio Jolieper la messa in esecuzione di un microservizio Jolie
3)3) Indipendenza:Indipendenza: un microservizio jolie non è legato aun microservizio jolie non è legato a
nessun protocollo di comunicazione in particolarenessun protocollo di comunicazione in particolare
Paradigmaticità
Il programmatore programma e progetta l'architettura a microservizi in unico passaggio
poiché il linguaggio fornisce tutti gli strumenti base per la creazione e manipolazione dei
microservizi.
Conseguenza importante: durante la programmazione il programmatore si
disinteressa di come dovranno essere eseguiti i microservizi
Dall'applicazione monolitica...
...esecuzione come singola
applicazione
...verso...
...eseguiti in due macchine
...i microservices
Autosufficienza
Un servizio Jolie necessita solamente di
una Java Virtual Machine per funzionare
Non sono necessari framework
aggiuntivi per il suo funzionamento
No application server, No web server
Importazione di codice Legacy
Legacy Code
Indipendenza
HTTP
SOAP
HTTPS
custom protocol
Si possono
sviluppare protocolli
custom specifici
L'interdipendenza tra linguaggi e
supporti
Memorie
meccaniche
0101010
1940
Assembler
1954Memorie
elettroniche
Memorie
TTL 1973
C
Multi
piattaforma
Cloud
2010
1991
Java
IoT
2030
Le due vie ai microservizi
Programmazione: dal punto di
vista della programmazione la
sfida è quella di trovare nuovi
linguaggi in grado di catturarne
l'essenza.
Linguaggio è la parola chiave.
Diciamo che questa via segue il
paradigma linguistico
Sistemi: dal punto di vista dei
sistemi, i microservizi possono
essere visti come applicazioni
indipendenti in grado di servire
più richieste. Sono eseguiti
all'interno di artefatti chiamati
containers.
Container é la parola chiave.
Diciamo che questa via segue il
paradigma sistemistico.
Paradigma Sistemistico
vs
Paradigma Lingustico
Il paradigma linguistico si basa
sull'idea che i principi fondazionali
della programmazione a
microservizi possano essere
condensato in un unico linguaggio.
Non è importante come venga
eseguito un microservizio, la cosa
importante è che ogni singola
unità programmabile sia un
microservizio.
Il paradigma sistemistico, è
basato sui contaner e parte
dall'idea che:
Non è importante come un
microservizio è realizzato, la cosa
più importante è che il
microservizio sia eseguito
all'interno di un container che può
essere spostato, rimpiazzato o
scalato.
Catena produttiva del software
DESIGN
Paradigma sistemistico Paradigma linguistico
DEVELOPMENT
PACKAGING
DEPLOYMENT
Il progettista pensa a microservizi Il progettista pensa a microservizi
Lo sviluppatore programma
seguendo un altro paradigma
(oggetti, funzionale, ecc)
Il programmatore sviluppa
direttamente a microservizi
Lo sviluppatore trasforma il suo
artefatto software in un microservizio
Utilizzando tool e framework
aggiuntivi
Lo sviluppatore esegue il
microservizio in un container
Lo sviluppatore può eseguire il
microservizio in un container
(non necessario)
I confini di un microservizio
Paradigma Sistemistico Paradigma Lingustico
Un microservizio può essere il
risultato della composizione di
altri microservizi
Un microservizio è un artefatto software
sviluppato con un dato insieme di tecnologie
ed impachettato all'interno di un container
I microservizi sono atomici All'interno di un microservizio possono
esserci altri microservizi
L'architettura
Paradigma Sistemistico Paradigma linguistico
Un'architettura a microservizi è una rete di
containers
Un'architettura a microservizi è una
composizione di microservizi
L'architettura
Paradigma Sistemistico Paradigma Linguistico
A microservice can be easily moved from
inside to outside of a container (and vice
versa)
In order to bring an internal component out
of a microservice, a specific programming
task must be carried out
X
Containers
Paradigma Sistemistico Paradigma Linguistico
Il container è solamente uno strumento
che per l'esecuzione
Il Container è l'elemento chiave
dell'archtettura
Vantaggi
Paradigma Sistemistico Linguistic paradigm
Indipendenza dalla
Tecnologia
Le architetture possono cambiare
in modo semplice ricomponendo i
microservizi
Esecuzione semplice e scalabile
La progettazione a microservizi si
traduce immediatamente in
programmazione nativa
Compatibile con lo stack del Cloud
Computing
Compatibile con il paradigma
sistemistico
La rivoluzione dei
microservizi
Paradigma Linguistico
La rivoluzione si trova nell'intersezione tra questi due mondi
Paradigma sistemistico
Un sistema software complesso non è mai un'entità statica ma è
soggetto a continue modifiche per potersi adattare agli stimoli
esterni... come il pensiero umano

La rivoluzione dei Microservizi

  • 1.
    La rivoluzione deimicroservizi Il nuovo paradigma di progettazione architetturale che cambierà i vostri sistemi IT rendendoli più flessibili e più dinamici Meeting On Microservices - Bologna, 20/12/2016
  • 2.
  • 3.
    Il Sistema Informativoal centro Processi Organizzativi Dati Organizzativi Organizzazione Contesto economico Strategie di Business
  • 4.
    Serve capacità diadattamento Contesto economico 1)Riduzione della visibilità a lungo termine. 2) Internet come piazza abilitante al commercio 1) Aumento della pressione esterna 2) Richiesta di maggiore capacità di adattamento in tempi brevi Interveniamo qui
  • 5.
    Com'è il sistemaora… Sistema amministrativo Web Dati Specifici di Applicazioni terze Il sistema amministrativo è spesso il cuore dell'IT I processi ed i dati organizzativi IT si trovano sparsi in diverse porzioni del sistema: 1) Dentro il sistema amministrativo 2) Nei processi di integrazione 3) Dentro applicativi di terze parti I processi ed i dati organizzativi IT si trovano sparsi in diverse porzioni del sistema: 1) Dentro il sistema amministrativo 2) Nei processi di integrazione 3) Dentro applicativi di terze parti La gestione dei processi organizzativi così come la gestione dei dati, richiede impegno in termini di: 1) Tempo 2) Risorse umane 3) Risorse economiche (Consulenze, prodotti,...)
  • 6.
    Come dovrebbe essere? Unsistema altamente adattivo e flessibile dovrebbe essere composto da tanti componenti interdipendenti ciascuno dei quali offre funzionalità ben delineate
  • 7.
    Architettura logica astrati Sorgenti di dati Processi base Processi di business API Applicativi
  • 8.
    La scalabilità? Un sistemaflessibile dovrebbe essere in grado di scalare linearmente rispetto al carico a cui è sottoposto così da essere in grado di scalare linearmente anche i suoi costi. utilizzatori costi
  • 9.
    I Microservices Applicativo monolitico LibA Lib B Lib C μS A μS B μS C μS MainApplicativo monolitico Lib A Lib B Lib C μS A μS B μS C μS MainApplicativo monolitico Lib A Lib B Lib C μS A μS B μS C μS Main MONOLITICO vs DISTRIBUITO
  • 10.
    Microservices - Riusabilità Applicativomonolitico A Lib A Lib B Lib C Applicativo monolitico B Lib A Lib B Lib C Lib A Lib B Lib C Sorgenti μS A μS B μS C μS Main A μS Main B
  • 11.
    Microservices - Scalabilità μSA μS B μS C μS Main Applicativo monolitico Lib A Lib B Lib C Applicativo monolitico Lib A Lib B Lib CApplicativo monolitico Lib A Lib B Lib C μS B μS C μS Main μS B μS B
  • 12.
    Microservices - Deployment μSA μS B μS C μS Main Applicativo monolitico Lib A Lib B Lib C
  • 13.
    Microservices Resistenza agli errori Applicativomonolitico Lib A Lib B Lib C μS A μS B μS C μS Main μS C'
  • 14.
    Microservices - Monitoring Applicativomonolitico Lib A Lib B Lib C μS A μS B μS C μS Main LOG Logger
  • 15.
    I microservizi comesoluzione Sorgenti di dati MICROSERVIZI MICROSERVIZI API Applicativi
  • 16.
    Jolie Java Orchestration LanguageInterpreter Engine, nasce come alternativa al linguaggi di orchestrazione per web service WS-BPEL ● Semplificandone la gestione ● Non richiede la presenza di motori di esecuzione dedicati ● La definizione non è definita mediante xml ma è scritta in linguaggio nativo eseguito dall’interprete ● Estendendone le funzionalità ● Possibilità di integrare logica applicativa Java ● Possibilità di utilizzare il linguaggio per implementare microservizi ● Orchestrazione di Web Service Soap, Rest, Jolie
  • 17.
    Perché un linguaggio? ANNO2016 Ho comprato uno smartphone nuovo con sistema operativo Android e connessione ad internet
  • 18.
    Perché un linguaggio? ANNO1800? Ho comprato uno smartphone nuovo con sistema operativo Android e connessione ad internet
  • 19.
    Perché un linguaggio? ANNO1800? Ho acquistato un oggetto grande quanto un libro di piccole dimensioni la cui copertina straordinariamente lucida e variopinta è in grado di mostrare immagini così ben definite da apparire quasi rappresentazioni della realtà, ma questo è nulla poiché è sufficiente sfiorare tale oggetto con un dito per innescare un meccanismo quasi diabolico in grado di fare udire la mia voce ad una persona all'altro capo del mondo in tempo reale così che io possa comunicare con lei una volta acquisito un numero che mi permette di riconoscerla tra tutti. L'oggetto è nuovo con sistema operativo Android e connessione ad internet
  • 20.
    Il linguaggio faguadagnare TEMPO e SPAZIO oggetto grande quanto un libro di piccole dimensioni la cui copertina straordinariamente lucida e variopinta è in grado di mostrare immagini così ben definite da apparire quasi rappresentazioni della realtà, ma questo è nulla poiché è sufficiente sfiorare tale oggetto con un dito per innescare un meccanismo quasi diabolico in grado di fare udire la mia voce ad una persona all'altro capo del mondo in tempo reale così che io possa comunicare con lei una volta acquisito un numero che mi permette di riconoscerla tra tutti. smartphone
  • 21.
    Il linguaggi diprogrammazione 01010100010100010010 01001001010001010000 10100100100101001010 10100101001001010010 01010100010100010010 01001001010001010000 10100100100101001010 10100101001001010010 01010100010100010010 01001001010001010000 10100100100101001010 10100101001001010010 01010100010100010010 01001001010001010000 10100100100101001010 10100101001001010010 01010100010100010010 01001001010001010000 MACCHINA ORG 2050H MOV DPTR,#CNT MOV A,#INIT MOVX @DPTR,A MOV SP,#2FH CLR RS0 CLR RS1 ACALL SERIAL MOV DPTR,#HEADING ACALL STRING ORG 2050H MOV DPTR,#CNT MOV A,#INIT MOVX @DPTR,A MOV SP,#2FH CLR RS0 ASSEMBLER C MENO ERRORI UMANI int main() { int n, sum = 0, c, value; printf("Enter the number of integers "); scanf("%d", &n); printf("Enter %d integersn",n); for (c = 1; c <= n; c++) { scanf("%d",&value); sum = sum + value; } printf("Sum of entered integers = %dn",sum); return 0; }
  • 22.
    Un vantaggio concreto ●Il primo compilatore completo fu creato dall'equippe di John. W. Backus presso i laboratori IBM nel 1957. Era un compilatore FORTRAN. Ci vollero ben ● 18 anni uomo per realizzarlo. ● Al tempo non era stata ancora sviluppata la teoria dei linguaggi. ● Oggi in molte università, viene data la creazione di un compilatore come esercizio d'esame. John. W. Backus
  • 23.
    I tre vantaggicompetitivi di Jolie 1)1) ParadigmaticitàParadigmaticità:: il programmatore scrive e pensa direttamente a microservizi. 2)2) Autosufficienza:Autosufficienza: non sono necessari tool aggiuntivinon sono necessari tool aggiuntivi per la messa in esecuzione di un microservizio Jolieper la messa in esecuzione di un microservizio Jolie 3)3) Indipendenza:Indipendenza: un microservizio jolie non è legato aun microservizio jolie non è legato a nessun protocollo di comunicazione in particolarenessun protocollo di comunicazione in particolare
  • 24.
    Paradigmaticità Il programmatore programmae progetta l'architettura a microservizi in unico passaggio poiché il linguaggio fornisce tutti gli strumenti base per la creazione e manipolazione dei microservizi. Conseguenza importante: durante la programmazione il programmatore si disinteressa di come dovranno essere eseguiti i microservizi
  • 25.
  • 26.
  • 27.
  • 28.
    Autosufficienza Un servizio Jolienecessita solamente di una Java Virtual Machine per funzionare Non sono necessari framework aggiuntivi per il suo funzionamento No application server, No web server
  • 29.
    Importazione di codiceLegacy Legacy Code
  • 30.
  • 31.
    L'interdipendenza tra linguaggie supporti Memorie meccaniche 0101010 1940 Assembler 1954Memorie elettroniche Memorie TTL 1973 C Multi piattaforma Cloud 2010 1991 Java IoT 2030
  • 32.
    Le due vieai microservizi Programmazione: dal punto di vista della programmazione la sfida è quella di trovare nuovi linguaggi in grado di catturarne l'essenza. Linguaggio è la parola chiave. Diciamo che questa via segue il paradigma linguistico Sistemi: dal punto di vista dei sistemi, i microservizi possono essere visti come applicazioni indipendenti in grado di servire più richieste. Sono eseguiti all'interno di artefatti chiamati containers. Container é la parola chiave. Diciamo che questa via segue il paradigma sistemistico.
  • 33.
    Paradigma Sistemistico vs Paradigma Lingustico Ilparadigma linguistico si basa sull'idea che i principi fondazionali della programmazione a microservizi possano essere condensato in un unico linguaggio. Non è importante come venga eseguito un microservizio, la cosa importante è che ogni singola unità programmabile sia un microservizio. Il paradigma sistemistico, è basato sui contaner e parte dall'idea che: Non è importante come un microservizio è realizzato, la cosa più importante è che il microservizio sia eseguito all'interno di un container che può essere spostato, rimpiazzato o scalato.
  • 34.
    Catena produttiva delsoftware DESIGN Paradigma sistemistico Paradigma linguistico DEVELOPMENT PACKAGING DEPLOYMENT Il progettista pensa a microservizi Il progettista pensa a microservizi Lo sviluppatore programma seguendo un altro paradigma (oggetti, funzionale, ecc) Il programmatore sviluppa direttamente a microservizi Lo sviluppatore trasforma il suo artefatto software in un microservizio Utilizzando tool e framework aggiuntivi Lo sviluppatore esegue il microservizio in un container Lo sviluppatore può eseguire il microservizio in un container (non necessario)
  • 35.
    I confini diun microservizio Paradigma Sistemistico Paradigma Lingustico Un microservizio può essere il risultato della composizione di altri microservizi Un microservizio è un artefatto software sviluppato con un dato insieme di tecnologie ed impachettato all'interno di un container I microservizi sono atomici All'interno di un microservizio possono esserci altri microservizi
  • 36.
    L'architettura Paradigma Sistemistico Paradigmalinguistico Un'architettura a microservizi è una rete di containers Un'architettura a microservizi è una composizione di microservizi
  • 37.
    L'architettura Paradigma Sistemistico ParadigmaLinguistico A microservice can be easily moved from inside to outside of a container (and vice versa) In order to bring an internal component out of a microservice, a specific programming task must be carried out X
  • 38.
    Containers Paradigma Sistemistico ParadigmaLinguistico Il container è solamente uno strumento che per l'esecuzione Il Container è l'elemento chiave dell'archtettura
  • 39.
    Vantaggi Paradigma Sistemistico Linguisticparadigm Indipendenza dalla Tecnologia Le architetture possono cambiare in modo semplice ricomponendo i microservizi Esecuzione semplice e scalabile La progettazione a microservizi si traduce immediatamente in programmazione nativa Compatibile con lo stack del Cloud Computing Compatibile con il paradigma sistemistico
  • 40.
    La rivoluzione dei microservizi ParadigmaLinguistico La rivoluzione si trova nell'intersezione tra questi due mondi Paradigma sistemistico
  • 41.
    Un sistema softwarecomplesso non è mai un'entità statica ma è soggetto a continue modifiche per potersi adattare agli stimoli esterni... come il pensiero umano