Press "Enter" to skip to content

GOTO 2017 • Effective Microservices in a Data-Centric World • Randy Shoup


[Musica]
grazie mille che è bello essere
ritorno a Chicago e Beckett
per cui parlerò di efficacia
micro servizi in un mondo incentrato sui dati
e ti dirò un po ‘ del mio
sfondo lo sfondo della società
per cui lavoro e poi l’ ho applicato a
alcune conoscenze che abbiamo avuto e
costruire architetture di micro-servizi
quindi basta una punta che si sa dove sto
provenendo da I sono il VP di ingegneria di
un’azienda a San Francisco chiamata punto
fix and stitch fix è un abbigliamento
rivenditore che sta rivoluzionando
vendita al dettaglio girando la testa e noi
piace usare ci piace pensare al nostro
combinazione del modello di business come
combinando arte con la scienza e se questo
non ha senso va bene, ma è così
sarà in un paio di diapositive prima che io
era una sorta di CTO itinerante come servizio
come i miei amici mi chiamavano ero
aiutare un gruppo di aziende a scalare le proprie
le organizzazioni scalano le loro tecnologie
e in gran parte o in spesso parte il
tecnologie coinvolte nell’adozione di micro
servizi e migrazione di monoliti a
micro servizi prima di quello che ero
direttore di in direttore di ingegneria
a Google per Google App Engine quindi App
Il motore è la piattaforma di Google come servizio
e al tempo ero lì c’era il
il più grande del mondo che potresti essere
familiarità con Roku o qualche altro
piattaforme come servizio è tipo in
quello stesso stesso spazio e poi
all’inizio della mia carriera ero capo
ingegnere di eBay per circa sei e a
mezzo anni io e durante quel tempo io
ho speso un sacco di sforzi per aiutare
migrare eBay attraverso un paio di
iterazioni del loro fondamentale
architettura raffreddare quindi voglio dirvi
un po ‘di correzione del punto
e questo non è per dirti che tu
dovresti comprare i tuoi vestiti attraverso i nostri
servizio che ovviamente dovresti ma
è fondamentalmente per darti uno sfondo
sul modello di business perché così sarà
Permetti di avere un’idea del motivo per cui i dati
è così importante e perché i micro servizi
sono una buona misura per quello che noi cosa
stiamo cercando di fare così il modello di business
alla correzione del punto è fondamentalmente il contrario
di vendita al dettaglio standard quindi piuttosto che andare
in un negozio o in un online online
sito di e-commerce si compila una bella
profilo di stile dettagliato su di te
ci dici tutte le cose che ti piacciono tutte
le cose che non ti piacciono del tuo prezzo
preferenze tutte le tue preferenze di stile
tipi di informazioni che vorresti dire
forse il tuo amico
o tua sorella o tuo fratello e per
qualcuno che sta andando a scegliere i vestiti
per te così ci dai tutto questo
informazioni che ti inviamo cinque raccolte a mano
elementi in una scatola che abbiamo selezionato
esattamente per te e poi tieni cosa
vuoi e restituisci quello che vuoi
e ovviamente tieni le cose che sei
andando a pagarci per loro ma se tu
non tenerli tornano gratis
e nessun problema quindi dietro quel modello è un
molta arte e molta scienza dei dati
così abbiamo facciamo abbiamo fatto una tale una tale
investimento in scienza dei dati che noi
in realtà hanno un rapporto uno a uno tra
ingegneri e scienziati dei dati così abbiamo
circa 70-75 ingegneri nel team
che lavorare su noi abbiamo circa 75 dati
scienziati nel nostro team di algoritmi e come
per quanto ne so, questo rapporto è unico in
il nostro settore intendo dire che mi piacerebbe sentire il
contro esempio ma finora credo
è l’unica società che è una sorta di bar
scala che ha una sorta di parti uguali
ingegneria e scienza dei dati e cosa fare
lo facciamo bene con 75 scienziati di dati
in realtà applichiamo l’intelligenza a tutti
parte del nostro business, quindi lo applichiamo a
il processo di acquisto al dettaglio
chiamato merchandising lo applichiamo a
gestione dell’inventario quindi abbiamo effettivamente
magazzini fisici e la gestione del
l’inventario è fatto con i dati
scienza lo facciamo con cui ci rivolgiamo
l’ottimizzazione della logistica così spedizione fuori
per portare le cose alle persone a destra
tempo al minimo costo per cui lo facciamo
consigli di stile che sto andando
di cui parlare per la prossima coppia di
minuti quindi i consigli al
stilista umano che in realtà sceglie il
vestiti che entreranno nel
scatola per te e facciamo anche più standard
cose come la previsione della domanda che cercano di
pensa a cercare di capire quanti
i clienti che avremo intenzione di andare
inoltrare
quante correzioni o quante scatole nel nostro
terminologia lo invieremo
tipo di cose e la cosa fondamentale però
attraverso tutti quelli tutti quei settori è quello
abbiamo umani e macchine che aumentano
l’un l’altro
gli umani non sarebbero in grado di fare come
bene senza macchine e macchine
non sarei in grado di fare altrettanto senza
gli umani quindi lascia che ti dia una rapida
esempio di un esempio funzionante di ciò che noi
chiama lo styling in modo da scegliere lo stile
quei cinque oggetti che entrano nella scatola
per te e abbiamo circa 3500 umani
stilisti che sono in tutto il Regno
Gli stati che guardano guardano il nostro
inventario e fuori l’altro e loro
scegli i cinque elementi per te e poi
essi
mandali a te nella scatola e speriamo
che ti piacciono ma in realtà dietro
questo è un mucchio di algoritmi
lavoro algoritmico e una tonnellata di dati
scienza così abbiamo appena firmato
con il servizio con quello dettagliato
profilo possiamo immediatamente raggruppare
con circa con un mucchio di altri
clienti che hanno gusti e gusti simili
quindi eseguiamo un sacco di macchine per saperne di più
fare previsioni su quello che sei
intenzione di mantenere e che cosa si sta andando a
ritorno e quelli algoritmici
le raccomandazioni vanno nell’interfaccia
che gli stilisti usano per scegliere il
cose che inviamo e poi quelle in
lo stilista non sta solo prendendo i primi cinque
cose che consigliamo lo stilista è
fare ciò che gli umani fanno meglio a mettere
insieme un vestito che decide che questo è
una cosa che un ingegnere del software in San
Francisco indosserebbe o questo è
qualcosa che un socialite di Manhattan
indosserei praticamente le cose che
gli umani sono bravi e le macchine
non sono ancora così per il resto del discorso
voglio parlare di come lavoriamo a punto
fissare concentrandosi principalmente sul micro
servizi ma e voglio parlare di I
voglio anche parlare del perché di questo modo di
lavorare funziona davvero così moderno
lo sviluppo del software per la mia mente è una specie
composto da quattro diversi segmenti così
c’è e non è solo tecnologia
ha ragione è organizzazione i suoi processi
e pratica la sua cultura e la sua
tecnologia e per quanto ne so o in
la mia opinione personale sui modi che mi piacciono
team ad alte prestazioni con cui ho lavorato
nell’approccio quei problemi in questo
così in organizzazioni che ci piace avere
piccole squadre con aree ben definite di
responsabilità per i processi e
pratiche sono un forte sostenitore in
sviluppo guidato da test e continuo
consegna per la cultura sono un forte
credente in DevOps che lo significhi
tutti possiedono end to end dei servizi
e applicazioni che costruiscono e
finalmente credo fortemente in micro
servizi quindi ho intenzione di passare attraverso
quei primi tre super velocemente per gentile
di darti una linea di base e poi il resto
del discorso sta per essere su micro
servizi anche se hanno promesso così rapidamente
sulle piccole squadre così così
organizzazioni ad alte prestazioni che ho
ha funzionato in una sorta di Google il
Gli eBay di tutto il mondo fanno così hanno
piccoli team che sono allineati a
particolari domini aziendali quindi una squadra
ha una chiara area ben definita di
responsabilità e una squadra
in genere in genere mantiene un singolo
servizio o applicazione o un insieme di
team di servizi e applicazioni correlati
sono cross-funzionali quindi all’interno del
confine della squadra hanno tutto il
set di abilità di cui hanno bisogno per fare il loro
lavoro ora non sto dicendo che hanno tutto
set di abilità nel mondo come noi no
fare il nostro hardware non facciamo il nostro
i propri sistemi operativi ma tutte le cose
che la squadra ha bisogno di ottenere il loro lavoro
fatto sono tutti entro i confini di
la squadra e ovviamente quelle squadre
dipende da altri team di statistiche per
servizi di supporto alle biblioteche
e strumenti sui processi e
le pratiche laterali di nuovo siamo forti
credenti nello sviluppo basato sui test e
consegna continua
quindi, per lo sviluppo basato sui test, lo facciamo
questo perché i test ci aiutano ad andare più veloci
giusto stiamo facendo un investimento investito
in anticipo nella scrittura di test mentre scriviamo il nostro
software ma lo facciamo perché il
i test hanno le spalle proprio li ‘
sono lì per farci per farcelo sapere
quando qualcosa è rotto a causa di a
cambia che abbiamo fatto e in realtà finisce
aumentando la nostra velocità di sviluppo
piuttosto che rallentare i test aiuta
facciamo un codice migliore in modo che ci dia il
pavoneggia la fiducia per essere in grado di rompere
cose e ci dà la fiducia
essere in grado di refactoring in modo molto coraggioso
modo quando le cose quando vogliamo fare
qualcosa di diverso con il codice e
finalmente i test rendono i sistemi migliori così
ci permette di catturare bug prima e
ci permette di fallire più velocemente così l’altro
lo sviluppo basato sui test è stato
praticato da un gruppo di persone per a
molto tempo ma ampiamente nel settore
relativamente recentemente così spesso lo farai
ascoltare dai tipi di gestione e ho
diventa questa persona quindi sono triste ma tu
spesso sentiamo dai tipi di gestione che noi
non ho tempo per farlo bene e dico
torto dico che non abbiamo tempo per farlo
due volte, quindi se lo facciamo bene, almeno
abbastanza giusto la prima volta come Brian
Cantrell ha anche detto nel keynote di oggi
allora saremo molto meglio
posizione per costruire qualcosa di solido
che esiste già ed essere in grado di muoversi
avanti in un modo fantastico e in effetti questo
è forse controintuitivo ma più
costretti siamo in termini di tempo e
risorse, più importante è
costruire la prima volta giusto se noi
non ho molto tempo e non abbiamo
molte risorse dovremmo passare il nostro tempo
costruendo un piccolo numero di davvero grandiosi
insegnanti piuttosto che un gran numero di
tipo di metà implementato e giusto
per essere chiari quando dico giusto no
significa perfetto, hai costruito l’80/20
regola della cosa di cui hai effettivamente bisogno
per essere fatto lo fai bene di alta qualità
spostati sulle implicazioni che ciò ha
per noi a stitch fix è davvero
interessante
è la prima volta che lavoro
Sono nel settore da molto tempo
tempo come si può dire che stanno guardando
io e fondamentalmente non abbiamo un bug
sistema di tracciamento bug sono stati corretti in modo da
Sono venuti fuori così abbiamo un sistema che
questo ci mostra gli errori che sono
accadendo in tempo reale nel
applicazioni, ma quando arrivano noi
risolvili e abbiamo un solido
da quel momento in poi, naturalmente, lo faremo
un arretrato non è come non lo sappiamo
cosa faremo la prossima settimana dopo
mese o il prossimo trimestre abbiamo un arretrato
ma quelli arretrati sono nuove funzionalità giuste
caratteristiche che vogliamo costruire debito tecnico
che vogliamo ripagare non è un intero
lista delle cose che che sono rotti in
l’attuale serie di funzioni fa questo
un po ‘di buon senso sì, è davvero bello
e io e io amiamo molto lavorare in un
ambiente come questo, ecco perché
tiralo su così l’altra angolazione
i processi e le pratiche sono
consegna continua quindi la maggior parte dei nostri
le applicazioni che risolvono i punti sono
schierato più volte al giorno e quando io
usato per parlare di Stephanie Bay quando ho
prima ha iniziato a tenere conferenze
circa nel 2006 stavo parlando del
Architettura di eBay e alcuni dei nostri altri
pratiche su eBay ed è stato il primo
tempo in cui eBay aveva aperto il
kimono e ha parlato pubblicamente di cosa
stavano facendo e quindi una delle cose
abbiamo parlato oltre l’architettura
eBay è stato utilizzato per pubblicare il sito
treno di due settimane in modo che avrebbero affittato il
intero sito una volta ogni due settimane e
solo per dare un senso di quanto lontano
siamo venuti 11 anni fa che è stato fantastico
le persone erano come il mio dio che hai rilasciato
l’intero sito ogni due settimane e ora
se lo dicessi a questa conferenza, gente
sarebbe come oh mio dio hai rilasciato il
sito ogni due settimane, quindi lo stiamo facendo
più volte al giorno questo porta a più
sistemi solidi proprio così ci consente di
rilascia unità di lavoro più piccole che significa
la cosa che piccole unità che noi
il rilascio è più veloce per riparare più facilmente
diagnosticare se vanno male e loro sono
piccoli cambiamenti che per noi essere in grado
rotolare indietro o rotolare in avanti e
ci consente anche di fare veramente velocemente
esperimenti piccoli esperimenti che
sono davvero economici quindi possiamo fare a / b
test e a
test e test ABCD perché è
a buon mercato siamo in grado di iterare rapidamente e
sperimentare molto velocemente e io porto
questo perché sarà super
pertinente alla roba di dati che sono
andando a parlare in un momento, ma la
l’ultimo tipo di pilastro su cui è stato costruito
sono gli aspetti culturali di DevOps e
cosa significa per me è end-to-end
proprietà per una squadra del
servizio in modo che una squadra possieda un servizio da
progettazione attraverso l’implementazione fino a
pensionamento e la squadra è responsabile
per tutti gli aspetti del servizio no
solo le caratteristiche ma anche la qualità
del servizio le prestazioni del
servizio le operazioni del servizio
e il mantenimento del servizio è
fondamentalmente la reificazione del Rio delle Amazzoni
idea di te che lo fai funzionare ok così
quello è lo sfondo e ora voglio
prendi il resto del tempo per parlare
micro servizi alcuni dei modi in cui
abbiamo affrontato il problema alcuni dei
Le cose che abbiamo imparato durante la migrazione sono
database monolitico in individuo
servizi e anche alcuni modelli e
pratiche che puoi riprendere come
stai provando a far muovere forse il tuo mana
monolite allo stesso modo ok ma prima
è facile pensare che a
conferenza dove ci sono molti discorsi
su micro servizi che avremmo
stai dicendo che sai che dovresti fare micro
servizi per tutto ciò che è in realtà
non è vero e ti darò un grande
esempi infatti ci sono esempi da
luoghi di cui probabilmente avete sentito parlare
eBay a seconda di come si conta è acceso
si tratta della quinta generazione della sua
architettura quindi è iniziata notoriamente come a
applicazione perl monolitica sovrascritta
un weekend di tre giorni dalla fonderia di
1995 così ha voluto giocare con
questa nuova cosa web e provalo
ed era un devoto di economia e lui
era come se costruissi un sito di aste
non aveva in programma di costruire
un business questo è stato come un piccolo divertimento
hack non hack giorno come hack tre giorni
incidere un lungo fine settimana per se stesso ma è così
ha finito per diventare un business e tu
so ora che vive alle Hawaii e
roba così è abbastanza bello quindi il prossimo
gen la prossima generazione di eBay
architettura la v2 di essa era a
monolitico C ++ applicazione e che la sua
la cosa peggiore era circa 3,4 milioni
linee di codice in una singola DLL sì no
Fai quello
vuoi parlare, pensi di avere un
scrivania modello sì 3,4 milioni di righe di
codice in una singola DLL oh ed erano
colpendo i limiti del compilatore sul
numero di metodi per classe che è 16
Il K così seriamente non lo fa ok il prossimo
iterazione v3 è stata una reimplementazione in
java e non erano micro-servizi ma
puoi pensarlo come tanti
applicazioni quindi prendi una pagina o un
serie di pagine correlate sul sito come
la parte di acquisto la parte di ricerca il
vendendo la parte ecc. e possono fare a
applicazione java fuori da quello e poi
c’erano un sacco di database condivisi
sotto e poi il collo del
ultima iterazione dell’architettura di eBay
e dove è oggi è possibile
può fondamentalmente descriverlo come un insieme di
micro servizi poliglotta così Twitter ha
attraversato un’evoluzione simile così
a seconda di come conti su Twitter
sulla sua terza generazione, quindi è iniziato
notoriamente come un binario monolitico
applicazione che i miei amici su Twitter
dimmi che chiamano la monorotaia che
questo è un nome intelligente il prossimo
l’iterazione dopo che si è scatenata a
mazzo del front-end in JavaScript a
mazzo di back – end in
servizi scritti in Scala e poi ora
è giusto caratterizzare Twitter come a
set di micro servizi poliglotta Amazon
ha attraversato un’evoluzione simile così
Amazon non è così pulito sul difetto di
le divisioni tra la loro architettura
sono andati in largo relativamente presto ma loro
ha iniziato con un Perl C ++ monolitico
applicazione che in realtà puoi ancora
vedere in alcune delle pagine dei dettagli del prodotto
se vai in Amazzonia, se mai lo vedrai
obidos OB idos nell’URL che era il
nome di quel monolito originale
applicazione e, naturalmente, per la ricerca
ottimizzazione del motore come non vogliono
per cambiare le pagine a causa del PageRank
e sì sì, così hanno iniziato a rompere
il loro back-end in a
un sacco di architettura orientata al servizio
servizi scritti principalmente in Java e
Scala e ora penso che sia giusto
caratterizzare Amazon come un insieme di poliglotta
micro servizi quindi ci sono due cose
per togliere da questo è tutto questo
i posti non sono iniziati facendo micro
servizi, ma tutti hanno finito per farlo
ha senso così quando lo sei
iniziando e stai ancora cercando di
capire se se c’è una
modello di business e se hai
mercato del prodotto in forma e se tu sia
deliziare i tuoi clienti questo non lo è
il tempo per costruire un sistema distribuito
più tardi quando hai raggiunto quando lo hai fatto
raggiunto una scala enorme che è il momento
va bene così ora che abbiamo una specie di put
microservizi in un po ‘di un
contesto evolutivo architettonico che cosa
è un microservizio quindi per me il micro di
microservice non riguarda il numero di
linee di codice che sono dentro ma è
circa la dimensione e la portata del
interfaccia quindi un micro servizio
monouso ha un semplice
interfaccia ben definita ed è modulare
e indipendente e questo se questo sembra
buono solo semplicemente buono è capsulato
design di classe hai ragione
questo è esattamente quello che è e se lo è
sembra che questo sia il modo giusto per
costruire servizi e perché abbiamo bisogno di
diciamo micro hai ragione per quanto sono
il micro interessato non è niente di micro
i servizi non sono altro che
l’architettura orientata ai servizi è fatta
correttamente ma l’altro elemento di micro
servizi che è dove un po ‘di
così tanto sono così … architetture
è andato storto è un elemento critico di a
il servizio di micro di successo è quello che ha
persistenza isolata in altre parole
Il servizio di Micra è l’unico modo per entrare e
ottenere i dati dentro e fuori da un micro
database di servizi o quant’altro
il meccanismo di persistenza che usa è attraverso
l’interfaccia pubblicata lo fa
senso ma questo è isolato non c’è
modo backdoor per entrare per entrare nel
base di dati dall’esterno come fa che
lavoro Randy, sono contento che tu l’abbia chiesto, quindi lo farò
vi dica un po darvi un paio di
modelli o un paio di approcci a
come potresti essere in grado di fare
persistenza in questo modo così l’approccio
erano il numero uno è che la squadra che
costruisce e gestisce il micro servizio
gestisce anche il proprio archivio dati
alla correzione del punto usiamo Postgres come nostro
back-end quindi abbiamo un sacco di servizi
dove la squadra è essenzialmente
mantenendo la propria istanza di
Postgres ma potresti sostituirlo con
conosci il mio sequel o qualsiasi altra cosa
meccanismo di persistenza che ti piace un altro
approccio è quello di utilizzare un servizio persistente
giusto, quindi archivia le tue tabelle o
il tuo spazio all’interno di un persistente
servizio gestito a tuo nome da forse
un’altra squadra nella tua azienda o forse a
fornitore di servizi cloud di terze parti come Amazon
servizio di database dinamo o relazionale o
Google spanner o qualcosa del genere
e la chiave l’idea è che sarebbe
operato per vostro conto, così non lo fate
bisogno di sapere come scalare in
il meccanismo di persistenza ma cosa ma
la cosa fondamentale che vuoi avere
il proprietario del servizio è la tua fetta di quello
il sistema multi-tenant è tuo ed è
isolato per te e nessun altro può ottenere
in questo ha senso quello che sono
parlare di
si no va tutto bene e ancora
la cosa critica che stiamo provando
per arrivare qui è l’unico accesso esterno
al mio archivio dati del mio servizio è
attraverso la mia interfaccia di servizio pubblicata
così parlando un po ‘di interfacce I
voglio essere sicuro di voler parlare a
un po ‘su come evolvere
interfacce in un mondo di micro servizi così
un sacco di persone hanno forse preoccupato
bene come faccio versione micro e servizi
non è davvero complicato e
prende un po ‘di disciplina ma
in realtà non è complicato come te
potrebbe pensare ma chiave l’elemento chiave che
si desidera che si desidera avere qui si è
in pratica come stai sviluppando e
evolvendo l’interfaccia del tuo servizio
vuoi semplicemente assicurarti che
le modifiche che fai sono entrambe
compatibile con le versioni precedenti e successive e il
l’obiettivo principale qui è che tu voglia
fare in modo che non avete mai rompere il vostro
codice client ma Randy te lo dico ma
tu mi dici che a volte ho bisogno di fare
rompendo i cambiamenti a volte ho bisogno di
fare iterazioni sull’interfaccia
ottimo quindi il modo di pensarci
qualcosa chiamato versioning semantico
che probabilmente la maggior parte di noi ha
sentito parlare così della versione semantica
è come versione minore versione principale
le patch delle versioni principali sono per la rottura
cambia le versioni minori sono per le aggiunte
a quel cambiamento di comportamento come l’aggiunta
nuovi metodi e patch sono per le cose
che non cambia affatto il comportamento ma
sono solo una sorta di miglioramento del bug
correzioni o prestazioni o qualcosa del genere
così spesso e se ne hai uno
situazione in cui si desidera fare
rompere le modifiche alla tua interfaccia
stai spesso mantenendo multipli
versioni dell’interfaccia del tuo servizio e
che in realtà potrebbe significare mantenere
schieramenti multipli ha senso
quindi se voglio andare dalla versione 10 punti
qualunque sia la versione 11.10 da mantenere
un’istanza della versione 10 e una
istanza della versione 11 e se lo faccio
quello che voglio avere è piuttosto esplicito
politica di deprecazione con i clienti che
stanno usando il mio servizio in altre parole che
voglio voglio andare a questo cliente e
Dico guarda la nuova versione è la versione 11
Continuerò a mantenere questo per
tu per non so tre mesi sei
mesi ciò che è la cosa amichevole
all’interno della vostra azienda ma notate che il
DevOps
idea di possedere e gestire il servizio
me stesso mi costringe ad avere un forte
incentivo per aiutare i miei clienti a svezzarsi
della versione 10 su una versione 11 lo fa
ha senso perché sto dicendo che lo sono
mantenendo entrambe le versioni fino a
ci sono clienti di cui sono clienti
il mio che sta ancora usando la versione 10 I
continuare a mantenerlo e
continuare a farlo funzionare, ma non appena io
può ottenere che l’ultimo cliente duri un client
off sulla versione 11 allora posso chiuderlo
giù e stiamo bene così io e il mio team
avere un forte incentivo per investire
nell’aiutare i clienti a spostarsi da
la versione 10 alla versione 11 lo fa
capisci di cosa sto parlando
va tutto bene così la prossima cosa su
dati e micro servizi sono dispiaciuti
la prossima cosa riguarda l’estrazione di micro
servizi da un monolite così a punto
fissiamo noi costruiamo la maggior parte delle nostre applicazioni in
rotaie e abbiamo un sacco di back-end
servizi e vai
così le rotaie ti vogliono davvero costruire
applicazione monolitica e per fortuna noi
evitato quella tentazione così abbiamo circa
40 diverse applicazioni per diversi
aree del nostro business e diverse
diverse funzioni delle persone in
aree diverse ma abbiamo fatto ma il nostro
la versione del problema del monolite siamo noi
affare ma abbiamo costruito un monolitico
database condiviso quindi non sono sicuro che sia possibile
so che immagino tu possa vedere meglio di me
può vedere ma fondamentalmente ha tutto
le entità interessanti del nostro sistema
giusto così il database condiviso che cuci
fix ha informazioni sui client che ha
informazioni sulle spedizioni di articoli che
sono quelle correzioni o scatole che inviamo
fuori ha informazioni sul
informazioni sui metadati sugli stili
e SKU che vendiamo e abbiamo nel nostro
inventario ha informazioni sul nostro
magazzini ecc ecc ecc e quindi tutto il
diverso sai tutti i 40 diversi
le applicazioni utilizzano più o meno
informazioni in questo database condiviso
ovviamente questo è un singolo punto di
fallimento questa è una singola prestazione
collo di bottiglia è una specie di sfida come
andiamo avanti per essere in grado di muoversi
molto veloce in parallelo e ottieni il vero
benefici di quelle piccole squadre
consegna continua ecc questo è il
collo di bottiglia che che ci rallenta in modo
cercheremo di sbarazzarcene e
parleremo attraverso lo schema di come
ci stiamo avvicinando così l’obiettivo qui
è disaccoppiare applicazioni e servizi
dal database condiviso quindi prendo a
un po ‘più piccolo esempio come Let’s
immagina solo così che lì
non saranno così tante scatole e linee sul
schermo in modo Immaginiamo abbiamo due
applicazioni e tre tavoli nella
database quindi il primo passo è che noi
voglio creare un servizio, diciamo
i clienti avevano ragione, i clienti erano una cosa
che abbiamo in una tabella in comune
database quindi prima creiamo un client
servizio allora abbiamo le applicazioni
quello era quello che era direttamente
parlando al tavolo ora parlare con il
servizio e ora lo estraiamo
tabella dal database condiviso e ora
ora abbiamo un servizio autonomo che è
non dipende dalla cosa condivisa e
ora non ci resta che continuiamo a fare più e
ancora una volta così ci risciacquiamo e ripetiamo come noi
come dire in America, quindi creiamo un
servizio articolo in cima agli elementi principali
tavolo creiamo un servizio di stile in cima
del tavolo SKU e ora questi sono i nostri
nuovi micro servizi giusto così ora possiamo
disegnare i confini questi sono si conosce il
la vera portata del micro servizio è questa
confine di interfaccia che circonda il
tipo di applicazione della logica aziendale a
parte del servizio e del database
questo ha senso semplici passi ora io
ha dimostrato che dentro come tutto ciò che si
minuto e potrebbe potrebbe averti
potrebbe aver pensato che stavo facendo
sembra che sia facile non lo è affatto
facile che cosa è difficile è uncut encase
transazioni che hanno a che fare con quelle
tavoli individuali quindi c’è davvero
un bel po ‘di lavoro associato a questo
ma una volta l’hai disaccoppiata
voi siete in grado di seguire questo
questo modello o questo tipo di conduttura
di lavoro che ho appena pensato di aver appena posato
out fresco ok così ora voglio parlare di
alcuni modi di trattare i dati in
microsecondi che abbiamo trovato
davvero efficace nella correzione dei punti e
cose che abbiamo fatto anche su Google
anche in passato ok così una cosa è
come possiamo fare con dati condivisi in modo giusto
nel nostro nel nostro database monolitico lì
sono un mucchio di tavoli che sono usati in
un sacco di domande diverse e in un sacco di
diverse applicazioni e come facciamo noi
affrontare così il problema qui
che il database monolitico lo rende
davvero facile da accedere al condiviso
data right Posso solo unirmi ad esso in a
segreto in una dichiarazione selezionata posso farlo
interrogalo nelle applicazioni che stai usando
un database e quindi la domanda è dove
fa che condividere database andare in a
mondo dei microservizi
e il principio qui è che lì
dovrebbe essere per ogni pezzo di dati un singolo
sistema di registrazione all’interno del generale
ecosistema complessivo quindi ogni dato
è di proprietà di uno e solo un servizio
va bene ora che l’implementazione del servizio
probabilmente ha replica e così via io
non intendo una singola macchina come me, ma io
significa un unico servizio logico che è
questa è la parte responsabile per questo
particolare pezzo di dati e quello
il servizio è il sistema canonico di
registrare per quella cosa
quindi c’è una volta che conosci l’ideale
ecosistema di micro- servizi che siamo
muovendosi verso la correzione del punto ci sarà
essere un servizio che possiede un altro cliente
servizio che possiede articoli di un altro servizio
che possiede ordini ecc. ogni altra copia di
quei dati nel nostro sistema a vicenda
posto che rappresentiamo un cliente o un
oggetto o qualsiasi cosa è una lettura sola
cache non autorevole prenditi un momento per
come lasciare che affondare ha senso
c’è un posto dove posso
aggiornalo e questo è dove effettivamente
vive in qualsiasi altro posto che si ricordi
qualsiasi cosa sugli oggetti è solo una cache di
quella cosa
quindi se si mantiene che nella parte posteriore della vostra
mente ora l’ approccio è che io sono
andando a suggerire stanno andando a fare di più
senso okay, quindi il primo approccio è
tipo di ricerca giusta in modo sincrono
Voglio trovare informazioni su cosa è
l’esempio qui sui clienti
e così il mio servizio di ordine ha bisogno
informazioni sui clienti come forse
ha bisogno dell’indirizzo per sapere dove
inviare l’ordine o qualcosa del genere
e così l’idea qui è che il
il servizio clienti è il record del sistema
per informazioni sui clienti e l’ordine
servizio chiama in modo sincrono a quello
servizio che il servizio clienti in realtà
il tempo ha senso questo è carino
semplice
ok il secondo approccio sta facendo leva
più tecniche guidate dagli eventi come abbiamo visto
nel keynote di ieri da Martin
uccellatore
così in ancora il proprietario del servizio è proprietario
dati del cliente ma al posto dell’ordine
servizio di chiamata in modo sincrono a
il servizio clienti forse l’ordine
il servizio deve essere complicato
roba con il cliente
informazioni forse e ha bisogno di avere un
cache per farlo in modo efficiente
immaginiamo che il servizio clienti
invia eventi quando i clienti sono cambiati
così detto in qualcosa come cliente
eventi aggiornati
il servizio ordini sta ascoltando quelli
eventi e il servizio ordini quindi prende
quell’informazione e la incassa localmente
e quindi ora può usare per fare il suo
roba di fantasia fare questo ha senso
quindi lo schema quando si chiama a
evento sincrono più una cache locale e
riconoscere che se mai ho chiesto l’ordine
dei servizi per conoscere lo stato di un cliente che
sarebbe sbagliato giusto sarebbe
potenzialmente stantio e dal modo in cui il
il servizio ordini non dovrebbe mai avere un
interfaccia come ho appena suggerito ma ma
tutte le informazioni nel servizio di ordine
sui clienti è potenzialmente leggermente
stantio va bene e quindi l’approccio 3 è per
cose che per dati sono relativamente
immutabile e ne abbiamo un sacco a questo
punto di correzione giusto è una sorta di immutabile
metadati di sola lettura come gli schemi delle dimensioni
è una cosa come dimensioni numeriche per
donne taglia giusta taglia per taglia 6 ecc
piccolo medio grande extra-large si sa
per altri tipi di dimensioni di una taglia
schema e questa è la cosa che non lo fa
cambia molto spesso, a destra è raro
avere alcuni nuovi extra extra
piccola o qualcosa di simile che i colori sono
cosa simile per noi tessuti negli Stati Uniti
Uniti in questo spero di Dio non c’è
nessuno che ha implementato un micro servizio
che serve sai cosa sono i
valori della umane degli Stati Uniti, ma
sì, quindi non farlo così come facciamo
con quello usiamo ancora molti di questi
roba di applicazione in Ruby così è
perché ho un po ‘che conosci lo schema delle gemme
dell’icona gemma lì, ma come se gli elementi
servizio necessario informazioni su non lo faccio
conosci colori e cose e poi stile
il servizio era necessario e riceveva il servizio
necessario questo sarebbe solo un condiviso
la biblioteca ha senso, ok
quindi quelle sono le scelte che noi
avere dati condivisi e quello che sono
non dirti che è uno di loro
meglio come usiamo effettivamente tutti quelli
tecniche che cuciono fisse per vari
varie cose dipende totalmente dal
quanto spesso cambiano i dati e cosa
il caso d’uso è ok, quindi ora voglio parlare a
un po ‘ di eventi e voglio
parla degli eventi ora perché è così
andando a darci un altro set di strumenti per
fai la prossima serie di modelli che sono
andando a parlare di dopo quindi sono un
forte credente nella cosa che Martin
ha detto nel suo keynote e non ha ottenuto un
ridi anche se lui dovrebbe assolutamente avere
quali sono gli eventi sono di prima classe
concetto costruisca dentro in programmazione e
non prendiamo vantaggio tanto quanto
davvero dovrebbe così se chiedi a Wikipedia un
l’evento è un cambiamento significativo nello stato
quindi è fondamentalmente una dichiarazione che alcuni
cosa interessante è successo nel nostro
sistema e potrebbe essere che tu lo sappia
quando produco un evento potrebbe essere questo
nessuno sta ascoltando potrebbe essere quello
il consumatore ascolta e potrebbe essere
che molti consumatori stanno ascoltando ma
l’idea è che il produttore produca
l’evento e in genere i consumatori sono
abbonarsi a quell’evento e aggiornarlo
se stessi o facendo qualcosa
interessante in base all’evento
propagato credo fermamente che
Gli eventi sono il underappreciated sai
figliastro dai capelli rossi quarto fondamentale
building block di costruzione di grandi sistemi
giusto, quindi conosciamo tutti i tre livelli
architettura dove c’è un
livello di presentazione e applicazione o
livello di logica aziendale e persistenza
strato penso che dovremmo aggiungere a questo a
concetto di prima classe dei cambiamenti di stato in
la forma di eventi in esso e questo è
gli eventi giusti intuitivi rappresentano come il
il mondo reale funziona davvero così se
pensi alla finanza
quando Deutsche Bank e Bank of America
stanno scambiando valute come se non lo fossero
fare una transazione distribuita a destra
loro stanno producendo un mucchio di
eventi su entrambi i lati in modo diverso
altro e poi si riconciliano alla fine
del giorno in cui stavo cercando di farlo come me
Stavo mettendo insieme questo discorso
avvolgendo il mio cervello per cercare di pensare
qual è un esempio davvero viscerale di
eventi nelle nostre vite bene ecco uno
per quanto riguarda l’esatto il software attuale
processo di sviluppo quindi sono un grande fan di
consegna continua ma alzi la mano
se ogni volta che premi INVIO nel tuo
IDE che viene distribuito alla produzione
qualcuno lo fa
non così perché questo sarebbe giusto folle che
sarebbe completamente pazzo
quindi quando sento persone dire che è difficile
motivo per i sistemi in cui qualcosa
succede in una zona del sistema ma è così
non si è ancora propagato a un altro e come
mi occupo di ciò a cui penso?
cosa fate 8 ore 10 ore 12
ore ogni giorno ha senso, sì
e qualsiasi cosa tu chiami un flusso di lavoro
questo è esattamente in un insieme di eventi
ha senso un flusso di lavoro è una cosa che
Lo faccio che produce un evento e poi
c’è un’altra cosa e un’altra cosa
nel flusso di lavoro un’altra cosa nel
flusso di lavoro ecc. Ok, quindi sto usando questo
per usare questo come elemento di base come me
ho appena detto di costruire qualcosa di interessante
cose che possiamo fare con i microservizi
quindi gli eventi nei microservizi vanno molto molto
bene insieme così come il
parte sincrona dei nostri eventi di interfaccia
sono una parte di prima classe dell’interfaccia
di un servizio quindi un’interfaccia di servizio
include le cose ovvie che sono simili
la parte di risposta di richiesta sincrona di
giusto così se è riposo e JSON
o G RPC o qualsiasi altra soluzione alla tua richiesta
risposte come quella è la parte ovvia
dell’interfaccia ma qualsiasi evento quello
il tuo servizio produce eventi che
il tuo servizio consuma anche quelli
parti di prima classe della tua interfaccia e
anche qualsiasi massa legge e scrive che tu
fare in dentro o fuori della vostra perseveranza
meccanismo come per gli scopi ETL o
analisi o qualcosa di simile che coloro
sono anche parte della tua interfaccia, quindi di nuovo
L’ho detto prima e farò un po ‘
stadion perché è così importante il
l’interfaccia di un servizio è qualsiasi meccanismo
che ottiene dati dentro e fuori da un servizio
ha senso fresco va bene così, ora che
abbiamo micro quindi ora abbiamo eventi
i nostri micro servizi ora lo mettiamo
insieme e fare cose più fantasiose così
si unisce quando ho un monolitico
i join del database sono super facili, quindi il
il problema qui è che mi ci abituo
giusto così ottengo il super tutto quello che devo fare è
modifica la clausola from nel mio sequel
dichiarazione e magicamente mi sono unito
insieme un mucchio di tavoli nel mio e
gruppo di entità diverse nella mia nella mia
sistema quando ho diviso quei tavoli in
servizi separati questo diventa molto
più difficile quindi ho intenzione di darti un po ‘
tecniche per farlo
quindi il primo approccio è un servizio che
si materializza che si uniscono o si materializzano
quella vista per te quindi cosa intendo io
immaginiamo che voglio produrre
qualcosa come un servizio di feedback degli oggetti
come si sentivano le persone a punto fisso?
oggetti e con gli elementi che abbiamo inviato a
loro pezzi di abbigliamento e quali
le persone le abbiamo mandate e andiamo
immagina che lo useremo per alcuni
scopo algoritmico più tardi così così
il modo in cui lo faremmo è l’oggetto
il servizio produrrà eventi quando
gli articoli sono aggiornati o aggiunti nel sistema
il servizio di ordine sta per produrre
aggiornamenti ed eventi sugli ordini che cambiano
nel nostro sistema e lo saremo
accumulandolo nel nostro articolo
Servizio Veck e fondamentalmente denormalizzante
il join tra articoli e ordini così dentro
questo modello non stiamo facendo il join in
in tempo reale al momento della query stiamo facendo il
unisciti a noi stiamo reificando stiamo denormalizzando
il join prima del tempo lo fa tipo di
concettualmente ha senso di cosa sto parlando
Sì, quindi l’idea è che siamo noi
mantenendo un join denormalizzato di elementi
e ordini insieme nel nostro magazzino locale
nel nostro piccolo conoscete il database o
qualunque cosa per questo servizio e questo
usi questa tecnica quando hai un
numero molto alto di file su ciascun lato
quindi si chiama cardinalità elevata e
termini del database quindi se ne ho un sacco
articoli e molti ordini per quelli
voci questa è una grande grande cosa da fare
quindi se questo sembra davvero strano cosa io
Ho appena suggerito che voglio che tu faccia un passo
indietro e pensare che in realtà non vi
sono tonnellate di sistemi che usi
questa tecnica esatta così quasi ogni no
approccio seguito si avvicina le cose in
in questo modo proprio nei database relazionali
lo rendiamo super facile scriviamo
cose individuali e poi noi
ricostruire le cose insieme alla query
tempo e soprattutto la maggior parte nessun sequel
si avvicina al modo in cui lo fai, sei tu
calcola effettivamente al momento della scrittura
le domande che vuoi eseguire così tu
non posso eseguire interrogazioni arbitrarie ma tu ma
calcoli a tempo di scrittura fai il
denormalizzazione a quel punto e questo è
esattamente la tecnica che ho appena
descritto un altro esempio è la dicitura
che in realtà ho usato qui così tanto
sistemi di database Oracle ecc. Ho un
concetto di una visione materializzata giusta
forse è molto costoso iscriversi
articoli e ordini insieme perché lì
sono così tanti e quindi cosa tu cosa
dire al sistema di database di fare è come
mantenere quella vista per me denormalizzare
tutto il tempo e fammi interrogare la Corea
rapidamente i motori di ricerca funzionano in questo modo
giusto così qualcuno usa Elasticsearch
ha questo strumento nella sua analisi degli strumenti
i sistemi sicuramente fanno proprio questo
utilizzo del data warehouse o del sistema analitico
questa tecnica e in realtà registro
gli aggregatori hanno ragione sulle cose da portare
singoli registri insieme che è anche un
unirsi così è questo che ha senso
sentirsi più familiare su questo
Scivola forse che l’ ultima va bene così
ecco la prossima tecnica la prossima
la tecnica è semplicemente unirsi a
runtime right so join tra join
l’applicazione o
mai servizio al cliente che si sta utilizzando in modo
immaginiamo che qui il caso d’uso
qui voglio mostrare una cronologia degli ordini
pagina quindi voglio mostrare ad uno dei nostri
clienti tutti gli ordini che hanno
più alcuni metadati su se stessi come
forse il loro nome o quante scatole abbiamo
inviato loro o qualcosa del genere così il
l’idea è che stiamo per prima interrogare su
al servizio clienti e ottenere il
record del cliente per te lo sai
particolare cliente e stiamo andando a
interrogare al servizio ordini e
stiamo andando a dire di trovarmi tutto il
gli ordini corrispondenti per questo diritto cliente
super semplice questo ha senso, sì e
come lo faremmo in un monolitico
database con cui sarebbe solo unirsi
siete tutti due nella clausola from
bene ora lo stiamo solo facendo
nella giusta applicazione siamo solo
semplicemente andando in un posto per ottenere una metà
di unirsi a un altro posto per ottenere il
l’altra metà del join e questo
tecnica distinta dal precedente
uno è il migliore per i casi in cui ho un
singolo cliente, quindi un singolo che conosci
un lato del join e più ordini
dall’altra parte del join così dentro
termini del database l’altro era M
e M a N e questo è in 1 a n join
questo ha un senso fantastico, ne sono sicuro
sembra abbastanza familiare alle persone ma se
non lo hai fatto per tutto il tempo
applicazione che va a quella che è
come costruire una pagina su due
diverse fonti di dati lo fa
giusto così se tu se visualizzi una pagina
che ha qualcosa di più di una query
tipicamente stai facendo un join come questo
proprio tu stai andando in un posto a cercare
un pezzo di informazione una entità
e stai andando in un altro posto forse
ottenere i dettagli o cercare un’altra entità
quello che è collegato a questo ha un senso freddo
Va bene, ne faremo un passo avanti
tacca quindi voglio parlare di flussi di lavoro
e qualcosa chiamato saga così il
il problema qui è scrivere le transazioni
le transazioni sono fantastiche sono così divertenti
e così facile e così facile a
database monolitico effettua transazioni
attraverso più entità banalmente facile
questo è quello che è uno dei grandi
cose su database proprio così se
stai usando un database relazionale tu
ottenere transazioni acide che posso aggiornare a
record del cliente e tutti i suoi ordini a
nello stesso tempo tutto in una transazione e
è facile una volta che li ho divisi
tabelle in due servizi separati questo è
davvero difficile quindi la risposta è molto
non fare una transazione distribuita con a
commit a due fasi, per favore non farlo
quello che ucciderà la tua scalabilità e
essere un vero collo di bottiglia delle prestazioni ma
vuoi ancora avere tutto questo
succede tutto in una volta o non va affatto bene
quello è l’a e gli acidi che voglio fare
certo che ho alzato alla fine della giornata
Aggiorno le due entità allo stesso modo
tempo o va bene o non aggiorno neanche
vanno bene così il trucco qui è che noi
voglio trasformare quella transazione in quel super
transazione facile in un po ‘di più
complicato ma scalabile ma più scalabile
la cosa ha chiamato una saga quindi una saga è un mucchio
di trent di passaggi collegati da eventi
sono fondamentalmente una macchina a stati
modelleremo questa transazione
attraverso più entità come stato
macchina di eventi atomici singolarmente
e una volta che facciamo un evento, lo faremo
faremo la prossima parte di ciò che faremo
la prossima parte faremo la prossima
parte bene quindi l’idea è quella di
ri-implementare questa cosa come un flusso di lavoro così
immaginiamo che volevamo originariamente
aggiorna come e B e C insieme
in una singola transazione atomica in a
il mondo dei microservizi distribuiti non è possibile
fallo in un colpo solo ma alla fine puoi
del giorno alla fine di questo flusso di lavoro
farlo accadere o non accadere così l’idea
aggiorni il a a manda un evento
quell’aggiornamento aggiorneremo il B
che invia un evento a cui stiamo andando
aggiornamento per vedere che invia un evento lo farà
aggiorna D ottenendo il rollback di
facendo ciò che viene chiamato compensare
transazioni o operazioni di compensazione
lì dentro al contrario nel retro
quindi se abbiamo avuto un fallimento lungo la strada
invierebbe eventi per tipo di ritorno
attraverso questa catena torna l’altro
direzione attraverso la macchina di stato e
tipo di annullare le cose che abbiamo bisogno di
fai bene, così rimuoviamo tutto il DS che noi
aggiunto o provato ad aggiungere che poi quello
dice gli eventi e questo verrà rimosso
tutte le tasse e rimuovere tutte le B e
la rivoluzione ecc. lo fa almeno
concettualmente ha senso, sì, è così
più complicato di un database
transazione che non ho intenzione di dirti
altrimenti, ma almeno lo è
almeno una prova dell’esistenza questa è una cosa
che in realtà puoi farlo è così
è il modo in cui puoi ottenere il tipo di
caratteristiche transazionali
qualcosa di simile alla traccia transazionale
caratteristiche quando sei nel micro
mondo dei servizi, quindi, ancora una volta voglio portare
questo torna a qualcosa che è forse di più
viscerale per le persone quindi se lo pensi
nessun sistema funziona come ho appena descritto
non è vero ci sono in realtà un sacco di
sistemi che funzionano in questo modo e sono
davvero complicato praticamente nulla
che hai parlato come un flusso di lavoro
funziona come ho appena descritto
così l’elaborazione dei pagamenti a destra la si
inizia con te sai per favore prendi 50
dollari fuori da questo credito clienti
carta e metterlo nel nostro account ci sono
un sacco di passaggi che entrano in quello
flusso quei passaggi non sono fatti in a
unico database atomico immediato
transazione giusta non attraversiamo
tutti i diversi emittenti di carte di credito
e banche e acquisizione di cose e tutto
quel genere di cose che non succede
come una transazione che accade come a
flusso di lavoro o una serie di passaggi o saga di
cose individuali collegate da eventi
e tutto ciò che parliamo di qualsiasi cosa siamo
stiamo parlando dell’approvazione di qualcosa
come un flusso di lavoro di approvazione come un
rapporto spese magari nel tuo dentro
la tua compagnia che scorre attraverso di te
deve essere approvato da persona X poi Y.
persona allora Z persona questo è esattamente il
stessa cosa giusta e se qualcuno al
fine della catena o al più alto livello
della catena dice no le spese di Randy
così sai che Jazz Club mi dispiace
non è qualcosa che copriamo
più è il peccato, ma va bene così va
di nuovo giù alla catena e come ottiene
respinto fino in fondo e forse se io
può convincere il mio capo che non è lì
in realtà era uno scopo commerciale per il mio
andando al Jazz Club e sì, allora
forse puoi tornare su di nuovo lo fa
ha senso sì sì okay così così
non sarebbe stato magazzino non sarebbe completo
senza almeno un cenno a serverless
giusto così uno dei più interessanti di
i casi d’uso forse ovvi per il servizio
le funzioni tecniche del servizio è
esattamente la cosa che ho appena descritto
quindi un uso ideale delle funzioni come a
servizio o quello che chiamiamo server
liste è questo prodotto super leggero
elaborazione che facciamo in quello in quello
catena di eventi in una di queste saghe
giusto quindi immaginiamo che fa il suo
l’operazione B fa un po ‘ di
in lavorazione
e poi sai invia un altro evento
lei fa un po ‘di elaborazione ecc
quelli sono come logica super leggera
quelli sono probabilmente esempi di ciò che sai
dieci righe di codice venti righe di codice
molto semplice se si arriva fino ad
che logica è che sono apolidi
sono attivati ​​da un evento e
poi fanno le loro operazioni e poi
producono altri eventi dall’altra
lato e quindi sono perfetti per
qualcosa come Amazon lambda o Google
Funzioni cloud o qualcosa di simile
questo ha senso, sì, è ovvio ma
diciamo solo ad alta voce i servizi di Micra
non sono la risposta ad ogni problema
l’elenco dei server dei servizi non è la risposta
ad ogni problema ma questi sono giusti
strumenti che abbiamo nella nostra cassetta degli attrezzi e a
un’azienda sana ora e in futuro è
probabilmente sta per essere combinato
tecniche che utilizzano i micro servizi per a
un sacco di cose usa serverless o
funziona come un servizio per un sacco di
altre cose che sarà possibile fare
qualcosa in cui diciamo funzioni
la lista dei server traccia ieri lì
è stato un grande esempio da uno dei
presentatori su come questo costruito
tutta la compagnia e tutto il suo elearning
sistema attorno agli eventi è fantastico
ma la grande maggioranza dei sistemi lo sono
sarà una combinazione tra
diverse tecniche proprio come sono
oggi va bene così voglio finire
tempo qui quindi voglio solo riassumere un
un po
così di nuovo lo sviluppo del software moderno
fare le cose rapidamente ed efficacemente
a in un ambiente altamente incentrato sui dati
come abbiamo a punto fisso così per
organizzazioni lo raccomando vivamente
il modo in cui ci muoviamo velocemente e
in modo efficiente è con piccole squadre con
aree di responsabilità ben definite in
termini di processi e pratiche
sviluppo guidato da test e continuo
consegna in termini di cultura a DevOps
cultura della proprietà e che si costruisce
lo esegui e infine fai leva
lo strumento almeno in una certa scala
sfruttando i micro servizi come il tuo
approccio tecnologico qui quindi grazie
molto Sarei negligente se non l’ho fatto
fai sapere a tutti che è stata la correzione del punto
assumere
quindi quei 75 ingegneri che speravamo di fare
crescere un po ‘più là il link è
qui stiamo assumendo un’applicazione
sviluppo e scienza dei dati e
piattaforma ovunque siamo basati in San
Francisco ma in realtà più della metà di
gli ingegneri del mio team sono remoti e
essi
da tutti gli Stati Uniti
a volte dalle loro case a volte
dagli uffici più piccoli che noi
avere in altre parti del paese
come Pittsburgh e Austin, quindi sentitevi liberi
per afferrarmi personalmente lo sai mentre sono
qui sarò qui per il resto del
giorno puoi twittare su di me a Randy shout
o connettersi con me su LinkedIn ci piacerebbe
se qualcosa di tutto questo suona davvero
interessante vuoi saperne di più
Sarei felice di parlare con te così
grazie mille
[Applausi]

Please follow and like us: