okay ciao, il mio nome è James così com’è
già stato sottolineando ho intenzione di
parleremo oggi di sistemi di costruzione
che non sono mai stati fatti così è questo discorso
davvero su di esso è davvero su di me
pensando a tutte le pratiche che ho
imparato nel corso degli anni come un software
ingegnere come sviluppatore e se
sono applicabili nel mondo di
costruire micro servizi è così
davvero di cosa parla questo perché è così
chiamato mai fatto bene mai fatto
c’è un certo numero di significati proprio il
il primo significato che non ho mai fatto è
qualcosa che è incompleto, giusto così
Intendo quando parlo di costruzione
sistemi che non sono mai stati fatti
sistemi di costruzione incompleti
tornare a quell’aggiornamento rapporto caos
da questa mattina sai che non voglio
essere in quel 50 per cento dispari di
sviluppatori che stanno costruendo edifici
software che non funzionerà mai o mai
non entra mai in produzione, quindi non lo faccio
significa davvero che questo non è ciò che intendo
mai fatto invece ho pensato
su cosa significa costruire sistemi
che si distinguono quell’ultimo destra che si distinguono
la prova del tempo e per me in realtà
è qui che sono stati avviati i micro-servizi
dove ho iniziato ad interessarmi
questo è stato in risposta a parlare con
molte persone da diversi
comunità di software in modo che il dominio
comunità di progettazione guidata il tipo di
la comunità di integrazione così piace alla gente
Judy per fare del male a persone come Jimmy Neilson
persone in questa e integrazione web
comunità così la comunità di riposo nel
comunità di messaggistica e abbiamo ottenuto
insieme come gruppo come un gruppo di persone
e quindi stavamo parlando di sistemi e
perché i sistemi stanno diventando così grandi ma
praticamente abbiamo passato tre giorni a provare
per capire perché stavamo tutti costruendo
prodotti che non avevamo poi sostituito
dopo un paio di anni e per me quello
quella era la chiave è come quello che è
su questi sistemi che significa di
applicazioni che costruiamo che il
sistemi che stiamo costruendo significa
non durano più di
più di due o tre o quattro anni abbiamo
dobbiamo buttarli via, dobbiamo andare
torna per tornare ai nostri team di gestione
i nostri dirigenti e chiediamo altri 10 milioni
Euro per ricostruire qualcosa, quindi ci sto provando
pensare di non aver mai fatto in quello in
senso di costruire sistemi che durino
quello resiste la prova del tempo così invece
di questa diversa questa definizione di
loro sono stati incompleti, lo farò
usa questa definizione da una spugna
libro a cricchetto prenota il quinto elemento così in spugna
Pratchet è un autore fantasy inglese lui
è morto tristemente un paio di mesi fa
ma ha scritto oltre 40 libri uno di
che è l’ elefante del quinto elefante e
in questo libro descrive a
la storia è un nano con una grande barba lunga
e un’ascia che racconta una storia sulla sua
ascia della famiglia e questo è il modo in cui mi piace
pensa al suo edificio
sistemi in questi giorni sulla costruzione
sistemi che non sono mai stati fatti e lui
descrive l’ascia della sua famiglia, dice lui
lui dice che questa ascia è stata nella mia
famiglia per 900 anni questa è la mia famiglia
ascia e parafrasare ovviamente sopra
tempo ogni parte di questo asse è cambiata
Ho sostituito la maniglia che abbiamo
a volte sostituiva la lama dell’ascia
abbiamo avuto un intaglio di nuovi regali in
il manico a volte abbiamo sostituito il
gestire di nuovo a volte abbiamo sostituito
di nuovo la testa , ma questo non è il mio
ascia della famiglia 900 anni dopo e questo è
una rivisitazione di una storia in cui è un
antica specie di pensiero filosofico
Sperimenta la nave del thieve thebes
e l’esperimento mentale che esiste è
questo se hai una nave che dura 300
anni e ogni singolo pezzo di quello
la nave è stata sostituita su quelle 300
anni alla fine del trecento
anni in cui non è rimasto nulla del
nave originale è ancora la stessa nave
Terry Pratchett usa questo nel mio
atto di famiglia e penso che sia così come noi
dovrebbe essere pensando di costruire
sistemi Chad Fowler L’ ho visto parlare
recentemente ha avuto una bella frase che ha detto
il ragazzo dell’ID di Nizza ha detto che dobbiamo reclamare
la parola legacy è la sua eredità e IT
connotazioni terribilmente cattive
sai che l’eredità è un’eredità negativa
il codice è una cosa brutta
i sistemi legacy sono cose cattive e io sono
l’accusa stava dicendo bene ciò di cui abbiamo bisogno
fare è guardare in eredità in a
luce positiva come Mozart o Bach lasciati
un’eredità hanno lasciato un’eredità positiva
come vogliamo lasciare un’eredità al nostro
i nostri figli vogliamo lasciarli
qualcosa che è positivo no
negativo e quindi questa idea di recupero
legacy questa idea di sistemi di costruzione
che dura quella portata che si estendono decente
periodo di tempo ma composto da più piccoli
sistemi composti da microservizi che
può essere sostituito individualmente, ecco cosa
Intendo costruendo un software che non è mai
fatto costruire software che dove il
sistema nel suo complesso il sistema nel suo complesso
dura per un periodo di tempo un lungo periodo
di tempo ma i singoli componenti di
che può essere può essere cambiato o lo sono
cambiato nel tempo Fred se senti il
parlo un minuto fa, di cui stava parlando Fred
uno dei motivi per cui potremmo volerlo
whoops potrebbe voler utilizzare i microservizi
o il motivo per cui le persone stanno parlando
sui microservizi Adriane Cockroft e
Netflix è molto chiaro in questo che vogliono
usare un servizio orientato ai servizi
architetture perché vogliono andare come
velocemente possibile vogliamo andare più veloce
per tutte le ragioni che abbiamo sentito
circa prima, quindi conosci la concorrenza
le startup concorrenti stanno prendendo il nostro
quota di mercato che ha bisogno di entrare nel nostro
ciclo decisionale dei concorrenti a
innovare più velocemente di loro che dobbiamo essere
in grado di andare il più velocemente possibile e in
la teoria dei micro servizi dovrebbe fare per noi
che oltre a essere sistemi che durano
dovrebbero permetterci di apportare modifiche
davvero molto velocemente e abbiamo avuto
esempi precedenti del nostro di un
architettonico di una di un’implementazione
di un’architettura di microservizi che
ti permette di farlo così questo è ciò che io
un po ‘di speranza per un micro
servizi basati su architettura bene te
sanno che dovrebbero essere economici da sostituire
nel tempo dovrebbero essere veloci da ridimensionare
dovremmo essere in grado di portare cose e
portare cose giù e dovrebbero essere
robusto resiliente in grado di resistere
fallimento
la vecchia linea internet non è un
tessuto cinque-nove non è mai stato più
appropriato e questo ci dovrebbe permettere di
vai il più velocemente possibile, quindi vado a
coprire rapidamente alcuni della stessa terra
che Fred non ne ha fatto molto però
questa è una citazione da da Neal Ford voi
conoscici rispondendo alla domanda o
tentare di rispondere alla domanda perché
ora e la risposta di Neal’s Mill a questo
la domanda era buona, è il primo post
Lo stile architettonico DevOps è il
prima il primo tentativo che abbiamo fatto come un
industria e pubblica questo post di DevOps
movimento in via di sviluppo della cultura DevOps
l’ edificio che sta sviluppando la cultura
per sviluppare uno stile architettonico dare
fino a sviluppare sistemi in modo diverso Dan
North che è un altro ex collega
piace quello che Fred e molti altri che hanno
è stato coinvolto in questa comunità che ha
una diversa interpretazione dei microservizi in
Infatti lui odia il nome micro-servizi lui
pensa che sia un nome terribile che preferisce
il molto meno scattante a mio avviso ma
non meno meno sostituibile
l’architettura dei componenti è ciò che siamo
parlando con microservizi
architetture dei componenti sostituibili
sistemi che non sono mai fatti che possono essere
cambiato nel tempo dan wolf ha perso il
battaglia di battitura si verifica quando Martin
Fowler ha nominato qualcosa che rimane così chiamato
scusa Dan ed è interessante perché
c’è un altro tema che attraversa
Le parole di Fred riguardavano il modo in cui stiamo imparando
come stiamo stiamo imparando come costruire
questi sistemi sono composti da
sistemi più piccoli e in qualche modo il
il futuro è piuttosto spaventoso e sto solo andando
prendere un momento per spiegare cosa intendo
da questo futuro che stiamo vivendo in o
la caratteristica che stiamo per vivere in
o qualcosa di essere un po ‘spaventoso così
questa è una citazione di alcuni decenni fa
ora è attribuito a John von Neumann
una Polonia matematico polacco chiamato
stanislav Stanislaw ulam che ha lavorato
strettamente con Newman registrato a
conversazione che ha avuto quando Newman ha parlato
a
il concetto di singolarità a
singolarità tecnologica basata sul
Infatti, per esempio, l’ hardware del computer
stava diventando più veloce, dice sempre
accelerando il progresso e i cambiamenti nel
la modalità della vita umana ci dà il
aspetto di avvicinarsi ad alcuni essenziali
singolarità nella storia della razza
oltre il quale gli affari umani come sappiamo
loro non potevano continuare ora ho visto a
single arity con i miei occhi e questo
successo un paio di anni fa questo è un
pannello per andare a chi è ed è
interessante perché vai dal nostro who’s that
anno era un paio di due anni fa I
pensare il feedback che è stato ottenuto da
il da parte delle persone che partecipavano
la conferenza è stata per molto tempo un tema
del perché non ci parlano gli oratori
cosa fare ci sono state molte conferenze
parla di diverse tecnologie
e sulle diverse tecniche
come microservizi ma nessuno ne aveva
risposte concrete davvero da dare e questo
è una specie di strana singolarità in cui
molte delle persone più famose di
nel nostro settore ma una specie di scrollata di spalle
le loro spalle un po ‘ e dicendo noi
non so davvero cosa succederà
al momento ci sono tutti questi strumenti
in fase di sviluppo c’è tutto questo nuovo
queste nuove pratiche questi nuovi principi
questo nuovo stile così uno di questi intendo
potresti riconoscere che questo è da a
pochi anni fa, ma era meravigliato
dove probabilmente era l’anno scorso che il
La singolarità di JavaScript ti è successo
non può superare uno sviluppatore JavaScript
senza tre nuove librerie MVC in calo
fuori che tasca destra ha JavaScript
appena esploso ma anche conosciuto allo stesso modo
i contenitori hanno sperato che no
esploso contro la tecnologia dei contenitori
e aziende che sviluppano container e
diverse soluzioni di container basate
le soluzioni stanno esplodendo c’è questo
tipo di strana somiglianza contenitore e
come accennato in precedenza sono parte del
pensato consiglio di consulenza tecnologia Wix
e abbiamo messo insieme questo TechRadar
e ne abbiamo notato un altro e il
l’altro che abbiamo notato ha a che fare con
cose come l’ aggregazione dei log così lunga
singolarità aggregazione non puoi
non posso parlare
a qualcuno che durante le operazioni o la perdita di
il personale sviluppa il ruolo in questi giorni
senza di loro che ti dicono 15
aggregazione di log diversa ti famiglie
dovrebbe usare lo stack ELQ no no
stiamo andando a utilizzare log di registro scorta
e chiave barlen no no no è necessario acquistare
spunk al quale la risposta è avere te
hai quanti soldi hai avuto ragione?
perché lo sperma essenzialmente succhierà tutto
i tuoi soldi da te, quindi è meglio che tu sia
in grado di sostituirlo abbastanza rapidamente ma
ci sono queste singolarità diverse
che stiamo vivendo e come
beh, c’è questa specie di micro
servizio singolarità verificano così sorta di
più vicino a casa per noi come abbiamo progettato
il software sta decisamente cambiando basandosi su
basato su tutti questi diversi strumenti
sviluppato le pratiche i principi
e come ho detto un minuto fa, sai
quando Martin nomina qualcosa , rimane
Nomi questo è il nostro tentativo Martin mio
provare a descrivere le caratteristiche
di uno stile architettonico microscopista
quindi eravamo molto chiari qui che non eravamo
cercando di definire quali sono i micro servizi
stavamo cercando di descrivere quello che eravamo
vedendo le squadre fare in natura abbiamo parlato
sui servizi di acquisto di containerizzazione
organizzato intorno alle capacità di business
e così via, è fantastico perché le squadre
stanno avendo un sacco e molto successo
proprio con lo stile dei micro servizi
ci sono molti molti software esistenti e
prove di esistenza di aziende che sono
avendo successo con questo inizio dal
grande il Netflix e il Twitter e
i google e gli eBay e i
documenti ecc. per i più piccoli al
startup che stanno costruendo edifici
architetture basate su micro servizi ma
ci sono alcuni problemi davvero difficili da
risolvi con microservices il primo I
pensare è un problema veramente difficile è come
hai fatto test end-to-end quando
si sta costruendo un micro di servizio
architetture basate quindi questo è qualcosa
che abbiamo abituati a più di un
periodo di tempo e nel nostro settore del
capacità di saperlo funzionare essenzialmente
test di livello del prodotto in cui testiamo
dall’esterno forse usando a
browser o qualcosa o forse guidare un
API e questo metterà alla prova tutti i nostri
codice o almeno testare il percorso felice
forse il tuo utente viaggia attraverso il nostro
codebase questo tipo di automatizzato
i test end-to-end sono davvero preziosi
per noi sapere se il nostro software è
lavorando o no ci dà un feedback come
parte del nostro ciclo di costruzione davvero davvero
utile la prossima cosa è come facciamo noi
distribuire queste cose in modo indipendente come fare
evitiamo di dover distribuire un sacco di piccoli
cose in scioglimento perché il pericolo di
corso quando si separano le applicazioni
è in molti piccoli micro servizi
che tu vada da una grande palla monolitica
di fango pieno di codice spaghetti ad a
monolite distribuito e distribuito grande
palla di fango dove tutto è stretto
accoppiati e hai dovuto distribuire tutto
insieme non vogliamo ciò che vogliamo
evitare di fare cose come la distribuzione in lotti
passo come lo facciamo e il prossimo
cosa è che abbiamo colpito un po ‘di questo a
minuto fa come facciamo il servizio
versioning come possiamo evolvere questi questi
servizi indipendentemente dato che noi
voglio schierarli da soli
dato che vogliamo o dato che lo è
difficile da testarli end to end sì
e questi sono problemi reali e noi siamo
imparando come risolverli non penso
se qualcuno ti dice che hanno il
rispondi a ciò che sono loro
dicendoti la verità se sono onesto, lo sono
anche un consulente dal modo in cui così
dipende è la mia risposta predefinita a questo
ma come facciamo questo e abbiamo
approcci e questo mi ha portato a pensare
riguardo se abbiamo se possiamo
ancora fare affidamento su alcuni degli altri strumenti in
la nostra cassetta degli attrezzi ne parlerò in a
momento
quindi cosa intendo testando
microservizi è difficile, quindi abbiamo un
paio di anni di servizi come un veloce
esempio
Sto usando quella piramide di prova così
test di grandi dimensioni medi e piccoli piccoli
probabilmente unità di test più grandi del tipo di
test end-to-end i test del prodotto sono
chiamandoli grandi non è qualcosa di simile
fine alla fine perché è un po ‘come
la VY Emacs combatte proprio se tu se tu
dire end-to-end di qualcun altro vuole
chiamali test di viaggio dell’utente o
test di accettazione o test di integrazione o
qualunque sia così grande prova prove che quella
testare l’esecuzione e coprire molti dei nostri
applicazione molto del nostro prodotto e in
che tipo di scenario vogliamo scrivere un
test che sta per guidare uno dei nostri
servizi e sarà necessario
integrare con un altro dei nostri
servizi quindi cosa c’è di così difficile
bene a un tratto dobbiamo pensare
creare ambienti per distribuirli
le cose nel dispiegare un sacco di diversi
le cose vanno bene se devi
forse se ne hai un migliaio
servizi diversi puoi scrivere un
test end-to-end che al momento del commit
qualche codice e codice passa attraverso il tuo
costruire una pipeline che verrà eseguita
contro il nuovo pezzo del nuovo servizio
e un migliaio delle sue dipendenze in
una specie di ambiente di test come fai
effettivamente farlo
è abbastanza complicato e ciò che abbiamo ordinato
di cui parlavo davvero oltre il
gli ultimi due anni non stanno facendo così
in realtà testiamo sempre queste cose
isolamento come parte della citazione
test end-to-end in modo da eliminarli in alcuni
modi con test di integrazione e
l’ ambiente di integrazione invece utilizza
mozziconi sociali che sopprimono qualsiasi esterno
dipendenze in un servizio un’altra cosa
è piuttosto difficile e questo è piuttosto un
il punto sottile è in questo questo no
solo il test del test end-to-end
di questi servizi il livello del prodotto
test di questi servizi diventando
difficile ma integrando questi servizi
costruirli autonomamente servizi
passerà attraverso o totale passaggio
costruire la pipeline in fasi questo è
generalmente
succede quando scriviamo questi software
giorni e li stiamo seguendo da Tania
pratiche di consegna e va bene quando
hai una grande applicazione perché tu
avere una pipeline di costruzione e passa
attraverso di esso e poi viene schierato
potenzialmente automaticamente in
la produzione è geniale è stata
verificato funziona ma improvvisamente se lo hai
ho dieci pipeline di costruzione o cento
costruire pipelines e tutti questi servizi
stanno parlando potenzialmente l’un l’altro
come facciamo quel lavoro, ma in un modo il
il modo tradizionale sarebbe quello di fan-in e
distribuire queste cose in un’integrazione
ambiente li distribuiremo in alcuni
ambiente di test di integrazione ed esecuzione
una serie di test di integrazione contro di essa
che va bene se ne hai uno molto piccolo
numero di cose, ma quando ti dico
finisco con molte di queste cose che sono
avere lo stesso problema con il
clicker mentre Fred si trovava lì
quindi torno indietro quando ne hai un sacco
di queste cose questo diventa quasi
geometricamente più complicato perché
cosa dovremmo fare quando ognuno di
queste cose cambiano è distribuire il
l’ambiente di integrazione esegue alcuni test
contro di loro per quello che succede con il
condizioni di gara di me che commetto o
un’altra squadra che ha commesso un codice a un altro
uno dei servizi, che passa attraverso
la sua propria pipeline di costruzione entra in gioco
lo stesso ambiente di integrazione cosa
succede se scrive oltre una versione
un’altra pipeline dipende da bene
forse dovremo crearne un altro
ambiente di test di integrazione bene lo faremo
avere i test di integrazione per ciascuno
delle singole pipeline è basato su
le sue dipendenze produttive e quindi
ci faremo spingere in quella ed eseguire alcuni
test di integrazione contro la produzione
versioni di ciò che accade sul punto morto
e le condizioni di gara piuttosto noi
creare un altro ambiente di integrazione
per la costruzione di condotte quindi abbiamo improvvisamente
a con le dipendenze dello snapshot e tutto
le dipendenze di produzione improvvisamente
inizia a diventare molto complicato, se lo fai
ottenuto 10 servizi che stai parlando in
usando quell’approccio devi
ambienti di integrazione da costruire
pipeline volte il numero di servizi così
questo lo sai che è un po ‘complicato
quindi forse questi sono esempi di alcuni di
le pratiche che abbiamo seguito
come parte di te usando XP, le pratiche di XP
e cose che non sono necessariamente
più a lungo che valido e parlerò
su alcuni approcci per affrontare questo
più tardi, ma come ho detto stavo pensando
circa poi le altre pratiche che abbiamo
vengo a fare affidamento su e sì io lavoro per
il pensiero funziona come è stato menzionato
e mentre siamo un piccolo agile un negozio così
noi non lo diciamo veramente bene
sappiamo che siamo un misum shop o
qualunque cosa, ma la cosa che io penso di noi
probabilmente tutti sarebbero d’accordo sul fatto che lo fossero
siamo un negozio di programmazione estremo che abbiamo
aveva un programma su praticamente tutto
siamo sì, abbiamo usato i test scritti
sviluppo progettiamo il nostro codice attraverso
test seguiamo un carico dei principi
che potresti aspettarti da XP e
da cose come l’artigianato del software
programmatore di formattazione del codice pulito così
progettazione emergenti e Gang of Four di progettazione
i modelli mantengono semplice la presa
modelli questi sono tutti strumenti che hanno
stato nel nostro toolkit per un bel po ‘
periodo di tempo come cose come
test di integrazione come cose come
gli ambienti di integrazione sono ancora qui
valido quando stiamo costruendo sistemi
compositori di piccoli micro servizi che è
quello che stavo pensando stavo chattando con
con un amico nel ragazzo degli Stati Uniti
chiamato Russ Olson che è un ragazzo fantastico
ha fatto un discorso fantastico allo skew Khan
Londra credo che era stato chiamato a
la luna ed era su di lui ricorda
il suo lui che ricorda la luna dell’Apollo
atterraggi e ciò che noi, come ingegneri, possiamo
prendi dagli sbarchi sulla Luna di Apollo e
l’ingegneria che li ha coinvolti
fantastico fantastico ha scritto e lo farei
consiglio di guardarlo fino alla luna ma
Russ Russ mi ha raccontato quest’altra storia
sulla NASA e sulle prime fasi di
il nostro lo sai dello spazio con equipaggio
esplorazione e lui mi parla di questo
questa cosa questa è la JIT di cui fa parte
del progetto Gemini e con il
Progetto Gemini inizialmente voluto
atterrare su una pista utilizzando un deltaplano
giusto che potrebbe sembrare un po ‘strano ma
se si pensa di nuovo al sì credo
I primi anni ’60 la NASA era composta da un gruppo
di persone che erano essenzialmente
ingegneri aeronautici e piloti così
questo è ciò di cui Masen era composto e
quando sono stati incaricati di progettare a
nave spaziale che sarebbe andata essenzialmente
nello spazio essere lanciato nello spazio sopra
la terra e poi tornare indietro
c’è un test essenzialmente per il
Programma Apollo che va sulla luna
ingegnere aeronautico e piloti
tornato a quello che loro tipo di
sapeva meglio e quello era l’atterraggio di aerei
piste che è gentile di in questa
ambiente chiuso e questo questo tipo di
aveva senso per loro in base al loro
esperienze e poi qualcosa di divertente
successo e quello era un program manager
è venuto da esternamente al gruppo e lui
dai un’occhiata ai loro piani in realtà questo
questo tipo di lavoro ha funzionato in questo modo
atterrò la capsula dei Gemelli fu in grado di farlo
andare nello spazio e atterrare su un blocco usando un blocco
aliante
ma questo project manager ha preso un
guarda questo program manager dai un’occhiata
a questo e ha detto bene che fondamentalmente
Detto Sei pazzo um questo genere di
vieni dall’esterno e mangia questo
è un tipo pazzo di approccio alla risoluzione
questi problemi quello che vuoi fare
perché è molto più semplice e molto più economico
e molto più sicuro per tutti gli interessati è
in sostanza cinturino un paio di grandi
paracadute in alto e drop drop it
nel mare e poi lo faremo
raccoglierlo e questo è quello che è finito
accadendo è quello che è successo
anche con Apollo, così ero
pensando a questa idea di qualcuno
entrando e guardando esternamente
guardando le nostre pratiche e il loro ISM
e anche questa idea di ridimensionare i livelli
di astrazione quindi abbiamo micro
servizi abbiamo tutte le pratiche che noi
capire come scrivere codice pulito
come scrivere sai ben progettato bene
blah design dice del tuo codice orientato
beh, che aspetto ha?
contesto di chunking fino al livello di
micro servizi e micro servizi basati
architetture come pensare che
e questo è ciò che il resto di questo è
circa e quello che pensavo fosse essenzialmente
sono le tartarughe fino in fondo
Tartarughe completamente dagli oggetti
funziona fino ai sistemi di
sistemi e quindi ho intenzione di spiegare
forse il mio ragionamento e forse spiegherò perché
alcune delle cose su cui siamo venuti a fare affidamento
secondo me dopo aver pensato un po ‘
questo è ancora valido
quindi la prima cosa di cui voglio parlare
è fuori da questo grande gruppo di grande gruppo di
le tecniche non le coprirò tutte io
potrebbe parlare di World of Warcraft a
Alla fine se la gente vuole davvero che io e
la prima cosa che ho intenzione di parlare di
è l’agonia quindi ora le mani in alto
spazio per le persone che hanno incontrato il
non ti servirà l’ agonia
va bene questo è abbastanza comune
principio con cui conosci le persone
programmatori particolarmente agili
tipo di sviluppatori agili si sono avvicinati al
idea di scrivere codice intendo per media
acnes è in realtà basato sui test
lo sviluppo più di tutto così io
imparato a conoscere il principio yagna da a
pochi colleghi dove sai se lo sei
test-guida il tuo codice anche anche a parità di condizioni
una variabile creata che non è necessaria da
i tuoi test sono essenzialmente l’agonia di te
sai che non si sta per bisogno di liberarsi
ne è spreco e Martin Fowler ha
recentemente descritto in lei in un
articolo e descrive questo tre quattro
tipi di rifiuti che si ottengono con il
comportandosi bene così l’importante da
il mio esempio che introduce un extra
variabile anche se non si pensa
è come un grosso problema nel tuo codice
aumenta effettivamente il costo del carry of
il tuo codice base aumenta la quantità
di cose che hai per definizione e
straordinari che roba maturano a meno che tu
aggiusta le finestre rotte alle quali si unirà
un equipaggio e un equipaggio e si finisce con
calamità quindi in realtà il codice è piaciuto
pensando che l’acne si applica quando siamo
costruzione di applicazioni di microservizi
Penso che lo penso assolutamente
fa nel senso che ciò che vogliamo
fare quando stiamo costruendo
microservices non sta costruendo roba fuori
prima del tempo che abbiamo
bisogno e questo potrebbe essere ovvio, ma tu lo faresti
essere sorpreso dal numero di avorio
tipi di torri che si sono trasferiti nella costruzione
micro-servizi che dicono proprio quello che siamo
andando a fare ora è progettare tutto il nostro
i micro servizi in questo momento spesso lo fanno
la mia opinione che non funzionerà
approccio penso che dovremmo ancora prendere è
che non si ha intenzione di bisogno costruire
fuori le cose quando ne hai bisogno
quando ne hai bisogno solo quando ti serve
loro quindi inizialmente costruiscono un servizio
e poi quando hai bisogno di costruire
un’altra forse è la base del codice
complesso
forse forse per altri fattori potrebbe essere
i fattori non funzionali si sviluppano senza
il prossimo servizio è ciò che penso
risposta e quasi all’idea di fare noi
inizia con il monolite o no ma
in modo cruciale l’ Agni si applica al micro
architetture di servizi è tutto
costruire le cose quando ne hai bisogno
non progettare di nuovo davanti così per me
questo tipo di detiene ancora questo è questo è
un insieme di modelli che sembra avere
caduto dal generale non usare perché
le persone riconoscono ancora l’importanza
ma delle mani di memoria collettiva della gente
su, se vi siete imbattuti, comprendete, sì, lo è
un po ‘interessante, quindi questo è bene
prima ha iniziato ad interessarsi di sorta
del design la Gang of Four e tutti questi
cose che mi sono state presentate per cogliere e
sono gli stand dal generale
incarico di responsabilità nel software
schemi abbastanza sicuri di quello giusto
e sono stati sviluppati da un tizio chiamato
Craig lahrman che è diventato credo di più
ben noto più tardi per scrivere libri
su tutte le tecniche di gestione agili
sviluppo e gestione del software
gestione come tutti i progetti software ma
da noi ne prendiamo un paio davvero
molto conosciuto e abbastanza ovvio
modelli che sono PI al livello di
micro servizi illustrerò questo
era con un esempio quindi ero a un cliente
dei nostri l’anno scorso la scorsa estate
ed erano un posto interessante
perché hanno costruito un set di
servizi in India e un set di
servizi nel Regno Unito ho avuto una grande squadra in
L’India è una grande squadra nel Regno Unito e li incontra
sia per fortuna che per noiosa possibilità felice
ognuna di queste diverse posizioni era
costruire una capacità particolare
proprio così in India ne stava costruendo uno
cosa una cosa molto discreta e in
Londra stavano costruendo un altro
cosa discreta c’erano una specie di a
compagnia di viaggi vendono biglietti per
cose così un posto stava costruendo il bit
questo bene è possibile acquistare i biglietti come un
il cliente e l’altro bit stavano costruendo
il pezzo in cui hai ricevuto il biglietto
giusto essenzialmente l’adempimento al dettaglio
ci sono altre cose più complicate in
anche nel mezzo , ma sì
praticamente lo diciamo e la realizzazione
e la cosa veramente carina di questo e
Penso che forse la cosa ovvia
succede e ancora se per fortuna o
giudizio o qualche altro Samar o
qualcos’altro avevano finito con questo
soluzione in cui avevano una grande importanza in
Londra e una grande cosa in India con a
autobus in mezzo e stavano passando
messaggi tra i due
incidentalmente Simon Brown se lo conosci
odia i miei diagrammi di architettura e questo
è un esempio in realtà di due modelli
da afferrare così l’erba parlava in un
mondo ideale che vogliamo avere altamente
software adesivo e liberamente accoppiato
software e questi due indipendenti
le capacità erano estremamente vaghe
accoppiato da questo autobus nel mezzo e
il messaggio che lo trasmetteva funzionava
davvero molto bene le due squadre
potrebbe operare indipendentemente il test di implementazione
indipendentemente e così via così assolutamente io
pensa quando stiamo costruendo i micro servizi
architetture basate che vogliamo essere
in cerca di alta coesione e basso
accoppiamento e penso che storicamente abbiamo
fatto un brutto lavoro soprattutto alla coesione
perché ciò che abbiamo teso a fare è concentrarsi
sulla coesione intorno a preoccupazioni tecniche così
saremo coesi per separati
preoccupazioni ed essere di circa
presentazione e
i sistemi dicono e quindi metteremo tutto il
roba di presentazione in un posto e tutto
la roba di persistenza in un altro posto
che è un po ‘coeso, sono io
preoccupazioni tecniche ma che porta a
tipo di accoppiamento molto stretto tra
preoccupazioni di business quindi in questo esempio
quello che stiamo facendo è coeso intorno al
le imprese riguardano il business
capacità le cose funzionali reali
che questa cosa deve fare piuttosto
che l’ organizzazione tecnica di esso
questa è la prossima cosa che sono la prossima cosa che sono
intenzione di parlare è asciutto così questo è venuto
come una domanda negli ultimi e ai
fine dell’ultimo discorso sul discorso di Fred
quindi non ripeterti asciutto e questo è
questo spesso succede se dovessimo permettere
duplicazione tra servizi o schwöre
dovremmo forse estrarre qualche codice comune
estrarre alcune librerie di dominio comuni e
in modo che condividiamo il codice tra i servizi
e quindi la mia risposta semplice è che non dovresti
estrai codice comune a meno che non sia molto
tipo di infrastruttura di base molto semplice codice I
spiega perché questa è la definizione di
asciutto questo è da prav Dave credo che se
lui è nella stanza, non ne sono sicuro
il pezzo di conoscenza deve avere un singolo
rappresentazione autoritaria inequivocabile
all’interno di un sistema
Stavo pensando questo è ancora
vale ancora per i micro servizi
hai già sentito la mia risposta ma io
spiega il mio ragionamento quindi se ne abbiamo due
servizi e abbiamo del codice condiviso
indicato dalla stella in questo diagramma o
comune ci può essere la duplicazione attraverso
queste cose, la tentazione è quella di
estrai quella stella e dì che sai cosa
riutilizziamo lo inseriremo in un file jar
da qualche parte o qualche dll condivisa ci incolleremo
nella nuova ottenere questi giorni faremo Stick it
nel nostro repo Maven e io sono a
repository artifactory e quindi sai
qualunque cosa abbia bisogno può abbatterlo e
possono includerlo in fase di compilazione e
allora possono essere schierati può essere
schierato
ma il problema con questo è ogni volta che tu
introdurre le dipendenze binarie condivise
tra persone tra diverse
servizi che bloccano completamente il loro treno
cicli insieme e se intendi se
hai mai usato la saggezza per me
sul tipo di deathstar delle SS mai
mai usare il legame di saggezza che è dove tu
generare stub a generare stub come
una fase di pre-elaborazione e quindi includere
quei tronconi nella tua nella tua applicazione
e utilizzare quegli stub per effettuare chiamate attraverso
la rete se l’hai mai usata
probabilmente hai visto i problemi con
ciò che è ogni volta uno di quelli
i servizi di una di queste API sono i cambiamenti
improvvisamente ognuno dei tuoi
i clienti stanno per ricompilare e
ridistribuire e questo è il motivo per cui non lo facciamo
o meglio il mio io e i miei colleghi di
le parrucche piene non tendono a preferire l’uso
qualcosa come la saggezza vincolante ma
estraendo l’estrazione del codice di dominio condiviso
ti dà esattamente lo stesso problema
all’improvviso ti stai bloccando cambierai
cicli del tuo software insieme e se
hai centinaia di microservizi e
forse condividono qualcosa di comune
chiamato un cliente che davvero non vuoi
deve essere distribuito ridistribuzione a
cento cose ogni volta che il tuo cliente
ottiene un nuovo tipo di campo di schifezze ci sono
approcci diversi per affrontare questo
ho già detto che per esempio sono
personalmente va bene con l’estrazione
cose come condivise come condivise
codici infrastrutturali se hai un
Client HTTP che probabilmente va bene inserire
in un nuovo pacchetto get da qualche parte
un file jar se guardi tutto il
Netflix open source troppo tardi si
tutte cose molto specificamente generiche
come l’implementazione dell’interruttore automatico
monitoraggio delle implementazioni dei bulbo
questo genere di cose mi sta bene
c’è un altro approccio che è da usare
qualcosa chiamato un modello di servizio così a
molti strumenti ora, quindi cose del genere
il boot o drop wizard di primavera va in qualche modo
verso la fornitura di un modello che è possibile utilizzare
per costruire servizi e ci sono
altri in altre lingue, ma questi lo sono
quelli che mi sono più familiari ma che cosa
non lo fanno è darti il
roba specifica del dominio su quello che tu
richiedere nella tua organizzazione in cima
così buona pratica che abbiamo trovato è quella di estrarre
un modello di servizio che contiene forse
sì, il modo in cui facciamo il login qui come noi
monarca monitorando il nostro modo di fare
le pagine di stato lo mettono in una condivisione
posizione e poi quando è necessario
crea un nuovo servizio che puoi semplicemente clonare
meno e ricevi per esempio due servizi
modelli e la ragione un altro di
le ragioni per cui questa è una buona idea sono
perché essenzialmente se non stiamo condividendo
il codice principale o anche se stiamo condividendo
il codice principale su ciascuno dei nostri servizi
il tempo sta per cambiare sta per
diventare sta per passare attraverso la propria
insieme di singoli cambiamenti che stanno andando
divergere dal modello di servizio
in sostanza stanno per passare
pantaloni diversi su tutte le biforcazioni
tracce di realtà e quindi questo è il motivo
essenzialmente sono arrivato a questa conclusione
che è lo stesso che aveva Fred
che è essenzialmente copia e incolla
okay
copia e incolla va bene, ma continuo a pensare
dovremmo essere asciutti all’interno dei servizi così
all’interno dei singoli micro servizi I
penso che dovremmo ancora applicare allo stesso
serie di pratiche per rimuovere la duplicazione
in modo da mantenere il codice pulito successivo in modo
c’è stato un bel po ‘di polemiche
sullo sviluppo basato su test di recente
dovremmo farlo se dovessimo farlo affatto
è solo uno spreco, è solo uno spreco
le mie opinioni su questo e loro no
corrisponde sempre con alcuni dei nostri altri
ben noto con altre persone ben note
nel UM qui nel nostro settore così
la prova di prova si sviluppa usando test-driven
sviluppo come strumento per il design
in primo luogo prima che io non sono del tutto sicuro che
Non so certamente più di un decennio e io
è stato molto fortunato perché in realtà ho imparato
come scrivere il codice guidato dai test di a
un sacco di persone che lavoro con quel pensiero
funziona bene mi sono iscritto circa 10 anni fa
11 anni fa um e come parte dell’apprendimento
come scrivere il codice guidato dai test I
ho notato una cosa davvero divertente che è stata
il codice che ho scritto
ho finito per guardare in un certo modo la mia gente
l’ho notato se segui il test
Scrivo un test che Watson viene qui fornire
alcuni refactor rosso refactor codice
cicla ma il tuo codice finisce per apparire a
certo modo nei linguaggi orientati agli oggetti
ti ritrovi con piccoli oggetti in genere
con un piccolo numero di responsabilità
tendi a iniettare le cose attraverso
dipendenze dei costruttori attraverso
il codice dei costruttori sembra semplice e
comprensibile e nel tempo a volte io
non utilizzare lo sviluppo basato su test
in esclusiva sarò onesto
a volte penso solo a cose di te
so cosa sto per fare, sono una specie di I
capisco bene questo problema, lo farò
fare un test intorno a quello che
verifica che il mio software funzioni
anche se queste unità di software sono
lavorando e continuerò a scrivere alcuni
codice ma in generale negli ultimi 10 11
anni qualunque sia il modo in cui scrivo
codice è stato guidato da imparare a
fai TDD perché penso quindi guidato dai test
sviluppo a parte il fatto che esso
Penso che guidi il codice pulito perché lo faccio
pensa che questo sia importante per micro
servizi bene abbiamo già parlato a
minuto fa all’inizio su come
i test end-to-end diventano davvero reali
duro proprio così scrivendo un sacco di questi
test di grandi dimensioni diventano davvero davvero
difficile
Vedo che mi aspetto scrivere più unità
prova quindi isolando questi servizi e
scrivere unit test per la funzionalità
al loro interno per il codice al loro interno
diventa più importante in quel caso
se non hai letto questo libro è
fantastici hamburger con piume di microfono
descrive la crescita orientata agli oggetti
software guidato da test con un prezzo dell’app
e Steve Freeman come a Londra
Scuola di sviluppo test-driven entrambi
da entrambi gli autori erano a parrucche piene
Quando sono entrato a Londra, ho passato un po ‘di tempo
li incontrai ovviamente in un certo tempo con
non hanno mai realmente lavorato a un progetto
con loro ma questo libro descrive come
per cui Londra o le persone che lavorano
dentro per cui Londra pensa davvero
riguardo a scrivere o scrivere test
codice guidato e come progettare il tuo
software scrivendo prima i test
quindi ha voluto rispondere a questa domanda o
forse una domanda leggermente diversa
dovremmo preoccuparci di testare la nostra guida
codice se vogliamo solo buttare le cose
via giusta costruzione bene sostituibile
micro servizi micro servizi che noi
può buttare via la costruzione del sistema di costruzione
software che non è mai fatto, dovremmo noi
perdere tempo con esso, a mio parere penso che
dovrebbe perché il valore io personalmente
ottenere o io e vedere le nostre squadre ottenere
dalla scrittura prova test unitari speciali
e prova a guidare il loro codice e il
importanza di avere test più piccoli
con i micro servizi per me intendo io
credo che dovremmo essere e sto solo andando
per coprire forse alcuni dei
CONTROVERSIE questi sono i alcuni dei
persone che ho avuto la fortuna di lavorare
con nel pensiero che Londra così tanto
queste persone sono diventate giuste
ben noto nel test
comunità la comunità del design l ‘
le comunità di architettura, ad esempio
in quel prezzo e Steve Freeman ha scritto
quel libro giù a nord
conosci l’originatore di BVD liske qui
lei ha un premio passato dall’agile
DeAngelis un gruppo di altri e oltre
tempo le loro opinioni su TDD hanno
cambiato nel tempo un sacco di ben noto
figure in opinioni del nostro settore circa
QP ha cambiato le mie sensazioni come ho detto
quel test che guida il nostro codice è ancora molto
molto prezioso e mi piacerebbe avere forse
terrorizzare il modo in cui penso a come forse
alcune altre persone parlano di TDD
questo è qualcosa chiamato Dreyfus
modello di acquisizione di abilità in cui sono stato
software per I do not know what is 15
non si. 15 anni 16 anni non sono tranquillo
un cuz di barba grigia che dura da 20 anni, ma io sì
avere una barba grigia se questo aiuta così ho
stato scrivere software per un po ‘di tempo
e in alcune aree del software
sviluppo mi considero un esperto
sulla scala Dreyfus per la pesca o un
esperto
probabilmente esperto o esperto in
lo sviluppo basato sui test comunque e molto
delle persone che ho appena menzionato
anche esperti nello sviluppo basato sui test
hanno imparato le lezioni e lo sono
iniziando a muoversi sulle loro cose e
hanno interiorizzato quello che hanno
imparato a scrivere il codice di scrittura
guidato dai test, credo che la ragione per cui sono
menzionare questo è pensare attentamente
prima di prendere il consiglio che con
i micro-servizi improvvisamente non dovremmo
scrivere qualsiasi desiderio non dovremmo testare la guida
la nostra sterlina più perché un sacco di
le persone danno un consiglio anche se valido
consigli per loro e per il lavoro
loro stanno venendo da una posizione
di esperienza avendo imparato le lezioni
loro già scrivono il codice in un certo modo
perché loro hanno imparato come
fallo prima scrivendo il codice test
quindi per riassumere dovrebbe essere scritto
test unitari personalmente penso che dovremmo
e penso che sia più importante di
mai abbiamo bisogno di continuare a quel test
piramide con un sacco di piccoli test al
in fondo la prossima cosa è SRP single
principio di responsabilità e oggetti
dovrebbe avere una sola ragione per cambiare
era la dichiarazione originale quindi la mia
collega che ora è nel primo
colonie ora vicino a 4j Alastair Jones
il mio software su una squadra e siamo arrivati
con questa euristica essenzialmente è a
ridefinizione di SRP ed è una classe
non dovrebbe essere più grande della mia testa e
questo è questo è la testa di Allister questo è
un orecchio in realtà vicino e loro
uffici a Londra, quindi questo è di Allister
testa e sta controllando se una classe
è abbastanza grande o troppo grande e io
pensa al tweet che hanno deciso che fosse
bene ma cosa intendiamo per non più grande
di una testa e come si applica a
micro servizi bene per me
mandare le sue tartarughe fino in fondo credo
è come hai fatto a pezzi diversi livelli
di astrazione per me il singolo
principio di responsabilità applica il
altro stato vicino all’altra direzione di
guardandoli non più grande di testa
cosa dovrei essere in grado di capire
tutto di un oggetto tutto bene io
dovrebbe essere in grado di consapevolmente in realtà
essere in grado di ragionare esattamente su tutto
oggetto sta facendo dovrebbe avere un singolo
responsabilità unica ragione per cambiare
e mentre dividi dal livello di un
oggetto in dire servizio che dovrebbe avere
una sola responsabilità e come pezzo
di nuovo al livello di forse un insieme di
servizi che il nostro team possiede che dovrebbero
avere una singola responsabilità singola
motivo per cambiare mentre ti blocchi di nuovo
al livello di un sistema di sistemi
singola responsabilità e ad ogni livello
di astrazione dovresti essere in grado di adattarti
questa roba nella tua testa ovviamente io
non posso tenere la testa su un monitor e
controlla se Netflix si adatta al tutto
L’architettura distribuita di Netflix è
grande come la mia testa ma concettualmente
è così che dovrebbe essere un servizio SRP
non essere più grande della mia testa il prossimo
bacia le mani in alto bacio mantienilo stupido
cosa rendere semplice se siamo carini
quindi questo è qualcosa dall’ultima
edizione del nostro radar tecnologico a
ThoughtWorks e questo è dove
abbiamo messo in attesa i server delle applicazioni ora
questo potrebbe questo è un po ‘paura di troppo
la gente ha un po ‘paura ai team ops ma noi
stavamo solo cercando di chiamare essenzialmente
che i tempi non sono più cambiati
bisogno di usare una grande applicazione di ferro
server che non è più necessario distribuire
micro servizi molti di loro in un grande
server delle applicazioni ho paura per quelli
persone che sono attualmente su WebLogic
squadra non sta guardando così grande e il
cosa interessante è perché se tu
pensaci ma i tempi sono cambiati
destra siamo passati da avere uno
costosa macchina grande in modo che avremmo
mettere un server di applicazioni che sarebbe
gestire un sacco di piccoli di
applicazioni su di esso per avere un sacco e
molte piccole macchine va bene questo è
il movimento verso di te sa di aiuto
il movimento del contenitore o un singolo
servizio per immagine macchina singola
server
per esempio sull’onore
infrastruttura-come-un-servizio che non lo facciamo
bisogno dei server delle applicazioni pesanti
in quel mondo si mettono di mezzo
dei test che fanno rallentano i test
giù
rendono più difficile la consegna continua
fanno in modo che il mio lavoro si sviluppi di nuovo
cercando di ottenere il codice più velocemente
i server applicazioni sono in attesa quando penso
riguardo al bacio questo mi passa per la testa
WWJD e che probabilmente non lo fa
senso, ma significa che cosa farebbe Joe
questo è Joe, con cui ho lavorato per me
per un tempo in tutti i modi e lui è di gran lunga
lo sviluppatore più produttivo che abbia mai visto
incontrato non sono un grande fan di ora sono
tipo di cosa 10 volte la produttività, ma
Joe da solo è equivalente a a
squadra di circa 10 persone quindi forse c’è
una parte di verità in esso e quando ci penso
cosa farebbe quello che Joe farebbe quello che Joe
farebbe la cosa più semplice possibile
manterrebbe le cose davvero davvero
semplice se si trova di fronte a un problema lui
lo risolve in un modo molto molto elegante
un esempio di ciò è che era su a
progetto voleva che lui avesse bisogno del nostro lui
necessario per comunicare con WebSockets
un client e un browser e stava cercando
attorno a tutti i diversi WebSocket
supporto nei diversi server delle app
lì è una specie di grandi cose che è
pensato ora non ho intenzione di farlo e così
quello che ha fatto è invece ha rotto il suo proprio
ha scritto il proprio server di applicazioni ora
sembra pazzesco, tutto a posto
pazzo che potremmo uscire e scrivere
il nostro server di applicazioni ma in realtà
a volte fare cose del genere è il
la cosa più semplice che possa funzionare
mantenendolo semplice e ti darò
un altro esempio di questo da un progetto I
era su così stavamo costruendo il mio
Architetture del ricevitore per una scienza
sito di pubblicazione e abbiamo avuto il
obbligo di provare e visualizzare i nostri
infrastruttura in cui stavamo implementando
AWS e volevamo visualizzare il nostro
infrastrutture abbiamo avuto un paio di opzioni
uno dei quali doveva aspettare fino ad alcuni di
i fornitori di strumenti pesanti erano in grado di farlo
supporto server immutabili e tipo di
infrastruttura solo append questo è dove
server fa
un su e giù per tutto il tempo e molto
le grandi case di software non lo fanno
sostenere Battlestar eppure scherziamo per schierare
qualcosa come console ma al fine di
console di produzione hardening sei tu
parlando di voi conoscete cinque anelli dei nodi
è abbastanza complicato da ottenere
quello e nel frattempo fino a che non abbiamo ottenuto
lì non abbiamo davvero capito cosa
era in produzione e quindi due
giorni Mina compagno si avvicinò con questo
visualizzazione quindi questa è la nostra produzione
infrastruttura facendo una distribuzione Bluegreen
se puoi vederlo e usiamo cron e
Il punto e il grafico di Python e Bato e PI lo è
e questo ha funzionato correttamente questo era il
la cosa più semplice che potremmo fare
visualizzare la nostra infrastruttura in modo tale
sai che i nostri tester hanno capito bene
quali versioni erano in esecuzione che il
gli sviluppatori potrebbero guardare lo schermo e
vedi tutto bene va bene l’endpoint DNS ha
cambiato la cosa più semplice che
potrebbe funzionare e poi eventualmente
mettiamo console e abbiamo tutto il
belle dashboard e cose così fa
tenerlo semplice significa molto in questo senso io
penso che si applica ancora penso che ancora
si applica in questo senso è sempre
applicato che è provare e trovare il
soluzione più semplice che c’è possibile
non inclinarti verso pesi massimi molto grandi
le soluzioni fanno la cosa più semplice possibile
così rapidamente perché ho due minuti
a sinistra ho intenzione di parlare di integrazione
e il dispiegamento così ho coperto quelli a
l’inizio quindi se siamo in questo mondo
dove l’integrazione verifica tutti questi
altre pratiche sono ancora valide
che dire di questo tipo di integrazione
testare il problema degli ambienti di integrazione
quello non sembra farlo per essere valido
ci sono altri strumenti che possiamo mettere in
la nostra cassetta degli attrezzi penso che ci siano così i
la prima cosa che possiamo aggiungere è questa idea
di monitoraggio semantico così semantico
il monitoraggio è dove in produzione corriamo
cose che sarebbero normalmente cose
come test di viaggio dell’utente o accettazione
test contro la nostra produzione
infrastruttura quindi testiamo se tu
come in produzione non è così
diverso dall’idea del test del fumo
è solo leggermente più è leggermente
approccio più disciplinato c’è un grande
descrizione
di esso sui baluardi scienza radar se
hanno uno sguardo che è la prima cosa
la prossima cosa che penso di poter fare penso
ci saranno alcuni discorsi che parlano di questo
più tardi possiamo provare e ottenere feedback per
quando rompiamo le animazioni precedenti
rotto prima sai che ti conosci
sai che conosci i cicli di feedback in modo che possiamo
distribuire il nostro software in produzione e
vedi se rompe è un approccio e
il monitoraggio semantico ci dirà se è così
compra un’altra cosa che vogliamo
voglio fare è sviluppatori è capire a
un po ‘prima e quindi possiamo scrivere
contratti eseguibili per i nostri servizi
e darli alle persone che scrivono
i servizi e questi sono chiamati
contratti guidati dai consumatori e questi possono
essere eseguito come amico del nostro ciclo di build così
acquistiamo mano dei contratti guidati dai consumatori
loro ai nostri fornitori di
servizi e poi quando eseguono il loro
costruire se il comportamento ha cambiato il
costruisco pause scusate per ottenere un po ‘ meta io sono
intenzione deliberatamente nel tempo di a
un paio di minuti è un motivo per essere noi
non voglio inondare completamente il pranzo
alle code mi è stato chiesto di farlo comunque
è tornato ai contratti guidati dai consumatori
semplicemente quello che fai è scrivere a
insieme di aspettative come consumatore di a
il servizio va bene si tratta di un eseguibile
formato e lo includi come parte del
costruzione dei servizi costruire pipeline
idea semplice ma in realtà era abbastanza
rivoluzionari dieci anni fa um non ha
davvero adottato fino a forse questo
l’anno scorso e ora c’è l’attrezzatura
disponibile a fare questo certamente in Ruby
patto di sintesi disponibile su
github è uno strumento open source quindi
la prossima cosa è testare in produzione I
accennato brevemente cosa intendo con
testare in produzione bene piuttosto che
tonalità come parte di un UAT formale simile
fase prima di voi distribuiamo il nostro software
tutto a ventaglio in un’integrazione
ambiente abbiamo effettivamente spingere il nostro
software direttamente in produzione e
prova lì tutto bene se ce l’abbiamo davvero
buon monitoraggio quindi sappiamo che le cose non lo sono
spezzare questo è un tipo di valido
approccio se abbiamo quella semantica
monitoraggio se abbiamo da sumer
diversi contratti
luogo in modo da minimizzare il numero di
rompendo i cambiamenti che ci ottenere questo è
funzionerà quindi a cosa si basa
naturalmente è stato in grado di salvare il nostro QA è
i nostri product manager o proprietari di prodotti
sono in grado di accedere e come
scusa, siamo in grado di farlo
distinguere chi sono così che loro
posso testare in produzione così sono davvero
dicendo che avremo intenzione di farla finita
ambienti di integrazione penso molto
di aziende che stanno costruendo micro
le architetture di servizio hanno già io
pensalo mentre ottieni più di queste cose
Penso che sia inevitabile, penso che sia così
solo il modo devi andare um
è spaventoso, mi dispiace proprio così
è ma questo è qualcosa che forse
aiuta ad affrontare il dolore questo è reale
la realizzazione che ho avuto di nuovo sta andando indietro
per quello che abbiamo fatto nella vostra regione per avere
forse due data center e abbiamo abbiamo
un attivo e un passivo avremmo alcuni
software che li gestisce uno e
allora aggiorneremmo l’altro sì
uno era vivo e uno era al caldo uno
non era in questi giorni con elastico
infrastruttura quando stiamo implementando
cose in infrastrutture come il
fornitori di servizi non ci sono davvero scuse
c’è una differenza tra il dispiegamento
nel tuo ambiente di produzione così
sabbioso capisce qualcosa che è
su quello è là fuori che è sul web
e in realtà vengono utilizzati da
persone c’è una differenza tra
essere in diretta e ottenere traffico dal vivo e
in realtà essere in produzione, quindi puoi
distribuire effettivamente tante versioni di
le cose che vuoi nel tuo ultimo rack
infrastruttura ma a meno che effettivamente usi
a usarlo non è live, quindi questo lo rende
l’idea di farla finita
ambienti di integrazione un po ‘meno
spaventoso giusto
perché possiamo solo schierare nel
produzione possiamo permettere il nostro prodotto
proprietari responsabili di prodotto QA di business popolare
s per testare le cose in produzione e poi
possiamo farlo vivere dirigendo il traffico
e questo è il modo per farlo
incluso questo è blu canarino build
distribuisce il verde ed è giusto in a / b
testare così
finalmente cambiando servizi in modo indipendente
beh, questo è qualcosa che ho imparato
dal parlare con alcune persone in
Adrienne Cockcroft in particolare se
faremo una modifica ad a
servizio commettere un codice che sta per
passare attraverso la produzione
una delle cose che dobbiamo pensare è
qual è il raggio di esplosione di quel cambiamento
giusto chi è che il cambiamento avrà un impatto
quali altri servizi cambieranno
impatto e penso che ci sia quasi come
tre livelli qui è il primo livello
se il cambiamento è limitato all’interno
la tua squadra se qualcuno al di fuori del tuo
la squadra sarà interessata perché se
è questo se non si espanderà dentro
il raggio di esplosione che l’esplosione non ha
espandi la tua squadra e poi probabilmente tu
in grado di gestire il controllo delle versioni e modificare solo da
Parlando con le persone, cambierò questo
devi cambiare la tua cosa ora è
va bene, va bene
andiamo via la prossima cosa è è
limitato all’interno di un contesto a banda o scusa
tra un contesto limitato se è allora
potresti volerlo pensare
contratti guidati dai consumatori e forse
versioni semantiche di questo tipo
di tecniche e la terza cosa è
organizzativo quindi se il tuo Google tu
non voglio cambiare l’API di Maps
molto spesso perché il raggio di esplosione di
che va bene è una specie di Occidentale
civiltà come la conosciamo bene
e la ragione per cui stavo pensando a questo
è questo libro di Thomas Allen che hanno parlato
riguardo a questo, parla di come
flussi di informazioni in giro
organizzazioni ed è interessante
perché dopo circa 15 metri o 10
metri di distanza da qualcuno il
probabilità di interagire di avere
conversazioni serendipite è
praticamente zero perché è così importante
beh, vuoi limitare il tuo cambiamento
voglio applicare diverse tecniche
più lontano sei da qualcuno e
questo è di nuovo il punto in cui entra in vigore la legge delle virgole
quindi per l’integrazione interaziendale forse
stai pensando a modelli come
versioning semantico ma se quando
stai parlando del cambiamento in un
l’organizzazione tra le squadre dice la tua trama
applicando diversi tipi di
cose così forse potrebbero essere versioni semantiche
testare i lettori tolleranti
e poi all’interno dei team forse lo siamo
parlando di cambiamenti conversazionali così
Cambierò questo puoi cambiare il tuo
cosa è un’estate il futuro è spaventoso
giusto non sappiamo come fare un sacco di
questa roba ancora per parafrasare Auto mi dispiace
per reiterare quello che Fred stava dicendo ma a
allo stesso tempo molte cose che sappiamo
come si fa già ancora, penso
quando stiamo costruendo servizi di micro così
è una specie di bella cosa e anche
ci sono un sacco di nuove cose interessanti che noi
può fare bene e c’è un sacco di novità
roba da imparare e francamente uno dei
I motivi per cui sono nel software è perché io
amo imparare cose nuove così in sintesi
la cosa più semplice possibile grazie molto
tanto
tu
già stato sottolineando ho intenzione di
parleremo oggi di sistemi di costruzione
che non sono mai stati fatti così è questo discorso
davvero su di esso è davvero su di me
pensando a tutte le pratiche che ho
imparato nel corso degli anni come un software
ingegnere come sviluppatore e se
sono applicabili nel mondo di
costruire micro servizi è così
davvero di cosa parla questo perché è così
chiamato mai fatto bene mai fatto
c’è un certo numero di significati proprio il
il primo significato che non ho mai fatto è
qualcosa che è incompleto, giusto così
Intendo quando parlo di costruzione
sistemi che non sono mai stati fatti
sistemi di costruzione incompleti
tornare a quell’aggiornamento rapporto caos
da questa mattina sai che non voglio
essere in quel 50 per cento dispari di
sviluppatori che stanno costruendo edifici
software che non funzionerà mai o mai
non entra mai in produzione, quindi non lo faccio
significa davvero che questo non è ciò che intendo
mai fatto invece ho pensato
su cosa significa costruire sistemi
che si distinguono quell’ultimo destra che si distinguono
la prova del tempo e per me in realtà
è qui che sono stati avviati i micro-servizi
dove ho iniziato ad interessarmi
questo è stato in risposta a parlare con
molte persone da diversi
comunità di software in modo che il dominio
comunità di progettazione guidata il tipo di
la comunità di integrazione così piace alla gente
Judy per fare del male a persone come Jimmy Neilson
persone in questa e integrazione web
comunità così la comunità di riposo nel
comunità di messaggistica e abbiamo ottenuto
insieme come gruppo come un gruppo di persone
e quindi stavamo parlando di sistemi e
perché i sistemi stanno diventando così grandi ma
praticamente abbiamo passato tre giorni a provare
per capire perché stavamo tutti costruendo
prodotti che non avevamo poi sostituito
dopo un paio di anni e per me quello
quella era la chiave è come quello che è
su questi sistemi che significa di
applicazioni che costruiamo che il
sistemi che stiamo costruendo significa
non durano più di
più di due o tre o quattro anni abbiamo
dobbiamo buttarli via, dobbiamo andare
torna per tornare ai nostri team di gestione
i nostri dirigenti e chiediamo altri 10 milioni
Euro per ricostruire qualcosa, quindi ci sto provando
pensare di non aver mai fatto in quello in
senso di costruire sistemi che durino
quello resiste la prova del tempo così invece
di questa diversa questa definizione di
loro sono stati incompleti, lo farò
usa questa definizione da una spugna
libro a cricchetto prenota il quinto elemento così in spugna
Pratchet è un autore fantasy inglese lui
è morto tristemente un paio di mesi fa
ma ha scritto oltre 40 libri uno di
che è l’ elefante del quinto elefante e
in questo libro descrive a
la storia è un nano con una grande barba lunga
e un’ascia che racconta una storia sulla sua
ascia della famiglia e questo è il modo in cui mi piace
pensa al suo edificio
sistemi in questi giorni sulla costruzione
sistemi che non sono mai stati fatti e lui
descrive l’ascia della sua famiglia, dice lui
lui dice che questa ascia è stata nella mia
famiglia per 900 anni questa è la mia famiglia
ascia e parafrasare ovviamente sopra
tempo ogni parte di questo asse è cambiata
Ho sostituito la maniglia che abbiamo
a volte sostituiva la lama dell’ascia
abbiamo avuto un intaglio di nuovi regali in
il manico a volte abbiamo sostituito il
gestire di nuovo a volte abbiamo sostituito
di nuovo la testa , ma questo non è il mio
ascia della famiglia 900 anni dopo e questo è
una rivisitazione di una storia in cui è un
antica specie di pensiero filosofico
Sperimenta la nave del thieve thebes
e l’esperimento mentale che esiste è
questo se hai una nave che dura 300
anni e ogni singolo pezzo di quello
la nave è stata sostituita su quelle 300
anni alla fine del trecento
anni in cui non è rimasto nulla del
nave originale è ancora la stessa nave
Terry Pratchett usa questo nel mio
atto di famiglia e penso che sia così come noi
dovrebbe essere pensando di costruire
sistemi Chad Fowler L’ ho visto parlare
recentemente ha avuto una bella frase che ha detto
il ragazzo dell’ID di Nizza ha detto che dobbiamo reclamare
la parola legacy è la sua eredità e IT
connotazioni terribilmente cattive
sai che l’eredità è un’eredità negativa
il codice è una cosa brutta
i sistemi legacy sono cose cattive e io sono
l’accusa stava dicendo bene ciò di cui abbiamo bisogno
fare è guardare in eredità in a
luce positiva come Mozart o Bach lasciati
un’eredità hanno lasciato un’eredità positiva
come vogliamo lasciare un’eredità al nostro
i nostri figli vogliamo lasciarli
qualcosa che è positivo no
negativo e quindi questa idea di recupero
legacy questa idea di sistemi di costruzione
che dura quella portata che si estendono decente
periodo di tempo ma composto da più piccoli
sistemi composti da microservizi che
può essere sostituito individualmente, ecco cosa
Intendo costruendo un software che non è mai
fatto costruire software che dove il
sistema nel suo complesso il sistema nel suo complesso
dura per un periodo di tempo un lungo periodo
di tempo ma i singoli componenti di
che può essere può essere cambiato o lo sono
cambiato nel tempo Fred se senti il
parlo un minuto fa, di cui stava parlando Fred
uno dei motivi per cui potremmo volerlo
whoops potrebbe voler utilizzare i microservizi
o il motivo per cui le persone stanno parlando
sui microservizi Adriane Cockroft e
Netflix è molto chiaro in questo che vogliono
usare un servizio orientato ai servizi
architetture perché vogliono andare come
velocemente possibile vogliamo andare più veloce
per tutte le ragioni che abbiamo sentito
circa prima, quindi conosci la concorrenza
le startup concorrenti stanno prendendo il nostro
quota di mercato che ha bisogno di entrare nel nostro
ciclo decisionale dei concorrenti a
innovare più velocemente di loro che dobbiamo essere
in grado di andare il più velocemente possibile e in
la teoria dei micro servizi dovrebbe fare per noi
che oltre a essere sistemi che durano
dovrebbero permetterci di apportare modifiche
davvero molto velocemente e abbiamo avuto
esempi precedenti del nostro di un
architettonico di una di un’implementazione
di un’architettura di microservizi che
ti permette di farlo così questo è ciò che io
un po ‘di speranza per un micro
servizi basati su architettura bene te
sanno che dovrebbero essere economici da sostituire
nel tempo dovrebbero essere veloci da ridimensionare
dovremmo essere in grado di portare cose e
portare cose giù e dovrebbero essere
robusto resiliente in grado di resistere
fallimento
la vecchia linea internet non è un
tessuto cinque-nove non è mai stato più
appropriato e questo ci dovrebbe permettere di
vai il più velocemente possibile, quindi vado a
coprire rapidamente alcuni della stessa terra
che Fred non ne ha fatto molto però
questa è una citazione da da Neal Ford voi
conoscici rispondendo alla domanda o
tentare di rispondere alla domanda perché
ora e la risposta di Neal’s Mill a questo
la domanda era buona, è il primo post
Lo stile architettonico DevOps è il
prima il primo tentativo che abbiamo fatto come un
industria e pubblica questo post di DevOps
movimento in via di sviluppo della cultura DevOps
l’ edificio che sta sviluppando la cultura
per sviluppare uno stile architettonico dare
fino a sviluppare sistemi in modo diverso Dan
North che è un altro ex collega
piace quello che Fred e molti altri che hanno
è stato coinvolto in questa comunità che ha
una diversa interpretazione dei microservizi in
Infatti lui odia il nome micro-servizi lui
pensa che sia un nome terribile che preferisce
il molto meno scattante a mio avviso ma
non meno meno sostituibile
l’architettura dei componenti è ciò che siamo
parlando con microservizi
architetture dei componenti sostituibili
sistemi che non sono mai fatti che possono essere
cambiato nel tempo dan wolf ha perso il
battaglia di battitura si verifica quando Martin
Fowler ha nominato qualcosa che rimane così chiamato
scusa Dan ed è interessante perché
c’è un altro tema che attraversa
Le parole di Fred riguardavano il modo in cui stiamo imparando
come stiamo stiamo imparando come costruire
questi sistemi sono composti da
sistemi più piccoli e in qualche modo il
il futuro è piuttosto spaventoso e sto solo andando
prendere un momento per spiegare cosa intendo
da questo futuro che stiamo vivendo in o
la caratteristica che stiamo per vivere in
o qualcosa di essere un po ‘spaventoso così
questa è una citazione di alcuni decenni fa
ora è attribuito a John von Neumann
una Polonia matematico polacco chiamato
stanislav Stanislaw ulam che ha lavorato
strettamente con Newman registrato a
conversazione che ha avuto quando Newman ha parlato
a
il concetto di singolarità a
singolarità tecnologica basata sul
Infatti, per esempio, l’ hardware del computer
stava diventando più veloce, dice sempre
accelerando il progresso e i cambiamenti nel
la modalità della vita umana ci dà il
aspetto di avvicinarsi ad alcuni essenziali
singolarità nella storia della razza
oltre il quale gli affari umani come sappiamo
loro non potevano continuare ora ho visto a
single arity con i miei occhi e questo
successo un paio di anni fa questo è un
pannello per andare a chi è ed è
interessante perché vai dal nostro who’s that
anno era un paio di due anni fa I
pensare il feedback che è stato ottenuto da
il da parte delle persone che partecipavano
la conferenza è stata per molto tempo un tema
del perché non ci parlano gli oratori
cosa fare ci sono state molte conferenze
parla di diverse tecnologie
e sulle diverse tecniche
come microservizi ma nessuno ne aveva
risposte concrete davvero da dare e questo
è una specie di strana singolarità in cui
molte delle persone più famose di
nel nostro settore ma una specie di scrollata di spalle
le loro spalle un po ‘ e dicendo noi
non so davvero cosa succederà
al momento ci sono tutti questi strumenti
in fase di sviluppo c’è tutto questo nuovo
queste nuove pratiche questi nuovi principi
questo nuovo stile così uno di questi intendo
potresti riconoscere che questo è da a
pochi anni fa, ma era meravigliato
dove probabilmente era l’anno scorso che il
La singolarità di JavaScript ti è successo
non può superare uno sviluppatore JavaScript
senza tre nuove librerie MVC in calo
fuori che tasca destra ha JavaScript
appena esploso ma anche conosciuto allo stesso modo
i contenitori hanno sperato che no
esploso contro la tecnologia dei contenitori
e aziende che sviluppano container e
diverse soluzioni di container basate
le soluzioni stanno esplodendo c’è questo
tipo di strana somiglianza contenitore e
come accennato in precedenza sono parte del
pensato consiglio di consulenza tecnologia Wix
e abbiamo messo insieme questo TechRadar
e ne abbiamo notato un altro e il
l’altro che abbiamo notato ha a che fare con
cose come l’ aggregazione dei log così lunga
singolarità aggregazione non puoi
non posso parlare
a qualcuno che durante le operazioni o la perdita di
il personale sviluppa il ruolo in questi giorni
senza di loro che ti dicono 15
aggregazione di log diversa ti famiglie
dovrebbe usare lo stack ELQ no no
stiamo andando a utilizzare log di registro scorta
e chiave barlen no no no è necessario acquistare
spunk al quale la risposta è avere te
hai quanti soldi hai avuto ragione?
perché lo sperma essenzialmente succhierà tutto
i tuoi soldi da te, quindi è meglio che tu sia
in grado di sostituirlo abbastanza rapidamente ma
ci sono queste singolarità diverse
che stiamo vivendo e come
beh, c’è questa specie di micro
servizio singolarità verificano così sorta di
più vicino a casa per noi come abbiamo progettato
il software sta decisamente cambiando basandosi su
basato su tutti questi diversi strumenti
sviluppato le pratiche i principi
e come ho detto un minuto fa, sai
quando Martin nomina qualcosa , rimane
Nomi questo è il nostro tentativo Martin mio
provare a descrivere le caratteristiche
di uno stile architettonico microscopista
quindi eravamo molto chiari qui che non eravamo
cercando di definire quali sono i micro servizi
stavamo cercando di descrivere quello che eravamo
vedendo le squadre fare in natura abbiamo parlato
sui servizi di acquisto di containerizzazione
organizzato intorno alle capacità di business
e così via, è fantastico perché le squadre
stanno avendo un sacco e molto successo
proprio con lo stile dei micro servizi
ci sono molti molti software esistenti e
prove di esistenza di aziende che sono
avendo successo con questo inizio dal
grande il Netflix e il Twitter e
i google e gli eBay e i
documenti ecc. per i più piccoli al
startup che stanno costruendo edifici
architetture basate su micro servizi ma
ci sono alcuni problemi davvero difficili da
risolvi con microservices il primo I
pensare è un problema veramente difficile è come
hai fatto test end-to-end quando
si sta costruendo un micro di servizio
architetture basate quindi questo è qualcosa
che abbiamo abituati a più di un
periodo di tempo e nel nostro settore del
capacità di saperlo funzionare essenzialmente
test di livello del prodotto in cui testiamo
dall’esterno forse usando a
browser o qualcosa o forse guidare un
API e questo metterà alla prova tutti i nostri
codice o almeno testare il percorso felice
forse il tuo utente viaggia attraverso il nostro
codebase questo tipo di automatizzato
i test end-to-end sono davvero preziosi
per noi sapere se il nostro software è
lavorando o no ci dà un feedback come
parte del nostro ciclo di costruzione davvero davvero
utile la prossima cosa è come facciamo noi
distribuire queste cose in modo indipendente come fare
evitiamo di dover distribuire un sacco di piccoli
cose in scioglimento perché il pericolo di
corso quando si separano le applicazioni
è in molti piccoli micro servizi
che tu vada da una grande palla monolitica
di fango pieno di codice spaghetti ad a
monolite distribuito e distribuito grande
palla di fango dove tutto è stretto
accoppiati e hai dovuto distribuire tutto
insieme non vogliamo ciò che vogliamo
evitare di fare cose come la distribuzione in lotti
passo come lo facciamo e il prossimo
cosa è che abbiamo colpito un po ‘di questo a
minuto fa come facciamo il servizio
versioning come possiamo evolvere questi questi
servizi indipendentemente dato che noi
voglio schierarli da soli
dato che vogliamo o dato che lo è
difficile da testarli end to end sì
e questi sono problemi reali e noi siamo
imparando come risolverli non penso
se qualcuno ti dice che hanno il
rispondi a ciò che sono loro
dicendoti la verità se sono onesto, lo sono
anche un consulente dal modo in cui così
dipende è la mia risposta predefinita a questo
ma come facciamo questo e abbiamo
approcci e questo mi ha portato a pensare
riguardo se abbiamo se possiamo
ancora fare affidamento su alcuni degli altri strumenti in
la nostra cassetta degli attrezzi ne parlerò in a
momento
quindi cosa intendo testando
microservizi è difficile, quindi abbiamo un
paio di anni di servizi come un veloce
esempio
Sto usando quella piramide di prova così
test di grandi dimensioni medi e piccoli piccoli
probabilmente unità di test più grandi del tipo di
test end-to-end i test del prodotto sono
chiamandoli grandi non è qualcosa di simile
fine alla fine perché è un po ‘come
la VY Emacs combatte proprio se tu se tu
dire end-to-end di qualcun altro vuole
chiamali test di viaggio dell’utente o
test di accettazione o test di integrazione o
qualunque sia così grande prova prove che quella
testare l’esecuzione e coprire molti dei nostri
applicazione molto del nostro prodotto e in
che tipo di scenario vogliamo scrivere un
test che sta per guidare uno dei nostri
servizi e sarà necessario
integrare con un altro dei nostri
servizi quindi cosa c’è di così difficile
bene a un tratto dobbiamo pensare
creare ambienti per distribuirli
le cose nel dispiegare un sacco di diversi
le cose vanno bene se devi
forse se ne hai un migliaio
servizi diversi puoi scrivere un
test end-to-end che al momento del commit
qualche codice e codice passa attraverso il tuo
costruire una pipeline che verrà eseguita
contro il nuovo pezzo del nuovo servizio
e un migliaio delle sue dipendenze in
una specie di ambiente di test come fai
effettivamente farlo
è abbastanza complicato e ciò che abbiamo ordinato
di cui parlavo davvero oltre il
gli ultimi due anni non stanno facendo così
in realtà testiamo sempre queste cose
isolamento come parte della citazione
test end-to-end in modo da eliminarli in alcuni
modi con test di integrazione e
l’ ambiente di integrazione invece utilizza
mozziconi sociali che sopprimono qualsiasi esterno
dipendenze in un servizio un’altra cosa
è piuttosto difficile e questo è piuttosto un
il punto sottile è in questo questo no
solo il test del test end-to-end
di questi servizi il livello del prodotto
test di questi servizi diventando
difficile ma integrando questi servizi
costruirli autonomamente servizi
passerà attraverso o totale passaggio
costruire la pipeline in fasi questo è
generalmente
succede quando scriviamo questi software
giorni e li stiamo seguendo da Tania
pratiche di consegna e va bene quando
hai una grande applicazione perché tu
avere una pipeline di costruzione e passa
attraverso di esso e poi viene schierato
potenzialmente automaticamente in
la produzione è geniale è stata
verificato funziona ma improvvisamente se lo hai
ho dieci pipeline di costruzione o cento
costruire pipelines e tutti questi servizi
stanno parlando potenzialmente l’un l’altro
come facciamo quel lavoro, ma in un modo il
il modo tradizionale sarebbe quello di fan-in e
distribuire queste cose in un’integrazione
ambiente li distribuiremo in alcuni
ambiente di test di integrazione ed esecuzione
una serie di test di integrazione contro di essa
che va bene se ne hai uno molto piccolo
numero di cose, ma quando ti dico
finisco con molte di queste cose che sono
avere lo stesso problema con il
clicker mentre Fred si trovava lì
quindi torno indietro quando ne hai un sacco
di queste cose questo diventa quasi
geometricamente più complicato perché
cosa dovremmo fare quando ognuno di
queste cose cambiano è distribuire il
l’ambiente di integrazione esegue alcuni test
contro di loro per quello che succede con il
condizioni di gara di me che commetto o
un’altra squadra che ha commesso un codice a un altro
uno dei servizi, che passa attraverso
la sua propria pipeline di costruzione entra in gioco
lo stesso ambiente di integrazione cosa
succede se scrive oltre una versione
un’altra pipeline dipende da bene
forse dovremo crearne un altro
ambiente di test di integrazione bene lo faremo
avere i test di integrazione per ciascuno
delle singole pipeline è basato su
le sue dipendenze produttive e quindi
ci faremo spingere in quella ed eseguire alcuni
test di integrazione contro la produzione
versioni di ciò che accade sul punto morto
e le condizioni di gara piuttosto noi
creare un altro ambiente di integrazione
per la costruzione di condotte quindi abbiamo improvvisamente
a con le dipendenze dello snapshot e tutto
le dipendenze di produzione improvvisamente
inizia a diventare molto complicato, se lo fai
ottenuto 10 servizi che stai parlando in
usando quell’approccio devi
ambienti di integrazione da costruire
pipeline volte il numero di servizi così
questo lo sai che è un po ‘complicato
quindi forse questi sono esempi di alcuni di
le pratiche che abbiamo seguito
come parte di te usando XP, le pratiche di XP
e cose che non sono necessariamente
più a lungo che valido e parlerò
su alcuni approcci per affrontare questo
più tardi, ma come ho detto stavo pensando
circa poi le altre pratiche che abbiamo
vengo a fare affidamento su e sì io lavoro per
il pensiero funziona come è stato menzionato
e mentre siamo un piccolo agile un negozio così
noi non lo diciamo veramente bene
sappiamo che siamo un misum shop o
qualunque cosa, ma la cosa che io penso di noi
probabilmente tutti sarebbero d’accordo sul fatto che lo fossero
siamo un negozio di programmazione estremo che abbiamo
aveva un programma su praticamente tutto
siamo sì, abbiamo usato i test scritti
sviluppo progettiamo il nostro codice attraverso
test seguiamo un carico dei principi
che potresti aspettarti da XP e
da cose come l’artigianato del software
programmatore di formattazione del codice pulito così
progettazione emergenti e Gang of Four di progettazione
i modelli mantengono semplice la presa
modelli questi sono tutti strumenti che hanno
stato nel nostro toolkit per un bel po ‘
periodo di tempo come cose come
test di integrazione come cose come
gli ambienti di integrazione sono ancora qui
valido quando stiamo costruendo sistemi
compositori di piccoli micro servizi che è
quello che stavo pensando stavo chattando con
con un amico nel ragazzo degli Stati Uniti
chiamato Russ Olson che è un ragazzo fantastico
ha fatto un discorso fantastico allo skew Khan
Londra credo che era stato chiamato a
la luna ed era su di lui ricorda
il suo lui che ricorda la luna dell’Apollo
atterraggi e ciò che noi, come ingegneri, possiamo
prendi dagli sbarchi sulla Luna di Apollo e
l’ingegneria che li ha coinvolti
fantastico fantastico ha scritto e lo farei
consiglio di guardarlo fino alla luna ma
Russ Russ mi ha raccontato quest’altra storia
sulla NASA e sulle prime fasi di
il nostro lo sai dello spazio con equipaggio
esplorazione e lui mi parla di questo
questa cosa questa è la JIT di cui fa parte
del progetto Gemini e con il
Progetto Gemini inizialmente voluto
atterrare su una pista utilizzando un deltaplano
giusto che potrebbe sembrare un po ‘strano ma
se si pensa di nuovo al sì credo
I primi anni ’60 la NASA era composta da un gruppo
di persone che erano essenzialmente
ingegneri aeronautici e piloti così
questo è ciò di cui Masen era composto e
quando sono stati incaricati di progettare a
nave spaziale che sarebbe andata essenzialmente
nello spazio essere lanciato nello spazio sopra
la terra e poi tornare indietro
c’è un test essenzialmente per il
Programma Apollo che va sulla luna
ingegnere aeronautico e piloti
tornato a quello che loro tipo di
sapeva meglio e quello era l’atterraggio di aerei
piste che è gentile di in questa
ambiente chiuso e questo questo tipo di
aveva senso per loro in base al loro
esperienze e poi qualcosa di divertente
successo e quello era un program manager
è venuto da esternamente al gruppo e lui
dai un’occhiata ai loro piani in realtà questo
questo tipo di lavoro ha funzionato in questo modo
atterrò la capsula dei Gemelli fu in grado di farlo
andare nello spazio e atterrare su un blocco usando un blocco
aliante
ma questo project manager ha preso un
guarda questo program manager dai un’occhiata
a questo e ha detto bene che fondamentalmente
Detto Sei pazzo um questo genere di
vieni dall’esterno e mangia questo
è un tipo pazzo di approccio alla risoluzione
questi problemi quello che vuoi fare
perché è molto più semplice e molto più economico
e molto più sicuro per tutti gli interessati è
in sostanza cinturino un paio di grandi
paracadute in alto e drop drop it
nel mare e poi lo faremo
raccoglierlo e questo è quello che è finito
accadendo è quello che è successo
anche con Apollo, così ero
pensando a questa idea di qualcuno
entrando e guardando esternamente
guardando le nostre pratiche e il loro ISM
e anche questa idea di ridimensionare i livelli
di astrazione quindi abbiamo micro
servizi abbiamo tutte le pratiche che noi
capire come scrivere codice pulito
come scrivere sai ben progettato bene
blah design dice del tuo codice orientato
beh, che aspetto ha?
contesto di chunking fino al livello di
micro servizi e micro servizi basati
architetture come pensare che
e questo è ciò che il resto di questo è
circa e quello che pensavo fosse essenzialmente
sono le tartarughe fino in fondo
Tartarughe completamente dagli oggetti
funziona fino ai sistemi di
sistemi e quindi ho intenzione di spiegare
forse il mio ragionamento e forse spiegherò perché
alcune delle cose su cui siamo venuti a fare affidamento
secondo me dopo aver pensato un po ‘
questo è ancora valido
quindi la prima cosa di cui voglio parlare
è fuori da questo grande gruppo di grande gruppo di
le tecniche non le coprirò tutte io
potrebbe parlare di World of Warcraft a
Alla fine se la gente vuole davvero che io e
la prima cosa che ho intenzione di parlare di
è l’agonia quindi ora le mani in alto
spazio per le persone che hanno incontrato il
non ti servirà l’ agonia
va bene questo è abbastanza comune
principio con cui conosci le persone
programmatori particolarmente agili
tipo di sviluppatori agili si sono avvicinati al
idea di scrivere codice intendo per media
acnes è in realtà basato sui test
lo sviluppo più di tutto così io
imparato a conoscere il principio yagna da a
pochi colleghi dove sai se lo sei
test-guida il tuo codice anche anche a parità di condizioni
una variabile creata che non è necessaria da
i tuoi test sono essenzialmente l’agonia di te
sai che non si sta per bisogno di liberarsi
ne è spreco e Martin Fowler ha
recentemente descritto in lei in un
articolo e descrive questo tre quattro
tipi di rifiuti che si ottengono con il
comportandosi bene così l’importante da
il mio esempio che introduce un extra
variabile anche se non si pensa
è come un grosso problema nel tuo codice
aumenta effettivamente il costo del carry of
il tuo codice base aumenta la quantità
di cose che hai per definizione e
straordinari che roba maturano a meno che tu
aggiusta le finestre rotte alle quali si unirà
un equipaggio e un equipaggio e si finisce con
calamità quindi in realtà il codice è piaciuto
pensando che l’acne si applica quando siamo
costruzione di applicazioni di microservizi
Penso che lo penso assolutamente
fa nel senso che ciò che vogliamo
fare quando stiamo costruendo
microservices non sta costruendo roba fuori
prima del tempo che abbiamo
bisogno e questo potrebbe essere ovvio, ma tu lo faresti
essere sorpreso dal numero di avorio
tipi di torri che si sono trasferiti nella costruzione
micro-servizi che dicono proprio quello che siamo
andando a fare ora è progettare tutto il nostro
i micro servizi in questo momento spesso lo fanno
la mia opinione che non funzionerà
approccio penso che dovremmo ancora prendere è
che non si ha intenzione di bisogno costruire
fuori le cose quando ne hai bisogno
quando ne hai bisogno solo quando ti serve
loro quindi inizialmente costruiscono un servizio
e poi quando hai bisogno di costruire
un’altra forse è la base del codice
complesso
forse forse per altri fattori potrebbe essere
i fattori non funzionali si sviluppano senza
il prossimo servizio è ciò che penso
risposta e quasi all’idea di fare noi
inizia con il monolite o no ma
in modo cruciale l’ Agni si applica al micro
architetture di servizi è tutto
costruire le cose quando ne hai bisogno
non progettare di nuovo davanti così per me
questo tipo di detiene ancora questo è questo è
un insieme di modelli che sembra avere
caduto dal generale non usare perché
le persone riconoscono ancora l’importanza
ma delle mani di memoria collettiva della gente
su, se vi siete imbattuti, comprendete, sì, lo è
un po ‘interessante, quindi questo è bene
prima ha iniziato ad interessarsi di sorta
del design la Gang of Four e tutti questi
cose che mi sono state presentate per cogliere e
sono gli stand dal generale
incarico di responsabilità nel software
schemi abbastanza sicuri di quello giusto
e sono stati sviluppati da un tizio chiamato
Craig lahrman che è diventato credo di più
ben noto più tardi per scrivere libri
su tutte le tecniche di gestione agili
sviluppo e gestione del software
gestione come tutti i progetti software ma
da noi ne prendiamo un paio davvero
molto conosciuto e abbastanza ovvio
modelli che sono PI al livello di
micro servizi illustrerò questo
era con un esempio quindi ero a un cliente
dei nostri l’anno scorso la scorsa estate
ed erano un posto interessante
perché hanno costruito un set di
servizi in India e un set di
servizi nel Regno Unito ho avuto una grande squadra in
L’India è una grande squadra nel Regno Unito e li incontra
sia per fortuna che per noiosa possibilità felice
ognuna di queste diverse posizioni era
costruire una capacità particolare
proprio così in India ne stava costruendo uno
cosa una cosa molto discreta e in
Londra stavano costruendo un altro
cosa discreta c’erano una specie di a
compagnia di viaggi vendono biglietti per
cose così un posto stava costruendo il bit
questo bene è possibile acquistare i biglietti come un
il cliente e l’altro bit stavano costruendo
il pezzo in cui hai ricevuto il biglietto
giusto essenzialmente l’adempimento al dettaglio
ci sono altre cose più complicate in
anche nel mezzo , ma sì
praticamente lo diciamo e la realizzazione
e la cosa veramente carina di questo e
Penso che forse la cosa ovvia
succede e ancora se per fortuna o
giudizio o qualche altro Samar o
qualcos’altro avevano finito con questo
soluzione in cui avevano una grande importanza in
Londra e una grande cosa in India con a
autobus in mezzo e stavano passando
messaggi tra i due
incidentalmente Simon Brown se lo conosci
odia i miei diagrammi di architettura e questo
è un esempio in realtà di due modelli
da afferrare così l’erba parlava in un
mondo ideale che vogliamo avere altamente
software adesivo e liberamente accoppiato
software e questi due indipendenti
le capacità erano estremamente vaghe
accoppiato da questo autobus nel mezzo e
il messaggio che lo trasmetteva funzionava
davvero molto bene le due squadre
potrebbe operare indipendentemente il test di implementazione
indipendentemente e così via così assolutamente io
pensa quando stiamo costruendo i micro servizi
architetture basate che vogliamo essere
in cerca di alta coesione e basso
accoppiamento e penso che storicamente abbiamo
fatto un brutto lavoro soprattutto alla coesione
perché ciò che abbiamo teso a fare è concentrarsi
sulla coesione intorno a preoccupazioni tecniche così
saremo coesi per separati
preoccupazioni ed essere di circa
presentazione e
i sistemi dicono e quindi metteremo tutto il
roba di presentazione in un posto e tutto
la roba di persistenza in un altro posto
che è un po ‘coeso, sono io
preoccupazioni tecniche ma che porta a
tipo di accoppiamento molto stretto tra
preoccupazioni di business quindi in questo esempio
quello che stiamo facendo è coeso intorno al
le imprese riguardano il business
capacità le cose funzionali reali
che questa cosa deve fare piuttosto
che l’ organizzazione tecnica di esso
questa è la prossima cosa che sono la prossima cosa che sono
intenzione di parlare è asciutto così questo è venuto
come una domanda negli ultimi e ai
fine dell’ultimo discorso sul discorso di Fred
quindi non ripeterti asciutto e questo è
questo spesso succede se dovessimo permettere
duplicazione tra servizi o schwöre
dovremmo forse estrarre qualche codice comune
estrarre alcune librerie di dominio comuni e
in modo che condividiamo il codice tra i servizi
e quindi la mia risposta semplice è che non dovresti
estrai codice comune a meno che non sia molto
tipo di infrastruttura di base molto semplice codice I
spiega perché questa è la definizione di
asciutto questo è da prav Dave credo che se
lui è nella stanza, non ne sono sicuro
il pezzo di conoscenza deve avere un singolo
rappresentazione autoritaria inequivocabile
all’interno di un sistema
Stavo pensando questo è ancora
vale ancora per i micro servizi
hai già sentito la mia risposta ma io
spiega il mio ragionamento quindi se ne abbiamo due
servizi e abbiamo del codice condiviso
indicato dalla stella in questo diagramma o
comune ci può essere la duplicazione attraverso
queste cose, la tentazione è quella di
estrai quella stella e dì che sai cosa
riutilizziamo lo inseriremo in un file jar
da qualche parte o qualche dll condivisa ci incolleremo
nella nuova ottenere questi giorni faremo Stick it
nel nostro repo Maven e io sono a
repository artifactory e quindi sai
qualunque cosa abbia bisogno può abbatterlo e
possono includerlo in fase di compilazione e
allora possono essere schierati può essere
schierato
ma il problema con questo è ogni volta che tu
introdurre le dipendenze binarie condivise
tra persone tra diverse
servizi che bloccano completamente il loro treno
cicli insieme e se intendi se
hai mai usato la saggezza per me
sul tipo di deathstar delle SS mai
mai usare il legame di saggezza che è dove tu
generare stub a generare stub come
una fase di pre-elaborazione e quindi includere
quei tronconi nella tua nella tua applicazione
e utilizzare quegli stub per effettuare chiamate attraverso
la rete se l’hai mai usata
probabilmente hai visto i problemi con
ciò che è ogni volta uno di quelli
i servizi di una di queste API sono i cambiamenti
improvvisamente ognuno dei tuoi
i clienti stanno per ricompilare e
ridistribuire e questo è il motivo per cui non lo facciamo
o meglio il mio io e i miei colleghi di
le parrucche piene non tendono a preferire l’uso
qualcosa come la saggezza vincolante ma
estraendo l’estrazione del codice di dominio condiviso
ti dà esattamente lo stesso problema
all’improvviso ti stai bloccando cambierai
cicli del tuo software insieme e se
hai centinaia di microservizi e
forse condividono qualcosa di comune
chiamato un cliente che davvero non vuoi
deve essere distribuito ridistribuzione a
cento cose ogni volta che il tuo cliente
ottiene un nuovo tipo di campo di schifezze ci sono
approcci diversi per affrontare questo
ho già detto che per esempio sono
personalmente va bene con l’estrazione
cose come condivise come condivise
codici infrastrutturali se hai un
Client HTTP che probabilmente va bene inserire
in un nuovo pacchetto get da qualche parte
un file jar se guardi tutto il
Netflix open source troppo tardi si
tutte cose molto specificamente generiche
come l’implementazione dell’interruttore automatico
monitoraggio delle implementazioni dei bulbo
questo genere di cose mi sta bene
c’è un altro approccio che è da usare
qualcosa chiamato un modello di servizio così a
molti strumenti ora, quindi cose del genere
il boot o drop wizard di primavera va in qualche modo
verso la fornitura di un modello che è possibile utilizzare
per costruire servizi e ci sono
altri in altre lingue, ma questi lo sono
quelli che mi sono più familiari ma che cosa
non lo fanno è darti il
roba specifica del dominio su quello che tu
richiedere nella tua organizzazione in cima
così buona pratica che abbiamo trovato è quella di estrarre
un modello di servizio che contiene forse
sì, il modo in cui facciamo il login qui come noi
monarca monitorando il nostro modo di fare
le pagine di stato lo mettono in una condivisione
posizione e poi quando è necessario
crea un nuovo servizio che puoi semplicemente clonare
meno e ricevi per esempio due servizi
modelli e la ragione un altro di
le ragioni per cui questa è una buona idea sono
perché essenzialmente se non stiamo condividendo
il codice principale o anche se stiamo condividendo
il codice principale su ciascuno dei nostri servizi
il tempo sta per cambiare sta per
diventare sta per passare attraverso la propria
insieme di singoli cambiamenti che stanno andando
divergere dal modello di servizio
in sostanza stanno per passare
pantaloni diversi su tutte le biforcazioni
tracce di realtà e quindi questo è il motivo
essenzialmente sono arrivato a questa conclusione
che è lo stesso che aveva Fred
che è essenzialmente copia e incolla
okay
copia e incolla va bene, ma continuo a pensare
dovremmo essere asciutti all’interno dei servizi così
all’interno dei singoli micro servizi I
penso che dovremmo ancora applicare allo stesso
serie di pratiche per rimuovere la duplicazione
in modo da mantenere il codice pulito successivo in modo
c’è stato un bel po ‘di polemiche
sullo sviluppo basato su test di recente
dovremmo farlo se dovessimo farlo affatto
è solo uno spreco, è solo uno spreco
le mie opinioni su questo e loro no
corrisponde sempre con alcuni dei nostri altri
ben noto con altre persone ben note
nel UM qui nel nostro settore così
la prova di prova si sviluppa usando test-driven
sviluppo come strumento per il design
in primo luogo prima che io non sono del tutto sicuro che
Non so certamente più di un decennio e io
è stato molto fortunato perché in realtà ho imparato
come scrivere il codice guidato dai test di a
un sacco di persone che lavoro con quel pensiero
funziona bene mi sono iscritto circa 10 anni fa
11 anni fa um e come parte dell’apprendimento
come scrivere il codice guidato dai test I
ho notato una cosa davvero divertente che è stata
il codice che ho scritto
ho finito per guardare in un certo modo la mia gente
l’ho notato se segui il test
Scrivo un test che Watson viene qui fornire
alcuni refactor rosso refactor codice
cicla ma il tuo codice finisce per apparire a
certo modo nei linguaggi orientati agli oggetti
ti ritrovi con piccoli oggetti in genere
con un piccolo numero di responsabilità
tendi a iniettare le cose attraverso
dipendenze dei costruttori attraverso
il codice dei costruttori sembra semplice e
comprensibile e nel tempo a volte io
non utilizzare lo sviluppo basato su test
in esclusiva sarò onesto
a volte penso solo a cose di te
so cosa sto per fare, sono una specie di I
capisco bene questo problema, lo farò
fare un test intorno a quello che
verifica che il mio software funzioni
anche se queste unità di software sono
lavorando e continuerò a scrivere alcuni
codice ma in generale negli ultimi 10 11
anni qualunque sia il modo in cui scrivo
codice è stato guidato da imparare a
fai TDD perché penso quindi guidato dai test
sviluppo a parte il fatto che esso
Penso che guidi il codice pulito perché lo faccio
pensa che questo sia importante per micro
servizi bene abbiamo già parlato a
minuto fa all’inizio su come
i test end-to-end diventano davvero reali
duro proprio così scrivendo un sacco di questi
test di grandi dimensioni diventano davvero davvero
difficile
Vedo che mi aspetto scrivere più unità
prova quindi isolando questi servizi e
scrivere unit test per la funzionalità
al loro interno per il codice al loro interno
diventa più importante in quel caso
se non hai letto questo libro è
fantastici hamburger con piume di microfono
descrive la crescita orientata agli oggetti
software guidato da test con un prezzo dell’app
e Steve Freeman come a Londra
Scuola di sviluppo test-driven entrambi
da entrambi gli autori erano a parrucche piene
Quando sono entrato a Londra, ho passato un po ‘di tempo
li incontrai ovviamente in un certo tempo con
non hanno mai realmente lavorato a un progetto
con loro ma questo libro descrive come
per cui Londra o le persone che lavorano
dentro per cui Londra pensa davvero
riguardo a scrivere o scrivere test
codice guidato e come progettare il tuo
software scrivendo prima i test
quindi ha voluto rispondere a questa domanda o
forse una domanda leggermente diversa
dovremmo preoccuparci di testare la nostra guida
codice se vogliamo solo buttare le cose
via giusta costruzione bene sostituibile
micro servizi micro servizi che noi
può buttare via la costruzione del sistema di costruzione
software che non è mai fatto, dovremmo noi
perdere tempo con esso, a mio parere penso che
dovrebbe perché il valore io personalmente
ottenere o io e vedere le nostre squadre ottenere
dalla scrittura prova test unitari speciali
e prova a guidare il loro codice e il
importanza di avere test più piccoli
con i micro servizi per me intendo io
credo che dovremmo essere e sto solo andando
per coprire forse alcuni dei
CONTROVERSIE questi sono i alcuni dei
persone che ho avuto la fortuna di lavorare
con nel pensiero che Londra così tanto
queste persone sono diventate giuste
ben noto nel test
comunità la comunità del design l ‘
le comunità di architettura, ad esempio
in quel prezzo e Steve Freeman ha scritto
quel libro giù a nord
conosci l’originatore di BVD liske qui
lei ha un premio passato dall’agile
DeAngelis un gruppo di altri e oltre
tempo le loro opinioni su TDD hanno
cambiato nel tempo un sacco di ben noto
figure in opinioni del nostro settore circa
QP ha cambiato le mie sensazioni come ho detto
quel test che guida il nostro codice è ancora molto
molto prezioso e mi piacerebbe avere forse
terrorizzare il modo in cui penso a come forse
alcune altre persone parlano di TDD
questo è qualcosa chiamato Dreyfus
modello di acquisizione di abilità in cui sono stato
software per I do not know what is 15
non si. 15 anni 16 anni non sono tranquillo
un cuz di barba grigia che dura da 20 anni, ma io sì
avere una barba grigia se questo aiuta così ho
stato scrivere software per un po ‘di tempo
e in alcune aree del software
sviluppo mi considero un esperto
sulla scala Dreyfus per la pesca o un
esperto
probabilmente esperto o esperto in
lo sviluppo basato sui test comunque e molto
delle persone che ho appena menzionato
anche esperti nello sviluppo basato sui test
hanno imparato le lezioni e lo sono
iniziando a muoversi sulle loro cose e
hanno interiorizzato quello che hanno
imparato a scrivere il codice di scrittura
guidato dai test, credo che la ragione per cui sono
menzionare questo è pensare attentamente
prima di prendere il consiglio che con
i micro-servizi improvvisamente non dovremmo
scrivere qualsiasi desiderio non dovremmo testare la guida
la nostra sterlina più perché un sacco di
le persone danno un consiglio anche se valido
consigli per loro e per il lavoro
loro stanno venendo da una posizione
di esperienza avendo imparato le lezioni
loro già scrivono il codice in un certo modo
perché loro hanno imparato come
fallo prima scrivendo il codice test
quindi per riassumere dovrebbe essere scritto
test unitari personalmente penso che dovremmo
e penso che sia più importante di
mai abbiamo bisogno di continuare a quel test
piramide con un sacco di piccoli test al
in fondo la prossima cosa è SRP single
principio di responsabilità e oggetti
dovrebbe avere una sola ragione per cambiare
era la dichiarazione originale quindi la mia
collega che ora è nel primo
colonie ora vicino a 4j Alastair Jones
il mio software su una squadra e siamo arrivati
con questa euristica essenzialmente è a
ridefinizione di SRP ed è una classe
non dovrebbe essere più grande della mia testa e
questo è questo è la testa di Allister questo è
un orecchio in realtà vicino e loro
uffici a Londra, quindi questo è di Allister
testa e sta controllando se una classe
è abbastanza grande o troppo grande e io
pensa al tweet che hanno deciso che fosse
bene ma cosa intendiamo per non più grande
di una testa e come si applica a
micro servizi bene per me
mandare le sue tartarughe fino in fondo credo
è come hai fatto a pezzi diversi livelli
di astrazione per me il singolo
principio di responsabilità applica il
altro stato vicino all’altra direzione di
guardandoli non più grande di testa
cosa dovrei essere in grado di capire
tutto di un oggetto tutto bene io
dovrebbe essere in grado di consapevolmente in realtà
essere in grado di ragionare esattamente su tutto
oggetto sta facendo dovrebbe avere un singolo
responsabilità unica ragione per cambiare
e mentre dividi dal livello di un
oggetto in dire servizio che dovrebbe avere
una sola responsabilità e come pezzo
di nuovo al livello di forse un insieme di
servizi che il nostro team possiede che dovrebbero
avere una singola responsabilità singola
motivo per cambiare mentre ti blocchi di nuovo
al livello di un sistema di sistemi
singola responsabilità e ad ogni livello
di astrazione dovresti essere in grado di adattarti
questa roba nella tua testa ovviamente io
non posso tenere la testa su un monitor e
controlla se Netflix si adatta al tutto
L’architettura distribuita di Netflix è
grande come la mia testa ma concettualmente
è così che dovrebbe essere un servizio SRP
non essere più grande della mia testa il prossimo
bacia le mani in alto bacio mantienilo stupido
cosa rendere semplice se siamo carini
quindi questo è qualcosa dall’ultima
edizione del nostro radar tecnologico a
ThoughtWorks e questo è dove
abbiamo messo in attesa i server delle applicazioni ora
questo potrebbe questo è un po ‘paura di troppo
la gente ha un po ‘paura ai team ops ma noi
stavamo solo cercando di chiamare essenzialmente
che i tempi non sono più cambiati
bisogno di usare una grande applicazione di ferro
server che non è più necessario distribuire
micro servizi molti di loro in un grande
server delle applicazioni ho paura per quelli
persone che sono attualmente su WebLogic
squadra non sta guardando così grande e il
cosa interessante è perché se tu
pensaci ma i tempi sono cambiati
destra siamo passati da avere uno
costosa macchina grande in modo che avremmo
mettere un server di applicazioni che sarebbe
gestire un sacco di piccoli di
applicazioni su di esso per avere un sacco e
molte piccole macchine va bene questo è
il movimento verso di te sa di aiuto
il movimento del contenitore o un singolo
servizio per immagine macchina singola
server
per esempio sull’onore
infrastruttura-come-un-servizio che non lo facciamo
bisogno dei server delle applicazioni pesanti
in quel mondo si mettono di mezzo
dei test che fanno rallentano i test
giù
rendono più difficile la consegna continua
fanno in modo che il mio lavoro si sviluppi di nuovo
cercando di ottenere il codice più velocemente
i server applicazioni sono in attesa quando penso
riguardo al bacio questo mi passa per la testa
WWJD e che probabilmente non lo fa
senso, ma significa che cosa farebbe Joe
questo è Joe, con cui ho lavorato per me
per un tempo in tutti i modi e lui è di gran lunga
lo sviluppatore più produttivo che abbia mai visto
incontrato non sono un grande fan di ora sono
tipo di cosa 10 volte la produttività, ma
Joe da solo è equivalente a a
squadra di circa 10 persone quindi forse c’è
una parte di verità in esso e quando ci penso
cosa farebbe quello che Joe farebbe quello che Joe
farebbe la cosa più semplice possibile
manterrebbe le cose davvero davvero
semplice se si trova di fronte a un problema lui
lo risolve in un modo molto molto elegante
un esempio di ciò è che era su a
progetto voleva che lui avesse bisogno del nostro lui
necessario per comunicare con WebSockets
un client e un browser e stava cercando
attorno a tutti i diversi WebSocket
supporto nei diversi server delle app
lì è una specie di grandi cose che è
pensato ora non ho intenzione di farlo e così
quello che ha fatto è invece ha rotto il suo proprio
ha scritto il proprio server di applicazioni ora
sembra pazzesco, tutto a posto
pazzo che potremmo uscire e scrivere
il nostro server di applicazioni ma in realtà
a volte fare cose del genere è il
la cosa più semplice che possa funzionare
mantenendolo semplice e ti darò
un altro esempio di questo da un progetto I
era su così stavamo costruendo il mio
Architetture del ricevitore per una scienza
sito di pubblicazione e abbiamo avuto il
obbligo di provare e visualizzare i nostri
infrastruttura in cui stavamo implementando
AWS e volevamo visualizzare il nostro
infrastrutture abbiamo avuto un paio di opzioni
uno dei quali doveva aspettare fino ad alcuni di
i fornitori di strumenti pesanti erano in grado di farlo
supporto server immutabili e tipo di
infrastruttura solo append questo è dove
server fa
un su e giù per tutto il tempo e molto
le grandi case di software non lo fanno
sostenere Battlestar eppure scherziamo per schierare
qualcosa come console ma al fine di
console di produzione hardening sei tu
parlando di voi conoscete cinque anelli dei nodi
è abbastanza complicato da ottenere
quello e nel frattempo fino a che non abbiamo ottenuto
lì non abbiamo davvero capito cosa
era in produzione e quindi due
giorni Mina compagno si avvicinò con questo
visualizzazione quindi questa è la nostra produzione
infrastruttura facendo una distribuzione Bluegreen
se puoi vederlo e usiamo cron e
Il punto e il grafico di Python e Bato e PI lo è
e questo ha funzionato correttamente questo era il
la cosa più semplice che potremmo fare
visualizzare la nostra infrastruttura in modo tale
sai che i nostri tester hanno capito bene
quali versioni erano in esecuzione che il
gli sviluppatori potrebbero guardare lo schermo e
vedi tutto bene va bene l’endpoint DNS ha
cambiato la cosa più semplice che
potrebbe funzionare e poi eventualmente
mettiamo console e abbiamo tutto il
belle dashboard e cose così fa
tenerlo semplice significa molto in questo senso io
penso che si applica ancora penso che ancora
si applica in questo senso è sempre
applicato che è provare e trovare il
soluzione più semplice che c’è possibile
non inclinarti verso pesi massimi molto grandi
le soluzioni fanno la cosa più semplice possibile
così rapidamente perché ho due minuti
a sinistra ho intenzione di parlare di integrazione
e il dispiegamento così ho coperto quelli a
l’inizio quindi se siamo in questo mondo
dove l’integrazione verifica tutti questi
altre pratiche sono ancora valide
che dire di questo tipo di integrazione
testare il problema degli ambienti di integrazione
quello non sembra farlo per essere valido
ci sono altri strumenti che possiamo mettere in
la nostra cassetta degli attrezzi penso che ci siano così i
la prima cosa che possiamo aggiungere è questa idea
di monitoraggio semantico così semantico
il monitoraggio è dove in produzione corriamo
cose che sarebbero normalmente cose
come test di viaggio dell’utente o accettazione
test contro la nostra produzione
infrastruttura quindi testiamo se tu
come in produzione non è così
diverso dall’idea del test del fumo
è solo leggermente più è leggermente
approccio più disciplinato c’è un grande
descrizione
di esso sui baluardi scienza radar se
hanno uno sguardo che è la prima cosa
la prossima cosa che penso di poter fare penso
ci saranno alcuni discorsi che parlano di questo
più tardi possiamo provare e ottenere feedback per
quando rompiamo le animazioni precedenti
rotto prima sai che ti conosci
sai che conosci i cicli di feedback in modo che possiamo
distribuire il nostro software in produzione e
vedi se rompe è un approccio e
il monitoraggio semantico ci dirà se è così
compra un’altra cosa che vogliamo
voglio fare è sviluppatori è capire a
un po ‘prima e quindi possiamo scrivere
contratti eseguibili per i nostri servizi
e darli alle persone che scrivono
i servizi e questi sono chiamati
contratti guidati dai consumatori e questi possono
essere eseguito come amico del nostro ciclo di build così
acquistiamo mano dei contratti guidati dai consumatori
loro ai nostri fornitori di
servizi e poi quando eseguono il loro
costruire se il comportamento ha cambiato il
costruisco pause scusate per ottenere un po ‘ meta io sono
intenzione deliberatamente nel tempo di a
un paio di minuti è un motivo per essere noi
non voglio inondare completamente il pranzo
alle code mi è stato chiesto di farlo comunque
è tornato ai contratti guidati dai consumatori
semplicemente quello che fai è scrivere a
insieme di aspettative come consumatore di a
il servizio va bene si tratta di un eseguibile
formato e lo includi come parte del
costruzione dei servizi costruire pipeline
idea semplice ma in realtà era abbastanza
rivoluzionari dieci anni fa um non ha
davvero adottato fino a forse questo
l’anno scorso e ora c’è l’attrezzatura
disponibile a fare questo certamente in Ruby
patto di sintesi disponibile su
github è uno strumento open source quindi
la prossima cosa è testare in produzione I
accennato brevemente cosa intendo con
testare in produzione bene piuttosto che
tonalità come parte di un UAT formale simile
fase prima di voi distribuiamo il nostro software
tutto a ventaglio in un’integrazione
ambiente abbiamo effettivamente spingere il nostro
software direttamente in produzione e
prova lì tutto bene se ce l’abbiamo davvero
buon monitoraggio quindi sappiamo che le cose non lo sono
spezzare questo è un tipo di valido
approccio se abbiamo quella semantica
monitoraggio se abbiamo da sumer
diversi contratti
luogo in modo da minimizzare il numero di
rompendo i cambiamenti che ci ottenere questo è
funzionerà quindi a cosa si basa
naturalmente è stato in grado di salvare il nostro QA è
i nostri product manager o proprietari di prodotti
sono in grado di accedere e come
scusa, siamo in grado di farlo
distinguere chi sono così che loro
posso testare in produzione così sono davvero
dicendo che avremo intenzione di farla finita
ambienti di integrazione penso molto
di aziende che stanno costruendo micro
le architetture di servizio hanno già io
pensalo mentre ottieni più di queste cose
Penso che sia inevitabile, penso che sia così
solo il modo devi andare um
è spaventoso, mi dispiace proprio così
è ma questo è qualcosa che forse
aiuta ad affrontare il dolore questo è reale
la realizzazione che ho avuto di nuovo sta andando indietro
per quello che abbiamo fatto nella vostra regione per avere
forse due data center e abbiamo abbiamo
un attivo e un passivo avremmo alcuni
software che li gestisce uno e
allora aggiorneremmo l’altro sì
uno era vivo e uno era al caldo uno
non era in questi giorni con elastico
infrastruttura quando stiamo implementando
cose in infrastrutture come il
fornitori di servizi non ci sono davvero scuse
c’è una differenza tra il dispiegamento
nel tuo ambiente di produzione così
sabbioso capisce qualcosa che è
su quello è là fuori che è sul web
e in realtà vengono utilizzati da
persone c’è una differenza tra
essere in diretta e ottenere traffico dal vivo e
in realtà essere in produzione, quindi puoi
distribuire effettivamente tante versioni di
le cose che vuoi nel tuo ultimo rack
infrastruttura ma a meno che effettivamente usi
a usarlo non è live, quindi questo lo rende
l’idea di farla finita
ambienti di integrazione un po ‘meno
spaventoso giusto
perché possiamo solo schierare nel
produzione possiamo permettere il nostro prodotto
proprietari responsabili di prodotto QA di business popolare
s per testare le cose in produzione e poi
possiamo farlo vivere dirigendo il traffico
e questo è il modo per farlo
incluso questo è blu canarino build
distribuisce il verde ed è giusto in a / b
testare così
finalmente cambiando servizi in modo indipendente
beh, questo è qualcosa che ho imparato
dal parlare con alcune persone in
Adrienne Cockcroft in particolare se
faremo una modifica ad a
servizio commettere un codice che sta per
passare attraverso la produzione
una delle cose che dobbiamo pensare è
qual è il raggio di esplosione di quel cambiamento
giusto chi è che il cambiamento avrà un impatto
quali altri servizi cambieranno
impatto e penso che ci sia quasi come
tre livelli qui è il primo livello
se il cambiamento è limitato all’interno
la tua squadra se qualcuno al di fuori del tuo
la squadra sarà interessata perché se
è questo se non si espanderà dentro
il raggio di esplosione che l’esplosione non ha
espandi la tua squadra e poi probabilmente tu
in grado di gestire il controllo delle versioni e modificare solo da
Parlando con le persone, cambierò questo
devi cambiare la tua cosa ora è
va bene, va bene
andiamo via la prossima cosa è è
limitato all’interno di un contesto a banda o scusa
tra un contesto limitato se è allora
potresti volerlo pensare
contratti guidati dai consumatori e forse
versioni semantiche di questo tipo
di tecniche e la terza cosa è
organizzativo quindi se il tuo Google tu
non voglio cambiare l’API di Maps
molto spesso perché il raggio di esplosione di
che va bene è una specie di Occidentale
civiltà come la conosciamo bene
e la ragione per cui stavo pensando a questo
è questo libro di Thomas Allen che hanno parlato
riguardo a questo, parla di come
flussi di informazioni in giro
organizzazioni ed è interessante
perché dopo circa 15 metri o 10
metri di distanza da qualcuno il
probabilità di interagire di avere
conversazioni serendipite è
praticamente zero perché è così importante
beh, vuoi limitare il tuo cambiamento
voglio applicare diverse tecniche
più lontano sei da qualcuno e
questo è di nuovo il punto in cui entra in vigore la legge delle virgole
quindi per l’integrazione interaziendale forse
stai pensando a modelli come
versioning semantico ma se quando
stai parlando del cambiamento in un
l’organizzazione tra le squadre dice la tua trama
applicando diversi tipi di
cose così forse potrebbero essere versioni semantiche
testare i lettori tolleranti
e poi all’interno dei team forse lo siamo
parlando di cambiamenti conversazionali così
Cambierò questo puoi cambiare il tuo
cosa è un’estate il futuro è spaventoso
giusto non sappiamo come fare un sacco di
questa roba ancora per parafrasare Auto mi dispiace
per reiterare quello che Fred stava dicendo ma a
allo stesso tempo molte cose che sappiamo
come si fa già ancora, penso
quando stiamo costruendo servizi di micro così
è una specie di bella cosa e anche
ci sono un sacco di nuove cose interessanti che noi
può fare bene e c’è un sacco di novità
roba da imparare e francamente uno dei
I motivi per cui sono nel software è perché io
amo imparare cose nuove così in sintesi
la cosa più semplice possibile grazie molto
tanto
tu
Please follow and like us: