quindi penso che tu abbia sentito che il futuro
è già qui non è uniformemente
distribuito quindi se vuoi sapere qualcosa
il futuro come diciamo il 2020 in realtà
non è così lontano nel futuro
forse più di tre anni al 2025 tutti voi
deve fare è guardare un po ‘ nel
angoli di quello che sta succedendo oggi e e
in effetti a questa conferenza stai andando
fare un bel po ‘di quello e tu
avere una buona idea di dove il
futuro sta per andare diamo tuttavia go
di ritorno forse 20 anni o qualcosa del genere
così e la prima cosa che voglio
parlare di scala sta diventando grande
perché in realtà 20 anni fa le cose
erano cose che sembravano grandi sono davvero
piccolo oggi e cose grandi
oggi si sono ridimensionati in modo particolare
modo interessante hanno scalato piuttosto piuttosto
che alto quindi se tu fossi un pinguino in
Tutte le immagini di questa isola della Georgia del sud
a proposito sono stati presi da mio marito Tom
chi è un grande fotografo e questo è
re pinguini e quando non hanno
Hai abbastanza spazio per andare in mare
non si arrampicano su più montagne e
quindi parliamo di cosa è successo 20
anni fa
nel 1996 qual era lo stato di ciò che era
andando là la maggior parte del software
lo sviluppo in quel momento era business
software o software di controllo quando l’ho fatto
sviluppo del software ero un processo
Ingegnere di controllo che ho controllato in grande
pezzi di equipaggiamento con il mio codice che
Sono di parte, ma penso che sia il migliore
soffrire nel mondo e quindi non ero
coinvolto in questa roba che chiamano IT
ma la maggior parte del software è stato fatto almeno il
la letteratura per leggere la letteratura
era tutto sulla grande transazione
elaborazione per lo più in imprese
e questo è come Internet ha iniziato
insieme un po ‘di software
Ricordo che nel 1999 qualcuno stava dicendo
su quanto velocemente il software è grande
il software non era il tempo necessario
Cambiamo stiamo parlando di un rilascio di un anno
è stato veloce, mi ricordo di aver letto
mondo informatico che ci sono alcune squadre
là fuori che hanno imparato come
consegnare il software in sei mesi puoi
immagina che sia stato davvero lento
cambio e pensavo sapessi che c’è un
moltissimo nuovo software che è arrivato
questo è novantanove e stavo parlando con
alcuni colleghi e si chiama il
Internet si sa che è un sacco di
un software che è stato sviluppato nel
ultimi anni e mi guardò e disse
Internet che non è software sì
è ma è diverso tipo di software
quindi nel 1996 abbiamo pensato a
elaborazione delle transazioni come qui a
database un database ERP quando ero
Ho seguito i sistemi di controllo del processo
uno dei miei sistemi per una produzione
pianta e ho diretto l’ informazione
ufficio tecnologico nella produzione
pianta e abbiamo fatto qualcosa chiamato MRP
chiamata pianificazione dei fabbisogni materiali
il che significa che abbiamo pianificato tutto il
diversi movimenti di inventario che
capita attraverso la pianta e tutto il
stazioni di lavoro di produzione e quello
alla fine ampliato al tutto
impresa quindi ottenuto di essere chiamato ERP
pianificazione delle risorse aziendali e
era la pianificazione delle risorse aziendali
centrato su un database aziendale
database l’unica cosa che ordina
di tutte le applicazioni integrate in
l’impresa e lo fa ancora
ed è seduto su un singolo server e bene
perchè è così, sai, c’è questo?
Teorema chiamato teorema del cappuccio che puoi
ne ho sentito parlare che sostanzialmente dice se
hai diviso il tuo database su due
diversi server lì puoi averne uno
di due cose ma non puoi averle entrambe
puoi averlo a disposizione
istantaneamente quando lo vuoi o puoi farlo
avere una coerenza
sistente si può avere la consistenza di
attraverso una transazione il tutto
transazione o niente di tutto ciò, ma non è possibile
avere entrambi e così perché il database
è stata la cosa che ci ha fornito entrambi
la disponibilità e la coerenza di
transazioni dovevamo averlo su un
server singolo, quindi se si guarda nel
Alla fine degli anni ’90 tutti i database erano lì
l’ impresa corporativa seduta su
un grande computer e integrato attraverso
quel computer e quello era come l’ unico
strada da percorrere ma poi lo sai
Arriva Google e improvvisamente ci fu
un sacco di dati che non andavano bene
un server in effetti se ne hai
1,3 miliardi di pagine questo è il 2001
non è solo andare a lavorare si deve
attraversare un gruppo più un mucchio di più
server devi capire come fare
in un modo che ti consente di rispondere
molto rapidamente quindi ci sono due modi in cui puoi
vai alla grande o puoi andare largo ok o alto
largo si può ottenere molto più grande
computer e abbastanza interessante in
circa 2000 penso che sia stato Amazon
seduto lì con un grande fronte in uno
grande front-end e quando il grande back-end si
conoscere quel singolo database e ad ogni
le festività natalizie non potevano assolutamente
gestire il volume della transazione più
e così sai cosa hanno fatto loro hanno ottenuto un
computer più grande e sai cosa
successo ok se ne sapete qualcosa
teoria delle code tu vai al gruppo più grande
e tu diventi più lento e loro sono più lenti
così hanno detto bene che non lo farà
lavoro così questo è Grace Hooper che hai
sentito parlare di grigio super lei è una sorta di te
so che è lei che ha progettato COBOL
e tutto quanto e lei ha detto se un atto
non poteva fare un lavoro che non hanno cercato di
coltivare un bue più grande che erano abituati a fare
quando abbiamo bisogno di una maggiore potenza del computer
la risposta è di non avere un computer più grande
è costruire sistemi di computer e
gestirli in parallelo gestiti da
software che è l’intero concetto di
ridimensionamento anziché scalare
ottieni più computer
e capisci come affrontare il
fatto che hanno problemi così per
esempio qui è uno dei primi Hardware
rack di Google nel 1999 è nel
Computer History Museum ora e quando io
sentito per la prima volta come stavano conservando
tutti quei miliardi di pagine che ero
piuttosto sorpreso hanno usato questo davvero
roba economica e si aspettavano che fallisse
e hanno mantenuto più copie di roba
quindi potevano semplicemente buttar via la roba
che fallisce come una buona idea e
lo hanno gestito con un software in modo che il
concetto era in realtà tipo di radicale
prima ma davvero l’unico modo per farlo
l’intera idea se stai andando a cercare
l’intero internet e tu stai andando a
fornire risposte istantaneamente è così
solo prendi il tuo hardware e
spargilo devi fare lo stesso
con il tuo file system ecco quindi il
documento iniziale del 2003 sul file di Google
sistema e lo stesso concetto che hai preso tu
prendi piccoli pezzi del tuo file
buttali ovunque nel posto che fai
certo che hai tre buone copie di
tutto e poi quando uno di loro
muore va bene ci sono altri due voi
solo una sorta di buttare via quella roba
muore e lo rigenera ed è quello
tutto il concetto che il tuo intero sottostante
il sistema è fragile nessun problema tu gestisci
e tu hai più istanze così
puoi affrontarlo e poi ovviamente
hai i dati che si devono
ricerca sparpagliata all’istante
questi file e un anno dopo, nel 2004
sono usciti con il giornale
MapReduce che divenne la base per
Hadoop che si diffonde
circa prese dal 2004 a forse il 2010 12
prima che emergesse improvvisamente come questo
cosa meravigliosa che tutti potrebbero usare
ci è voluto molto tempo per ottenere Hadoop
gestendo solo alcuni file e solo tu
conosci solo un paio di computer
qualcosa che potrebbe affrontare enormi
quantità di dati ed è stato fatto
fatto con Apache open source
progetto e penso sia stata la kalfa –
che ha lavorato su di esso
ha lavorato a yahoo con il quale è stato assunto
Yahoo perché hanno deciso forse loro
meglio andare anche a questa cosa MapReduce
e tra le varie grandi aziende in
Silicon Valley al momento il tutto
era la struttura sottostante di Hadoop
sviluppato su circa cinque- otto
periodo di un anno e c’era un sacco
di condivisione perché Doug lo ha deciso
stava per essere open source e lo farebbe
essere felice di lavorare per Yahoo, ma doveva essere
open source ed è quella cosa che noi
facciamo nel mondo dell’ingegneria del software noi
condividi le nostre conoscenze in modo che possano crescere
molto più veloce e non penso
senza la condivisione di tutto il
diversa conoscenza di come questi file
strutture e database funzionano penso che se
queste società mantenevano un proprietario che avremmo
essere un lungo ritorno da dove siamo
adesso
quindi questo è un concetto si scala con
un file system quando guardi il tuo
architettura è lo stesso concetto di te
potrebbe pensare che tu abbia un grande monolitico
database ma se ne hai una grande
database monolitico non sei grande
perché se è tutto in un punto è
in realtà piuttosto piccola per davvero
ottenere grandi è necessario scalare in modo cerchiamo di
torna in quell’Amazzonia come ho detto
circa 2004 2001 e ci sono stati
le transazioni gazillion e avevano
per gestire tutte queste transazioni tutte
allo stesso tempo e la prima opzione
era su scala okay quindi prendi e prendi a
singola transazione diciamo che è tutto
quattro cose là c’è lo shopping
carrello della spesa sai fare shopping
pagamento del carrello e adempimento va bene e se
dai un’occhiata a quello che poi puoi
ridimensiona l’intera transazione, magari anche
attraverso in diversi computer di Regent
se vuoi ma se vuoi ridimensionare
fuori scala in modo diverso
prendi la tua transazione e dici
sai cosa
Non lascerò che il database gestisca
più mi occuperò di ciò
transazione tutto da solo, quindi ho il mio
quattro diversi servizi dicono la navigazione
e l’acquisto e l’adempimento
nel pagamento e se ne ho alcuni
sono i colli di bottiglia che scalerò
quella piccola area risultò essere
più o meno il modo in cui le persone hanno
capito come scalare da come in
hanno fatto i micro servizi molto prima di a
molte altre compagnie e l’hanno fatto
perché l’ idea era se lo avessimo fatto
gestire molte transazioni
dovremo pensare in modo diverso
su come abbiamo scala Amazon ha avuto un incontro
dei dirigenti dopo uno di questi
disastri vacanza quasi disastrosa
stagioni e hanno detto come stiamo andando
per affrontare tutto questo il prossimo anno
e arrivarono a una conclusione
la conclusione era che dobbiamo comunicare
meglio hai mai sentito quel tipo di
suona familiare
Penso che sia una sorta di sbocco
se cop-out è una buona parola in inglese
è solo che non so cosa dici
Tedesco per il cop-out è um qual è il
qual è la buona traduzione per quello
hmm
su
l’avete sentito voi, quindi è un?
scusa interessante ma non è il
In effetti, sento la stessa cosa
allenando oh se solo avessimo avuto più allenamento
bene sai che Jeff Pisa dice che lo sai
quello di cui abbiamo bisogno è meno comunicazione
invece di più comunichiamo troppo
non scala non alla scala che io
intenzione di scalare questa azienda e così il
l’idea non è quella di comunicare di più l’ idea
è comunicare di meno e lo fai
attraverso un’architettura che non lo fa
costringere le persone a dover comunicare così
decise che avevano deciso che lo erano
andando a rompere l’azienda in molto
squadre più piccole e mettere quelle squadre
pezzi di software che non avevano
dipendenza in modo da non dover parlare
tra loro erano relativamente
squadre autonome come autonome come loro
potrebbe farli senza dipendenze come
il più possibile ed erano ciò che Jeff
Bezos chiama una squadra di pizza che potrebbero
essere servito il pranzo con due grandi Seattle
pizze di dimensioni sì sì forse otto persone
o qualcosa del genere e possiedono il
intero servizio dalla culla alla tomba
implementazione di test di progettazione di idee
tutto il monitoraggio in produzione e
così hai queste due squadre di pizza
trattare tutte queste transazioni
arrivando a possedere potrebbe a
servizio di carrello o potrebbero possedere
il servizio di raccomandazione o qualcosa del genere
così che il concetto di ridimensionamento
piuttosto che scalare funziona solo se tu
stanno usando software per gestire le cose
prima dipendevi dal
hardware o dipendendo dal dipendente
sul database quindi andiamo avanti
infrastruttura come codice e continua il nostro
storia perché ho appena parlato di scala
di cui vuoi parlare
l’infrastruttura come codice è un’altra
importante cosa estremamente importante
accadendo in ingegneria del software così
hai sentito parlare della legge di Conway per lo più
hai per quelli che non hanno
dice una sorta di organizzazione
struttura e la tua architettura di sistema
stanno andando a corrispondere non importa quanto sia difficile
non provi per la tua architettura
andando a guidare la tua organizzazione
struttura o la tua organizzazione
la struttura guiderà la tua architettura
ora se andiamo ad Amazon che poi si è rotto
in queste due squadre di pizza, ora
avere una struttura organizzativa che
ha guidato la loro architettura, quindi cosa
è successo questi due pezzi di squadre
dovevano essere autonomi, sì e
quindi avevano squadre autonome e
autonomo significa schieramenti indipendenti
questo è quello che ho intenzione di definirlo come
non posso prendere le mie decisioni
come posso distribuire senza dover
parlare con tutte le altre squadre che è cosa
una sorta di significato lì che fondamentalmente
ha creato il caos nelle operazioni se sei dentro
ops e all’improvviso ne hai avuti 50
milioni di team che cercano di schierare tutti
indipendenti l’ uno dall’altro e tu no
effettivamente gestito tutte le dipendenze
questo potrebbe essere un vero incubo
era così Chris Pinkham che era il vizio
presidente del pensiero infrastrutturale
su Amazon e pensato al
problema e ha detto che sai cosa dovremmo
fare come avere un self-service
implementazione per lo sviluppo facilità sai
invece di scaricare tutti i loro problemi
noi e le operazioni dovremmo lasciarli gestire
il loro problema li daremo loro
il codice da distribuire da soli e lui
detto che sai forse potremmo anche vendere
questa capacità e se sai qualcosa
a proposito di Jeff Bezos che è l’amministratore delegato lì
lo sai che se hai qualcosa, lui
potrebbe essere in grado di vendere era veramente
interessato ci è voluto un po ‘di tempo per
quell’interesse a sollevarsi
e poi di nuovo giù e intanto Chris
Pinkham tornò in Sud Africa dove
è cresciuto
e quando finalmente arrivarono alla sua idea
e disse: facciamolo, l’hanno inseguito
giù in Sud Africa e ha detto di dire perché
Non si fa a mettere insieme una squadra c’è
dove vuoi essere e vedere se tu
non può far funzionare questa idea così ha fatto lui
riunito e guidato una squadra e in due
anni sono usciti con ec2 elastico
nube
Alessa compute cloud che è stata lanciata
nel 2006
e come dico il resto è storia qui noi
sono 10 anni dopo e Amazon Web
I servizi stanno facendo circa 10 miliardi
dollari americani all’anno o qualcosa del genere
e crescendo per paura che tu sappia che ero abituato
dì un miliardo di dollari al trimestre, ma è così
è ancora di più adesso e ne è venuto fuori tutto
questo concetto di questi team indipendenti
quello potrebbe fare qualcosa che realmente
potrebbe essere separata in modo da se ci pensiamo bene
che poi um voglio proteggere mi propongo
che c’è una nuvola nel tuo futuro I
non importa se ci sono regolamenti per
mantienilo se sei in un
banca o qualsiasi cosa telecom o se sei dentro
area medica in questo momento siamo in realtà
non c’è una nuvola ci sarà e
il motivo è perché da economico
il punto di vista della nuvola è generalmente più economico
parlando la maggior parte delle nuvole sono più economiche di più
stabile più sicuro e più espandibile
di gran lunga rispetto alla maggior parte dei data center on-premise
quindi se il tuo centro IT è a costo e
diventa possibile superare quelli
problemi di regolamentazione e cose simili
che allora ci sarà una nuvola lì
perché sarà semplicemente più economico
più semplice e sicuro e così via anche se
non è oggi è quasi certamente andando
essere e poi c’è cosa dispiace
e poi c’è una tecnologia quindi se
Diciamo che sei in una banca ok
le banche attualmente sono tutte on-premise o
a volte ibrido e roba del genere
davvero deve essere memorizzato
la premessa rimane lì ma in questo momento GE ha
una nuvola chiamata
qual è il pretesto giusto?
predice che è un orologio Industrial IT
può ad esempio gestire l’elettrico
griglie era la tecnologia di base
che gestito la rete elettrica in
Londra durante le Olimpiadi per essere sicuro
che nessuno dei locali ha perso il potere
durante il uno degli eventi che sono stati
c’è ora se riesci a mettere i dispositivi IOT su
griglie elettriche o motore aeronautico
quale ge fa e invia quello
informazioni al cloud in qualche luogo
devi essere in grado di farlo in modo sicuro
questo è quello che fanno loro fanno questa roba
con un alto grado di sicurezza e loro
fallo
corrispondenti a qualsiasi regolamento del di
i governi che stanno lavorando
con così il loro cloud è probabilmente abbastanza
regolamenti sicuri e corrispondenti in
aree industriali e hanno appena messo
un dispositivo medico nube insieme che
che passa almeno in tutti gli Stati Uniti
Regolamenti HIPPA che conosci persone
detto non potrebbe essere fatto ma hanno calcolato
fuori come farlo quindi se sei in una banca
Scommetto che tra qualche anno
qualche banca là fuori troverà un
nuvola bancaria che corrisponde a tutto il
regolamenti e requisiti di sicurezza
che attualmente pensi non possa essere
abbinato e poi si torna a quello
il cloud sarà probabilmente più economico di più
stabile più sicuro e più espandibile
di quello che vi capita di lavorare con
in questo momento quindi l’economia di esso sarà
incredibile, quindi scommetto che c’è una nuvola in
il tuo futuro e non necessariamente un ibrido
folla perché le persone stanno facendo ibridi
nuvole ma il giusto caso d’uso per ibridi
nubi che rende davvero il diritto
cosa da fare deve ancora essere scoperto ora
se stai andando su una nuvola, stai andando
per capire che le applicazioni
che sono progettati con dati tradizionali
le architetture non funzioneranno molto
bene nel cloud perché il cloud è
distribuito perché un cloud vuole essere
seduto sulla cima di un mucchio di dire che è
come costruire una casa sulla sabbia
Pitts e devi capire come
occuparsi della costruzione di una casa sulla sabbia
quando sei su internet o quando
sei nel club quindi l’altra area
non vogliono parlare di è
infrastruttura come codice perché è così
una parte di questo come faccio a trattare
l’intero ambiente cloud perché
questo è quello che è infrastruttura come
codice e puoi farlo internamente ma
alla fine probabilmente stai andando
verso qualche meccanismo di cloud
contenitori come ci sarà molto
di discorsi sui contenitori almeno uno
o due non ne parlerò oggi
ma i contenitori sono la cosa che
crea un processo che consente al tuo
sviluppo da inserire facilmente in a
meccanismo standardizzato sicuro così quando
è schierato non devi preoccuparti
su una qualsiasi delle cose a valle
alle opere di pensiero piace chiamarlo a
contenitori un processo che ti permette di
avere un ambiente standardizzato sicuro
e poi ci sono architetture di servizio
e penso che ci sia stato parlare di questo
ieri senza server è il mio genere di cose
perché ricorda quello che ho fatto quando ero
facendo lo sviluppo del software ero io
programmazione di pezzi di equipaggiamento e noi
non avevo questo voglio dire la nostra attrezzatura
inviato interruzioni e abbiamo aspettato per ascoltare
a quelli e abbiamo risposto a loro era
un ambiente guidato dall’invenzione che per me
è un posto davvero comodo per essere, ma
a molti programmatori a cui sono abituati
programmazione procedurale è una specie di
di cosa si tratta, ma l’idea di
essere un inventore di un ambiente è
davvero importante quando entri nel
Internet delle cose e molte persone
sono coinvolti nel lesyk del server quando ce ne sono
tipo di variazione in risposta a
roba là fuori nel mondo sta trovando
questo è un enorme vantaggio economico no
di avere roba seduta lì
in attesa che gli eventi accadano solo
costa molto meno e poi
reti definite dal software in modo da dimenticare il
hardware di rete più il c’è a
solo un documento davvero interessante di Google
di recente su come strutturano tutti
delle loro reti con software
più hardware più perché è giusto
non abbastanza grande che non può gestire il
tipo di volume che si stanno dirigendo per
così quando si pensa che quando si
pensare a dove tutto questo insieme
una sorta di aree nuvolose che vanno lì a
completamente nuova tecnologia stack si deve
imparare a trattare con la parte posteriore in te
conoscere 20 anni fa lasso di tempo abbiamo avuto una
thick client server abbiamo avuto alcuni di voi
conosci i runtime e alcuni middleware e
qualche sistema operativo e poi abbiamo avuto
alcuni database monolitici seduti
sotto di esso e oggi è molto di più
come un’app sin su un tablet mobile o
una cosa del genere si tratta di un semplice faremo
assemblare un assortimento dei migliori
servizi disponibili che cambieranno
costantemente e in esecuzione su qualsiasi cosa
l’ hardware disponibile è in giro
quindi se ci pensi allora il vero
il problema che abbiamo in architettura è un
problema di dipendenza il fondamentale
problema che stiamo vedendo nel software
l’ingegneria della nostra storia è quella che abbiamo
questa cosa è chiamata un’impresa
architettura hai visto questa immagine
nessuno
alcune persone hanno ragione è una specie di io
stava dando una chiacchierata ad alcune imprese
ingegneri quindi sono andato a cercare cosa
era tutto e questo è quello che è
tutto di buono e Ana il problema qui
è che c’è questo unico database
sorta di integratore magico di
tutto il resto ma se ci pensi
è anche il generatore di dipendenza magica
di tutto il resto è ciò che è a
enorme generatore di grandi dipendenze e così via
è un approccio su scala e se tu
voglio davvero diventare grande, non puoi scalare
su devi scalare per ottenere
seriamente grande quindi hai bisogno di un federato
architettura di qualche tipo
non necessariamente servizi di Micra ma in
qualsiasi ambiente dove vuoi
essere in grado di diventare davvero grande di cui hai bisogno
ridimensionare in modo da aver bisogno di una sorta di
architettura federata in cui i dati
i negozi sono all’interno della federazione
l’architettura non è una cosa centrale
tutto insieme quindi questo fondamentale
il concetto di un’architettura federata è
dove dobbiamo andare per liberarci
delle dipendenze che ci stanno uccidendo
ritardare le nostre implementazioni e tutte
quel genere di cose e questo è un po ‘
l’architettura che devi avere se tu
voglio passare al cloud e io no
pensa anche se ti scommetto un sacco di
sei seduto sul lato sinistro oggi io
non pensare di poter rimanere lì è tuo
il futuro deve essere finito qui dove
c’è una sorta di federazione
architettura quindi devi imparare come
fai ingegneria del software non con
database ma con API che significa
sono ugualmente importanti e
prezioso e soggetto a tutti i tipi di
vincoli a cui i nostri database erano abituati
essere soggetto a tutti i tipi di cose come
devi avere una buona indurito
interfacce devi avere buone
directory devi avere degli standard
da cui cambiano le interfacce
lentamente devi fare il versioning sui cambiamenti
è quasi come un modo diverso per
guarda il database ma in un modo che può
essere localizzato quindi se pensi di api è come
l’architettura che fanno è abilitata
architetture di servizio che abbassano questo
attrito di integrazione perché è solo
solo tra me e l’altro servizio
laggiù non sono io e tutti i 50 di
questi altri servizi e hanno locale
persistenza quindi i nostri database SQL
rapidamente sostituito da questa roba
che si diffonde attraverso tutti questi
diversi file che hai visto su Google
struttura del file invece di uno solo e
non ci preoccupiamo più di non facciamo
avere spazio per metterlo nel nostro database noi
dispone di spazio stiamo andando a preoccuparsi
il nostro database più tardi sai che non siamo noi
sapere di quali informazioni abbiamo bisogno e siamo
andando a metterlo dove appartiene come te
sentito nel poco prima di questo discorso siamo
andare a raccogliere solo e metterlo in su
lì in qualche formato e capire
in seguito come affrontarlo e cosa fare
con esso e quelli sono solo un intero
concetto diverso quindi
il modo in cui siamo abituati a pensare
database solo pochi anni fa è possibile
anche pensare a API come un prodotto così
L’API è come un prodotto significa che l’ API ha bisogno
essere di proprietà di una squadra che capisce
chi sono i consumatori di tale API e
chi si concentra su di esso e chi ha evoluto il
funzionalità di tale API quindi se lo fai
uno sguardo per esempio a qualsiasi cosa nel
Internet of Things questo sarebbe un nido
termostato e ha una API e poi
Posso usare quell’API per mettere un’app mobile
insieme sul mio telefono Android e via e
trattare con il mio termostato o il mio iPhone o
qualunque sia l’Api è quello che
permettere quelle piccole cose nel
internet possono possedere un’API
contro il quale puoi metterti a conoscenza
qualunque cosa e parlare con loro così sono a
prodotto e questo è ciò che li rende in
un prodotto è la loro connessione API al
resto del mondo lo trovo
interessante quel Carnegie Mellon che
è sempre stato davvero grande su cosa fare
dobbiamo pensare al software
ingegneria nel 2014 sono usciti
con un articolo che riguarda il software
ingegneria per i grandi sistemi di dati ora
quello che hanno detto sono le applicazioni di big data
stanno spingendo i limiti del software
l’ingegneria è essenziale per il corpo
di conoscenza architettonica del software
si evolve per catturare il design avanzato
conoscenza per i sistemi di big data che è
dove l’ingegneria del software deve essere
passare il tempo e se stai pensando
di andare a pensare alla ricerca
pensando a cosa fai in a
università stai pensando al
ingegneria necessaria per davvero bene
i grandi sistemi di dati hanno detto che i big data
i sistemi sono intrinsecamente distribuiti
non c’è alternativa all’architettura
quindi deve gestire in modo esplicito parziale
insuccesso consistenza di concorrenza e
replicazione
e qualsiasi tipo di latenza di comunicazione così
sono sicuri che ciò accada
gestito in tutto il concetto di gestione
i grandi dati devono avere architetture
che replicano i dati per garantire il
disponibilità in caso di fallimento e loro
essere in grado di progettare componenti
che sono privi di stato perché componenti
e le istanze vengono uccise tutto il tempo
che sono replicati e che sono
tollerante di guasti su dipendenti
servizi quindi abbiamo bisogno di capire come
spostare l’ ingegneria architettonica in questo modo
non solo per i big data ma sicuramente per
big data quindi l’ultima cosa che voglio
parlare di questa intera area del
il cloud è ingegneria della resilienza perché
ora abbiamo enormi quantità di cose
a seconda del nostro software come per
esempio c’erano un paio di compagnie aeree
che è andato giù negli Stati Uniti come a
tutto il giorno a luglio entro due settimane di
l’altro era Delta e uno con
Southwest e hanno avuto un piccolo problema
così a sud-ovest ha perso un router e ci sono voluti
circa quattro al giorno
e Delta gli ha perso un interruttore elettrico
ad Atlanta e questo è che conosci casa
base e si scopre che al fine di
volare un aereo devi presentare un file
riferire con la FAA Federal Aviation
Amministrazione e quindi per qualsiasi aereo
per volare ovunque questo rapporto deve essere
archiviato e l’unico computer che potrebbe
Fate questo capita di essere collegato a quel
interruttore elettrico che ha fallito così la
l’intero sistema era giù perché uno
interruttore elettrico ad Atlanta no
permettere che i piani di volo siano archiviati così
dove stiamo andando a sapere quando questi
i fallimenti stanno per accadere se proviamo
per fare tutto al cento per cento
senza errori dobbiamo iniziare a pensare
diversamente dobbiamo cominciare a pensare
su anti fragile invece così se tu
voglio vedere di più su questo che puoi leggere
Nikolas ha detto a bum tell tell abut the
l’intero concetto è che ci sono cose
che sono fragili come il vetro e c’è
le cose sono robuste come spade
e poi ci sono cose il
migliorare quando vengono attaccati come
per esempio un mese fa ho avuto un vaccino antinfluenzale
ogni autunno ho un vaccino antinfluenzale e da mettere
queste cose cattive nel mio corpo così che esso
diventa più forte e non capisco questo
non si ammalano più da allora
iniziato a farlo così l’intera idea di
aggiungere cose cattive per rendere le cose migliori è
cos’è anti fragile, quindi se tu
guarda le donne classiche del met
Flicks con il loro esercito di simian che fanno
roba tutto il tempo da piccoli ogni due
ore ho intenzione di uccidere un istance che sono
andando ad aggiungere Layton vede il loro caos
gorilla che abbatte un’Amazzonia intera
regione ogni tanto solo per vedere come
tutto risponde così quando pensi
sui test devi anche pensare
su Netflix pensa al vero test
è o meno il tuo sistema
il software può sopravvivere in produzione con
tutte queste scimmie del caos e cose simili
quella
uccidere le istanze e assicurarsi che
le cose funzionano ancora e il test finale
di buono è se sia o non sia così
il modo in cui il test finale di qualsiasi
la squadra è buona o meno nessuno dei due
i loro servizi falliscono quando uno di questi
i gorilla entrano e le scimmie entrano
e ucciderli in modo da riassumere il software
ingegneria nel cloud e dove vedo
andando dobbiamo passare a federati
architetture non c’è proprio
sarà un’opzione che sarà
modo più economico, più veloce per la distribuzione e
sarà necessario perché
andrai al club
dobbiamo iniziare a pensare al
il database smette di pensare al
database come integratore e io
ancora leggendo roba in McKinsey e
e Gartner su come il database in
il sistema ERP è l’integratore che è
devo smettere di essere l’integratore, va bene
è così che l’ultimo decennio ci serve
pensa a come ci colleghiamo con le API
attraverso molteplici concetti diversi di
modo in cui archiviamo i dati abbiamo tutti questi
protocolli stateful ma quando iniziamo
entrare in tutto ciò che sarà
là fuori come l’ Internet delle cose noi
devi pensare apolidi perché quando tu
andare sul cloud, la roba muore tutto il tempo
e perderà quota, quindi cosa sei
farò su di esso se stai dipendendo
che dobbiamo smettere di pensare a
esecuzione consecutiva e riflettere
roba che succede contemporaneamente e noi
non so in realtà quale condizione di gara
sta per vincere posso ricordare quella gara
le condizioni sono una delle più grandi cose
Ho dovuto affrontare quando ero
apparecchiature di programmazione e tu sempre
pensato a chi si otterrà
per prima cosa non lo sai più di
comunicazione sincrona come parlare
su un telefono dobbiamo capire come
fare comunicazione asincrona come
messaggi di testo va bene l’altra persona
non deve essere lì prima di averli
andare in giro a rispondere al tuo testo noi
deve capire come fare
programmazione guidata dagli eventi, come ho detto a me
è naturale perché era il
primo modo ho pensato bene forse il
secondo o terzo modo in cui pensavo
programmazione ma quando hai pezzi grandi
di attrezzature è ancora un po ‘di molto
ovvio, ma mi è stato detto che è davvero
difficile da pensare alle persone
programmazione guidata dagli eventi, se tu
sappi fidati di me non è così difficile solo tu
devo cambiare un po ‘la testa
po
invece di programmazione procedurale e noi
devo iniziare a pensare di dimenticare
riguardo al difetto, dimenticalo perché
questo significa che siamo fragili, dobbiamo
pensa a quando succede qualcosa come
resilienti siamo quanto velocemente possiamo recuperare
quanto piccolo possiamo limitare il raggio di esplosione
quando le cose vanno giù perché sta andando
andare giù quindi questo è come un artefatto
dell’impresa come
vedi roba e questo è più come te
devo fare per essere coinvolto in internet
di cose e quando otteniamo questa roba
lavorando in quel momento abbiamo intenzione di essere
molto più avanti nel futuro di noi
erano ora non è la fine della mia ora così
Ho intenzione di continuare con qualcosa
altro
ma è più o meno la stessa cosa, quindi è così
La Germania e mi è stato detto che in realtà ho
ha osservato che le persone come processano
Germania, così questo intero whoa come facciamo noi
che fare con tutto questo incertezza
diventa il processo in cui possiamo applicare
Per mettere le mani su questo quindi ho
vorrei parlare di DevOps questo è
un libro che non ha un mese e io
in realtà non sono sicuro di poter ottenere il tuo
le mani su ancora ho le mani mie
su di esso e l’ho letto e mi piace
molto è di Jean Kim e giusto
umile e Patrick / in John Lewis e
riguarda i tre modi in cui Jean Kim ha scritto
il progetto Phoenix su DevOps e
questo è un po ‘come il manuale dietro
è un sacco di come e in esso
enfatizza questi tre modi i tre
modi il nostro flusso di feedback e
sperimentazione e apprendimento così
altra parte di questo discorso riguarda il flusso
feedback e mentoring esperto e
imparando perché se vuoi farlo
questa roba funziona che devi capire
come far funzionare quel processo
quindi c’è una cosa che sappiamo per
certo assolutamente per certo quando abbiamo un
sistema complesso non importa se lo è
un sistema meteorologico o conosci un riscaldamento
sistema o sistema software qui
qualcosa che non funziona quando tu
prendi un sistema complesso e lo distruggi
non hai idea di come andrà a finire
rispondere garantito che tutte le scommesse sono fuori di te
non conosco le interconnessioni
non conosco le conseguenze non volute
non si sa esattamente cosa sta per
capita e prova come potresti testarlo
non puoi capirlo quindi cosa fa
funziona ciò che funziona per i sistemi complessi
Questo
e c’è una terribile esperienza
mostrandoci che questo è il modo di fare
certo che abbiamo un complesso stabile sicuro
sistemi che non si bloccano mentre li colpiamo
invece di Smashing e rispondiamo a
qualunque cosa accada con quel piccolo
contenuto poke così a causa di quel tipo
della cosa punto di riferimento che è successo in
Il 2010 è Dave Farley e solo umilia
prenota sulla consegna continua e se tu
non l’ho letto che dovresti e forse tu
dovrebbe andare alle azione di Dave Farrelly
se non l’hai sentito perché questo ha
cambia il modo in cui pensiamo al software
processo di sviluppo ha appena avuto un
impatto incredibile e questo è praticamente
il processo che devi pensare
circa se vuoi un buon sistema stabile così
che cosa è questa storia si tratta di fare
sicuro che il tuo processo è guidato da
test di accettazione che sono eseguibili e
che scrivi codice per superare quei test
si tratta di assicurarti di averlo
team interfunzionali o full stack
che include l’intera pila di persone
necessario fare quella cosa particolare
stai cercando di fare il prodotto deve essere
lì il QA deve essere lì ossessionato
là sì poche colombe – si tratta di
tutto automatizzato costruisce test
distribuzione della migrazione di macwrite del database
lo chiami che si tratta di distribuire al
tronco non ha ramificazioni come
molti qui hanno rami
okay allora non sei ancora qui
ma si tratta di non avere rami Wow
ora se ne hai 30 ne prendi tre
sai che hai fatto un grande passo ma nel
fine vuoi avere un solo tronco
che si sta continuamente l’integrazione di
e quel software è sempre di produzione
pronto o si ottiene un diritto corretto
priorità distanza
sembra terrificante che è dove hai bisogno
per andare e si dispiega tutto il tempo
costantemente diverso per dominio ma
la distribuzione e il rilascio non sono la stessa cosa
cosa rilasciate girando qualcosa
con un interruttore che si distribuisce tutto il tempo
il codice non deve essere attivo fino a quando
lo accendi ma lo distribuisci
costantemente così se ci pensi come
una pipeline di distribuzione quello che hai è
qualcosa che sarà più veloce è
sarà più sicuro e lo sarà
meglio intendo quello che avevi prima e
questo deve essere il processo che pensi
molto difficile nel dirigersi verso il
il secondo pezzo ricorda i tre modi
feedback di flusso il prossimo è il feedback
e ti propongo di aver bisogno di end-to-end
feedback hai bisogno di sì per vedere cosa c’è
andando avanti in produzione con il monitoraggio
sistemi ma devi anche vedere cosa c’è
andando avanti quando il codice è distribuito con
i tuoi consumatori e ricevi quel feedback
dritto alle persone che stanno facendo
decisioni su cosa fare dopo chi ha avuto
meglio essere nella squadra
perché questo è un processo veloce, quindi noi
non ce l’ho più
design in outsourcing
c’è una ricerca per dimostrare che il
il product manager ha torto almeno la metà
il tempo e ho messo il riferimento giù
qui puoi ottenere queste diapositive e guardare
su e in realtà se parlo al prodotto
i manager dicono che sì, in realtà questo è
vero quindi come facciamo a non fare tutto questo
ci viene chiesto di fare perché chiaramente la metà
il tempo è solo una supposizione, beh, è così
sempre solo per indovinare e si potrebbe capovolgere
una moneta per decidere quale deve prendere solo
come facilmente um o se dai un’occhiata a a
specifica che qualcuno ti ha dato come un
ente governativo o qualcosa del genere
probabilmente due terzi delle funzionalità e
le funzioni nelle specifiche non lo sono
necessario non è necessario essere lì ok
e quindi è solo meglio essere pigri e
farlo solo un terzo o meno della
lavoro che in realtà sta per fornire
valore rispetto a fare tutto nelle specifiche
quindi non dovremmo essere il design in outsourcing
a qualcun altro che dice ai nostri team
cosa dobbiamo fare per passare dalla consegna
squadre per squadre di problem solving così
squadre di consegna ottenere le istruzioni prendono
ordini sai che qualcuno dà loro il
dai loro un menu e loro lo danno
tu l’ordine e dobbiamo trasferirci
le squadre che risolvono i problemi sembrano avere
tutti necessari per risolvere un problema
non una soluzione ma ecco cosa è il
i consumatori stanno cercando di realizzare qui
è il lavoro che devono essere fatto
ecco la metrica che dobbiamo spostare in a
direzione diversa vedi cosa puoi fare
con esso e abbiamo bisogno di avere problemi
risolvere team che affrontano questo tipo di
domanda piuttosto che team che sono quello
viene detto cosa fare se si guarda
la sperimentazione e il processo di apprendimento
Ti ho promesso un processo qui è
si inizia con segnali non requisiti
hai una dichiarazione di problema no
caratteristiche che vuoi concentrarti su cosa sono
i problemi che stiamo cercando di risolvere e
la dichiarazione del problema non è facile da pianificare
con ipotesi non stime non lo è
chiaro a me più se hai problemi
risolvendo i team che cosa fanno le buone stime
chiunque tu debba sapere che puoi
risolvere il problema entro i limiti
e dato che il resto dovrebbe essere fino a
la squadra qui è i miei limiti ecco la mia
problema se riesci a gestirlo all’interno
quei vincoli di solito di tempo e
i soldi
poi vai avanti e fai a modo tuo e così
non vogliamo un arretrato di storie noi
voglio più esperimenti che stiamo andando
corri contro le ipotesi e noi no
voglio supposizioni vogliamo analisi e
conclusione quindi questo è lo standard I
non conosco il metodo scientifico
processo di ingegneria e se questo processo
non è alla base del processo che tu
usa oggi, quindi dovresti chiederlo
te stesso perché no perché nel nostro mondo
con la nostra incertezza questo è l’unico
processo che funziona ora hanno gli scienziati
stato usando questo processo per centinaia di
anni in realtà non è poi così male
processo ma è ora che ci siamo arrivati ma
una delle parti difficili di questo processo
è la prima parte che problema siamo noi
andando a servire risolvere e quali tipi di
ipotizza le nostre ipotesi razionali
prendi così bene, alla fine, eccomi qui
solo andando a prendere un paio di minuti a
parlare di un processo che ho incontrato
di recente certamente non è l’ unico fuori
ce n’è una che trovo carina
interessante e si chiama Google
ein sprint è stato introdotto nel 2014 a
la conferenza i / o di Google è interessante
conferenza su di esso è più un design
conferenza piuttosto che uno sviluppo
contest ed è un processo per capire
fuori come prototipare e testare qualsiasi idea
tra cinque giorni
va bene che significa prima di te in realtà
codice è descritto abbastanza bene in questo
fammi passare attraverso che inizia sul
primo giorno in cui tutti andare avanti
la stessa pagina come facciamo roba che cosa è
il problema che stiamo cercando di risolvere qui
sono i problemi qui i vincoli e
poi il secondo giorno c’è qualcosa
Ne parlerò tra un po ‘
di più ma riguarda l’ individuo H
abbozzando in silenzio le proprie idee
su come farlo e poi condividere
sotto la guida di un designer perché
è un processo di progettazione standard e quindi
condividendo quelle idee su carta in modo che
non abbiamo a che fare con il brainstorming
che ha dimostrato di cervello di fame
è stato dimostrato per assicurarsi che il
persone che sono più rumorose o più dentro
comando della lingua o qualsiasi altra cosa
è o è il più simile a tutti gli altri
sono quelli che fanno sentire le loro idee
quindi preferiamo un processo che consenta
molte idee diverse da più tranquille
persone e dalle persone che non lo sono
così comodo parlare per ottenere il loro
idee troppo e poi c’è decidere quale
uno è quelli di queste idee e io ci sono
andando a parlare di non votare perché
il voto di nuovo sopprime le idee delle minoranze
e poi fai un prototipo molto veloce
hai alcuni designer li hanno messi
insieme qualcosa di veramente veloce non lo è
codice è forse una nota chiave o lo sai
PowerPoint o qualcosa del genere e
poi il quinto giorno ne hai alcuni
gli utenti entrano ed effettivamente provano il
idea con un intervistatore che li cammina
attraverso alcune cose resto della squadra
guardando da uno schermo remoto per vedere come
le cose vanno e scopri come questa idea
gioca con almeno alcune persone così
questo è il concetto generale qui e qui
è un libro su cui puoi ottenere molto
ulteriori informazioni e sto solo andando a
fare un rapido video di un sommario di esso in
il tempo di sviluppo del business è un prezioso
risorsa perché stai sprecando per essere
Google più efficiente e reattivo
Ventures ha creato il design sprint the
processo per la risposta alle attività critiche
domande in soli cinque giorni
il primo giorno dello sprint è per
condivisione di informazioni tra reparti
e creando una semplice giornata di viaggio dell’utente
due è il giorno dello schizzo in cui la squadra lavora
individualmente per generare creativo
soluzioni al problema
il mercoledì la squadra guarda tutto il
soluzioni e decide il meglio
approccio
crea uno storyboard visivo e lo sei
pronto per il prototipo Giovedi è ora
per diventare produttivi e costruire il tuo
prototipo l’ ultimo giorno che metti alla prova il tuo
idea su persone reali per vedere se ha qualche
valore se fa cinque in alto
stai andando a fare qualcosa di grande, se è così
non va bene hai imparato qualcosa
e il costo è solo di cinque giorni quindi fermati
sprecare il tuo tempo e comprimere il
ciclo di dibattito senza fine in un singolo
disegno sprint settimana così um due cose
sullo sprint del progetto che mi piacerebbe
indica rapidamente qui se lo trovi
affascinante e uno è l’idea
la generazione del secondo giorno è davvero
interessante perché sta avendo
le persone non competono tra loro
per far sentire le loro idee direttamente dal
all’inizio ma permettendo a quelli fragili
idee da sviluppare da parte degli individui
lentamente fino ad arrivare ad alcuni dettagli
cosa che pubblicano e poi è così
recensito bene dal gruppo senza nemmeno
sapendo di chi sono le idee, perché
c’è una cosa chiamata pregiudizio di conformità
uno dei pregiudizi di Linda sì, Linda ed è
sull’idea che le persone che pensano
sono al mattino saranno nel
la minoranza si autoregolerà o cambierà
la loro opinione e poi quella lo rende
ancora più difficile per le altre persone che hanno
pareri di minoranza di avere opinioni così
l’idea è quella di trovare un modo per le persone a
esponi le loro idee prima che abbiano
preoccuparsi se sono nel
maggioranza o in minoranza e in un modo
quello non richiede loro di essere il
la persona più rumorosa o la più conosciuta
persona in avanti o va bene se
sono un po ‘diversi dal
resto del gruppo ma non sono d’accordo
il modo in cui parlano di fare questo
il terzo giorno perché poi la gente vota
e non sono così divertente da votare
potresti immaginare
perchè ma a 3m dove ho lavorato per 20
anni non abbiamo votato sulle idee di prodotto noi
attratto le persone a idee di prodotto così noi
ha esplorato molte idee che dovresti
sii troppo perché poi è la santa Nydia
non accontentarti di una sola idea, prova un intero
molti di loro e assicurarsi che vengano da
l’intero spazio del design compresi alcuni
valori anomali che significa se si vota
gli avvocati non ce la faranno e così
vuoi perseguire una varietà di idee
e se lei ha un’idea e può attrarre a
un paio di altre persone per provare la sua idea
perché non lasciare che non debbano farlo
essere nella maggioranza possono essere solo un
poche persone che provano le loro idee
come quasi tutti i nostri veramente innovativi
le squadre di prodotto hanno funzionato se un campione potesse farlo
attirare un po ‘di altre persone l’ idea ha avuto
esplorato fino a quando non ha funzionato o
ha funzionato gradualmente si restringe il
idee a quelli che stanno andando a lavorare
e tu vuoi mantenere multipli
opzioni il più a lungo possibile prima
ti accontenti di qualcosa non solo
scegli una cosa e seguila così
riassumere il futuro del software
l’ingegneria prima di tutto sta andando
essere un grande progresso tecnico
lì possiamo vederlo ora
si tratta di ridimensionare di cui parla
infrastruttura come codice è su questo
tutta la nuova tecnologia di stack che è
seduto nella nuvola e avendo un
modo diverso per noi a pensare
programmare e pensare alla sicurezza e
pensa all’affidabilità e alla resilienza
e poi ci sono i tre modi di
DevOps sorta di espanderla per assicurarsi che
pensa a tutto il prodotto non solo
Devon ops ma il tutto così vogliamo
pensare a come otteniamo un
pipeline di distribuzione continua come facciamo noi
mettere insieme la risoluzione dei problemi dello stack completo
squadre
okay e assicurati che lo stiamo facendo
sperimentazione e apprendimento fino in fondo
attraverso il nostro ciclo di sviluppo quindi
il futuro è qui in realtà non lo è
facile da vedere non così uniformemente
distribuito ma se ti guardi intorno
troverai dei futures che conosci
anche nelle nostre sessioni durante il resto
del giorno quindi grazie mille
abbiamo tempo per due domande se tu
fai una domanda per favore, vieni al
microfono si
ciao grazie per il tuo discorso ho un
domanda riguardante la prima parte di
i tuoi discorsi di cui stai parlando
la tendenza lontano dai monoliti e altro ancora
verso i sistemi distribuiti ho paura
che molti sviluppatori stanno cercando
a quello che stanno facendo le grandi aziende e
chi parteciperà a colloqui come questi
quindi prova a risolvere i problemi che non hanno
hanno davvero e over-engineer loro
soluzioni come ad esempio l’utilizzo di Hadoop
quando hanno solo pochi gigabyte di
dati o un piccolo team che distribuisce
migliaia di micro servizi in cui a
il monolite potrebbe essere la scelta più economica
giusto cosa pensi che ci sia
non c’è mai qui è il finale
rispondi come se tutti si trasferissero qui di cui hai bisogno
per sapere dove sta andando la tendenza e
dove alla fine devi essere ma se
non hai un modo intelligente di ottenere
lì se all’improvviso ti credi
può saltare lì senza imparare a
tutto quello che stai quasi certamente sbagliato così per
esempio se sei in banca la tua banca
deve essere spaventato adesso perché
c’è così tanto attaccato sulle tariffe di
banche il loro reddito di base da tutti i tipi
di fintechs tutto che si tratti di
tasse ipotecarie o qualsiasi tipo di tasse così
vogliono velocemente fare qualcosa ma
non è facile essere veloci perché il
back-end è davvero difficile da spezzare
e come posso combinarlo con la parte anteriore
fine, quindi, grazie non ha avuto front-end
squadre e possono fare tutto ciò che vogliono
e i team di back-end sono lenti come
erano sempre ciò che significa che non possono
fare molti cambiamenti perché quasi
tutto dipende dal front end
il back-end e quindi ci deve essere un
soluzione ma forse la soluzione non lo è
domani possiamo rompere tutto
e ricominciare da capo perché abbiamo
hai già un business da sostenere così tu
devono capire come migrare e
che sta andando a dipendere dal contesto
che ti siedi in esso non sta andando a dipendere
su come quella società laggiù ha fatto
qualcosa che sono diverso da quello che uno
la cosa di cui puoi essere sicuro se la prendi
la soluzione di quell’azienda è la loro
la soluzione al loro problema è probabilmente
non
la tua soluzione al tuo problema così tu
bisogno di persone intelligenti che possano pensare e
capire dato le tendenze qual è il
giusto meccanismo per arrivare al giusto
la soluzione per noi in futuro ricorda
tutto ciò che riguarda Hadoop ha preso cinque o
sei anni su Amazon al servizio del microfono
l’architettura orientata richiedeva cinque o sei
anni ognuno di quelle cose ha preso
tanto tempo per passare da un’idea a realtà
sviluppare su larga scala e se ci pensi
puoi farlo in cinque mesi sei pazzo
e sto per succedere così sai che fermati
sognare ha senso, grazie ok, andiamo
prendiamo un’altra domanda da
l’app ho un sacco di domande qui
Mi dispiace non posso chiedere tutto a te
cosa ne pensi del ruolo di
sistemi di regolazione come i governi o
leggi nazionali nel cloud federato
mondo ben il il là sarà sicuramente
essere regolamenti governativi nazionali
non importa se sono buoni o cattivi
non hanno intenzione di andare via così che io
osservare è che le persone che sono
seduto tra le nuvole impara come
capire quei sistemi di regolazione
impara a capire la sicurezza
preoccupazioni e imparare come affrontarli
e quindi questa è un’altra ragione comunque
Penso che il cloud finirà per diventare
la cosa della scelta perché sono
attualmente i regolamenti sono
complicato da navigare in paese
paese e se hai il tuo OneSource
capire tutto potrebbe fare di più
senso so che in noi un sacco di
le persone stanno trasferendo molti dei loro personali
molti dei loro dati personali in Europa
i server di dati chiamano i server cloud perché
perché le leggi qui sono molto più
protezione dei dati personali individuali
di quanto non siano in noi, quindi se i dati si trovano su
i server qui sono molto più protetti da
regolamento così le nuvole che le persone
stanno cercando di capire quali sono i reg e
come affrontarli penso che GES
prevedere il sistema è davvero buono in questo
e altri venditori di cloud stanno imparando così
avranno per capirlo, ma le nuvole
può essere in molti posti diversi
Va bene e avranno a che fare con
qualunque sia il regolamento, grazie
grazie mille Maria per questo
nota fondamentale
tu
è già qui non è uniformemente
distribuito quindi se vuoi sapere qualcosa
il futuro come diciamo il 2020 in realtà
non è così lontano nel futuro
forse più di tre anni al 2025 tutti voi
deve fare è guardare un po ‘ nel
angoli di quello che sta succedendo oggi e e
in effetti a questa conferenza stai andando
fare un bel po ‘di quello e tu
avere una buona idea di dove il
futuro sta per andare diamo tuttavia go
di ritorno forse 20 anni o qualcosa del genere
così e la prima cosa che voglio
parlare di scala sta diventando grande
perché in realtà 20 anni fa le cose
erano cose che sembravano grandi sono davvero
piccolo oggi e cose grandi
oggi si sono ridimensionati in modo particolare
modo interessante hanno scalato piuttosto piuttosto
che alto quindi se tu fossi un pinguino in
Tutte le immagini di questa isola della Georgia del sud
a proposito sono stati presi da mio marito Tom
chi è un grande fotografo e questo è
re pinguini e quando non hanno
Hai abbastanza spazio per andare in mare
non si arrampicano su più montagne e
quindi parliamo di cosa è successo 20
anni fa
nel 1996 qual era lo stato di ciò che era
andando là la maggior parte del software
lo sviluppo in quel momento era business
software o software di controllo quando l’ho fatto
sviluppo del software ero un processo
Ingegnere di controllo che ho controllato in grande
pezzi di equipaggiamento con il mio codice che
Sono di parte, ma penso che sia il migliore
soffrire nel mondo e quindi non ero
coinvolto in questa roba che chiamano IT
ma la maggior parte del software è stato fatto almeno il
la letteratura per leggere la letteratura
era tutto sulla grande transazione
elaborazione per lo più in imprese
e questo è come Internet ha iniziato
insieme un po ‘di software
Ricordo che nel 1999 qualcuno stava dicendo
su quanto velocemente il software è grande
il software non era il tempo necessario
Cambiamo stiamo parlando di un rilascio di un anno
è stato veloce, mi ricordo di aver letto
mondo informatico che ci sono alcune squadre
là fuori che hanno imparato come
consegnare il software in sei mesi puoi
immagina che sia stato davvero lento
cambio e pensavo sapessi che c’è un
moltissimo nuovo software che è arrivato
questo è novantanove e stavo parlando con
alcuni colleghi e si chiama il
Internet si sa che è un sacco di
un software che è stato sviluppato nel
ultimi anni e mi guardò e disse
Internet che non è software sì
è ma è diverso tipo di software
quindi nel 1996 abbiamo pensato a
elaborazione delle transazioni come qui a
database un database ERP quando ero
Ho seguito i sistemi di controllo del processo
uno dei miei sistemi per una produzione
pianta e ho diretto l’ informazione
ufficio tecnologico nella produzione
pianta e abbiamo fatto qualcosa chiamato MRP
chiamata pianificazione dei fabbisogni materiali
il che significa che abbiamo pianificato tutto il
diversi movimenti di inventario che
capita attraverso la pianta e tutto il
stazioni di lavoro di produzione e quello
alla fine ampliato al tutto
impresa quindi ottenuto di essere chiamato ERP
pianificazione delle risorse aziendali e
era la pianificazione delle risorse aziendali
centrato su un database aziendale
database l’unica cosa che ordina
di tutte le applicazioni integrate in
l’impresa e lo fa ancora
ed è seduto su un singolo server e bene
perchè è così, sai, c’è questo?
Teorema chiamato teorema del cappuccio che puoi
ne ho sentito parlare che sostanzialmente dice se
hai diviso il tuo database su due
diversi server lì puoi averne uno
di due cose ma non puoi averle entrambe
puoi averlo a disposizione
istantaneamente quando lo vuoi o puoi farlo
avere una coerenza
sistente si può avere la consistenza di
attraverso una transazione il tutto
transazione o niente di tutto ciò, ma non è possibile
avere entrambi e così perché il database
è stata la cosa che ci ha fornito entrambi
la disponibilità e la coerenza di
transazioni dovevamo averlo su un
server singolo, quindi se si guarda nel
Alla fine degli anni ’90 tutti i database erano lì
l’ impresa corporativa seduta su
un grande computer e integrato attraverso
quel computer e quello era come l’ unico
strada da percorrere ma poi lo sai
Arriva Google e improvvisamente ci fu
un sacco di dati che non andavano bene
un server in effetti se ne hai
1,3 miliardi di pagine questo è il 2001
non è solo andare a lavorare si deve
attraversare un gruppo più un mucchio di più
server devi capire come fare
in un modo che ti consente di rispondere
molto rapidamente quindi ci sono due modi in cui puoi
vai alla grande o puoi andare largo ok o alto
largo si può ottenere molto più grande
computer e abbastanza interessante in
circa 2000 penso che sia stato Amazon
seduto lì con un grande fronte in uno
grande front-end e quando il grande back-end si
conoscere quel singolo database e ad ogni
le festività natalizie non potevano assolutamente
gestire il volume della transazione più
e così sai cosa hanno fatto loro hanno ottenuto un
computer più grande e sai cosa
successo ok se ne sapete qualcosa
teoria delle code tu vai al gruppo più grande
e tu diventi più lento e loro sono più lenti
così hanno detto bene che non lo farà
lavoro così questo è Grace Hooper che hai
sentito parlare di grigio super lei è una sorta di te
so che è lei che ha progettato COBOL
e tutto quanto e lei ha detto se un atto
non poteva fare un lavoro che non hanno cercato di
coltivare un bue più grande che erano abituati a fare
quando abbiamo bisogno di una maggiore potenza del computer
la risposta è di non avere un computer più grande
è costruire sistemi di computer e
gestirli in parallelo gestiti da
software che è l’intero concetto di
ridimensionamento anziché scalare
ottieni più computer
e capisci come affrontare il
fatto che hanno problemi così per
esempio qui è uno dei primi Hardware
rack di Google nel 1999 è nel
Computer History Museum ora e quando io
sentito per la prima volta come stavano conservando
tutti quei miliardi di pagine che ero
piuttosto sorpreso hanno usato questo davvero
roba economica e si aspettavano che fallisse
e hanno mantenuto più copie di roba
quindi potevano semplicemente buttar via la roba
che fallisce come una buona idea e
lo hanno gestito con un software in modo che il
concetto era in realtà tipo di radicale
prima ma davvero l’unico modo per farlo
l’intera idea se stai andando a cercare
l’intero internet e tu stai andando a
fornire risposte istantaneamente è così
solo prendi il tuo hardware e
spargilo devi fare lo stesso
con il tuo file system ecco quindi il
documento iniziale del 2003 sul file di Google
sistema e lo stesso concetto che hai preso tu
prendi piccoli pezzi del tuo file
buttali ovunque nel posto che fai
certo che hai tre buone copie di
tutto e poi quando uno di loro
muore va bene ci sono altri due voi
solo una sorta di buttare via quella roba
muore e lo rigenera ed è quello
tutto il concetto che il tuo intero sottostante
il sistema è fragile nessun problema tu gestisci
e tu hai più istanze così
puoi affrontarlo e poi ovviamente
hai i dati che si devono
ricerca sparpagliata all’istante
questi file e un anno dopo, nel 2004
sono usciti con il giornale
MapReduce che divenne la base per
Hadoop che si diffonde
circa prese dal 2004 a forse il 2010 12
prima che emergesse improvvisamente come questo
cosa meravigliosa che tutti potrebbero usare
ci è voluto molto tempo per ottenere Hadoop
gestendo solo alcuni file e solo tu
conosci solo un paio di computer
qualcosa che potrebbe affrontare enormi
quantità di dati ed è stato fatto
fatto con Apache open source
progetto e penso sia stata la kalfa –
che ha lavorato su di esso
ha lavorato a yahoo con il quale è stato assunto
Yahoo perché hanno deciso forse loro
meglio andare anche a questa cosa MapReduce
e tra le varie grandi aziende in
Silicon Valley al momento il tutto
era la struttura sottostante di Hadoop
sviluppato su circa cinque- otto
periodo di un anno e c’era un sacco
di condivisione perché Doug lo ha deciso
stava per essere open source e lo farebbe
essere felice di lavorare per Yahoo, ma doveva essere
open source ed è quella cosa che noi
facciamo nel mondo dell’ingegneria del software noi
condividi le nostre conoscenze in modo che possano crescere
molto più veloce e non penso
senza la condivisione di tutto il
diversa conoscenza di come questi file
strutture e database funzionano penso che se
queste società mantenevano un proprietario che avremmo
essere un lungo ritorno da dove siamo
adesso
quindi questo è un concetto si scala con
un file system quando guardi il tuo
architettura è lo stesso concetto di te
potrebbe pensare che tu abbia un grande monolitico
database ma se ne hai una grande
database monolitico non sei grande
perché se è tutto in un punto è
in realtà piuttosto piccola per davvero
ottenere grandi è necessario scalare in modo cerchiamo di
torna in quell’Amazzonia come ho detto
circa 2004 2001 e ci sono stati
le transazioni gazillion e avevano
per gestire tutte queste transazioni tutte
allo stesso tempo e la prima opzione
era su scala okay quindi prendi e prendi a
singola transazione diciamo che è tutto
quattro cose là c’è lo shopping
carrello della spesa sai fare shopping
pagamento del carrello e adempimento va bene e se
dai un’occhiata a quello che poi puoi
ridimensiona l’intera transazione, magari anche
attraverso in diversi computer di Regent
se vuoi ma se vuoi ridimensionare
fuori scala in modo diverso
prendi la tua transazione e dici
sai cosa
Non lascerò che il database gestisca
più mi occuperò di ciò
transazione tutto da solo, quindi ho il mio
quattro diversi servizi dicono la navigazione
e l’acquisto e l’adempimento
nel pagamento e se ne ho alcuni
sono i colli di bottiglia che scalerò
quella piccola area risultò essere
più o meno il modo in cui le persone hanno
capito come scalare da come in
hanno fatto i micro servizi molto prima di a
molte altre compagnie e l’hanno fatto
perché l’ idea era se lo avessimo fatto
gestire molte transazioni
dovremo pensare in modo diverso
su come abbiamo scala Amazon ha avuto un incontro
dei dirigenti dopo uno di questi
disastri vacanza quasi disastrosa
stagioni e hanno detto come stiamo andando
per affrontare tutto questo il prossimo anno
e arrivarono a una conclusione
la conclusione era che dobbiamo comunicare
meglio hai mai sentito quel tipo di
suona familiare
Penso che sia una sorta di sbocco
se cop-out è una buona parola in inglese
è solo che non so cosa dici
Tedesco per il cop-out è um qual è il
qual è la buona traduzione per quello
hmm
su
l’avete sentito voi, quindi è un?
scusa interessante ma non è il
In effetti, sento la stessa cosa
allenando oh se solo avessimo avuto più allenamento
bene sai che Jeff Pisa dice che lo sai
quello di cui abbiamo bisogno è meno comunicazione
invece di più comunichiamo troppo
non scala non alla scala che io
intenzione di scalare questa azienda e così il
l’idea non è quella di comunicare di più l’ idea
è comunicare di meno e lo fai
attraverso un’architettura che non lo fa
costringere le persone a dover comunicare così
decise che avevano deciso che lo erano
andando a rompere l’azienda in molto
squadre più piccole e mettere quelle squadre
pezzi di software che non avevano
dipendenza in modo da non dover parlare
tra loro erano relativamente
squadre autonome come autonome come loro
potrebbe farli senza dipendenze come
il più possibile ed erano ciò che Jeff
Bezos chiama una squadra di pizza che potrebbero
essere servito il pranzo con due grandi Seattle
pizze di dimensioni sì sì forse otto persone
o qualcosa del genere e possiedono il
intero servizio dalla culla alla tomba
implementazione di test di progettazione di idee
tutto il monitoraggio in produzione e
così hai queste due squadre di pizza
trattare tutte queste transazioni
arrivando a possedere potrebbe a
servizio di carrello o potrebbero possedere
il servizio di raccomandazione o qualcosa del genere
così che il concetto di ridimensionamento
piuttosto che scalare funziona solo se tu
stanno usando software per gestire le cose
prima dipendevi dal
hardware o dipendendo dal dipendente
sul database quindi andiamo avanti
infrastruttura come codice e continua il nostro
storia perché ho appena parlato di scala
di cui vuoi parlare
l’infrastruttura come codice è un’altra
importante cosa estremamente importante
accadendo in ingegneria del software così
hai sentito parlare della legge di Conway per lo più
hai per quelli che non hanno
dice una sorta di organizzazione
struttura e la tua architettura di sistema
stanno andando a corrispondere non importa quanto sia difficile
non provi per la tua architettura
andando a guidare la tua organizzazione
struttura o la tua organizzazione
la struttura guiderà la tua architettura
ora se andiamo ad Amazon che poi si è rotto
in queste due squadre di pizza, ora
avere una struttura organizzativa che
ha guidato la loro architettura, quindi cosa
è successo questi due pezzi di squadre
dovevano essere autonomi, sì e
quindi avevano squadre autonome e
autonomo significa schieramenti indipendenti
questo è quello che ho intenzione di definirlo come
non posso prendere le mie decisioni
come posso distribuire senza dover
parlare con tutte le altre squadre che è cosa
una sorta di significato lì che fondamentalmente
ha creato il caos nelle operazioni se sei dentro
ops e all’improvviso ne hai avuti 50
milioni di team che cercano di schierare tutti
indipendenti l’ uno dall’altro e tu no
effettivamente gestito tutte le dipendenze
questo potrebbe essere un vero incubo
era così Chris Pinkham che era il vizio
presidente del pensiero infrastrutturale
su Amazon e pensato al
problema e ha detto che sai cosa dovremmo
fare come avere un self-service
implementazione per lo sviluppo facilità sai
invece di scaricare tutti i loro problemi
noi e le operazioni dovremmo lasciarli gestire
il loro problema li daremo loro
il codice da distribuire da soli e lui
detto che sai forse potremmo anche vendere
questa capacità e se sai qualcosa
a proposito di Jeff Bezos che è l’amministratore delegato lì
lo sai che se hai qualcosa, lui
potrebbe essere in grado di vendere era veramente
interessato ci è voluto un po ‘di tempo per
quell’interesse a sollevarsi
e poi di nuovo giù e intanto Chris
Pinkham tornò in Sud Africa dove
è cresciuto
e quando finalmente arrivarono alla sua idea
e disse: facciamolo, l’hanno inseguito
giù in Sud Africa e ha detto di dire perché
Non si fa a mettere insieme una squadra c’è
dove vuoi essere e vedere se tu
non può far funzionare questa idea così ha fatto lui
riunito e guidato una squadra e in due
anni sono usciti con ec2 elastico
nube
Alessa compute cloud che è stata lanciata
nel 2006
e come dico il resto è storia qui noi
sono 10 anni dopo e Amazon Web
I servizi stanno facendo circa 10 miliardi
dollari americani all’anno o qualcosa del genere
e crescendo per paura che tu sappia che ero abituato
dì un miliardo di dollari al trimestre, ma è così
è ancora di più adesso e ne è venuto fuori tutto
questo concetto di questi team indipendenti
quello potrebbe fare qualcosa che realmente
potrebbe essere separata in modo da se ci pensiamo bene
che poi um voglio proteggere mi propongo
che c’è una nuvola nel tuo futuro I
non importa se ci sono regolamenti per
mantienilo se sei in un
banca o qualsiasi cosa telecom o se sei dentro
area medica in questo momento siamo in realtà
non c’è una nuvola ci sarà e
il motivo è perché da economico
il punto di vista della nuvola è generalmente più economico
parlando la maggior parte delle nuvole sono più economiche di più
stabile più sicuro e più espandibile
di gran lunga rispetto alla maggior parte dei data center on-premise
quindi se il tuo centro IT è a costo e
diventa possibile superare quelli
problemi di regolamentazione e cose simili
che allora ci sarà una nuvola lì
perché sarà semplicemente più economico
più semplice e sicuro e così via anche se
non è oggi è quasi certamente andando
essere e poi c’è cosa dispiace
e poi c’è una tecnologia quindi se
Diciamo che sei in una banca ok
le banche attualmente sono tutte on-premise o
a volte ibrido e roba del genere
davvero deve essere memorizzato
la premessa rimane lì ma in questo momento GE ha
una nuvola chiamata
qual è il pretesto giusto?
predice che è un orologio Industrial IT
può ad esempio gestire l’elettrico
griglie era la tecnologia di base
che gestito la rete elettrica in
Londra durante le Olimpiadi per essere sicuro
che nessuno dei locali ha perso il potere
durante il uno degli eventi che sono stati
c’è ora se riesci a mettere i dispositivi IOT su
griglie elettriche o motore aeronautico
quale ge fa e invia quello
informazioni al cloud in qualche luogo
devi essere in grado di farlo in modo sicuro
questo è quello che fanno loro fanno questa roba
con un alto grado di sicurezza e loro
fallo
corrispondenti a qualsiasi regolamento del di
i governi che stanno lavorando
con così il loro cloud è probabilmente abbastanza
regolamenti sicuri e corrispondenti in
aree industriali e hanno appena messo
un dispositivo medico nube insieme che
che passa almeno in tutti gli Stati Uniti
Regolamenti HIPPA che conosci persone
detto non potrebbe essere fatto ma hanno calcolato
fuori come farlo quindi se sei in una banca
Scommetto che tra qualche anno
qualche banca là fuori troverà un
nuvola bancaria che corrisponde a tutto il
regolamenti e requisiti di sicurezza
che attualmente pensi non possa essere
abbinato e poi si torna a quello
il cloud sarà probabilmente più economico di più
stabile più sicuro e più espandibile
di quello che vi capita di lavorare con
in questo momento quindi l’economia di esso sarà
incredibile, quindi scommetto che c’è una nuvola in
il tuo futuro e non necessariamente un ibrido
folla perché le persone stanno facendo ibridi
nuvole ma il giusto caso d’uso per ibridi
nubi che rende davvero il diritto
cosa da fare deve ancora essere scoperto ora
se stai andando su una nuvola, stai andando
per capire che le applicazioni
che sono progettati con dati tradizionali
le architetture non funzioneranno molto
bene nel cloud perché il cloud è
distribuito perché un cloud vuole essere
seduto sulla cima di un mucchio di dire che è
come costruire una casa sulla sabbia
Pitts e devi capire come
occuparsi della costruzione di una casa sulla sabbia
quando sei su internet o quando
sei nel club quindi l’altra area
non vogliono parlare di è
infrastruttura come codice perché è così
una parte di questo come faccio a trattare
l’intero ambiente cloud perché
questo è quello che è infrastruttura come
codice e puoi farlo internamente ma
alla fine probabilmente stai andando
verso qualche meccanismo di cloud
contenitori come ci sarà molto
di discorsi sui contenitori almeno uno
o due non ne parlerò oggi
ma i contenitori sono la cosa che
crea un processo che consente al tuo
sviluppo da inserire facilmente in a
meccanismo standardizzato sicuro così quando
è schierato non devi preoccuparti
su una qualsiasi delle cose a valle
alle opere di pensiero piace chiamarlo a
contenitori un processo che ti permette di
avere un ambiente standardizzato sicuro
e poi ci sono architetture di servizio
e penso che ci sia stato parlare di questo
ieri senza server è il mio genere di cose
perché ricorda quello che ho fatto quando ero
facendo lo sviluppo del software ero io
programmazione di pezzi di equipaggiamento e noi
non avevo questo voglio dire la nostra attrezzatura
inviato interruzioni e abbiamo aspettato per ascoltare
a quelli e abbiamo risposto a loro era
un ambiente guidato dall’invenzione che per me
è un posto davvero comodo per essere, ma
a molti programmatori a cui sono abituati
programmazione procedurale è una specie di
di cosa si tratta, ma l’idea di
essere un inventore di un ambiente è
davvero importante quando entri nel
Internet delle cose e molte persone
sono coinvolti nel lesyk del server quando ce ne sono
tipo di variazione in risposta a
roba là fuori nel mondo sta trovando
questo è un enorme vantaggio economico no
di avere roba seduta lì
in attesa che gli eventi accadano solo
costa molto meno e poi
reti definite dal software in modo da dimenticare il
hardware di rete più il c’è a
solo un documento davvero interessante di Google
di recente su come strutturano tutti
delle loro reti con software
più hardware più perché è giusto
non abbastanza grande che non può gestire il
tipo di volume che si stanno dirigendo per
così quando si pensa che quando si
pensare a dove tutto questo insieme
una sorta di aree nuvolose che vanno lì a
completamente nuova tecnologia stack si deve
imparare a trattare con la parte posteriore in te
conoscere 20 anni fa lasso di tempo abbiamo avuto una
thick client server abbiamo avuto alcuni di voi
conosci i runtime e alcuni middleware e
qualche sistema operativo e poi abbiamo avuto
alcuni database monolitici seduti
sotto di esso e oggi è molto di più
come un’app sin su un tablet mobile o
una cosa del genere si tratta di un semplice faremo
assemblare un assortimento dei migliori
servizi disponibili che cambieranno
costantemente e in esecuzione su qualsiasi cosa
l’ hardware disponibile è in giro
quindi se ci pensi allora il vero
il problema che abbiamo in architettura è un
problema di dipendenza il fondamentale
problema che stiamo vedendo nel software
l’ingegneria della nostra storia è quella che abbiamo
questa cosa è chiamata un’impresa
architettura hai visto questa immagine
nessuno
alcune persone hanno ragione è una specie di io
stava dando una chiacchierata ad alcune imprese
ingegneri quindi sono andato a cercare cosa
era tutto e questo è quello che è
tutto di buono e Ana il problema qui
è che c’è questo unico database
sorta di integratore magico di
tutto il resto ma se ci pensi
è anche il generatore di dipendenza magica
di tutto il resto è ciò che è a
enorme generatore di grandi dipendenze e così via
è un approccio su scala e se tu
voglio davvero diventare grande, non puoi scalare
su devi scalare per ottenere
seriamente grande quindi hai bisogno di un federato
architettura di qualche tipo
non necessariamente servizi di Micra ma in
qualsiasi ambiente dove vuoi
essere in grado di diventare davvero grande di cui hai bisogno
ridimensionare in modo da aver bisogno di una sorta di
architettura federata in cui i dati
i negozi sono all’interno della federazione
l’architettura non è una cosa centrale
tutto insieme quindi questo fondamentale
il concetto di un’architettura federata è
dove dobbiamo andare per liberarci
delle dipendenze che ci stanno uccidendo
ritardare le nostre implementazioni e tutte
quel genere di cose e questo è un po ‘
l’architettura che devi avere se tu
voglio passare al cloud e io no
pensa anche se ti scommetto un sacco di
sei seduto sul lato sinistro oggi io
non pensare di poter rimanere lì è tuo
il futuro deve essere finito qui dove
c’è una sorta di federazione
architettura quindi devi imparare come
fai ingegneria del software non con
database ma con API che significa
sono ugualmente importanti e
prezioso e soggetto a tutti i tipi di
vincoli a cui i nostri database erano abituati
essere soggetto a tutti i tipi di cose come
devi avere una buona indurito
interfacce devi avere buone
directory devi avere degli standard
da cui cambiano le interfacce
lentamente devi fare il versioning sui cambiamenti
è quasi come un modo diverso per
guarda il database ma in un modo che può
essere localizzato quindi se pensi di api è come
l’architettura che fanno è abilitata
architetture di servizio che abbassano questo
attrito di integrazione perché è solo
solo tra me e l’altro servizio
laggiù non sono io e tutti i 50 di
questi altri servizi e hanno locale
persistenza quindi i nostri database SQL
rapidamente sostituito da questa roba
che si diffonde attraverso tutti questi
diversi file che hai visto su Google
struttura del file invece di uno solo e
non ci preoccupiamo più di non facciamo
avere spazio per metterlo nel nostro database noi
dispone di spazio stiamo andando a preoccuparsi
il nostro database più tardi sai che non siamo noi
sapere di quali informazioni abbiamo bisogno e siamo
andando a metterlo dove appartiene come te
sentito nel poco prima di questo discorso siamo
andare a raccogliere solo e metterlo in su
lì in qualche formato e capire
in seguito come affrontarlo e cosa fare
con esso e quelli sono solo un intero
concetto diverso quindi
il modo in cui siamo abituati a pensare
database solo pochi anni fa è possibile
anche pensare a API come un prodotto così
L’API è come un prodotto significa che l’ API ha bisogno
essere di proprietà di una squadra che capisce
chi sono i consumatori di tale API e
chi si concentra su di esso e chi ha evoluto il
funzionalità di tale API quindi se lo fai
uno sguardo per esempio a qualsiasi cosa nel
Internet of Things questo sarebbe un nido
termostato e ha una API e poi
Posso usare quell’API per mettere un’app mobile
insieme sul mio telefono Android e via e
trattare con il mio termostato o il mio iPhone o
qualunque sia l’Api è quello che
permettere quelle piccole cose nel
internet possono possedere un’API
contro il quale puoi metterti a conoscenza
qualunque cosa e parlare con loro così sono a
prodotto e questo è ciò che li rende in
un prodotto è la loro connessione API al
resto del mondo lo trovo
interessante quel Carnegie Mellon che
è sempre stato davvero grande su cosa fare
dobbiamo pensare al software
ingegneria nel 2014 sono usciti
con un articolo che riguarda il software
ingegneria per i grandi sistemi di dati ora
quello che hanno detto sono le applicazioni di big data
stanno spingendo i limiti del software
l’ingegneria è essenziale per il corpo
di conoscenza architettonica del software
si evolve per catturare il design avanzato
conoscenza per i sistemi di big data che è
dove l’ingegneria del software deve essere
passare il tempo e se stai pensando
di andare a pensare alla ricerca
pensando a cosa fai in a
università stai pensando al
ingegneria necessaria per davvero bene
i grandi sistemi di dati hanno detto che i big data
i sistemi sono intrinsecamente distribuiti
non c’è alternativa all’architettura
quindi deve gestire in modo esplicito parziale
insuccesso consistenza di concorrenza e
replicazione
e qualsiasi tipo di latenza di comunicazione così
sono sicuri che ciò accada
gestito in tutto il concetto di gestione
i grandi dati devono avere architetture
che replicano i dati per garantire il
disponibilità in caso di fallimento e loro
essere in grado di progettare componenti
che sono privi di stato perché componenti
e le istanze vengono uccise tutto il tempo
che sono replicati e che sono
tollerante di guasti su dipendenti
servizi quindi abbiamo bisogno di capire come
spostare l’ ingegneria architettonica in questo modo
non solo per i big data ma sicuramente per
big data quindi l’ultima cosa che voglio
parlare di questa intera area del
il cloud è ingegneria della resilienza perché
ora abbiamo enormi quantità di cose
a seconda del nostro software come per
esempio c’erano un paio di compagnie aeree
che è andato giù negli Stati Uniti come a
tutto il giorno a luglio entro due settimane di
l’altro era Delta e uno con
Southwest e hanno avuto un piccolo problema
così a sud-ovest ha perso un router e ci sono voluti
circa quattro al giorno
e Delta gli ha perso un interruttore elettrico
ad Atlanta e questo è che conosci casa
base e si scopre che al fine di
volare un aereo devi presentare un file
riferire con la FAA Federal Aviation
Amministrazione e quindi per qualsiasi aereo
per volare ovunque questo rapporto deve essere
archiviato e l’unico computer che potrebbe
Fate questo capita di essere collegato a quel
interruttore elettrico che ha fallito così la
l’intero sistema era giù perché uno
interruttore elettrico ad Atlanta no
permettere che i piani di volo siano archiviati così
dove stiamo andando a sapere quando questi
i fallimenti stanno per accadere se proviamo
per fare tutto al cento per cento
senza errori dobbiamo iniziare a pensare
diversamente dobbiamo cominciare a pensare
su anti fragile invece così se tu
voglio vedere di più su questo che puoi leggere
Nikolas ha detto a bum tell tell abut the
l’intero concetto è che ci sono cose
che sono fragili come il vetro e c’è
le cose sono robuste come spade
e poi ci sono cose il
migliorare quando vengono attaccati come
per esempio un mese fa ho avuto un vaccino antinfluenzale
ogni autunno ho un vaccino antinfluenzale e da mettere
queste cose cattive nel mio corpo così che esso
diventa più forte e non capisco questo
non si ammalano più da allora
iniziato a farlo così l’intera idea di
aggiungere cose cattive per rendere le cose migliori è
cos’è anti fragile, quindi se tu
guarda le donne classiche del met
Flicks con il loro esercito di simian che fanno
roba tutto il tempo da piccoli ogni due
ore ho intenzione di uccidere un istance che sono
andando ad aggiungere Layton vede il loro caos
gorilla che abbatte un’Amazzonia intera
regione ogni tanto solo per vedere come
tutto risponde così quando pensi
sui test devi anche pensare
su Netflix pensa al vero test
è o meno il tuo sistema
il software può sopravvivere in produzione con
tutte queste scimmie del caos e cose simili
quella
uccidere le istanze e assicurarsi che
le cose funzionano ancora e il test finale
di buono è se sia o non sia così
il modo in cui il test finale di qualsiasi
la squadra è buona o meno nessuno dei due
i loro servizi falliscono quando uno di questi
i gorilla entrano e le scimmie entrano
e ucciderli in modo da riassumere il software
ingegneria nel cloud e dove vedo
andando dobbiamo passare a federati
architetture non c’è proprio
sarà un’opzione che sarà
modo più economico, più veloce per la distribuzione e
sarà necessario perché
andrai al club
dobbiamo iniziare a pensare al
il database smette di pensare al
database come integratore e io
ancora leggendo roba in McKinsey e
e Gartner su come il database in
il sistema ERP è l’integratore che è
devo smettere di essere l’integratore, va bene
è così che l’ultimo decennio ci serve
pensa a come ci colleghiamo con le API
attraverso molteplici concetti diversi di
modo in cui archiviamo i dati abbiamo tutti questi
protocolli stateful ma quando iniziamo
entrare in tutto ciò che sarà
là fuori come l’ Internet delle cose noi
devi pensare apolidi perché quando tu
andare sul cloud, la roba muore tutto il tempo
e perderà quota, quindi cosa sei
farò su di esso se stai dipendendo
che dobbiamo smettere di pensare a
esecuzione consecutiva e riflettere
roba che succede contemporaneamente e noi
non so in realtà quale condizione di gara
sta per vincere posso ricordare quella gara
le condizioni sono una delle più grandi cose
Ho dovuto affrontare quando ero
apparecchiature di programmazione e tu sempre
pensato a chi si otterrà
per prima cosa non lo sai più di
comunicazione sincrona come parlare
su un telefono dobbiamo capire come
fare comunicazione asincrona come
messaggi di testo va bene l’altra persona
non deve essere lì prima di averli
andare in giro a rispondere al tuo testo noi
deve capire come fare
programmazione guidata dagli eventi, come ho detto a me
è naturale perché era il
primo modo ho pensato bene forse il
secondo o terzo modo in cui pensavo
programmazione ma quando hai pezzi grandi
di attrezzature è ancora un po ‘di molto
ovvio, ma mi è stato detto che è davvero
difficile da pensare alle persone
programmazione guidata dagli eventi, se tu
sappi fidati di me non è così difficile solo tu
devo cambiare un po ‘la testa
po
invece di programmazione procedurale e noi
devo iniziare a pensare di dimenticare
riguardo al difetto, dimenticalo perché
questo significa che siamo fragili, dobbiamo
pensa a quando succede qualcosa come
resilienti siamo quanto velocemente possiamo recuperare
quanto piccolo possiamo limitare il raggio di esplosione
quando le cose vanno giù perché sta andando
andare giù quindi questo è come un artefatto
dell’impresa come
vedi roba e questo è più come te
devo fare per essere coinvolto in internet
di cose e quando otteniamo questa roba
lavorando in quel momento abbiamo intenzione di essere
molto più avanti nel futuro di noi
erano ora non è la fine della mia ora così
Ho intenzione di continuare con qualcosa
altro
ma è più o meno la stessa cosa, quindi è così
La Germania e mi è stato detto che in realtà ho
ha osservato che le persone come processano
Germania, così questo intero whoa come facciamo noi
che fare con tutto questo incertezza
diventa il processo in cui possiamo applicare
Per mettere le mani su questo quindi ho
vorrei parlare di DevOps questo è
un libro che non ha un mese e io
in realtà non sono sicuro di poter ottenere il tuo
le mani su ancora ho le mani mie
su di esso e l’ho letto e mi piace
molto è di Jean Kim e giusto
umile e Patrick / in John Lewis e
riguarda i tre modi in cui Jean Kim ha scritto
il progetto Phoenix su DevOps e
questo è un po ‘come il manuale dietro
è un sacco di come e in esso
enfatizza questi tre modi i tre
modi il nostro flusso di feedback e
sperimentazione e apprendimento così
altra parte di questo discorso riguarda il flusso
feedback e mentoring esperto e
imparando perché se vuoi farlo
questa roba funziona che devi capire
come far funzionare quel processo
quindi c’è una cosa che sappiamo per
certo assolutamente per certo quando abbiamo un
sistema complesso non importa se lo è
un sistema meteorologico o conosci un riscaldamento
sistema o sistema software qui
qualcosa che non funziona quando tu
prendi un sistema complesso e lo distruggi
non hai idea di come andrà a finire
rispondere garantito che tutte le scommesse sono fuori di te
non conosco le interconnessioni
non conosco le conseguenze non volute
non si sa esattamente cosa sta per
capita e prova come potresti testarlo
non puoi capirlo quindi cosa fa
funziona ciò che funziona per i sistemi complessi
Questo
e c’è una terribile esperienza
mostrandoci che questo è il modo di fare
certo che abbiamo un complesso stabile sicuro
sistemi che non si bloccano mentre li colpiamo
invece di Smashing e rispondiamo a
qualunque cosa accada con quel piccolo
contenuto poke così a causa di quel tipo
della cosa punto di riferimento che è successo in
Il 2010 è Dave Farley e solo umilia
prenota sulla consegna continua e se tu
non l’ho letto che dovresti e forse tu
dovrebbe andare alle azione di Dave Farrelly
se non l’hai sentito perché questo ha
cambia il modo in cui pensiamo al software
processo di sviluppo ha appena avuto un
impatto incredibile e questo è praticamente
il processo che devi pensare
circa se vuoi un buon sistema stabile così
che cosa è questa storia si tratta di fare
sicuro che il tuo processo è guidato da
test di accettazione che sono eseguibili e
che scrivi codice per superare quei test
si tratta di assicurarti di averlo
team interfunzionali o full stack
che include l’intera pila di persone
necessario fare quella cosa particolare
stai cercando di fare il prodotto deve essere
lì il QA deve essere lì ossessionato
là sì poche colombe – si tratta di
tutto automatizzato costruisce test
distribuzione della migrazione di macwrite del database
lo chiami che si tratta di distribuire al
tronco non ha ramificazioni come
molti qui hanno rami
okay allora non sei ancora qui
ma si tratta di non avere rami Wow
ora se ne hai 30 ne prendi tre
sai che hai fatto un grande passo ma nel
fine vuoi avere un solo tronco
che si sta continuamente l’integrazione di
e quel software è sempre di produzione
pronto o si ottiene un diritto corretto
priorità distanza
sembra terrificante che è dove hai bisogno
per andare e si dispiega tutto il tempo
costantemente diverso per dominio ma
la distribuzione e il rilascio non sono la stessa cosa
cosa rilasciate girando qualcosa
con un interruttore che si distribuisce tutto il tempo
il codice non deve essere attivo fino a quando
lo accendi ma lo distribuisci
costantemente così se ci pensi come
una pipeline di distribuzione quello che hai è
qualcosa che sarà più veloce è
sarà più sicuro e lo sarà
meglio intendo quello che avevi prima e
questo deve essere il processo che pensi
molto difficile nel dirigersi verso il
il secondo pezzo ricorda i tre modi
feedback di flusso il prossimo è il feedback
e ti propongo di aver bisogno di end-to-end
feedback hai bisogno di sì per vedere cosa c’è
andando avanti in produzione con il monitoraggio
sistemi ma devi anche vedere cosa c’è
andando avanti quando il codice è distribuito con
i tuoi consumatori e ricevi quel feedback
dritto alle persone che stanno facendo
decisioni su cosa fare dopo chi ha avuto
meglio essere nella squadra
perché questo è un processo veloce, quindi noi
non ce l’ho più
design in outsourcing
c’è una ricerca per dimostrare che il
il product manager ha torto almeno la metà
il tempo e ho messo il riferimento giù
qui puoi ottenere queste diapositive e guardare
su e in realtà se parlo al prodotto
i manager dicono che sì, in realtà questo è
vero quindi come facciamo a non fare tutto questo
ci viene chiesto di fare perché chiaramente la metà
il tempo è solo una supposizione, beh, è così
sempre solo per indovinare e si potrebbe capovolgere
una moneta per decidere quale deve prendere solo
come facilmente um o se dai un’occhiata a a
specifica che qualcuno ti ha dato come un
ente governativo o qualcosa del genere
probabilmente due terzi delle funzionalità e
le funzioni nelle specifiche non lo sono
necessario non è necessario essere lì ok
e quindi è solo meglio essere pigri e
farlo solo un terzo o meno della
lavoro che in realtà sta per fornire
valore rispetto a fare tutto nelle specifiche
quindi non dovremmo essere il design in outsourcing
a qualcun altro che dice ai nostri team
cosa dobbiamo fare per passare dalla consegna
squadre per squadre di problem solving così
squadre di consegna ottenere le istruzioni prendono
ordini sai che qualcuno dà loro il
dai loro un menu e loro lo danno
tu l’ordine e dobbiamo trasferirci
le squadre che risolvono i problemi sembrano avere
tutti necessari per risolvere un problema
non una soluzione ma ecco cosa è il
i consumatori stanno cercando di realizzare qui
è il lavoro che devono essere fatto
ecco la metrica che dobbiamo spostare in a
direzione diversa vedi cosa puoi fare
con esso e abbiamo bisogno di avere problemi
risolvere team che affrontano questo tipo di
domanda piuttosto che team che sono quello
viene detto cosa fare se si guarda
la sperimentazione e il processo di apprendimento
Ti ho promesso un processo qui è
si inizia con segnali non requisiti
hai una dichiarazione di problema no
caratteristiche che vuoi concentrarti su cosa sono
i problemi che stiamo cercando di risolvere e
la dichiarazione del problema non è facile da pianificare
con ipotesi non stime non lo è
chiaro a me più se hai problemi
risolvendo i team che cosa fanno le buone stime
chiunque tu debba sapere che puoi
risolvere il problema entro i limiti
e dato che il resto dovrebbe essere fino a
la squadra qui è i miei limiti ecco la mia
problema se riesci a gestirlo all’interno
quei vincoli di solito di tempo e
i soldi
poi vai avanti e fai a modo tuo e così
non vogliamo un arretrato di storie noi
voglio più esperimenti che stiamo andando
corri contro le ipotesi e noi no
voglio supposizioni vogliamo analisi e
conclusione quindi questo è lo standard I
non conosco il metodo scientifico
processo di ingegneria e se questo processo
non è alla base del processo che tu
usa oggi, quindi dovresti chiederlo
te stesso perché no perché nel nostro mondo
con la nostra incertezza questo è l’unico
processo che funziona ora hanno gli scienziati
stato usando questo processo per centinaia di
anni in realtà non è poi così male
processo ma è ora che ci siamo arrivati ma
una delle parti difficili di questo processo
è la prima parte che problema siamo noi
andando a servire risolvere e quali tipi di
ipotizza le nostre ipotesi razionali
prendi così bene, alla fine, eccomi qui
solo andando a prendere un paio di minuti a
parlare di un processo che ho incontrato
di recente certamente non è l’ unico fuori
ce n’è una che trovo carina
interessante e si chiama Google
ein sprint è stato introdotto nel 2014 a
la conferenza i / o di Google è interessante
conferenza su di esso è più un design
conferenza piuttosto che uno sviluppo
contest ed è un processo per capire
fuori come prototipare e testare qualsiasi idea
tra cinque giorni
va bene che significa prima di te in realtà
codice è descritto abbastanza bene in questo
fammi passare attraverso che inizia sul
primo giorno in cui tutti andare avanti
la stessa pagina come facciamo roba che cosa è
il problema che stiamo cercando di risolvere qui
sono i problemi qui i vincoli e
poi il secondo giorno c’è qualcosa
Ne parlerò tra un po ‘
di più ma riguarda l’ individuo H
abbozzando in silenzio le proprie idee
su come farlo e poi condividere
sotto la guida di un designer perché
è un processo di progettazione standard e quindi
condividendo quelle idee su carta in modo che
non abbiamo a che fare con il brainstorming
che ha dimostrato di cervello di fame
è stato dimostrato per assicurarsi che il
persone che sono più rumorose o più dentro
comando della lingua o qualsiasi altra cosa
è o è il più simile a tutti gli altri
sono quelli che fanno sentire le loro idee
quindi preferiamo un processo che consenta
molte idee diverse da più tranquille
persone e dalle persone che non lo sono
così comodo parlare per ottenere il loro
idee troppo e poi c’è decidere quale
uno è quelli di queste idee e io ci sono
andando a parlare di non votare perché
il voto di nuovo sopprime le idee delle minoranze
e poi fai un prototipo molto veloce
hai alcuni designer li hanno messi
insieme qualcosa di veramente veloce non lo è
codice è forse una nota chiave o lo sai
PowerPoint o qualcosa del genere e
poi il quinto giorno ne hai alcuni
gli utenti entrano ed effettivamente provano il
idea con un intervistatore che li cammina
attraverso alcune cose resto della squadra
guardando da uno schermo remoto per vedere come
le cose vanno e scopri come questa idea
gioca con almeno alcune persone così
questo è il concetto generale qui e qui
è un libro su cui puoi ottenere molto
ulteriori informazioni e sto solo andando a
fare un rapido video di un sommario di esso in
il tempo di sviluppo del business è un prezioso
risorsa perché stai sprecando per essere
Google più efficiente e reattivo
Ventures ha creato il design sprint the
processo per la risposta alle attività critiche
domande in soli cinque giorni
il primo giorno dello sprint è per
condivisione di informazioni tra reparti
e creando una semplice giornata di viaggio dell’utente
due è il giorno dello schizzo in cui la squadra lavora
individualmente per generare creativo
soluzioni al problema
il mercoledì la squadra guarda tutto il
soluzioni e decide il meglio
approccio
crea uno storyboard visivo e lo sei
pronto per il prototipo Giovedi è ora
per diventare produttivi e costruire il tuo
prototipo l’ ultimo giorno che metti alla prova il tuo
idea su persone reali per vedere se ha qualche
valore se fa cinque in alto
stai andando a fare qualcosa di grande, se è così
non va bene hai imparato qualcosa
e il costo è solo di cinque giorni quindi fermati
sprecare il tuo tempo e comprimere il
ciclo di dibattito senza fine in un singolo
disegno sprint settimana così um due cose
sullo sprint del progetto che mi piacerebbe
indica rapidamente qui se lo trovi
affascinante e uno è l’idea
la generazione del secondo giorno è davvero
interessante perché sta avendo
le persone non competono tra loro
per far sentire le loro idee direttamente dal
all’inizio ma permettendo a quelli fragili
idee da sviluppare da parte degli individui
lentamente fino ad arrivare ad alcuni dettagli
cosa che pubblicano e poi è così
recensito bene dal gruppo senza nemmeno
sapendo di chi sono le idee, perché
c’è una cosa chiamata pregiudizio di conformità
uno dei pregiudizi di Linda sì, Linda ed è
sull’idea che le persone che pensano
sono al mattino saranno nel
la minoranza si autoregolerà o cambierà
la loro opinione e poi quella lo rende
ancora più difficile per le altre persone che hanno
pareri di minoranza di avere opinioni così
l’idea è quella di trovare un modo per le persone a
esponi le loro idee prima che abbiano
preoccuparsi se sono nel
maggioranza o in minoranza e in un modo
quello non richiede loro di essere il
la persona più rumorosa o la più conosciuta
persona in avanti o va bene se
sono un po ‘diversi dal
resto del gruppo ma non sono d’accordo
il modo in cui parlano di fare questo
il terzo giorno perché poi la gente vota
e non sono così divertente da votare
potresti immaginare
perchè ma a 3m dove ho lavorato per 20
anni non abbiamo votato sulle idee di prodotto noi
attratto le persone a idee di prodotto così noi
ha esplorato molte idee che dovresti
sii troppo perché poi è la santa Nydia
non accontentarti di una sola idea, prova un intero
molti di loro e assicurarsi che vengano da
l’intero spazio del design compresi alcuni
valori anomali che significa se si vota
gli avvocati non ce la faranno e così
vuoi perseguire una varietà di idee
e se lei ha un’idea e può attrarre a
un paio di altre persone per provare la sua idea
perché non lasciare che non debbano farlo
essere nella maggioranza possono essere solo un
poche persone che provano le loro idee
come quasi tutti i nostri veramente innovativi
le squadre di prodotto hanno funzionato se un campione potesse farlo
attirare un po ‘di altre persone l’ idea ha avuto
esplorato fino a quando non ha funzionato o
ha funzionato gradualmente si restringe il
idee a quelli che stanno andando a lavorare
e tu vuoi mantenere multipli
opzioni il più a lungo possibile prima
ti accontenti di qualcosa non solo
scegli una cosa e seguila così
riassumere il futuro del software
l’ingegneria prima di tutto sta andando
essere un grande progresso tecnico
lì possiamo vederlo ora
si tratta di ridimensionare di cui parla
infrastruttura come codice è su questo
tutta la nuova tecnologia di stack che è
seduto nella nuvola e avendo un
modo diverso per noi a pensare
programmare e pensare alla sicurezza e
pensa all’affidabilità e alla resilienza
e poi ci sono i tre modi di
DevOps sorta di espanderla per assicurarsi che
pensa a tutto il prodotto non solo
Devon ops ma il tutto così vogliamo
pensare a come otteniamo un
pipeline di distribuzione continua come facciamo noi
mettere insieme la risoluzione dei problemi dello stack completo
squadre
okay e assicurati che lo stiamo facendo
sperimentazione e apprendimento fino in fondo
attraverso il nostro ciclo di sviluppo quindi
il futuro è qui in realtà non lo è
facile da vedere non così uniformemente
distribuito ma se ti guardi intorno
troverai dei futures che conosci
anche nelle nostre sessioni durante il resto
del giorno quindi grazie mille
abbiamo tempo per due domande se tu
fai una domanda per favore, vieni al
microfono si
ciao grazie per il tuo discorso ho un
domanda riguardante la prima parte di
i tuoi discorsi di cui stai parlando
la tendenza lontano dai monoliti e altro ancora
verso i sistemi distribuiti ho paura
che molti sviluppatori stanno cercando
a quello che stanno facendo le grandi aziende e
chi parteciperà a colloqui come questi
quindi prova a risolvere i problemi che non hanno
hanno davvero e over-engineer loro
soluzioni come ad esempio l’utilizzo di Hadoop
quando hanno solo pochi gigabyte di
dati o un piccolo team che distribuisce
migliaia di micro servizi in cui a
il monolite potrebbe essere la scelta più economica
giusto cosa pensi che ci sia
non c’è mai qui è il finale
rispondi come se tutti si trasferissero qui di cui hai bisogno
per sapere dove sta andando la tendenza e
dove alla fine devi essere ma se
non hai un modo intelligente di ottenere
lì se all’improvviso ti credi
può saltare lì senza imparare a
tutto quello che stai quasi certamente sbagliato così per
esempio se sei in banca la tua banca
deve essere spaventato adesso perché
c’è così tanto attaccato sulle tariffe di
banche il loro reddito di base da tutti i tipi
di fintechs tutto che si tratti di
tasse ipotecarie o qualsiasi tipo di tasse così
vogliono velocemente fare qualcosa ma
non è facile essere veloci perché il
back-end è davvero difficile da spezzare
e come posso combinarlo con la parte anteriore
fine, quindi, grazie non ha avuto front-end
squadre e possono fare tutto ciò che vogliono
e i team di back-end sono lenti come
erano sempre ciò che significa che non possono
fare molti cambiamenti perché quasi
tutto dipende dal front end
il back-end e quindi ci deve essere un
soluzione ma forse la soluzione non lo è
domani possiamo rompere tutto
e ricominciare da capo perché abbiamo
hai già un business da sostenere così tu
devono capire come migrare e
che sta andando a dipendere dal contesto
che ti siedi in esso non sta andando a dipendere
su come quella società laggiù ha fatto
qualcosa che sono diverso da quello che uno
la cosa di cui puoi essere sicuro se la prendi
la soluzione di quell’azienda è la loro
la soluzione al loro problema è probabilmente
non
la tua soluzione al tuo problema così tu
bisogno di persone intelligenti che possano pensare e
capire dato le tendenze qual è il
giusto meccanismo per arrivare al giusto
la soluzione per noi in futuro ricorda
tutto ciò che riguarda Hadoop ha preso cinque o
sei anni su Amazon al servizio del microfono
l’architettura orientata richiedeva cinque o sei
anni ognuno di quelle cose ha preso
tanto tempo per passare da un’idea a realtà
sviluppare su larga scala e se ci pensi
puoi farlo in cinque mesi sei pazzo
e sto per succedere così sai che fermati
sognare ha senso, grazie ok, andiamo
prendiamo un’altra domanda da
l’app ho un sacco di domande qui
Mi dispiace non posso chiedere tutto a te
cosa ne pensi del ruolo di
sistemi di regolazione come i governi o
leggi nazionali nel cloud federato
mondo ben il il là sarà sicuramente
essere regolamenti governativi nazionali
non importa se sono buoni o cattivi
non hanno intenzione di andare via così che io
osservare è che le persone che sono
seduto tra le nuvole impara come
capire quei sistemi di regolazione
impara a capire la sicurezza
preoccupazioni e imparare come affrontarli
e quindi questa è un’altra ragione comunque
Penso che il cloud finirà per diventare
la cosa della scelta perché sono
attualmente i regolamenti sono
complicato da navigare in paese
paese e se hai il tuo OneSource
capire tutto potrebbe fare di più
senso so che in noi un sacco di
le persone stanno trasferendo molti dei loro personali
molti dei loro dati personali in Europa
i server di dati chiamano i server cloud perché
perché le leggi qui sono molto più
protezione dei dati personali individuali
di quanto non siano in noi, quindi se i dati si trovano su
i server qui sono molto più protetti da
regolamento così le nuvole che le persone
stanno cercando di capire quali sono i reg e
come affrontarli penso che GES
prevedere il sistema è davvero buono in questo
e altri venditori di cloud stanno imparando così
avranno per capirlo, ma le nuvole
può essere in molti posti diversi
Va bene e avranno a che fare con
qualunque sia il regolamento, grazie
grazie mille Maria per questo
nota fondamentale
tu
Please follow and like us: