[Musica]
Grazie e grazie mille per essere venuti
a questo discorso viaggio microservices da
una prospettiva di avvio così quando tu
di solito ascolto e leggi sul successo
storie su micro servizi di solito
senti parlare dei grandi attori del settore
introdotto i micro servizi con successo
come Netflix Amazon eBay e solo per
citarne alcuni e se li guardi
storie di successo che potresti finire per dire
oh, è come quello che ci ha funzionato
applica anche a noi , copiamo solo quello
ma il problema è che ti manca uno
il punto è che ogni viaggio in micro
i servizi sono diversi in ogni
organizzazione uno dei motivi è quello
le circostanze per ogni organizzazione
sono così tanti che mai consenso
effetto nel tuo viaggio così uno dei
le circostanze potrebbero essere dall’altra parte
la struttura del team e le competenze all’interno
in termini di dimensioni che hanno un impatto diretto
i tuoi micro servizi viaggiano così
processo di trasformazione in sé non lo è
funzionamento in isolamento, per esempio se
sei una piccola squadra con pochissimo
Le pratiche DevOps in atto hanno un enorme
impatto sul processo di trasformazione
velocità e se anche tu prendi in
considerazione che devi ancora correre
un sistema legacy ancora necessario
mantenilo devi ancora aver cura
di esso e anche questo sta facendo attenzione
del tuo sistema legacy riduce il tempo
questo è disponibile per una trasformazione
processo e anche ciò che sta influenzando il tuo
il viaggio è anche l’ambiente di runtime
stai correndo su Prem o sei tu
in esecuzione su cloud native così puoi contare
su servizi gestiti ad esempio un API
gateway o devi configurazione
tutto da zero e mantenere e
monitorare tutto e anche quello che è molto
importante è la tua strategia sei tu
costretto a implementare nuove funzionalità in a
periodo di tempo molto breve e se lo sei
molto molto lottato con questo ma se
hai un periodo di tempo molto breve e
potresti lottare con dove
implementare il nuovo servizio devo metterlo
come nuovo servizio o devo aggiungerlo a
i monitor e l’alimentazione del monitor
di nuovo invece di restringerlo così da dare
sei un po ‘di storia
Sono Donna Kaiser che ero il CTO
solo del software che è una start-up in
Amburgo e soffri solo noi
sviluppando solo social che è un digitale
luogo di lavoro che fornisce app di collaborazione
per le tue squadre di comunicare e
collaborare con in team nel tuo
organizzazione e molto tempo fa quando noi
iniziato nel 2010 tutto era e
monitor in ogni aspetto, quindi ne abbiamo avuto uno
squadra che lavora su una collaborazione
prodotto e implementato come una base di codice
basato su uno stack tecnologico quindi dopo a
tempo tutto stava crescendo così una squadra
diventato più grande abbiamo aggiunto sempre di più
caratteristiche il nostro utente è aumentato e il
codebase ottenuto più grande e più grande che è
dovrebbe essere fantastico ma quello noi
aveva un problema che tutto era
sentirsi un po ‘ goffo perché
tutto era legato insieme così sul
un lato è che il fatto è questo
abbiamo aggiunto caratteristiche sempre più le
la cosa è che dovevamo rilasciare questi
cambia rapidamente e il problema era questo
bene perché il nostro team stava diventando più grande
e più grandi le decisioni e le discussioni
e le riunioni hanno richiesto più tempo di prima e
che abbiamo anche avuto non hanno davvero
responsabilità ben definite per
esempio quando è arrivato un Mac di backup chi è
prendersi cura di esso era una squadra così il
i processi stavano rallentando e il nostro
la produttività sofferto e grazie alla
fatto che stavamo aggiungendo sempre di più
caratteristiche l’usabilità è diventata più e
più complesso l’ usabilità e l’utente
esperienza sofferta attraverso continua
modifica delle caratteristiche e invece di
risolvere i problemi dei nostri utenti molto facilmente
ci stavamo sempre più confondendo e
a causa del fatto della natura di a
monolite non è stato molto facile per noi
rilasciare rapidamente le modifiche perché ogni volta
vorresti aggiungere qualcosa che hai
ricostruire e ridistribuire l’intera nave
anche l’intera nave madre
se hai solo una sola riga di
codice che hai cambiato così e questo
ha comportato distribuzioni ad alto rischio e
che è successo a meno che frequentemente così il tuo
nuove uscite rilasciate nuove modifiche
molte delle nuove funzionalità vengono rilasciate molto lentamente
così più di due anni fa e il nostro
la visione del prodotto è cambiata e lo eravamo
concentrandosi su usabilità e utente
sperimentare miglioramenti quindi ci siamo divisi
la nostra unica app per la collaborazione in separato
app di collaborazione che contengono ciascuno
ognuno di loro si sta prendendo cura di
caso d’uso specifico sono prendersi cura di uno
problema e risolvere questo problema molto bene
quindi avevamo un’app di collaborazione per
scambiare documenti per comunicare
in tempo reale per la gestione dei tuoi compiti e
anche distribuendo e condividendo corporate
notizie e pagine di contenuti in tutto il tuo
organizzazione e subito dopo questo o
probabilmente per lo più nel frattempo anche noi
dividere la nostra squadra in più
squadre più piccole e assegnate a ciascuno di
quelle squadre un insieme specifico di
app di collaborazione per abilitare quelle squadre
lavorare con responsabilità ben definite
e per consentire loro di lavorare in modo diverso
parti del software erano indipendenti
impatto minimo tra le squadre e così via
come ragionevole il prossimo passo originale
è anche quello di reagire riflettere questa autonomia
e anche flessibile anche la flessibilità
ora un sé per l’architettura e da
dividendo introducendo microservizi
per guadagnare anche tana significa il nostro software
architettura e quindi la motivazione
per noi da servizi di micro interinale è stato
per consentire a team autonomi di lavorare a
diverse parti del software
indipendentemente alla loro velocità a
il loro ritmo con un impatto minimo
attraverso altre squadre e sviluppare e
distribuire le app di collaborazione
indipendentemente e anche scalare se
più efficacemente così che alla fine noi
può rilasciare le modifiche rapidamente
così quando inizi quando hai deciso
per iniziare questo viaggio verso i micro-servizi
la prima cosa è che devi
identificare buoni candidati per micro
servizi e modellare buoni candidati
uno dei concetti chiave e quello che un buon
i servizi è seguire alcune chiavi
principi e principi chiave per
la modellazione di buoni servizi segue l’alto
coesione nel servizio e libera
accoppiamento tra tali servizi e
di solito nel design guidato dal dominio alto
la coesione all’interno di un servizio è di solito
riflesso dal comportamento correlato che
rimarrà coerente e così limitata
contesto stesso è un confine semantico
attorno a un modello di dominio in cui il modello di dominio
vive dentro e descrivono servizi che
sono responsabili per ben definito
funzione aziendale così per noi nel nostro caso
abbiamo identificato la nostra app di collaborazione come
i candidati perfetti per alto livello
contesto limitato a grana grossa che noi
può usare come nostro come punto di partenza per
il nostro viaggio di decomposizione e poi da
partendo da questo livello elevato a più fine
quelli più grossi in seguito, quindi abbiamo iniziato con
il solo con guida è il
app di collaborazione per prendersi cura di
condividere documenti all’interno del tuo
team e ogni documento stesso
creato da un autore e dai dati dell’autore
stesso è derivato dai dati del profilo
ei dati profilo è derivante dall’attuale
un altro contesto limitato che ancora
risiede nel monolite così abbiamo iniziato
estraendo il contesto limitato di just
guida della nostra app per la collaborazione documentale
come un servizio coesistente da zero e
abbiamo modellato il contesto limitato composto
del suo modello di dominio e prendersi cura di
il riflettere la logica del business ma
anche il servizio di applicazione prendendo
orchestrare casi d’uso e gestire
transazioni e anche l’ input
adattato di questo tuo del tuo limitato
contesto per esempio abbiamo le API di riposo
e tu sei la gestione persistente al
dall’altra parte e questo nuovo servizio allora
possiede lo stato del documento esclusivamente così
questo è l’ unico che Campos ha letto
da un lato ma anche modificarlo e
come accennato prima abbiamo avuto questo autore
dati che sono correlati a un documento che
vorremmo riflettere anche nel nostro nuovo
anche il servizio di notizie e l’autore
i dati provengono dal giorno dei profili
dal contesto delimitato del profilo che
risiede ancora nel monolite ed è
questo il modulo stesso possiede il
profilo Stati esclusivamente sul
sito monolito così e per evitare quando noi
sto visualizzando un documento a cui sono andato
evitare di richiedere la data del profilo o il
autore dati irrilevanti ogni volta quando
mostriamo un documento che abbiamo implementato noi
implementato un evento evento guidato
approccio così abbiamo la cosa è che abbiamo mantenuto
una copia locale dei dati rilevanti dell’autore
in noi stessi e da mantenere
questa copia locale e cosa abbiamo chiesto
il monolito ci stava notificando
sugli eventi di aggiornamento del profilo
quindi ogni volta che un profilo è stato aggiornato
stava pubblicando il monolite
pubblicare l’evento aggiornato del profilo su
un broker di messaggi che il nostro nuovo servizio
iscriversi a e quando l’evento ha avuto
la Concordata ricevuta era consumata
aggiornando la copia locale di conseguenza
quello che devo dire a questa cosa è a
questo stadio è che la coesistenza sta andando
di nuovo un po ‘in modo che la coesistenza
servizio che abbiamo stabilito noi
non un equivalente esatto del del
quello corrente invece anche noi
e intrecciato in questa trasformazione
processo e l’interfaccia utente che abbiamo aggiunto
nuove funzionalità e abbiamo anche fatto significativi
aggiustamenti alla struttura dati stessa
così e che stava causando ci turba in modo
di solito il servizio coesistente da
il graffio è in generale un buon approccio a
approccio alla decomposizione in particolare
se vuoi allontanarti
qualcosa se vuoi andartene
dalla tua attuale logica di business, se tu
vorrebbe allontanarsi dal tuo testo
pila per esempio ma cosa nel nostro caso
era il problema è che noi che noi
Metti un sacco di cose nuove a questo
processo di trasformazione e pure
quindi abbiamo fatto troppi passaggi come uno
soprattutto all’inizio non è stato
ottimale per iniziare perché nel
iniziando se non lo sei se lo sei
iniziando senza esperienza in questo
il mondo dei micro-servizi mentre in questo
il mondo dei micro-servizi l’unica cosa che
devi concentrarti su ciò che arrivi presto
risultati e ottenere risultati veloci in particolare
in principio perché si deve
acquisire esperienza in quel campo molto presto
così in era questo approccio un coesistente
servizio da zero e aggiungendo in cima
diverse molte altre sfide come
non era stato non era ottimale per noi
quindi con il prossimo contesto limitato che
era un’app di chat che abbiamo seguito in modo diverso
approccio che volevamo ottenere prima
risultati così abbiamo seguito la decomposizione
approccio di decomposizione in modo incrementale
dall’alto verso il basso quindi abbiamo iniziato a
estrai l’interfaccia utente come
app web separata e fornita un’API REST
sul monolite che la nuova app web
potrebbe affrontare e questo ci ha permesso di
sviluppare l’interfaccia utente in modo indipendente
e iterare sull’interfaccia utente
rapidamente così il passo successivo fu che noi
spostato la logica aziendale al nuovo
servizio
e la distruttiva logica commerciale sta causando
cambiamenti significativi del codice e in alcuni
i casi erano quindi dipende dal
dipendenze dovevamo anche fornire un
API per i monitor che i monitor
può quindi utilizzare la nostra attività estratta
logica anche a questo punto che avevamo ancora
la stessa archiviazione dei dati e lo eravamo
indirizzando la stessa archiviazione dei dati del
monolito a questo punto e – ancora a
raggiungere e disaccoppiare indipendente
servizio dovevamo spostare questi dati
Anche l’archiviazione è stata l’ultima
passo del nostro top-down incrementale
approccio di decomposizione così e quando noi
spostato l’archiviazione dei dati sul nuovo
servizio dovevamo riflettere il
circostanza che anche in questo caso ciascuno
Era anche la discussione di Chet
creato da una chat che ha avuto partecipanti
il Chet era era stato creato entrambi
attraverso questo partecipanti condivisi e
era anche questo datore partecipante a Chet
streaming dai dati del profilo che
era ancora risiede in più Ellis
stesso e abbiamo anche implementato qui il
principio di trasferimento di stato basato sugli eventi a
tenga molta copia locale alle nostre notizie
servizio e ottenere aggiornato ogni volta che a
il profilo è stato aggiornato sul monolite
così um quando hai più candidati
per i micro servizi una delle sfide
è per – condividere – per dare la priorità al tuo
il tuo prossimo candidato e cosa cosa veramente
funzionerebbe meglio se tu avessi come noi
ha fatto decomporre la nostra app di guida e
il primo inizio quello che veramente
funziona bene se si mantiene questo candidato
molto piccolo all’inizio, quindi se
questo ha pochissima dipendenza quindi se
è molto facile da estrarre perché cosa
ne esci è che arrivi presto
risultati e ti sei guadagnato presto
sperimenta i micro servizi
sì, ma era anche una decomposizione
processo in generale e anche la tua squadra
guadagni guadagnato la fiducia da ottenere in anticipo
esperienza come microservizi e poi tu
può anche andare avanti con il prossimo
concentrarsi su quei servizi che genera
il più grande vantaggio dopo l’estrazione così
uno dei vantaggi potrebbe essere quello se
hai un servizio che cambia molto
spesso è ottenuto un buon candidato per
concentrarsi su successivo perché dopo l’estrazione
hai la possibilità di distribuire il
il cambiamento è molto spesso molto rapidamente o tu
può anche concentrarsi su quei servizi che
richiedono diversi consumi di risorse
per esempio se hai un servizio
richiede più memoria di altri che puoi
distribuirlo su istanze con alto più alto
potere di memoria così per il nostro esempio che abbiamo avuto
un servizio che stava generando un documento
anteprime di cui avevano bisogno diverso
risorsa e in termini di CPU CPU così noi
dopo l’ estrazione potremmo schierare
quei servizi su istanze con con
più alto era più potenza della CPU stessa e così via
con ogni era ogni servizio che noi
estratto ci siamo confrontati con a
domanda o con la maggior parte del servizio
che avevamo estratto ci siamo confrontati
con la domanda su come gestire
preoccupazioni trasversali in questo
caso specifico come gestire
autorizzazione e darti un po ‘
contesto il nostro modello di autorizzazione è molto
a grana molto fine al livello dell’oggetto
quindi ad esempio in Drive puoi farlo
controllare l’autorizzazione di un documento
impostando l’autorizzazione del suo
cartella condivisa principale ma che aumenta
la complessità della nostra autorizzazione
il modello è che è anche nel servizio
dipendenti, quindi si basa anche sul
impostazioni di dati di autorizzazione che
risiede in un servizio diverso così e
questo era per esempio per
esempio se aggiungi documenti a a
Pagina di contenuto e diritto di accesso di
questo documento sono controllati dal
impostazioni di autorizzazione di questo contenuto
pagina e le celle del documento stanno recitando
in un servizio diverso così era
causandoci un sacco di mal di testa e di aver avuto
per gestire l’autorizzazione e cosa come a
il risultato è stato che non abbiamo risolto il problema
preoccupazione per l’ autorizzazione del paese di origine
fin dall’inizio e abbiamo detto che eravamo
rinviato va bene troviamo una soluzione
più tardi troviamo una soluzione più tardi ma cosa
beh le conseguenze erano molto molto
controproducente perché da quando abbiamo
non ha davvero fornito una distribuzione
gestione delle autorizzazioni come uno
conseguenza è stato che abbiamo implementato il
autorizzazione abbiamo aggiunto il servizio
servizio stesso che abbiamo identificato
a quella zona dove l’autorizzazione ha
già risolto e quello era il
monolite quindi abbiamo finito per alimentare il
ancora monolito e quello era l’obiettivo
per restringere Yamada e siamo stati molto
controproducente e di conseguenza
e l’altra parte era che eravamo noi
reinterpretato implementando il
autorizzazione per il livello di servizio e il
la cosa è di solito a prima vista tu
assumerebbe o anche i nostri primi
l’ipotesi era che l’autorizzazione stessa
si riferisce al modello di dominio ma a causa di
le dipendenze tra servizi che io
ho descritto in precedenza
è una preoccupazione trasversale e il
La cosa è che quando lo intendevamo davvero
per servizio che abbiamo duplicato che sono
la logica in sé, ma anche noi eravamo
spostando i dati avanti e indietro e ha avuto
introdotto il rischio di collisione così
anche questo era molto controproducente
per fare un breve una lunga storia breve siamo
ha fuso l’ autorizzazione in a
servizio centralizzato come cross-cutting
preoccupazione e fusione di un sistema decentralizzato
anche l’approccio in uno è molto molto
richiede molto tempo e la cosa è
evitare di alimentare il monolite o
reimplementare una preoccupazione trasversale
con ogni nuovo servizio che tu
introdurre
gestire le preoccupazioni trasversali molto
presto così se aveste avuto un
prima soluzione non avremmo eseguito
in questi problemi così e il prossimo
sfida quando si presenta in particolare
quando si introduce un servizio centralizzato
è evitare di introdurre un più distribuito
o meno così per esempio quando tu quando
apportare modifiche a un lato e è necessario
cambia l’ altro lato allo stesso tempo
e puoi ridistribuirli insieme a
forte indicatore che hai
ha introdotto un modello distribuito è e così
così ad esempio quando aggiungiamo un
nuovo servizio o quando si presenta
voi stessi o quando si apporta una modifica al
il tuo nuovo servizio e la tua autorizzazione
il servizio deve essere aggiornato allo stesso
tempo quindi stai combinando entrambi
svantaggi di entrambi i mondi come te
avere un sistema di accoppiamento stretto ma loro
stanno ora comunicando tramite la rete
e una cosa come evitare una distribuzione
il modello è è quello di stabilire una stabile
contratto a contratto comune che il
il servizio di autorizzazione centralizzato è proprietario
e che tutti gli altri consumano
servizi sono i nostri servizi a valle sono
devi tradurre devi conformarti a
così ogni volta che un servizio su quello
il lato richiede autorizzazione correlata
azioni lo traduce in questo
contratto comune e può essere gestito su
il servizio di autorizzazione di asura senza
traduzione extra extra stessa e
altro prerequisito per questo è
che questo contratto comune è stabile così
l’altro in modo da non doverlo fare
aggiornare tutti i servizi che sono
traducendo in questo contratto ogni
tempo in cui apporti una modifica o a
rompere il cambiamento in modo che anche il
servizio di autorizzazione quindi
i server di autorizzazione devono chiarire
che questo deve seguire il
principi di una stalla
e il contratto era ciò che non lo era
cambia così tanto spesso e così e quando
tu introduci micro-servizi come te
devono prendersi cura del servizio
interazione come I nell’esempio precedente
Mi è stata data l’ interazione guidata dagli eventi
stile
Stavo prescrivendo quello in cui tu
avere servizi che non comunicano
direttamente tra loro ma invece
stanno pubblicando eventi su un messaggio
broker o sottoscrizione di eventi da
da questo broker di messaggi al fine di
capovolgere il controllo di flusso al
ricevendo fine e per rendere questo il
i servizi stessi autonomi e
disaccoppiati e altri stili di interazione
l’approccio guidato dalle richieste in cui uno
il servizio chiama un altro servizio
direttamente sulla sua API e dove il flusso
il controllo della comunicazione è
per lo più controllato dal mittente stesso
ma dove i servizi sono più legati
insieme o puoi anche combinarli
modelli e modelli in un modello ibrido
dove combini la domanda e
modello basato sugli eventi insieme un altro
sfida quando si introduce micro
i servizi è la domanda su come gestire
dati condivisi e come ho menzionato prima in
il modello di interazione il modello ibrido
può essere può essere usato come una soluzione
dove tu comunità dove i tuoi servizi
stanno comunicando sugli eventi ma solo
per scopi di notifica, quindi quando uno
il servizio richiede dati aggiuntivi da
un altro contesto a cui fa una chiamata diretta
una chiamata cross-context remota direttamente a
la fonte con l’era un aspetto negativo che
stai unendo questi due servizi
insieme così, ma si potrebbe desiderare di andare per
la semplicità invece di
come il mantenimento dei dati detto a livello locale
soprattutto quando questo set di dati sta crescendo
per esempio quando vai al prossimo
modella il trasferimento di soggiorno guidato da eventi
mantieni la coppia locale fuori dai tuoi dati e
lì usi non divisioni non solo per
scopi di notifica ma anche per i dati
domanda per i tuoi vari dati
trasferirsi da solo uno dei lati negativi
di questo è che devi mantenere
il set di dati a livello locale e questo set di dati
questa stessa copia locale potrebbe crescere
molto veloce nel tempo e un altro dato
aspetto correlato che devi considerare
è la fonte della verità, quindi di solito in a
sei un sistema tradizionale basato sugli eventi
di solito ascoltando eventi e salvando
le tue azioni in un database e tu sei
emettendo anche nuovi eventi così e per
il tuo servizio interno per te
servizio stesso la fonte interna di
la verità è il tuo database ma tu tutti i tuoi
i servizi a valle sono per loro il
fonte della verità è il è il
mediatore di messaggi stesso per l’ evento così
abbiamo conservato e il fatto è che tu
avere in questo viene la complessità di
doppio scrive che scrivi nel database
ma anche al broker di messaggi e anche
l’altra complessità è che i dati
modello tra il database stesso e
anche il formato dell’evento potrebbe divergere
tempo quindi devi considerare di essere
consapevole della divergenza tra entrambi
mondi così come un’alternativa
approccio provvisorio è quello di unire quelli
rami in un unico negozio di eventi e
dove gli eventi sono considerati come primi
classe di prima classe i cittadini e sono i
fonte primaria dei tuoi servizi così dentro
questo caso i servizi si stanno indirizzando
la stessa fonte della stessa fonte per
i dati sono un’unica fonte di verità e in
in questo contesto entra in gioco Kafka
così Kafka è che è un distribuita scalabile
servizio di blocco commit tollerante ai guasti che
è stato originariamente creato da sviluppato da
Ellington e combina il
funzionalità di un sistema di messaggistica
Sistema Darsh e anche in streaming
piattaforma così nel nostro caso che abbiamo
ha presentato Kafka molto presto ma
principalmente principalmente all’inizio per
notifica e duplicazione dei dati
dove sono i casi principali che abbiamo
usato Kafka per così ma ultimamente abbiamo
ha introdotto anche i flussi di Kafka e
cercando di fare esperienza con
Anche Kafka scorre e così Kafka
i flussi o i flussi in generale sono un
Sequenza ordinata illimitata di strutturato
record di dati e sono definiti come chiave
coppie di valori che sono continuamente
aggiornato e quando lavori con Kafka
gli stream sono quando crei uno stream in
il tuo servizio si carica all’avvio del tuo
servizio un intero argomento Kafka nel tuo
lo streaming di un argomento di Kafka è logico
categoria in cui si produce
i servizi pubblicano eventi o il
i servizi di consumo sono abbonati a
per esempio il contesto delimitato dal profilo
ha un argomento di copia del profilo o il documento
servizio si basa su un profitto nel
servizi documentali liberato di accesso
il traffico del documento stesso così e
il flusso stesso è memorizzato nel buffer in a
negozio di stato che è un peso leggero
database di stato incorporato che è questo
in base al tuo servizio e quindi all’argomento
stesso è caricato nel tuo stream e
può essere elaborato nell’ambito del tuo
proprio servizio e la cosa è che il
il flusso stesso non è in esecuzione sul
broker è in esecuzione nello stesso processo
come il tuo micro servizio così i flussi
rendere i dati disponibili ovunque si trovino
e non devi fare un po ‘di telecomando
le chiamate che devono accettare per esempio,
il broker dei messaggi remoti così in Kafka
il flusso delle telecamere della morte di Kafka era un flusso
API e dove puoi unirti al gruppo di filtri
e aggregati e così via
loro stessi ed elaborarli nell’ambito
del tuo servizio e puoi anche elaborare
ogni messaggio alla volta per funzione come
operazioni come map peek transform e
così via e quando si implementa il flusso
l’elaborazione di ciò che di solito serve è a
stream stesso ma anche un database per
arricchimenti e l’API del flusso di Kafka
fornisce quelle funzionalità di
astrazione di flussi astratti e
tabelle in modo che un flusso stesso sia un cambiamento
blocco di una tabella che cattura i record di dati
come cambiamenti di stato del tavolo stesso e
la tabella è un’istantanea dell’ultima
valore per ogni chiave nel flusso in modo che
sono molto molto legati tra loro
hai una connessione molto forte e tu
può trasformare un flusso in una tabella e
una tabella in un flusso così e questo flusso
la dualità della tabella può essere usata molto
potente nei tuoi microservizi
anche l’architettura, quindi abbiamo iniziato a utilizzare
kafka si lancia da solo introducendo
viste materializzate così nel precedente
ad esempio quando stavo parlando
la visualizzazione dei documenti era anche rilevante
dati negli stream di kafka, esempio noi
potrebbe fare seguendo possiamo creare un
uscire dall’argomento del documento e
caricarlo nel tuo servizio e l’autore
dati pertinenti stessa possono essere caricati da
l’ argomento del profilo come tabella
arricchimento e possiamo filtrare quelli che
possono unirsi a quelli che insieme
stream the
mainstream e la tabella profilo può farlo
essere uniti e essere memorizzati come a
portare a un nuovo negozio di stato che è
quindi accessibile dall’esterno come un
vista materializzata integrata e questo è
quindi sempre aggiornato automaticamente
aggiornato ogni volta che un nuovo documento è stato
aggiunto per esempio o quando il profilo
i dati sono stati modificati in modo da confrontare
quei meccanismi guidati dagli eventi è questo
era con Kafka streaming sei
eliminando la copia locale quindi non lo fai
deve avere questa l’ applicazione permettersi
mantenendo una copia locale e vedendo ogni volta
ad esempio un’app di profilo che è stata
ha assicurato e così e spinge anche il
debito con i dati a dove è necessario
spinge al tuo servizio stesso così tu
non c’è bisogno di voi tipo di subito
attraverso l’ API di tre flussi senza
chiamate remote e questo aumenta
applicabilità per esempio quando tu
introdurre un nuovo servizio che puoi semplicemente
collegalo al tuo sistema di streaming
se stesso ed era fuori per esempio se lo sei
non può fare affidamento sui propri dati
i dati del flusso subito così in generale
abbassa la barriera all’ingresso per te
per il tuo nuovo servizio stesso e alla ricerca
ora da lui il senno di poi è come quello che abbiamo
imparato fino ad ora sta iniziando piccolo e
focalizzato su quelli che sono facili da fare
estrai nel primissimo inizio
è molto molto utile perché e
anche fare un passo alla volta uno
manovra passo passo alla volta e
perché se metti troppo carico sul tuo
le spalle proprio all’inizio
non ottenere risultati precoci e non lo sei
guadagnando davvero fiducia e maneggiando
microservizi ed è davvero frustrante
se non puoi se hai molto tardi
esperienza con quelle ore e fino a tardi
risultati e un altro è da evitare
alimentazione nuovamente e ai monitor
problemi di reimplementazione per servizio
livello sicuramente gestire il tuo
preoccupazioni trasversali molto presto a
evitare tutti questi problemi che abbiamo corso
dentro e al momento della fornitura centralizzata
servizio di evitare un modello distribuito è di
introducendo un contratto comune che è
stabile per te
per i tuoi servizi downstream e e
progetta il tuo sistema per essere facile
evolvete il design e guidate da eventi da raggiungere
alto disaccoppiamento e autonomia tra
i tuoi servizi e anche io lo farei
sicuramente considerare di nuovo stream come il
fonte condivisa di verità un buon tentativo come
bene e tornare a quello che ho
menzionato all’inizio essere a conoscenza di
le tue circostanze quindi non è il tuo
processo di trasformazione non è in esecuzione
in isolamento e per esempio se lo hai
per abbinare una timeline molto marcata e fare
il suo processo di trasformazione in parallelo
causa molte frustrazioni per entrambi
lati e tenere presente che ogni
il viaggio è diverso e il nostro viaggio
potrebbe essere totalmente diverso dal tuo
Grazie per l’attenzione
[Applausi]
grazie, innanzitutto, non dimenticare
votare è probabilmente la ventesima volta
è stato detto che ce ne sono alcuni
domande poste attraverso l’app
se avete domande ora ci proverò
per rinfrescare abbiamo un paio di minuti a sinistra
quindi ero una domanda riguarda il
maturità della società o del
squadra che hai intrapreso questo viaggio
con così come quanto sia stata esperta la squadra
e quanto era grande la squadra che tu
preso insieme in questo viaggio quindi siamo stati
l’unica squadra era di 13 persone e lo sono
per lo più senior in full stack
esperienza e persone anziane e in quello
campo ma era molto piccolo DevOps
pratiche in atto così che è anche uno
cosa che posso anche affrontare è quella
specialmente quando devi quando sei
correre su Prem, ad esempio, è così
anche uno spostamento verso una cultura DevOps
e devi considerare anche questo
rifletti anche nella tua squadra
in termini di specialmente se abbiamo un
piccola squadra quindi abbiamo avuto una grande scena e
spacco in tre diversi e
ma ciò che è molto importante è anche
che tu abbia per esempio una task force
all’inizio gestendo il monitoraggio
logging distribuito tutto questo
complessità operativa e che no
ogni squadra stessa sta cercando di risolvere a
lettura bilanciata ne fornisce alcuni
meccanismi che ogni squadra può quindi
riutilizzare e sono nei servizi noi
avere una domanda dal vivo Suzanne grazie
per l’equazione di presentazione ci sei
sapere costruire lo stato condiviso di
il flusso degli eventi è una bella idea
insieme ma conosci il tempo di avvio
dell’applicazione del contenitore
dipende molto dalla quantità di dati
che esiste questo flusso di eventi
alcuni miliardi di eventi che deve essere
caricato durante l’ora di inizio e
fondamentalmente alcuni di loro in realtà devono
essere cancellato perché è come lo sai
aggiornamenti spesso sono solo ridondanti
quale dovrebbe essere il suggerimento che piace
dovresti fornire aggiornamenti completi
lì all’interno del flusso di eventi o simili
qual è la tua esperienza con quella così
sì, non siamo che non sei Netflix
è necessario elaborare 1 trilione
messaggi al giorno ne abbiamo un po ‘meno ma
quello che c’è una sfida è quando
tu e quando hai a che fare con molto
dei dati è e si avvia un nuovo servizio
e devi caricare questo topic engineer
il servizio è che puoi correre in alto
caricare un tempo molto lungo per caricare
questi dati sono dati di argomento nel tuo e
tuo nel tuo stesso servizio nel
flusso così e ci sono Kafka suggerisce
tre tre cose uno è quello che sei
facendo principalmente è quello di fornire compattato
argomenti così così non siamo non avere il
mantenendo non i dati in sé, ma continuiamo
l’ ultima istantanea di ogni record di dati
con la sua chiave e questo riduce la quantità
di dati che caricare fino a caricare il tuo
servizio tutto bene ho avuto il mio dito su un
domanda interessante e poi di più
domande è venuto in così ho dovuto trovare
ancora così hai detto che c’è di
corso in testa in micro servizi molto
più che in un monolite ma ora lo hai
sia un monolite che i micro servizi
quindi punteggiano lo sforzo di manutenzione
e l’overhead aumenterà come eri tu
estraendo microservizi mi dispiace cosa
è stato l’ aumento in testa o ha fatto il
lo sforzo di manutenzione aumenta come
stavi estraendo questi micro servizi
dal grande monolite rendendolo più difficile
per il secondo estrarre il secondo
perché ora hai altro da fare si
specialmente quello che ho menzionato prima è così
quello che abbiamo fatto io così c’è anche sì
aumentare il
impegno di manutenzione soprattutto perché noi
non c’erano tutte le pratiche DevOps in
posto fin dall’inizio e
c’è anche una cosa che se inizi
con piccoli servizi in un primo momento
sicuramente devi prenderti cura di tutto tuo
le tue cose operative come sicuramente
un CI separato un gasdotto CDS ma anche
monitoraggio sul livello di servizio e anche
tracciamento della serratura e blocco distribuito e
aggregato D blocca quindi se non si dispone
questo al posto e stai gestendo il tuo
monitora e hai micro servizi dentro
produzione poi tu stai causando molto
di mal di testa e un sacco di sforzi da fare
gestirli così anche con i servizi
che decomponi anche stabilire il
anche le principali pratiche DevOps
riesci a uccidere il monolite no no
eppure credo che lo faremo ancora
mantienilo come una piccola storia di fango
quindi per affrontare questo come si
strati anti-corruzione solo sì non lo è
quindi stiamo cercando di concentrarci su quelli
servizi che stiamo generando beneficio
fuori di esso e non ci stiamo decomponendo
i nostri monoliti per introdurre
i tuoi servizi che stiamo cercando di venire
concentrarsi su quale servizio o quale beneficio
stiamo recuperando da esso quando noi
estrai il servizio quanto frequenti hai
rilascia la produzione con il monolite
e com’è ora con il micro
servizi sì, quindi c’è il problema
abbiamo un ambiente poliglotta che noi
avere cloud e abbiamo anche su carrozzina e
purtroppo sul cliente sul telaio così
e questo è davvero quello che ero
dicendo che il nostro viaggio era totalmente
diverso e quindi probabilmente altri
perché dobbiamo affrontare questa complessità
e dobbiamo ridurlo così e così noi
era un modello come lo era di per sé
probabilmente non riesco a ricordare ma lo era
mensile saggio e quindi il privato il
soluzione cloud privata che possiamo implementare
ogni giorno quindi c’è una osservazione interessante
commento con una domanda di qualcuno in
il pubblico che dice che ne abbiamo diversi
cento micro servizi ma sono ancora
un monolite di base è stabile così da dividere
non sembra mai avere affari
priorità
come avresti o hai affrontato questo
non era un problema nel tuo caso, sì
era un problema nel nostro caso dal
fatto che abbiamo iniziato con questo molto alto
contesto limitato a livello di solo unità e
recupero dei risultati molto tardi era anche
non guadagnarci non ci stiamo fidando
dalla direzione o così pensano
sono venuti da noi era bene, non è vero?
dire che si desidera rilasciare
cambia presto ma ora ci vuole molto
più a lungo e così è stato , è vero
problema era che uno e due, ma il
problema è che ci vuole più tempo nel
molto all’inizio quindi devi affrontare
che non è lento sta rallentando
il tuo processo invece di accelerare un pisolino
che tipo di sapore agile scalato così
qualcuno ha un opinione qui hai usato
al fine di gestire le squadre che si
utilizzare in modo sicuro o il modello di Spotify o
come hai fatto come hai organizzato?
le tue squadre quindi non abbiamo tribù
in questo modo si abbiamo così abbiamo
team di prodotti e così come ho detto
prima che queste squadre sono
assegnato a una serie di app di collaborazione
che si prendono cura dell’interfaccia utente
fino alla memorizzazione dei dati e così via
e il mio era quello che stavo forzando
che possono possono fare da soli
decisione autonoma
per gestire la propria collaborazione
le app in modo che siano più allineate e in grado di
scegli anche i loro metodi ideologici
di esso perfetto io sono strumento ed una squadra è stata
correndo sullo stretto l’altro era
correndo su Kanban qualcuno vorrebbe
sapere se hai avuto qualche aiuto esterno in
questo viaggio o è tutto ciò che tu e il
squadra che pensa a tutto questo è un
bella domanda così a volte spero sempre
Stavo pensando a Dio perché non ho chiesto
aiutare così e la cosa è che non avevamo
aiuto esterno in quel centro commerciale in quel momento
quindi ma stavo frequentando un sacco di
conferenze e io eravamo sì, eravamo tutti
scavando dentro di te in ogni libro che noi
potrei leggere ogni articolo che possiamo
trovare al momento e anche provare a
condividere questa conoscenza nei nostri team per
discuterne come a quale modello
lavora per noi adesso ma non è no
fonti esterne diverse da solo e
Apparentemente qualcuno è nella stanza e
qualcuno nella stanza sta cercando
aiuto esterno hanno notato il tuo ex
CTO è solo sociale e si stanno chiedendo
se sei per il noleggio che non è un
domanda da chiedere attraverso l’app perché
è anonimo e tu sai che lo è
difficile da ottenere un rapporto di lavoro
in modo anonimo, quindi se era possibile
mi avvicini più tardi quindi è un sì, lo sono
giusto non su una transizione , ma può farlo
fai questa domanda più tardi oh no nessun problema
qualcuno vuole fare una domanda non
in modo anonimo è spaventoso, non è così
okay sopravviverai alla maggior parte degli altri come
bene, sì, ci siamo
hai preso in considerazione eventuali alternative kafka
per la memorizzazione e l’invio degli eventi
spiacente
Alternative Kafka sulla terra ora perché
abbiamo già presentato Kafka per
notifica e trasferimento di eventi
scopi e per esempio non l’abbiamo fatto
considera eventi o qualcosa del genere
perché avevamo già questo in posizione
e non volevamo introdurne un altro
componente che dobbiamo eseguire e
mantenere così era solo un semplice
ragione per cui non abbiamo considerato che uno
tutti i tempi giusti sono quasi scaduti
grazie voi Grazie molto e la
le cose soprattutto se stiamo lasciando un
un po ‘ è il momento delle domande e
per favore le dia una mano calda
[Applausi]
Grazie e grazie mille per essere venuti
a questo discorso viaggio microservices da
una prospettiva di avvio così quando tu
di solito ascolto e leggi sul successo
storie su micro servizi di solito
senti parlare dei grandi attori del settore
introdotto i micro servizi con successo
come Netflix Amazon eBay e solo per
citarne alcuni e se li guardi
storie di successo che potresti finire per dire
oh, è come quello che ci ha funzionato
applica anche a noi , copiamo solo quello
ma il problema è che ti manca uno
il punto è che ogni viaggio in micro
i servizi sono diversi in ogni
organizzazione uno dei motivi è quello
le circostanze per ogni organizzazione
sono così tanti che mai consenso
effetto nel tuo viaggio così uno dei
le circostanze potrebbero essere dall’altra parte
la struttura del team e le competenze all’interno
in termini di dimensioni che hanno un impatto diretto
i tuoi micro servizi viaggiano così
processo di trasformazione in sé non lo è
funzionamento in isolamento, per esempio se
sei una piccola squadra con pochissimo
Le pratiche DevOps in atto hanno un enorme
impatto sul processo di trasformazione
velocità e se anche tu prendi in
considerazione che devi ancora correre
un sistema legacy ancora necessario
mantenilo devi ancora aver cura
di esso e anche questo sta facendo attenzione
del tuo sistema legacy riduce il tempo
questo è disponibile per una trasformazione
processo e anche ciò che sta influenzando il tuo
il viaggio è anche l’ambiente di runtime
stai correndo su Prem o sei tu
in esecuzione su cloud native così puoi contare
su servizi gestiti ad esempio un API
gateway o devi configurazione
tutto da zero e mantenere e
monitorare tutto e anche quello che è molto
importante è la tua strategia sei tu
costretto a implementare nuove funzionalità in a
periodo di tempo molto breve e se lo sei
molto molto lottato con questo ma se
hai un periodo di tempo molto breve e
potresti lottare con dove
implementare il nuovo servizio devo metterlo
come nuovo servizio o devo aggiungerlo a
i monitor e l’alimentazione del monitor
di nuovo invece di restringerlo così da dare
sei un po ‘di storia
Sono Donna Kaiser che ero il CTO
solo del software che è una start-up in
Amburgo e soffri solo noi
sviluppando solo social che è un digitale
luogo di lavoro che fornisce app di collaborazione
per le tue squadre di comunicare e
collaborare con in team nel tuo
organizzazione e molto tempo fa quando noi
iniziato nel 2010 tutto era e
monitor in ogni aspetto, quindi ne abbiamo avuto uno
squadra che lavora su una collaborazione
prodotto e implementato come una base di codice
basato su uno stack tecnologico quindi dopo a
tempo tutto stava crescendo così una squadra
diventato più grande abbiamo aggiunto sempre di più
caratteristiche il nostro utente è aumentato e il
codebase ottenuto più grande e più grande che è
dovrebbe essere fantastico ma quello noi
aveva un problema che tutto era
sentirsi un po ‘ goffo perché
tutto era legato insieme così sul
un lato è che il fatto è questo
abbiamo aggiunto caratteristiche sempre più le
la cosa è che dovevamo rilasciare questi
cambia rapidamente e il problema era questo
bene perché il nostro team stava diventando più grande
e più grandi le decisioni e le discussioni
e le riunioni hanno richiesto più tempo di prima e
che abbiamo anche avuto non hanno davvero
responsabilità ben definite per
esempio quando è arrivato un Mac di backup chi è
prendersi cura di esso era una squadra così il
i processi stavano rallentando e il nostro
la produttività sofferto e grazie alla
fatto che stavamo aggiungendo sempre di più
caratteristiche l’usabilità è diventata più e
più complesso l’ usabilità e l’utente
esperienza sofferta attraverso continua
modifica delle caratteristiche e invece di
risolvere i problemi dei nostri utenti molto facilmente
ci stavamo sempre più confondendo e
a causa del fatto della natura di a
monolite non è stato molto facile per noi
rilasciare rapidamente le modifiche perché ogni volta
vorresti aggiungere qualcosa che hai
ricostruire e ridistribuire l’intera nave
anche l’intera nave madre
se hai solo una sola riga di
codice che hai cambiato così e questo
ha comportato distribuzioni ad alto rischio e
che è successo a meno che frequentemente così il tuo
nuove uscite rilasciate nuove modifiche
molte delle nuove funzionalità vengono rilasciate molto lentamente
così più di due anni fa e il nostro
la visione del prodotto è cambiata e lo eravamo
concentrandosi su usabilità e utente
sperimentare miglioramenti quindi ci siamo divisi
la nostra unica app per la collaborazione in separato
app di collaborazione che contengono ciascuno
ognuno di loro si sta prendendo cura di
caso d’uso specifico sono prendersi cura di uno
problema e risolvere questo problema molto bene
quindi avevamo un’app di collaborazione per
scambiare documenti per comunicare
in tempo reale per la gestione dei tuoi compiti e
anche distribuendo e condividendo corporate
notizie e pagine di contenuti in tutto il tuo
organizzazione e subito dopo questo o
probabilmente per lo più nel frattempo anche noi
dividere la nostra squadra in più
squadre più piccole e assegnate a ciascuno di
quelle squadre un insieme specifico di
app di collaborazione per abilitare quelle squadre
lavorare con responsabilità ben definite
e per consentire loro di lavorare in modo diverso
parti del software erano indipendenti
impatto minimo tra le squadre e così via
come ragionevole il prossimo passo originale
è anche quello di reagire riflettere questa autonomia
e anche flessibile anche la flessibilità
ora un sé per l’architettura e da
dividendo introducendo microservizi
per guadagnare anche tana significa il nostro software
architettura e quindi la motivazione
per noi da servizi di micro interinale è stato
per consentire a team autonomi di lavorare a
diverse parti del software
indipendentemente alla loro velocità a
il loro ritmo con un impatto minimo
attraverso altre squadre e sviluppare e
distribuire le app di collaborazione
indipendentemente e anche scalare se
più efficacemente così che alla fine noi
può rilasciare le modifiche rapidamente
così quando inizi quando hai deciso
per iniziare questo viaggio verso i micro-servizi
la prima cosa è che devi
identificare buoni candidati per micro
servizi e modellare buoni candidati
uno dei concetti chiave e quello che un buon
i servizi è seguire alcune chiavi
principi e principi chiave per
la modellazione di buoni servizi segue l’alto
coesione nel servizio e libera
accoppiamento tra tali servizi e
di solito nel design guidato dal dominio alto
la coesione all’interno di un servizio è di solito
riflesso dal comportamento correlato che
rimarrà coerente e così limitata
contesto stesso è un confine semantico
attorno a un modello di dominio in cui il modello di dominio
vive dentro e descrivono servizi che
sono responsabili per ben definito
funzione aziendale così per noi nel nostro caso
abbiamo identificato la nostra app di collaborazione come
i candidati perfetti per alto livello
contesto limitato a grana grossa che noi
può usare come nostro come punto di partenza per
il nostro viaggio di decomposizione e poi da
partendo da questo livello elevato a più fine
quelli più grossi in seguito, quindi abbiamo iniziato con
il solo con guida è il
app di collaborazione per prendersi cura di
condividere documenti all’interno del tuo
team e ogni documento stesso
creato da un autore e dai dati dell’autore
stesso è derivato dai dati del profilo
ei dati profilo è derivante dall’attuale
un altro contesto limitato che ancora
risiede nel monolite così abbiamo iniziato
estraendo il contesto limitato di just
guida della nostra app per la collaborazione documentale
come un servizio coesistente da zero e
abbiamo modellato il contesto limitato composto
del suo modello di dominio e prendersi cura di
il riflettere la logica del business ma
anche il servizio di applicazione prendendo
orchestrare casi d’uso e gestire
transazioni e anche l’ input
adattato di questo tuo del tuo limitato
contesto per esempio abbiamo le API di riposo
e tu sei la gestione persistente al
dall’altra parte e questo nuovo servizio allora
possiede lo stato del documento esclusivamente così
questo è l’ unico che Campos ha letto
da un lato ma anche modificarlo e
come accennato prima abbiamo avuto questo autore
dati che sono correlati a un documento che
vorremmo riflettere anche nel nostro nuovo
anche il servizio di notizie e l’autore
i dati provengono dal giorno dei profili
dal contesto delimitato del profilo che
risiede ancora nel monolite ed è
questo il modulo stesso possiede il
profilo Stati esclusivamente sul
sito monolito così e per evitare quando noi
sto visualizzando un documento a cui sono andato
evitare di richiedere la data del profilo o il
autore dati irrilevanti ogni volta quando
mostriamo un documento che abbiamo implementato noi
implementato un evento evento guidato
approccio così abbiamo la cosa è che abbiamo mantenuto
una copia locale dei dati rilevanti dell’autore
in noi stessi e da mantenere
questa copia locale e cosa abbiamo chiesto
il monolito ci stava notificando
sugli eventi di aggiornamento del profilo
quindi ogni volta che un profilo è stato aggiornato
stava pubblicando il monolite
pubblicare l’evento aggiornato del profilo su
un broker di messaggi che il nostro nuovo servizio
iscriversi a e quando l’evento ha avuto
la Concordata ricevuta era consumata
aggiornando la copia locale di conseguenza
quello che devo dire a questa cosa è a
questo stadio è che la coesistenza sta andando
di nuovo un po ‘in modo che la coesistenza
servizio che abbiamo stabilito noi
non un equivalente esatto del del
quello corrente invece anche noi
e intrecciato in questa trasformazione
processo e l’interfaccia utente che abbiamo aggiunto
nuove funzionalità e abbiamo anche fatto significativi
aggiustamenti alla struttura dati stessa
così e che stava causando ci turba in modo
di solito il servizio coesistente da
il graffio è in generale un buon approccio a
approccio alla decomposizione in particolare
se vuoi allontanarti
qualcosa se vuoi andartene
dalla tua attuale logica di business, se tu
vorrebbe allontanarsi dal tuo testo
pila per esempio ma cosa nel nostro caso
era il problema è che noi che noi
Metti un sacco di cose nuove a questo
processo di trasformazione e pure
quindi abbiamo fatto troppi passaggi come uno
soprattutto all’inizio non è stato
ottimale per iniziare perché nel
iniziando se non lo sei se lo sei
iniziando senza esperienza in questo
il mondo dei micro-servizi mentre in questo
il mondo dei micro-servizi l’unica cosa che
devi concentrarti su ciò che arrivi presto
risultati e ottenere risultati veloci in particolare
in principio perché si deve
acquisire esperienza in quel campo molto presto
così in era questo approccio un coesistente
servizio da zero e aggiungendo in cima
diverse molte altre sfide come
non era stato non era ottimale per noi
quindi con il prossimo contesto limitato che
era un’app di chat che abbiamo seguito in modo diverso
approccio che volevamo ottenere prima
risultati così abbiamo seguito la decomposizione
approccio di decomposizione in modo incrementale
dall’alto verso il basso quindi abbiamo iniziato a
estrai l’interfaccia utente come
app web separata e fornita un’API REST
sul monolite che la nuova app web
potrebbe affrontare e questo ci ha permesso di
sviluppare l’interfaccia utente in modo indipendente
e iterare sull’interfaccia utente
rapidamente così il passo successivo fu che noi
spostato la logica aziendale al nuovo
servizio
e la distruttiva logica commerciale sta causando
cambiamenti significativi del codice e in alcuni
i casi erano quindi dipende dal
dipendenze dovevamo anche fornire un
API per i monitor che i monitor
può quindi utilizzare la nostra attività estratta
logica anche a questo punto che avevamo ancora
la stessa archiviazione dei dati e lo eravamo
indirizzando la stessa archiviazione dei dati del
monolito a questo punto e – ancora a
raggiungere e disaccoppiare indipendente
servizio dovevamo spostare questi dati
Anche l’archiviazione è stata l’ultima
passo del nostro top-down incrementale
approccio di decomposizione così e quando noi
spostato l’archiviazione dei dati sul nuovo
servizio dovevamo riflettere il
circostanza che anche in questo caso ciascuno
Era anche la discussione di Chet
creato da una chat che ha avuto partecipanti
il Chet era era stato creato entrambi
attraverso questo partecipanti condivisi e
era anche questo datore partecipante a Chet
streaming dai dati del profilo che
era ancora risiede in più Ellis
stesso e abbiamo anche implementato qui il
principio di trasferimento di stato basato sugli eventi a
tenga molta copia locale alle nostre notizie
servizio e ottenere aggiornato ogni volta che a
il profilo è stato aggiornato sul monolite
così um quando hai più candidati
per i micro servizi una delle sfide
è per – condividere – per dare la priorità al tuo
il tuo prossimo candidato e cosa cosa veramente
funzionerebbe meglio se tu avessi come noi
ha fatto decomporre la nostra app di guida e
il primo inizio quello che veramente
funziona bene se si mantiene questo candidato
molto piccolo all’inizio, quindi se
questo ha pochissima dipendenza quindi se
è molto facile da estrarre perché cosa
ne esci è che arrivi presto
risultati e ti sei guadagnato presto
sperimenta i micro servizi
sì, ma era anche una decomposizione
processo in generale e anche la tua squadra
guadagni guadagnato la fiducia da ottenere in anticipo
esperienza come microservizi e poi tu
può anche andare avanti con il prossimo
concentrarsi su quei servizi che genera
il più grande vantaggio dopo l’estrazione così
uno dei vantaggi potrebbe essere quello se
hai un servizio che cambia molto
spesso è ottenuto un buon candidato per
concentrarsi su successivo perché dopo l’estrazione
hai la possibilità di distribuire il
il cambiamento è molto spesso molto rapidamente o tu
può anche concentrarsi su quei servizi che
richiedono diversi consumi di risorse
per esempio se hai un servizio
richiede più memoria di altri che puoi
distribuirlo su istanze con alto più alto
potere di memoria così per il nostro esempio che abbiamo avuto
un servizio che stava generando un documento
anteprime di cui avevano bisogno diverso
risorsa e in termini di CPU CPU così noi
dopo l’ estrazione potremmo schierare
quei servizi su istanze con con
più alto era più potenza della CPU stessa e così via
con ogni era ogni servizio che noi
estratto ci siamo confrontati con a
domanda o con la maggior parte del servizio
che avevamo estratto ci siamo confrontati
con la domanda su come gestire
preoccupazioni trasversali in questo
caso specifico come gestire
autorizzazione e darti un po ‘
contesto il nostro modello di autorizzazione è molto
a grana molto fine al livello dell’oggetto
quindi ad esempio in Drive puoi farlo
controllare l’autorizzazione di un documento
impostando l’autorizzazione del suo
cartella condivisa principale ma che aumenta
la complessità della nostra autorizzazione
il modello è che è anche nel servizio
dipendenti, quindi si basa anche sul
impostazioni di dati di autorizzazione che
risiede in un servizio diverso così e
questo era per esempio per
esempio se aggiungi documenti a a
Pagina di contenuto e diritto di accesso di
questo documento sono controllati dal
impostazioni di autorizzazione di questo contenuto
pagina e le celle del documento stanno recitando
in un servizio diverso così era
causandoci un sacco di mal di testa e di aver avuto
per gestire l’autorizzazione e cosa come a
il risultato è stato che non abbiamo risolto il problema
preoccupazione per l’ autorizzazione del paese di origine
fin dall’inizio e abbiamo detto che eravamo
rinviato va bene troviamo una soluzione
più tardi troviamo una soluzione più tardi ma cosa
beh le conseguenze erano molto molto
controproducente perché da quando abbiamo
non ha davvero fornito una distribuzione
gestione delle autorizzazioni come uno
conseguenza è stato che abbiamo implementato il
autorizzazione abbiamo aggiunto il servizio
servizio stesso che abbiamo identificato
a quella zona dove l’autorizzazione ha
già risolto e quello era il
monolite quindi abbiamo finito per alimentare il
ancora monolito e quello era l’obiettivo
per restringere Yamada e siamo stati molto
controproducente e di conseguenza
e l’altra parte era che eravamo noi
reinterpretato implementando il
autorizzazione per il livello di servizio e il
la cosa è di solito a prima vista tu
assumerebbe o anche i nostri primi
l’ipotesi era che l’autorizzazione stessa
si riferisce al modello di dominio ma a causa di
le dipendenze tra servizi che io
ho descritto in precedenza
è una preoccupazione trasversale e il
La cosa è che quando lo intendevamo davvero
per servizio che abbiamo duplicato che sono
la logica in sé, ma anche noi eravamo
spostando i dati avanti e indietro e ha avuto
introdotto il rischio di collisione così
anche questo era molto controproducente
per fare un breve una lunga storia breve siamo
ha fuso l’ autorizzazione in a
servizio centralizzato come cross-cutting
preoccupazione e fusione di un sistema decentralizzato
anche l’approccio in uno è molto molto
richiede molto tempo e la cosa è
evitare di alimentare il monolite o
reimplementare una preoccupazione trasversale
con ogni nuovo servizio che tu
introdurre
gestire le preoccupazioni trasversali molto
presto così se aveste avuto un
prima soluzione non avremmo eseguito
in questi problemi così e il prossimo
sfida quando si presenta in particolare
quando si introduce un servizio centralizzato
è evitare di introdurre un più distribuito
o meno così per esempio quando tu quando
apportare modifiche a un lato e è necessario
cambia l’ altro lato allo stesso tempo
e puoi ridistribuirli insieme a
forte indicatore che hai
ha introdotto un modello distribuito è e così
così ad esempio quando aggiungiamo un
nuovo servizio o quando si presenta
voi stessi o quando si apporta una modifica al
il tuo nuovo servizio e la tua autorizzazione
il servizio deve essere aggiornato allo stesso
tempo quindi stai combinando entrambi
svantaggi di entrambi i mondi come te
avere un sistema di accoppiamento stretto ma loro
stanno ora comunicando tramite la rete
e una cosa come evitare una distribuzione
il modello è è quello di stabilire una stabile
contratto a contratto comune che il
il servizio di autorizzazione centralizzato è proprietario
e che tutti gli altri consumano
servizi sono i nostri servizi a valle sono
devi tradurre devi conformarti a
così ogni volta che un servizio su quello
il lato richiede autorizzazione correlata
azioni lo traduce in questo
contratto comune e può essere gestito su
il servizio di autorizzazione di asura senza
traduzione extra extra stessa e
altro prerequisito per questo è
che questo contratto comune è stabile così
l’altro in modo da non doverlo fare
aggiornare tutti i servizi che sono
traducendo in questo contratto ogni
tempo in cui apporti una modifica o a
rompere il cambiamento in modo che anche il
servizio di autorizzazione quindi
i server di autorizzazione devono chiarire
che questo deve seguire il
principi di una stalla
e il contratto era ciò che non lo era
cambia così tanto spesso e così e quando
tu introduci micro-servizi come te
devono prendersi cura del servizio
interazione come I nell’esempio precedente
Mi è stata data l’ interazione guidata dagli eventi
stile
Stavo prescrivendo quello in cui tu
avere servizi che non comunicano
direttamente tra loro ma invece
stanno pubblicando eventi su un messaggio
broker o sottoscrizione di eventi da
da questo broker di messaggi al fine di
capovolgere il controllo di flusso al
ricevendo fine e per rendere questo il
i servizi stessi autonomi e
disaccoppiati e altri stili di interazione
l’approccio guidato dalle richieste in cui uno
il servizio chiama un altro servizio
direttamente sulla sua API e dove il flusso
il controllo della comunicazione è
per lo più controllato dal mittente stesso
ma dove i servizi sono più legati
insieme o puoi anche combinarli
modelli e modelli in un modello ibrido
dove combini la domanda e
modello basato sugli eventi insieme un altro
sfida quando si introduce micro
i servizi è la domanda su come gestire
dati condivisi e come ho menzionato prima in
il modello di interazione il modello ibrido
può essere può essere usato come una soluzione
dove tu comunità dove i tuoi servizi
stanno comunicando sugli eventi ma solo
per scopi di notifica, quindi quando uno
il servizio richiede dati aggiuntivi da
un altro contesto a cui fa una chiamata diretta
una chiamata cross-context remota direttamente a
la fonte con l’era un aspetto negativo che
stai unendo questi due servizi
insieme così, ma si potrebbe desiderare di andare per
la semplicità invece di
come il mantenimento dei dati detto a livello locale
soprattutto quando questo set di dati sta crescendo
per esempio quando vai al prossimo
modella il trasferimento di soggiorno guidato da eventi
mantieni la coppia locale fuori dai tuoi dati e
lì usi non divisioni non solo per
scopi di notifica ma anche per i dati
domanda per i tuoi vari dati
trasferirsi da solo uno dei lati negativi
di questo è che devi mantenere
il set di dati a livello locale e questo set di dati
questa stessa copia locale potrebbe crescere
molto veloce nel tempo e un altro dato
aspetto correlato che devi considerare
è la fonte della verità, quindi di solito in a
sei un sistema tradizionale basato sugli eventi
di solito ascoltando eventi e salvando
le tue azioni in un database e tu sei
emettendo anche nuovi eventi così e per
il tuo servizio interno per te
servizio stesso la fonte interna di
la verità è il tuo database ma tu tutti i tuoi
i servizi a valle sono per loro il
fonte della verità è il è il
mediatore di messaggi stesso per l’ evento così
abbiamo conservato e il fatto è che tu
avere in questo viene la complessità di
doppio scrive che scrivi nel database
ma anche al broker di messaggi e anche
l’altra complessità è che i dati
modello tra il database stesso e
anche il formato dell’evento potrebbe divergere
tempo quindi devi considerare di essere
consapevole della divergenza tra entrambi
mondi così come un’alternativa
approccio provvisorio è quello di unire quelli
rami in un unico negozio di eventi e
dove gli eventi sono considerati come primi
classe di prima classe i cittadini e sono i
fonte primaria dei tuoi servizi così dentro
questo caso i servizi si stanno indirizzando
la stessa fonte della stessa fonte per
i dati sono un’unica fonte di verità e in
in questo contesto entra in gioco Kafka
così Kafka è che è un distribuita scalabile
servizio di blocco commit tollerante ai guasti che
è stato originariamente creato da sviluppato da
Ellington e combina il
funzionalità di un sistema di messaggistica
Sistema Darsh e anche in streaming
piattaforma così nel nostro caso che abbiamo
ha presentato Kafka molto presto ma
principalmente principalmente all’inizio per
notifica e duplicazione dei dati
dove sono i casi principali che abbiamo
usato Kafka per così ma ultimamente abbiamo
ha introdotto anche i flussi di Kafka e
cercando di fare esperienza con
Anche Kafka scorre e così Kafka
i flussi o i flussi in generale sono un
Sequenza ordinata illimitata di strutturato
record di dati e sono definiti come chiave
coppie di valori che sono continuamente
aggiornato e quando lavori con Kafka
gli stream sono quando crei uno stream in
il tuo servizio si carica all’avvio del tuo
servizio un intero argomento Kafka nel tuo
lo streaming di un argomento di Kafka è logico
categoria in cui si produce
i servizi pubblicano eventi o il
i servizi di consumo sono abbonati a
per esempio il contesto delimitato dal profilo
ha un argomento di copia del profilo o il documento
servizio si basa su un profitto nel
servizi documentali liberato di accesso
il traffico del documento stesso così e
il flusso stesso è memorizzato nel buffer in a
negozio di stato che è un peso leggero
database di stato incorporato che è questo
in base al tuo servizio e quindi all’argomento
stesso è caricato nel tuo stream e
può essere elaborato nell’ambito del tuo
proprio servizio e la cosa è che il
il flusso stesso non è in esecuzione sul
broker è in esecuzione nello stesso processo
come il tuo micro servizio così i flussi
rendere i dati disponibili ovunque si trovino
e non devi fare un po ‘di telecomando
le chiamate che devono accettare per esempio,
il broker dei messaggi remoti così in Kafka
il flusso delle telecamere della morte di Kafka era un flusso
API e dove puoi unirti al gruppo di filtri
e aggregati e così via
loro stessi ed elaborarli nell’ambito
del tuo servizio e puoi anche elaborare
ogni messaggio alla volta per funzione come
operazioni come map peek transform e
così via e quando si implementa il flusso
l’elaborazione di ciò che di solito serve è a
stream stesso ma anche un database per
arricchimenti e l’API del flusso di Kafka
fornisce quelle funzionalità di
astrazione di flussi astratti e
tabelle in modo che un flusso stesso sia un cambiamento
blocco di una tabella che cattura i record di dati
come cambiamenti di stato del tavolo stesso e
la tabella è un’istantanea dell’ultima
valore per ogni chiave nel flusso in modo che
sono molto molto legati tra loro
hai una connessione molto forte e tu
può trasformare un flusso in una tabella e
una tabella in un flusso così e questo flusso
la dualità della tabella può essere usata molto
potente nei tuoi microservizi
anche l’architettura, quindi abbiamo iniziato a utilizzare
kafka si lancia da solo introducendo
viste materializzate così nel precedente
ad esempio quando stavo parlando
la visualizzazione dei documenti era anche rilevante
dati negli stream di kafka, esempio noi
potrebbe fare seguendo possiamo creare un
uscire dall’argomento del documento e
caricarlo nel tuo servizio e l’autore
dati pertinenti stessa possono essere caricati da
l’ argomento del profilo come tabella
arricchimento e possiamo filtrare quelli che
possono unirsi a quelli che insieme
stream the
mainstream e la tabella profilo può farlo
essere uniti e essere memorizzati come a
portare a un nuovo negozio di stato che è
quindi accessibile dall’esterno come un
vista materializzata integrata e questo è
quindi sempre aggiornato automaticamente
aggiornato ogni volta che un nuovo documento è stato
aggiunto per esempio o quando il profilo
i dati sono stati modificati in modo da confrontare
quei meccanismi guidati dagli eventi è questo
era con Kafka streaming sei
eliminando la copia locale quindi non lo fai
deve avere questa l’ applicazione permettersi
mantenendo una copia locale e vedendo ogni volta
ad esempio un’app di profilo che è stata
ha assicurato e così e spinge anche il
debito con i dati a dove è necessario
spinge al tuo servizio stesso così tu
non c’è bisogno di voi tipo di subito
attraverso l’ API di tre flussi senza
chiamate remote e questo aumenta
applicabilità per esempio quando tu
introdurre un nuovo servizio che puoi semplicemente
collegalo al tuo sistema di streaming
se stesso ed era fuori per esempio se lo sei
non può fare affidamento sui propri dati
i dati del flusso subito così in generale
abbassa la barriera all’ingresso per te
per il tuo nuovo servizio stesso e alla ricerca
ora da lui il senno di poi è come quello che abbiamo
imparato fino ad ora sta iniziando piccolo e
focalizzato su quelli che sono facili da fare
estrai nel primissimo inizio
è molto molto utile perché e
anche fare un passo alla volta uno
manovra passo passo alla volta e
perché se metti troppo carico sul tuo
le spalle proprio all’inizio
non ottenere risultati precoci e non lo sei
guadagnando davvero fiducia e maneggiando
microservizi ed è davvero frustrante
se non puoi se hai molto tardi
esperienza con quelle ore e fino a tardi
risultati e un altro è da evitare
alimentazione nuovamente e ai monitor
problemi di reimplementazione per servizio
livello sicuramente gestire il tuo
preoccupazioni trasversali molto presto a
evitare tutti questi problemi che abbiamo corso
dentro e al momento della fornitura centralizzata
servizio di evitare un modello distribuito è di
introducendo un contratto comune che è
stabile per te
per i tuoi servizi downstream e e
progetta il tuo sistema per essere facile
evolvete il design e guidate da eventi da raggiungere
alto disaccoppiamento e autonomia tra
i tuoi servizi e anche io lo farei
sicuramente considerare di nuovo stream come il
fonte condivisa di verità un buon tentativo come
bene e tornare a quello che ho
menzionato all’inizio essere a conoscenza di
le tue circostanze quindi non è il tuo
processo di trasformazione non è in esecuzione
in isolamento e per esempio se lo hai
per abbinare una timeline molto marcata e fare
il suo processo di trasformazione in parallelo
causa molte frustrazioni per entrambi
lati e tenere presente che ogni
il viaggio è diverso e il nostro viaggio
potrebbe essere totalmente diverso dal tuo
Grazie per l’attenzione
[Applausi]
grazie, innanzitutto, non dimenticare
votare è probabilmente la ventesima volta
è stato detto che ce ne sono alcuni
domande poste attraverso l’app
se avete domande ora ci proverò
per rinfrescare abbiamo un paio di minuti a sinistra
quindi ero una domanda riguarda il
maturità della società o del
squadra che hai intrapreso questo viaggio
con così come quanto sia stata esperta la squadra
e quanto era grande la squadra che tu
preso insieme in questo viaggio quindi siamo stati
l’unica squadra era di 13 persone e lo sono
per lo più senior in full stack
esperienza e persone anziane e in quello
campo ma era molto piccolo DevOps
pratiche in atto così che è anche uno
cosa che posso anche affrontare è quella
specialmente quando devi quando sei
correre su Prem, ad esempio, è così
anche uno spostamento verso una cultura DevOps
e devi considerare anche questo
rifletti anche nella tua squadra
in termini di specialmente se abbiamo un
piccola squadra quindi abbiamo avuto una grande scena e
spacco in tre diversi e
ma ciò che è molto importante è anche
che tu abbia per esempio una task force
all’inizio gestendo il monitoraggio
logging distribuito tutto questo
complessità operativa e che no
ogni squadra stessa sta cercando di risolvere a
lettura bilanciata ne fornisce alcuni
meccanismi che ogni squadra può quindi
riutilizzare e sono nei servizi noi
avere una domanda dal vivo Suzanne grazie
per l’equazione di presentazione ci sei
sapere costruire lo stato condiviso di
il flusso degli eventi è una bella idea
insieme ma conosci il tempo di avvio
dell’applicazione del contenitore
dipende molto dalla quantità di dati
che esiste questo flusso di eventi
alcuni miliardi di eventi che deve essere
caricato durante l’ora di inizio e
fondamentalmente alcuni di loro in realtà devono
essere cancellato perché è come lo sai
aggiornamenti spesso sono solo ridondanti
quale dovrebbe essere il suggerimento che piace
dovresti fornire aggiornamenti completi
lì all’interno del flusso di eventi o simili
qual è la tua esperienza con quella così
sì, non siamo che non sei Netflix
è necessario elaborare 1 trilione
messaggi al giorno ne abbiamo un po ‘meno ma
quello che c’è una sfida è quando
tu e quando hai a che fare con molto
dei dati è e si avvia un nuovo servizio
e devi caricare questo topic engineer
il servizio è che puoi correre in alto
caricare un tempo molto lungo per caricare
questi dati sono dati di argomento nel tuo e
tuo nel tuo stesso servizio nel
flusso così e ci sono Kafka suggerisce
tre tre cose uno è quello che sei
facendo principalmente è quello di fornire compattato
argomenti così così non siamo non avere il
mantenendo non i dati in sé, ma continuiamo
l’ ultima istantanea di ogni record di dati
con la sua chiave e questo riduce la quantità
di dati che caricare fino a caricare il tuo
servizio tutto bene ho avuto il mio dito su un
domanda interessante e poi di più
domande è venuto in così ho dovuto trovare
ancora così hai detto che c’è di
corso in testa in micro servizi molto
più che in un monolite ma ora lo hai
sia un monolite che i micro servizi
quindi punteggiano lo sforzo di manutenzione
e l’overhead aumenterà come eri tu
estraendo microservizi mi dispiace cosa
è stato l’ aumento in testa o ha fatto il
lo sforzo di manutenzione aumenta come
stavi estraendo questi micro servizi
dal grande monolite rendendolo più difficile
per il secondo estrarre il secondo
perché ora hai altro da fare si
specialmente quello che ho menzionato prima è così
quello che abbiamo fatto io così c’è anche sì
aumentare il
impegno di manutenzione soprattutto perché noi
non c’erano tutte le pratiche DevOps in
posto fin dall’inizio e
c’è anche una cosa che se inizi
con piccoli servizi in un primo momento
sicuramente devi prenderti cura di tutto tuo
le tue cose operative come sicuramente
un CI separato un gasdotto CDS ma anche
monitoraggio sul livello di servizio e anche
tracciamento della serratura e blocco distribuito e
aggregato D blocca quindi se non si dispone
questo al posto e stai gestendo il tuo
monitora e hai micro servizi dentro
produzione poi tu stai causando molto
di mal di testa e un sacco di sforzi da fare
gestirli così anche con i servizi
che decomponi anche stabilire il
anche le principali pratiche DevOps
riesci a uccidere il monolite no no
eppure credo che lo faremo ancora
mantienilo come una piccola storia di fango
quindi per affrontare questo come si
strati anti-corruzione solo sì non lo è
quindi stiamo cercando di concentrarci su quelli
servizi che stiamo generando beneficio
fuori di esso e non ci stiamo decomponendo
i nostri monoliti per introdurre
i tuoi servizi che stiamo cercando di venire
concentrarsi su quale servizio o quale beneficio
stiamo recuperando da esso quando noi
estrai il servizio quanto frequenti hai
rilascia la produzione con il monolite
e com’è ora con il micro
servizi sì, quindi c’è il problema
abbiamo un ambiente poliglotta che noi
avere cloud e abbiamo anche su carrozzina e
purtroppo sul cliente sul telaio così
e questo è davvero quello che ero
dicendo che il nostro viaggio era totalmente
diverso e quindi probabilmente altri
perché dobbiamo affrontare questa complessità
e dobbiamo ridurlo così e così noi
era un modello come lo era di per sé
probabilmente non riesco a ricordare ma lo era
mensile saggio e quindi il privato il
soluzione cloud privata che possiamo implementare
ogni giorno quindi c’è una osservazione interessante
commento con una domanda di qualcuno in
il pubblico che dice che ne abbiamo diversi
cento micro servizi ma sono ancora
un monolite di base è stabile così da dividere
non sembra mai avere affari
priorità
come avresti o hai affrontato questo
non era un problema nel tuo caso, sì
era un problema nel nostro caso dal
fatto che abbiamo iniziato con questo molto alto
contesto limitato a livello di solo unità e
recupero dei risultati molto tardi era anche
non guadagnarci non ci stiamo fidando
dalla direzione o così pensano
sono venuti da noi era bene, non è vero?
dire che si desidera rilasciare
cambia presto ma ora ci vuole molto
più a lungo e così è stato , è vero
problema era che uno e due, ma il
problema è che ci vuole più tempo nel
molto all’inizio quindi devi affrontare
che non è lento sta rallentando
il tuo processo invece di accelerare un pisolino
che tipo di sapore agile scalato così
qualcuno ha un opinione qui hai usato
al fine di gestire le squadre che si
utilizzare in modo sicuro o il modello di Spotify o
come hai fatto come hai organizzato?
le tue squadre quindi non abbiamo tribù
in questo modo si abbiamo così abbiamo
team di prodotti e così come ho detto
prima che queste squadre sono
assegnato a una serie di app di collaborazione
che si prendono cura dell’interfaccia utente
fino alla memorizzazione dei dati e così via
e il mio era quello che stavo forzando
che possono possono fare da soli
decisione autonoma
per gestire la propria collaborazione
le app in modo che siano più allineate e in grado di
scegli anche i loro metodi ideologici
di esso perfetto io sono strumento ed una squadra è stata
correndo sullo stretto l’altro era
correndo su Kanban qualcuno vorrebbe
sapere se hai avuto qualche aiuto esterno in
questo viaggio o è tutto ciò che tu e il
squadra che pensa a tutto questo è un
bella domanda così a volte spero sempre
Stavo pensando a Dio perché non ho chiesto
aiutare così e la cosa è che non avevamo
aiuto esterno in quel centro commerciale in quel momento
quindi ma stavo frequentando un sacco di
conferenze e io eravamo sì, eravamo tutti
scavando dentro di te in ogni libro che noi
potrei leggere ogni articolo che possiamo
trovare al momento e anche provare a
condividere questa conoscenza nei nostri team per
discuterne come a quale modello
lavora per noi adesso ma non è no
fonti esterne diverse da solo e
Apparentemente qualcuno è nella stanza e
qualcuno nella stanza sta cercando
aiuto esterno hanno notato il tuo ex
CTO è solo sociale e si stanno chiedendo
se sei per il noleggio che non è un
domanda da chiedere attraverso l’app perché
è anonimo e tu sai che lo è
difficile da ottenere un rapporto di lavoro
in modo anonimo, quindi se era possibile
mi avvicini più tardi quindi è un sì, lo sono
giusto non su una transizione , ma può farlo
fai questa domanda più tardi oh no nessun problema
qualcuno vuole fare una domanda non
in modo anonimo è spaventoso, non è così
okay sopravviverai alla maggior parte degli altri come
bene, sì, ci siamo
hai preso in considerazione eventuali alternative kafka
per la memorizzazione e l’invio degli eventi
spiacente
Alternative Kafka sulla terra ora perché
abbiamo già presentato Kafka per
notifica e trasferimento di eventi
scopi e per esempio non l’abbiamo fatto
considera eventi o qualcosa del genere
perché avevamo già questo in posizione
e non volevamo introdurne un altro
componente che dobbiamo eseguire e
mantenere così era solo un semplice
ragione per cui non abbiamo considerato che uno
tutti i tempi giusti sono quasi scaduti
grazie voi Grazie molto e la
le cose soprattutto se stiamo lasciando un
un po ‘ è il momento delle domande e
per favore le dia una mano calda
[Applausi]
Please follow and like us: