Vediamo un po' di istruzioni, però, come si fa su Netflix parliamo dell'episodio, partiamo dall'episodio precedente e ripartiamo dalla definizione di Michael Bay.

Così ci riscaldiamo alternativa esistente per un'impresa tra produrre internamente make o acquistare dall'esterno buy beni o servizi necessari per lo svolgimento della propria attività.

In questo speech proveremo a raccontarvi il nostro buy processo di Baye Make raccontandovi tutta l'evoluzione, facendolo mostrandovi il modello decisionale per passare dal Bayern Make darvi due dritte su come scegliere la giusta soluzione tecnologica.

E poi, per riuscire a scegliere la giusta soluzione tecnologica, vi diamo due o tre informazioni tecniche che vi serviranno solo due o tre che vi serviranno per uscire a fare una valutazione.

Poi, alla fine regalino vi regaleremo l'architettura perfetta.

Noi siamo partiti dai, come raccontava prima Omar.

Esatto, abbiamo visto il nostro il nostro vai da un punto di vista infrastrutturale.

Ma vediamo le motivazioni che ci hanno portato a scegliere questa infrastruttura e a scegliere in primis questo approccio.

Contrapponendo lo al make.

Le motivazioni sono state il fatto che il nostro buy, quindi questa infrastruttura perfetta per validare era semplice, aveva un basso costo di implementazione sia di sviluppo, quindi, ma anche di manutenzione futura.

Il nuovo tecnico richiesto non era elevato come abbiamo detto prima, poche righe di codice efficaci che raggiungevano un obiettivo e avevamo sicuramente soluzioni già testate.

Se ci pensate, charged with active campaign sono tutti i servizi utilizzati da migliaia milioni di aziende che ogni giorno mettono alla prova questi servizi.

Quindi diciamo che eravamo confidenti del loro, del loro funzionalità e di come potevano essere adatti al nostro caso.

Ma la domanda è va sempre bene come facciamo a gestire più utenti? Il modo più semplice si chiama scalabilità verticale ed è più semplice perché non richiede sforzi nella norma.

Non richiede sforzi di sviluppo con una configurazione della cavi, ma cos'è la scalabilità verticale.

Ve lo spiego in stampatello, perché capisco che sul tecnicismo non ci siamo.

Allora immaginate di prendere un pullman di una capienza di cento persone e dovete portarne duecento, ma se siete a Londra potreste fare così aggiungete un piano e ne portate duecento.

Se ritorniamo sul tecnico significa che al sistema che avete aggiungete e pompate ram sei più comunque lo stesso sistema gli date una tigre ed un po'.

Come fate i passaggi da un abbonamento all'altro? Ma c'è un limite a quanti piani possiamo aggiungere al nostro pullman.

Lo so, siamo catastrofici.

Però rende l'idea.

Diciamo che ci eravamo dati dei limiti, ma vediamo se gli utenti erano effettivamente dei limiti.

Come potete vedere, la nostra infrastruttura iniziale era postata su godetevi il sito web punto com.

Supportava fino a diecimila visite al giorno per diciamo, per renderla accessibile, scalabile per i primi lanci abbiamo fatto una grande, quindi abbiamo esteso le potenzialità dei server e siamo arrivati a supportare fino a quindici mila visite giornaliere.

Ma vediamo WordPress che è uno degli strumenti piu' utilizzati per fare City, si è tirato al massimo su Un'infrastruttura.

Comunque potente.

Quanti utenti può gestire? Un milione e due c'e' qualcuno in sala che ha un milione e due di utenti da gestire.

Poi ne parliamo dopo.

Ti chiedo qualche consiglio.

Grazie.

Quello della casa? Sempre lui.

Comunque gli utenti, come potete vedere, non rappresentavano un grosso problema.

Ma allora vediamo se i costi erano un limite.

Parliamo di costi.

Come potete vedere, anche i costi si aggiravano attorno a quattro cinquecento euro al mese per tutta l'infrastruttura tutto lo stack e tutti i servizi coinvolti in affitto.

Esatto.

Un affitto a Milano? No, non a Milano.

Sono date a Milano tutti boxe.

Esatto, è diciamo che questi costi quindi erano sostenibili per un business agli inizi.

Comunque, rispetto ai costi che abbiamo adesso sono molto, molto più bassi.

Ma quindi quali erano le reali ragioni che ci hanno portato ad eliminare questa infrastruttura? Quindi il nostro byte e le ragioni che ci hanno portato a passare al make? Diciamo che una delle principali motivazioni per cui l'utente di Lerner per cui gli utenti diversi si scrivono e il fatto che non hanno tempo.

Ma come potevamo dare tempo all'utente? Come potevamo offrire il miglior valore nel minor tempo possibile? Con Un'automobile? Aveva bisogno di un app mobile nella bomba c'erano i corsi, I corsi erano sempre e continuamente in crescita, ma era tutto gestito manualmente.

Non c'.

Era un back office performante.

Non riuscivamo a caricarli costantemente e dovevamo automatizzare tutta questa parte.

Quindi dovevamo scalare la parte dei corsi E in ultimo, se prima abbiamo parlato di feedback loop, diciamo che avevamo bisogno di dati.

Ma i dati dove vengono presi? Con le analytics, con le analytics che avevamo al momento non eravamo in grado di raggiungere un grado di analisi soddisfacente per quello che dobbiamo fare.

Quindi avevamo bisogno di analisi avanzate.

Quindi qual è il prossimo step? Il prossimo step make invalidato la nostra checklist e passiamo al make prima di raccontarvi cosa abbiamo fatto, vi raccontiamo cosa non l'abbiamo fatto al grido, tanto poi vi servirà l'idea.

Ma io sto le funzionalità che nei prossimi cinque anni dovrà fare.

Faccio subito un'infrastruttura bella complessa che mi soddisfa tutti i problemi che avrò da qui a cinque anni.

Spendo tutto subito, mi levo il pensiero e via.

Sembra semplice, ma per quanto mi riguarda potrebbe essere anche il piano di evacuazione di questo edificio.

Non è molto chiaro.

Secondo me è una cosa che ho chiara è cosa abbiamo, cosa avremmo, cosa avremmo ottenuto con un'infrastruttura del genere suona male.

Non ricordiamoci di mettere una bella x soprattutto a tutte queste infrastrutture super complicate che non ci portano a niente.

Ricordatevi di evitare persone che vi propongono soluzioni tecnologiche con questo grido che abbiamo ripetuto per farvelo entrare in testa e del tanto poi vi servirà.

Ricordatevi che la complessità deve intervenire nel momento giusto.

Quindi in definitiva partite semplici, le infrastrutture dev'essere semplice, comprensibile monitor, abile estendibile e sostenibile estendibile, nel senso che deve essere facile facile aggiungere funzionalità all'interno dell'infrastruttura sostenibile, sia dal punto di vista di risorse di Tim, ma anche da un punto di vista di costi, perché é quello che poi alla fine interessa la maggior parte del business.

All'inizio bene, abbiamo visto come quali sono le motivazioni, come deve essere la soluzione.

Ma come possiamo passare concretamente all'azione? Sì, tu lo chiedi ancora quello che lo faccio così Ma tu sei proprio sicuro che prima ha risposto bene, quindi questa me lo so, ragazzi, non lo so.

Cioè, qualcuno in sala che ha una risposta Aiutate per noi.

Vediamo vediamo che Malcolm Meerkat forzare portarmi il lettino Grazie.

Cosa? È stato? Un ottimo il vettore di Natale? No? Lo volete vedere? Ah, ok.

Il pizzino di Mirko Il pizzino di Mirko Lasciamolo qua, Lo raccontò così? Qual è l'idea di Mirko che ci ha proposto questo fatto vero? Ripartiamo da qual era il problema? Che esposto? Omar, volevamo customizzare l'esperienza dell'utente esperienza utente significa applicazione.

Bene la nostra l'idea di Mirko Eh, ma perché il nostro export non lo spendiamo sull'applicazione Cerchiamo per il momento di utilizzare un brand già esistente e um una soluzione, un back office già esistente ed è nata l'idea di strappi cos'è, strappi, strappi, un CMS ehm si sta per Content Management System è un robot che gestisce contenuti robot.

È un termine tecnico, in pratica WordPress.

Ok, la differenza che strappi headless, che significa che non c' è la parte di front-end.

Detto così sembra una penalizzazione, ma era esattamente quello che ci serviva.

Perché? Perché ci dava un back office già pronto con cui il team poteva inserire contenuti.

In realtà ci dava di più perché ci permetteva per la sua struttura di estendere, automatizzare alcuni processi di automazione di caricamento di contenuti ci dava un back già pronto che riusciva a fornire l'applicazione applicazioni.

I dati, quindi contenuti i corsi dati ai professionisti, alle applicazioni tramite sono sostanzialmente il linguaggio di comunicazione tra tra i vari livelli delle applicazioni.

Vabbè, sticazzi alla romana il punto qual è? E che avevamo velocemente un sistema che forniva i dati che ci servivano per applicazioni.

Potevamo focalizzarci sull'applicazione infatti il primo punto abbiamo sviluppato un'applicazione mobile in un mese e mezzo follia.

Poi abbiamo sviluppato l'applicazione web intorno al Natale successivo e poi abbiamo scoperto un giorno che si sveglia.

Scusi.

Che poverina carica.

Ogni volta che usciva un costo doveva crearsi landing page sul loro punto com.

Quindi su WordPress, il le pagine e landing page dei corsi.

La manina ci ha guardato un po' strimpellare sul codice e ha visto che quei dati poteva prendere automaticamente.

Quindi è riuscita con WordPress a creare landing page in automatico coi dati presi da St.

Rapi'.

Quanto ci è costato questo scherzo? Settanta K.

Siamo più o meno no.

Monolocale, dai.

Va bene.

Ok.

Non siamo in Silicon Valley.

Niente garage stentata K.

Sette mesi di sviluppo, come abbiamo raccontato, però sono sette mesi incrementali.

Significava che abbiamo sviluppato un'applicazione dopo un mese e mezzo.

Abbiamo sviluppato poi qualche mese dopo l'happy una volta che ero a posto.

Più o meno sono passati sette mesi.

La parte interessante sono quei due K dei tabloid service.

In pratica è come se fossero i costi di condominio.

Ok, due k al mese.

Ogni volta un po'.

Caro suo condominio.

Mi sa che ce la piscina.

Però il budget non era un problema in quel momento.

Almeno questo budget la faccia proposta di queste due entità era su quanto poteva reggere.

Allora come abbiamo fatto a capire quanto poteva reggere? Ma sicuramente avevamo dei limiti, dei limiti che ci eravamo posti e sapevamo che avremmo poi prima ho dovuto, prima o poi dovuto risolvere, in primis i progressi degli utenti sul loro.

I progressi sono salvati ogni dieci secondi, continuamente all'interno del player delle elezioni.

Quindi erano tutte chiamate che andavano a influenzare il nostro server.

In secondo luogo, il check-out.

Durante i lanci erano andati un limite di duemilacinquecento registrazioni giornaliere da supportare, nel senso che anche qui erano tutte registrazioni che andavano a sovraccaricare il nostro sistema.

Avevamo anche picchi di utenze durante i webinar.

È tuttora comunque lì li abbiamo.

Quindi, quando duemila persone sono connesse simultaneamente, potevano verificarsi alcuni problemi strutturali e in ultimo anche le ricerche.

Quando ho cercato un contenuto, comunque, tra tutto il nostro archivio venne per fermata una ricerca che va ad influenzare sempre di più e sovraccaricare tutta l'infrastruttura.

Ma questi limiti come facevamo a superarne? Facciamo un passo indietro, dov'era il problema.

Facciamo un passo indietro cos'è un CMS, un CMS Content Management system, ovvero un sistema progettato per gestire contenuti che cambino raramente nel tempo.

Poche volte, se ci pensiamo bene i progressi degli utenti sono contenuti dinamici, sono in continuo aggiornamento, così come il check-out durante i lanci.

Ma eravamo consci di una cosa stavamo utilizzando uno strumento in un modo diverso da come era stato progettato.

Io non ho dubbi che sul fatto che questo strumento possa funzionare però l'ingegnere in occhio non penso che l'abbiano progettata in questo modo potrebbe ma sarebbe utile.

Ma quindi alla fine come facciamo sempre questa faccia super convinta, ma in realtà questa la faro', ma non perché lo sappia, ma perché in realtà quello che ha detto amaar ci porta la soluzione.

La soluzione un'architettura servizi vabbè, anche qua ve la spiego in stampatello.

Immaginate di aprire un business da soli, non so borse di lusso dovete cucirgli le borse, dovete fare le fatture avrà a che fare coi fornitori farà divi content instagram fate tutto voi, ma come fate a scalare a scalare il vostro business? Non potete fare tutto da soli, però ognuno di questi elementi che ho nominato sono di fatto un servizio.

Sono una funzione della vostra attività che potete spezzettare procedura rare e potete delegare a un team oppure a una persona con l'architettura servizi funziona esattamente la stessa cosa.

Noi dovevamo far fare l'operazione giuste allo strumento o servizio, giusto? Quindi da quel momento avremo fatto in modo che strappi si occupasse solo dei contenuti.

É tutto quello che prima faceva strappi l'abbiamo staccato in altri servizi che sono indipendenti e comunicano tra di loro.

Quindi abbiamo creato un servizio di sorcio.

Abbiamo creato un servizio per il profilo in servizio di checkout.

Successivamente abbiamo creato anche un servizio di AJ.

In realtà quello di streaming di contenuti c' era già il progress che il servizio piu' complesso ed è quello più alto stress.

Perché ogni dieci secondi le app web e mobile producono un messaggio Sul serio.

Quindi lo bombardiamo? Potevamo crearlo apposta per per quel ruolo? In pratica il framework che avete nel business, ma funziona anche dal punto di vista tecnico.

Vedete come il ministro della strategia tech tecnologica è uguale a quello business? Non cambia tanto.

Siete nati architetti, software.

In pratica il punto è avete una complessità.

La dividete in responsabilità, gli assegnate un ruolo e l'ho delegato un servizio nel business come la tecnologia.

Qual è il vantaggio? Il vantaggio è che potete progettare ogni servizio per quel caso d'uso anche a livello di stack tecnologico e di risorse.

Il progress l'elemento più complesso metto e fort e tecnologia per risolvere col quel problema.

In più ho anche vantaggio di abilitare la scalabilità orizzontale.

Ora però ho tirato fuori la scalabilità orizzontale e ho finito i termini stampatello e questo io non riesco.

Per spiegarlo torniamo all'esempio del pullman.

Prima scappavamo in verticale aggiungendo un piano a questo fantomatico pullman, ma c'è un modo più semplice e un modo più efficace di gestire questa cosa, quindi di portare le nostre persone.

Appunto, appunto b banalmente aggiungendo piu' pullman.

Quindi immaginate di avere più server replicati in orizzontale, che funziona allo stesso modo e mantengono l'infrastruttura.

Questo in parole semplici è la scalabilità orizzontale.

Super così in realtà, avendo anche la stabilità orizzontale, quella verticale, possiamo far scalare indipendentemente i servizi.

Quindi, ad esempio, il progress, come dicevo prima, è il punto più complesso.

Gli possiamo dare tre istanze.

Cosa? So cosa un'istanza? Immaginate di andare al supermercato.

Dovete andare a pagare in un'unica cassa con una cosa lunghissima.

Quello che succede è che vengono aperte più casse la fila si distribuisce nelle casse.

Chiaro? No? Qui funziona esattamente nella stessa maniera.

Le istanze sono le singole classi che vengono aggiunte di qualcosa che è così la abbiamo parlato in un modo e loro lo replichiamo.

Quindi al progress possiamo dargli tre istanze perché lo bombardiamo, ma possiamo fare qualcosa interessante.

Ad esempio durante dei lanci complicati Black Friday possiamo fare in modo di prendere il check-out? Direi che c' è per questo periodo.

Ti aggiungiamo un un'istanza, poi finito il il Black Friday torniamo al carico precedente.

Quindi non non serve tutto questo essere forte per il sistema.

In altri casi però non riusciamo a prevedere il carico il numero degli utenti.

Pensate a webinar, non sappiamo quanti utenti arrivano e con che distribuzione.

Quindi il bello è che la piattaforma su cui facciamo vivere i nostri servizi quello che fa è scalare automaticamente.

Quindi sta lui bello comodo sa lui non devi dire niente, sta lui.

Quando aggiungere risorse sa lui quando scalare aumentano gli utenti, lui aumenta la potenza e voi non vi accorgete di nulla e noi non piangiamo.

Pero' il punto, Omar, e dobbiamo fare tutto questo cinema solo per aumentare il numero di utenti.

Se a noi il numero di utenti va bene, così abbiamo anche un bonus che la fault tolerance.

Poiché è chiaro, poiché torniamo all'esempio di pullman, tocca di nuovo stampatello.

Andiamo da Milano a Roma con il nostro pullman doppio, quindi scalato verticalmente con duecento persone a bordo.

Cosa succede se questo pullman si rompe? Quante persone arrivano a destinazione? Zero.

Quindi il sistema è collassato, il nostro lancio è finito.

Passiamo al sistema invece con piu' pullman, quindi con due pullman.

Cento persone per il pullman.

E cosa succede se a metà percorso un pullman si rompe e l'altro arriva a destinazione? Quante persone arrivano? Cento.

Quindi in poche parole, questa questo è il vantaggio avere un'infrastruttura che esiste agli errori.

Se ad esempio voi sull'eterna, se il servizio dei progressi sulle dovesse andare in tilt e non dover funzionare più, voi potreste continuare a fruire le lezioni.

Senza il salvataggio dei progressi, però, tutto il sistema funzionerebbe questa Fall tolerance Figo ha spiegato bene.

Grazie.

Sono cose in piu'.

Tutto questo percorso ci ha portato alla nostra architettura del Duemila e ventitré che questa roba qua No, non è un piano di evacuazione.

Adesso mettetevi comodi da qua.

L'una.

Ve la spieghiamo Tutto pronti? No, scherzo.

Però se siete interessati ci picchiate fuori ne parliamo.

Detta così sembra una minaccia però non non facciamo niente, torniamo ai costi che la roba che vi interessa quanto costa sto giochino? Centottanta k diciotto mesi hosting i costi di hosting sono cinque mila.

Quattrocento euro.

Quindi abbiamo piu' o meno un trilocale fuori Milano o un monolocale a Milano? Sapete voi che però altro che piscina ce ne sono due.

Mi sa che c'è anche la sauna perché vi costa cinquemila quattrocento euro al mese.

Ok, vedete quanto costa il make con un buy con quattrocento euro al mese ve la cavate qua se è passata al make con quattrocento euro al mese manco ci pagate un quarto dei costi, oltre dei costi vivi mensili.

Oltre ai costi di sviluppo, quindi? Occhio però a parte i costi o é figo potenzialmente possiamo gestire un numero di utenti, pare Netflix, ma tutto troppo bello.

Sicuramente abbiamo anche degli svantaggi per la complessità di implementazione, la complessità strutturale.

Abbiamo dei costi comunque alti di monitoraggio, costi di ricerca, errori importanti.

Perché le infrastrutture, come comunque tende ad allargarsi, ad aumentare espandersi.

Abbiamo sicuramente maggiori competenze tecniche richieste.

Perché ovviamente se il biberon non richiedeva nessuna riga di codice.

Qui dobbiamo mettere le mani in pasta e ragionare solamente da sviluppatori e abbiamo anche un maggior tempo boarding, nel senso che se un nuovo membro del team entra dovete produrre anche della documentazione per introdurlo tutta questa struttura, perché non è semplice, non è affatto semplice e in ultimo abbiamo anche tutto il discorso di coordinamento dei servizi.

In conclusione cosa ci portiamo a casa? La semplicità all'inizio assolutamente paga partite semplici partite con il buy perché altrimenti soluzioni complesse si pagano che questo è il secondo punto se vi offrono un progetto che non capite scappate, tanto poi vi servirà.

Vi servirà.

Vi gestirà tantissimi utenti? No, una x sopra a quello.

E in ultimo il fatto che la soluzione tecnologica evolve con e per il business.

La tecnologia non deve essere impiegata solamente non deve essere un vanto.

La tecnologia deve essere un mezzo al servizio del prodotto.

Grazie a tutti per la tensione.

Ammiriamo di avervi.

Lo so che l'hai fatto perché volevi l'applauso però in realtà one more thing, come dicono quelli bravi non io ha mai accennato.

Il coordinamento però non ve l'ha spiegato io ve lo voglio raccontare.

Vi ricordate che C' era un bonus? Un regalino.

Vi avremmo dato all'architettura perfetta.

Quindi per arrivarci vi chiedo due favori.

Una Alzatevi in piedi, tutti.

Su, su, su.

Bravissimi.

Wow, Amara, è incredibile.

Se lo chiedo a mia figlia, non paga neanche di striscio.

Ok, Al mio tre come ieri sera.

Scatenatevi.

Tre, due, uno che Grazie.

Grandissimi ragazzi.

Complimenti.

Veramente.

E adesso questo qua è una cosa molto particolare.

Ha sentito la canzone che io ho un gusto musicale pessimo.

A casa mia c'era un sacco di libri, ma non ci era mai musica.

Ma mi hanno detto una cosa molto importante.

Possiamo avere L'ultima slide, per favore? Ancora per un secondo? La canzone che abbiamo appena sentito C' è un membro del team che l'ha cantata davanti a duemila persone.

Ventimila, ventimila persone.

E infatti vuoi dire tu, benedetta, da dove viene la storia? È un attimo di questo concerto.

Si, non so se lo conoscete.

Si chiama Rock in mille.

È un concerto che un gruppo di pazzi organizzato.

Pazzi fan dei Radiohead.

Organizzato perché vogliamo portare in Italia i Radiohead? Perché mi sbaglio? Scusate, fu fighter.

Scusate.

Pessima.

Scusate.

Ok, ricominciamo tutto.

Io non lo sapevo per quello della tua parola no troppo rilassata.

Scusate, fu fighter e quindi hanno hanno organizzato questo questo concerto dove facevano cantare e suonare, compresi gli strumenti mille persone Benedetta era lì e quindi vi chiederei un grosso applauso per Benedetta perché è stata grandiosa.

Prima di lasciare andare Gianluca Omar voglio dire, da dove veniamo ormai mille volte questa domanda costante sacrificio.

Io veramente ci tengo a dire che costanza queste persone hanno lavorato dietro tutta la struttura tecnologica dal giorno zero per tantissimo tempo e noi per primi diciotto mesi.

Gianluca ha impostato tutto con una metodologia molto incredibilmente base fondamentale e al tempo stesso basilare.

Noi ogni fine settimana facciamo uno sprint che è un'analisi uno spray planning c'e' un'analisi di quello che ho fatto da una settimana e pianificare la settimana dopo nella metodologia agile e l'abbiamo impostato di solito si fanno uno sprint sprint landing si fa una volta ogni due settimane per chiaramente prende tempo, ti toglie tempo.

Però noi abbiamo bisogno di essere così agili, ascoltare così tanto gli utenti, riuscire ad applicare quello che voi ci consiglia vate che abbiamo deciso di fare una volta a settimana.

Ma quando tu hai un team estremamente ridotto e non vuoi rubare tempo al tuo sprint alla tua settimana.

Quando lo fai? Quello al sabato mattina per diciotto mesi.

Ogni sabato mattina per tre ore.

Perché parlano all'infinito? Hai capito? No? Eravamo tutti lì.

Noi, noi loro del team tech più altre persone che vi farò vedere quando saliranno.

E io perché ero parte di questo.

Ho imparato per osmosi, ascoltandoli per almeno tre ore ogni sabato mattina a pianificare la settimana dopo.

E secondo me è costante sacrificio.

Queste due persone sono un grandissimo esempio di questo.