Benvenuti su GITBAR, il podcast dedicato al mondo dei fullstack developer.I mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare, nel modo più efficiente possibile, quei prodotti digitali che quotidianamente usiamo.Benvenuti in questo nuovo episodio di GITBAR.Qua a Leone il caldo si fa sempre più forte, speriamo i 40° e credetemi, veramente sto per non farcela più, ma ancora pochi giorni di sacrificio e finalmente potrò godermi il meritato riposo giù in Sardegna, finalmente al mare.Ma ricordatevi che comunque Geetbar non va in vacanza, per cui anche per tutto agosto continueremo ad avere i nostri episodi settimanali.Prima di iniziare però con l'episodio di oggi il mio ruolo è quello di introdurvi i contatti potete iscrivermi a @brainrepo su Twitter oppure a info@gitbar.it via email detto questo possiamo iniziare [sigla] e questa settimana voglio parlarvi per l'ennesima volta di un altro mio side project non entro nei dettagli di quello che il side project fa ma entro invece nello specifico di una fase che ho dovuto affrontare.Ne abbiamo accennato la settimana scorsa parlando di deploy con Michele.Questa settimana invece voglio entrare nello specifico e raccontarvi come ho fatto il deploy di un mio side project PHP qualche giorno fa.Beh le scelte che aveva a disposizione erano diverse.Il primo era deployarlo su uno steam condiviso, la ruba della situazione facendo l'upload via ftp, ma anche no.Il secondo era quello di configurare una macchina virtuale magari con ansible, una vps che poteva stare o su amazon quindi con su un ec2 oppure su un digital ocean o qualunque altro provider e appunto attraverso Ansible avviare e fare uno script di configurazione per poi appunto fare il deploy della mia applicazione.In questo caso diciamo che avrei dovuto gestire un unico server, avrei dovuto farmi tutti i miei script di provisioning ma diventava veramente prolisso, complesso e soprattutto mi ereditavo una complessità in fase di gestione che poi avrei dovuto gestire.L'alternativa era quella di creare un mio container in docker e caricarlo sul server, quindi magari avrei dovuto prendere una macchina virtuale, installare docker, in realtà le macchine già di DigitalOcean hanno delle configurazioni delle immagini già pronte per lanciare un WPS già col docker però avrei dovuto magari gestire un registro privato avrei dovuto fare una configurazione per tutta la cosa del certificato perché comunque questa applicazione esponeva delle API e comunque dovevo verificare di non deployare su questo container anche le configurazioni di dev quindi in realtà anche questo si complicava cosa che si complicava ancora di più quando consapevole del fatto che un unico container non mi sarebbe bastato ma magari avrei dovuto avrei avuto l'esigenza di tirarne un paio uno per esempio per il redis l'altro per il database lo so che molti di voi stanno dicendo che il database non si mette mai sui container però lo stato diciamo è meglio sempre metterlo da parte però diciamo che questa era una potenziale opportunità e in realtà docker compose non era lo strumento adatto per fare questo tipo di azione.Kubernetes diciamo che non mi andava di combattere con pod, servizi, impazzi...no, no non per un side project, non ne valeva la pena gestire un cluster Kubernetes.A questo punto allora l'alternativa era Heroku.Heroku è un prodotto commerciale che ti permette di deployare direttamente dal tuo repository git.Tu metti un profile quindi un file di configurazione, fai una git push a un'origine remota di git che sta appunto sui server di Heroku e poi fa tutto lui quindi capisce di che tipo di applicazioni sta parlando e ti crea in qualche modo l'ambiente per far girare la tua applicazione.C'è da dire però che Heroku pur essendo una soluzione interessante perché in realtà con una riga di codice con un git push tu fai il tuo deploy, il problema di Heroku è che in realtà i costi scalano rapidamente questo è acuito, si sente ancora di più quando si va ad aggiungere degli ulteriori servizi.La soluzione che ho trovato si chiama Doku.Doku è un platform as a service, cioè un sistema che ti permette di realizzare in qualche modo una piattaforma ed esporla come se fosse un servizio.In questa piattaforma noi ci andremo a deployare le applicazioni.Mima in qualche modo il comportamento e le azioni di Heroku, però essendo un progetto open source noi possiamo tranquillamente rilasciare all'interno di una nostra macchina virtuale della quale ne abbiamo il completo controllo.Come vi dicevo è un progetto open source, in realtà si compone di due elementi.il primo è uno script in codice bash lungo circa 200 righe che si occupa della gestione di doku il secondo è una CLI, una command line interface, che ci permette da remoto, quindi dalla nostra macchina, di interagire con questa server remoto, nel mio caso era una macchina digital ocean, per poter rilasciare le applicazioni.Come vi dicevo io questo docu lo ho installato su DigitalOcean e ho scoperto che in realtà direttamente DigitalOcean mette a disposizione un'immagine per poter tirar su davvero con un click la nostra platform AssaService quindi lui tirerà su una macchina virtuale con dentro doc installato pronta per essere utilizzata.Quindi setup super semplice e abbiamo subito il nostro ambiente dove possiamo deployare le applicazioni.Cosa facciamo a questo punto? Attraverso la command line interface noi non facciamo altro che creare una nuova applicazione e quando lanciamo il comando per creare una nuova applicazione ci verrà restituito un endpoint git, un origine git.Noi basta che facciamo una push all'interno di questa repository e automaticamente cosa farà doku? Doku capirà di cosa si parla.Pensate che noi faremo naturalmente una push senza pushare le dipendenze.Per cui dal file nel caso si tratti di un progetto php dal file composer.json o dal file package automaticamente verranno estratte le dipendenze installate verrà creato un ambiente consono a quello al linguaggio e al framework che noi vogliamo far girare.Basterà in questo caso aggiungere un semplice proc file che indica a doku come lanciare l'applicazione e a questo punto abbiamo deployato.E infatti la cosa è molto molto interessante perché ci permette di fare un deploy senza nessun tipo di frizione.Funziona esattamente come Roku quindi, che era una cosa che ho apprezzato tantissimo ma costa molto molto meno, specie per un side project.Questo perché in realtà i costi di Heroku scalano alla velocità della luce.Quando un pochino si cresce, magari si vuole avere una macchina attiva, sempre attiva, perché dovete sapere che Heroku dopo un tot di tempo di inattività, ammazza i container della vostra applicazione, per cui alla successiva richiesta c'è una sorta di delay dovuto al tirar su quei container che hai ammazzato.questo lo risolvi se paghi e loro ti tengono attivo sempre il container in questo caso noi avevo una macchina ho installato doku il container della mia applicazione deployata in realtà adesso ne possiede più di una rimane sempre attivo per cui la mia applicazione è sempre reachable contattabile e risponde in modo abbastanza veloce Per interagire con Doku, come vi dicevo, c'è una command line interface.In realtà è disponibile anche un'interfaccia grafica, si chiama WARF.Spero di averlo pronunciato bene.La trovate nelle note degli episodi, insieme naturalmente a due righe e due informazioni su cose Doku e come andarlo a installare.E ci permette la gestione delle nostre applicazioni anche attraverso l'interfaccia grafica.La cosa interessante in realtà di Doku è il suo ecosistema di plugin.In realtà esistono davvero tanti plugin molti dei quali si occupano di gestire lo stato.Per esempio installando un semplice plugin si ha la possibilità di avere direttamente un server Elasticsearch o un MySQL, un Postgre, un Redis, Rabbit...Insomma tutti questi sistemi che ti permettono di gestire le code o di gestire lo stato.Ma in realtà tra questi plug-in io naturalmente ho utilizzato MySQL che tra l'altro, una cosa molto molto interessante, mette a disposizione una command line interface per farci un sacco di cose.Una dei quali è quella di schedulare i backup.backup che vengono fatti in momenti specifici e che vengono salvati direttamente all'interno di S3 di Amazon.Quindi avete praticamente a seconda della time window che voi impostate avete direttamente i backup salvati sul vostro bucket S3.Veramente veramente interessante e questo database si può connettere in modo molto molto agevole all'interno dei vostri progetti deployati su Doku un altro plugin che sto usando in realtà è quello di Let's Encrypt che permette per l'endpoint quindi per la vostra applicazione deployata su Doku di avere direttamente un dominio basterà che dalla vostra configurazione DNS voi facciate puntare la macchina virtuale dove è installato l'ip della macchina virtuale dove è installato doku a questo punto lanciate un comando e quindi installate il plugin di let's encrypt lanciate un comando per la generazione di certificati per la vostra applicazione e in pochi istanti veramente avete l'end point della vostra applicazione protetto da https con un certificato rilasciato appunto da Let's Encrypt in modo veramente frictionless.In realtà non è così facile avere delle web application che girano su container protette da certificati specialmente in PHP.In realtà Doku ti permette veramente in pochi istanti di raggiungere questo risultato.Un altro plugin che sto utilizzando che è molto interessante quello di manutenzione ti permette infatti di disattivare o mettere in manutenzione una certa applicazione mostrando naturalmente una pagina di manutenzione semplicemente con lanciando un comando quindi diciamo che in qualche modo modo Doku semplifica il deploy di piccole applicazioni rendendole appunto disponibili subito e appunto facendo eliminando gran parte dei mal di testa allo sviluppatore che vuole fare solo lo sviluppatore e non occuparsi di operation.In realtà però Doku ha dei limiti uno dei quali è che in realtà scala solo verticalmente questo vuol dire che docu girando all'interno di una macchina virtuale l'unico modo che hai per scalare questa macchina è quella di aumentarla quindi aumentare la memoria aumentare la potenza del processore per cui diciamo che non si presta un approccio moderno di applicazioni che vogliono scalare in modo frictionless senza frizione perché in realtà l'unico modo che hai per scalare orizzontalmente quindi su più macchine è quello di montare un web balancer davanti, proteggere in questo caso l'ingresso con HTTPS, avere così più macchine che fanno girare Doku però a quel punto bisogna fare il deploy su ognuna delle macchine su ognuno dei nodi che fa girare Doku quindi complicando ulteriormente la modalità di rilascio e l'architettura che contiene la nostra applicazione quindi perdendo quelli che sono i vantaggi di un deploy semplice di questo tipo.Partire con Doku mi ha permesso di fare il deploy dell'applicazione in tempi veramente veramente minimi salvo poi però rendermi conto che in realtà questo site project sta iniziando ad avere un pochino d'accesso e per come è formato per cui ha bisogno di delle capacità computazionali un pochino più elastiche rispetto a quello che docu mi mette a disposizione a questo punto siccome già lo uso abbondantemente in ambiente javascript ho pensato a una soluzione serverless che mi dà il vantaggio di pagare solo quello che uso quindi solo le chiamate effettive e non mi dai mal di testa di dover configurare linux applicare patch e fare mille casini e mi permette appunto alla mia applicazione di girare in container isolati tanti container quanti sono necessari dal numero delle chiamate non mi soffermo tanto sulla tecnologia serverless perché ne ho già parlato in un altro episodio quando ho parlato del serverless framework in javascript.Però mi fermo per un secondo a ragionare su come funziona più o meno Amazon Lambda.Cosa succede? Quando io deploio una lambda function quindi rilascio una lambda function immaginiamo questa funzione come se messa in un container con tutto quello che gli serve per girare a questo punto quando arriva una chiamata sia essa da un endpoint di API gateway sia essa da un evento oppure da un timer oppure da altre 70.000 trigger disponibili automaticamente il mio codice viene eseguito e viene lasciata una risposta.Contestualmente però questo container, chiamiamolo così, rimane attivo per circa 10 minuti.Se non ci sono delle altre chiamate AWS lo killa direttamente, quindi lo uccide.E questo è uno dei motivi per cui lo Stato non può assolutamente stare all'interno di questi container.Ma se prima dello scavere dei 10 minuti c'è un'altra chiamata, verrà chiamato il container disponibile precedente.Questo fa sì che si riducano i tempi di "avvio" del container e renda tutto molto più rapido.Detto questo, quello che a me serviva era utilizzare questa tecnologia per questo progetto PHP, che è un progetto molto semplice, sviluppato con l'Aravel.Peccato che all'interno di AWS nel servizio lambda non esiste nessun supporto di PHP né normale né usando il serverless framework e questo mi suona ironico anche perché il PHP è uno di quei linguaggi che si presta perfettamente a questo tipo di struttura perché ha di per sé all'interno di come è stato concepito il meccanismo di richiesta-risposta.A differenza di altri linguaggi come può essere javascript per cui si mette in piedi per realizzare appunto un sistema serverless, si mettono in piedi tutta una serie di sfide architetturali.Un'altra cosa che mi spinge a dire che sembra quasi uno scacco, un gioco, fatto una presa in giro il fatto che non sia disponibile il php su lambda e che php abbraccia pienamente il concetto di share nothing perché ogni richiesta ogni flow di richiesta risposta fatto in php non condivide niente con il precedente e tanto meno con il successivo per cui ogni richiesta e risposta in qualche modo sono isolate però diciamo che i programmatori php non si sono fermati davanti all'ostacolo ma hanno messo in piedi tutta una serie di strumenti che ti permettono di far girare il php su amazon lambda.come fanno? come possono farlo? possono farlo utilizzando uno strumento specifico di AWS lambda e si tratta dei layer.Cosa sono i layer? I layer dobbiamo immaginarli come degli strati, fondamentalmente come delle cartelle che contengono qualcosa.Ogni funzione lambda può avere fino a 5 layer e ognuno di questi layer può essere grande fino a 150 megabyte.Per cui all'interno è possibile mettere il runtime che ti permette l'esecuzione e magari utilizzando che ne so una lambda function in node chiamare il runtime php ed eseguire del codice php ce ne sono davvero tanti esempi su come poterlo fare pensate che attraverso l'uso di questi di queste cartelle zippate che poi vengono iniettate all'interno dei container che fanno girare la nostra funzione lambda c'è qualcuno che ha provato a far girare persino il cobol quindi veramente c'è di tutto però quello che io cercavo in realtà e il mio obiettivo era quello di deployare la mia applicazione php e cercavo anche qualcosa che mi rendesse più semplice l'utilizzo di lambda nel progetto ma che mi semplificasse in qualche modo l'estensione di questo progetto e lo sviluppo qualcosa che fosse in qualche modo opinionato quindi che mi guidasse nelle scelte anche perché quello che ho trovato che avevo trovato fino ad allora erano solo come poter creare il layer con un runtime specifico magari usando immagini AMI di Amazon insomma una cosa particolarmente complicata quindi cercavo qualcosa di semplice che mi guidasse attraverso alcune scelte e cercavo anche qualcosa che mi permettessi di utilizzare le competenze in ambiente serverless e lambda che già avevo che erano quelle del serverless framework possibilmente anche con una buona documentazione insomma chiedevo quasi l'impossibile in realtà non si trattava di impossibile perché ho trovato qualcosa si chiama bref che vuol dire breve in francese ed è sviluppato da metieu napoli tra l'altro cosa simpatica che anche lui è uno sviluppatore e anche lui vive a lione.Che cos'è bref? bref è un package di composer che ci aiuta a rilasciare le nostre applicazioni php e quindi a farle girare appunto dentro le lambda.Utilizza il serverless framework per la configurazione e il deploy.Il serverless framework come vi dicevo ne abbiamo già parlato adesso non ricordo se era la puntata 15 forse, vediamo un po' giusto per dare i riferimenti, era la puntata numero 14 e in quella puntata vi ho detto che il serverless framework attraverso un file di configurazione ci permette di realizzare, di progettare la nostra piccola infrastruttura e di dire come le lambda devono essere eseguite, infrastruttura che viene in qualche modo trasformata in codice cloud formation date in pasto ad amazon che tira su tutto l'ecosistema e permette alle nostre funzioni lambda di girare.Anche utilizzando magari degli altri servizi propri di AWS.Un esempio può essere tirarsi un bucket S3 per andare a salvare delle immagini, insomma e via dicendo.La cosa interessante è che con bref bref utilizza il serverless framework ma a questo ci attacca un layer con un runtime che invece è gestito da meteo napoli che lo rilascia.Fino ad ora i runtime disponibili sono quelli che vanno dalla PHP 7.3 fino al supporto sperimentale di PHP 8 quindi è veramente veramente interessante questo possiamo rilasciare delle funzioni direttamente all'interno di Amazon AWS attraverso lambda in PHP 8.Quali sono gli use case tipici di bref? Beh, use case sono due come ha detto metti un Apple in una conferenza.La prima è adattare il tuo codice PHP a lambda.Cosa vuol dire? Che conosci più o meno come si comporta lambda e come si comportano il runtime PHP e quindi scrivi la tua app sotto forma di funzione.È il modo migliore per usare Amazon lambda.Trasformare la tua applicazione in un set di funzioni ognuna che fa qualcosa di specifico.L'alternativa è adattare lambda al tuo modo di scrivere php.Quindi cosa succede? La tua lambda utilizzerà il tuo container, diciamo, utilizzerà phpfpm per far girare i framework che già conosci all'interno di AWS Lambda.Questo tipo di azione vi permette per esempio di far girare Laravel o Symfony all'interno di una Lambda.Vero è che non è il migliore modo per utilizzarle perché sia Symfony che tanto più Laravel sono dei monoliti.Symfony più o meno dopo il Symfony 4 si è andata a snellire di quelli che sono gli elementi che lo rendevano monolita però comunque l'approccio che vedo spesso dei programmatori che utilizzano questi tipi di framework è un po' un approccio anche se a microservizi a fare dei microservizi un pochino cicciosi invece in questo caso è possibile deploiarli direttamente in una funzione lambda insomma un approccio in stile lambda as a web host esattamente come come deployavamo sull'ftp di aruba così possiamo fare direttamente dentro una una lambda quindi questi due approcci sono possibili appunto grazie al runtime php prima vi ho parlato di runtime in realtà il runtime come vi dicevo non è uno ma ma ci sono tre tipi diversi di runtime tipi che permettono, espongono diciamo versioni di PHP che vanno dalla 7.2 alla 8 che il cui supporto è sperimentale il primo tipo di runtime che si chiama PHP è quello diciamo più semplice e funziona un po' come funziona il PHP prima vi ho detto no che il concetto di PHP è un po' un concetto basato su richiesta risposta sulla non condivisione, appunto, sull'esecuzione isolata del processo richiesta risposta.Beh, e questo è.In realtà noi andremo a scrivere il nostro codice come se si trattasse di una funzione.Questo è utile in contesti dove non stiamo sviluppando delle applicazioni HTTP.L'alternativa, l'altro runtime interessante, è quello che si chiama PHPFPM.Che cosa fa questo runtime? Non fa altro che usare PHP FPM per andare a far girare un'applicazione HTTP dentro l'Amazon Lambda.Infatti PHP FPM gira all'interno della Lambda e quando arriva una chiamata a quell'endpoint, immaginiamo un endpoint esposto con API Gateway, quindi quando noi entriamo su quella pagina la nostra chiamata passa attraverso API Gateway e arriva alla nostra funzione lambda.Quando arriva la funzione lambda abbiamo "bref" che fa da "bridge" e quindi va a convertire l'evento di API Gateway che arriva appunto da API Gateway e lo traduce affinché PHPFPM lo capisca e possa far girare il nostro script.Quindi lo tradurrà in fast cgi protocol che è un protocollo di comunicazione tipico che si utilizza tra server e applicazione quindi cosa fa arriva una chiamata attraverso i pi gateway io ho il mio runtime php fpm c'ho bref dentro bref cosa fa converte l'evento e lo dà in pasto all'applicazione in modo che questa appunto possa capire il terzo runtime è quello di console per chi chi utilizza e sviluppa applicazioni symphony o laravel è una cosa particolarmente utile quante volte ci si trova davanti all'esigenza di dover eseguire dei comandi a terminale che abbiano accesso magari alle risorse della nostra applicazione che eseguono degli script interni della nostra applicazione basta immaginare appunto la symphony console o il comando di laravel artisan che ci permettono che ne so di fare immigrazioni nel database e di fare svuottamenti di cache permettono di fare tante altre cose volendo anche dei comandi personalizzati beh metti un appogli ha realizzato anche in questo caso un terzo runtime che ci permette l'esecuzione di questi comandi oltre a questo runtime in realtà bref espone anche un'utilità una command line interface che ci permette di eseguire dalla nostra macchina il comando direttamente sulla lambda che si trova appunto dentro AWS.Per cui noi con un semplice comando quindi vendorbin, brev, cli e diamo il nome della funzione, il comando da eseguire, automaticamente stiamo eseguendo questo comando che solitamente tendiamo a eseguire in locale oppure eseguiamo connessi sotto forma di ssh al server che hosta la nostra applicazione PHP, beh questa volta l'eseguiamo direttamente all'interno della nostra funzione serverless.Deployare l'applicazione Laravel o Symfony all'interno di una lambda function, beh, a questo punto crea un contesto dove noi possiamo parlare di monolith lambda pattern, cioè un'applicazione che ha un unico endpoint API gateway e poi è l'applicazione che divide a seconda del path dell'url alla quale si sta accedendo poi a di vari controller quindi tutto a quella parte di complessità viene delegata al framework sottostante quindi non è più API Gateway che la prende in carico ma la gira alla nostra applicazione.Però spesso le nostre applicazioni non sono solo delle API da servire.Spesso le nostre applicazioni per esempio hanno bisogno di asset che nel caso di un deploy così su lambda function non possono stare dentro le lambda perché aumenterebbero i costi e soprattutto tenete presente che le lambda sono dei container volatili quindi se non ci sono altre chiamate dopo dieci minuti vengono uccisi per cui rischiereste di perdere gli asset.A questo punto per gli asset è il caso di utilizzare magari il servizio S3 per andarli a salvare in modo definitivo e magari esporli sul web utilizzando un altro servizio di Amazon che si chiama CloudFront e che ci permette di rendere pubblico un accesso e soprattutto distribuirlo geograficamente, distribuire geograficamente quegli asset e magari anche proteggerli con HTTPS, proteggere appunto le chiamate con HTTPS.Quindi questo è diciamo il pattern che si utilizza per risolvere questo tipo di problema.Un altro problema sono le sessioni.Le sessioni nel caso di un'applicazione deploiata dentro una lambda function non possono stare sotto forma di file all'interno della lambda stessa per lo stesso motivo di cui vi parlavo prima per cui in quel caso le sessioni sarebbe il caso di salvarle nei database oppure magari su un'istanza di Redis che ci permette di una gestione molto più più rapida e snella.Un altro problema che risolviamo in modo molto semplice sono i log anche questi vengono scritti solitamente dentro una cartella nella applicazioni però a noi basterà semplicemente andarli a scrivere nello standard error output con una semplicissima configurazione che si mette con tre quattro righe di codice sia su laravel che su su symphony e automaticamente anche qua i nostri log saranno disponibili direttamente su cloud watch di AWS per cui visibili direttamente là con tutta una serie di vantaggi come per esempio gestire degli ascoltatori attivare delle lambda in funzione di questi log e quant'altro quindi in realtà in qualche modo è un queste poche configurazioni che dobbiamo fare per deployare la nostra applicazione dentro la lambda in qualche modo ci avvicinano verso un ragionamento un po meno monolitico pur continuando ad avere appunto questo monolita applicazione che gira dentro la nostra lambda function.Il poter deployare un'applicazione symphony/laravel dentro una lambda function perché è interessante? Beh non tutti siamo portati mentalmente a sviluppare applicazioni frammentando le in funzione in funzioni quindi con un approccio così cloud native per cui questo questo tipo d'approccio che bref porta oltre a diciamo permettere un utilizzo quasi da da da hosting provider, diciamo così, per le lambda permette anche a coloro che di lambda ne hanno visto poco o niente di avvicinarsi a questo mondo.Tanto che Bref è semplicissimo per cui deployare all'interno di una lambda diventa veramente semplice e questo può aprire le porte per l'esplorazione di un nuovo approccio di deploy che è quello cloud native dove serverless e microservizi sono gli attori principali.è tutto oro quello che lucica? beh no.l'utilizzo di PHPFPM per far girare la nostra applicazione symphony o l'aravel all'interno di una lambda introduce alcune problematiche.una di queste è chiamata cold start.Cosa vuol dire? Quando noi facciamo una chiamata che passa attraverso API Gateway che è il servizio appunto che ci permette di esporre le nostre lambda function su un endpoint, un url, a quel punto non esiste nessun container che sta facendo girare la mia lambda e c'è la necessità di avviare questo container.Se devo avviare questo container e dentro questo container deve avviarsi PHP e FPM.A questo punto i tempi di avvio si allungheranno.Si allungheranno e questa fase di tempo d'avvio viene chiamata cold start, quindi partenza a freddo.Perché questo? Perché in realtà, come vi dicevo prima, se io faccio una chiamata, termino la chiamata, AWS Lambda tiene attivo il container per 10 minuti.Quindi se io in meno di 10 minuti faccio un'altra chiamata non c'è bisogno che riparta tutto ma questo calcolando questo cold start in applicazioni medie metti un app e li dichiara che si aggira attorno allo 0.5 per cento del tempo di risposta quindi questo vuol dire che se devo utilizzare symphony magari dentro un lambda per applicazioni in real time beh forse l'avvio del runtime l'avvio di lambda forse non è il caso di utilizzare questa tecnologia ma per tutti gli altri casi d'uso beh a questo punto lo 0.5 per cento medio del tempo di risposta è diciamo il minore dei mali immaginiamo un e-commerce che ha picchi di utenza con un approccio normale se si aveva la necessità magari che la nostra infrastruttura scalasse e magari ci metteva diversi secondi oppure se non avevamo un'infrastruttura configurata per poter scalare magari crashava o non serviva le risposte.In questo caso lo 0.5 per cento di cold start è quasi impercettibile e la nostra applicazione potrà continuare a servire le richieste.Una cosa però importante da gestire quando si ragiona in termini di lambda è la relazione tra memoria e tempi di risposta.In realtà questa relazione non è necessariamente lineare.Metti un appolo infatti in una conferenza che è quella del PHP Barcelona che allego alle note dell'episodio mostra un chart, una tabella dove ci sono i vari tempi di risposta di una Hello World application, quindi un'applicazione che serve semplicemente Hello World a seconda della memoria che noi stiamo allocando alla nostra lambda function per una pagina per una risposta in php accent con 128 mega di di di memoria ci mette 10 millisecondi con symphony che deve buttare tutta la sua architettura ce ne mette 58 con 512 mega di ram ci mette un millisecondo e su symphony ce ne mette 4 4 4 millisecondi sono veramente impercettibili nel contesto della nostra applicazione come tempo di boot ma se noi portiamo la memoria a 1 giga questi tempi non diminuiscono rimangono sempre 1 millisecondo per la nostra applicazione di Hello World e 4 millisecondi per la nostra applicazione di HomeSymphony cosa vuol dire questo? Questo vuol dire che questo millisecondo per la mia applicazione e questi 4 millisecondi per la mia applicazione di Symphony, su Symphony, sono il concetto di cold start.Quindi il tempo che la mia Lambda Function mette per fare il setup e il boot di tutto l'ecosistema, il contesto per far girare appunto la mia funzione.per cui anche qua la nostra lambda function deve essere tarata con un pochino d'attenzione per appunto essere performante.Ma la domanda che io mi faccio è 4 millisecondi nel contesto di un'applicazione comune, di una web application che sviluppiamo, che cosa sono? Quanto incidono questi 4 millisecondi sulla vera velocità della nostra applicazione? Quindi in realtà forse parlare di cold start è un po come nascondersi dietro magari a un dito e usarlo come scusa quando invece potremmo migliorare le performance delle nostre applicazioni magari agendo su alcune scelte all'interno della della della code base.è veramente veramente interessante bref e ci introduce e aiuta introdurre gli sviluppatori php al mondo serverless.Devo dire che ci sono altre architetture che già supportano nativamente il php.Una di queste è OpenWiz che ne abbiamo parlato la precedente puntata con Michele Schiavarra.Questo approccio serverless non solo per le funzioni è molto interessante.Intanto ci permette veramente di gestire meno cose, scalare di più e pagare quello che ci serve sia in termini di tempo che in termini di spazio.Ed è veramente interessante come questo tipo di approccio si stia espandendo in altri contesti non solo nell'esecuzione di codice.Basti pensare a servizi come Cognito o come Auth0 che ci permettono di avere un'autenticazione as a service.Servizi come S3 che ci danno lo spazio as a service o servizi come Algolia che arrivano a offrire appunto dei servizi di search as a service.Amazon tra l'altro si sta dedicando tantissimo al mondo della persistenza dello stato as a service, un servizio che sta andando molto di moda è DynamoDB il servizio NoSQL che appunto si paga per il tempo che lo si utilizza e per la memoria che occupa e ha introdotto i servizi come Aurora Serverless che permettono di far girare e di utilizzare database compatibili con MySQL, Postgre, direttamente in modalità serverless.certo serverless è un approccio che sta prendendo sempre più piede ma rimane sempre presente l'utilizzo continuo di architetture e di framework che sono un po delle contraddizioni.Basti pensare che far girare l'arabel dentro una lambda può sembrare davvero una contraddizione ma una contraddizione che evidenzia un elemento importante che i programmatori non vogliono interessarsi sull'infrastruttura.Ma come dicevamo la precedente puntata vogliono essere concentrati il più possibile sulla logica di business che è quel tipo di logica che genera valore per la società.Il mondo, tanto più il mondo delle startup, ha bisogno di creare quelle applicazioni senza dover perdere tempo a pensare e sviluppare sistemi di autenticazione o sistemi di routing ed è è qui che il mondo serverless viene in aiuto.Naturalmente portando con sé anche dei lati negativi uno dei quali è il concetto di vendor lock-in anche questo l'abbiamo citato e ne abbiamo parlato con Michele la settimana scorsa.Per cui gli sviluppatori vogliono essere più dev e meno ops e quello che dal mio punto di vista si andrà sempre di più sviluppando sarà un approccio di infrastructure as a framework.Quello che i framework fanno non è altro che metterci a disposizione una serie di utilità che verranno poi sostituite e che vengono nel caso appunto del serverless sostituite dall'infrastruttura.Faccio un esempio.Quanti di noi utilizzano il routing delle applicazioni scritte in Laravel o scritte in Symfony? Tutti.Ma se sviluppiamo le nostre applicazioni sotto forma di funzioni PHP e le deploiamo su lambda, probabilmente il routing lo deleghiamo a API Gateway.Il messenger, basti pensare alle librerie di messaging all'interno dell'applicazione, potremo tranquillamente delegare tutta quella complessità all'infrastruttura.Per cui cosa diventeranno i framework? I framework diventeranno la colla tra l'infrastruttura e la nostra logica applicativa.Secondo me questo è il futuro dei framework.Speravo di fare una puntata breve ma in realtà ho visto l'orologio e mi sono dilungato tantissimo.credetemi contavo davvero di farla breve questa puntata spero vi sia piaciuta prima di lasciarvi e darvi appuntamento alla prossima settimana vi ricordo rapidamente i contatti potete scrivermi @brainrepo su twitter oppure via email a info@gitbar.it naturalmente se l'episodio vi è piaciuto aprite la vostra applicazione che utilizzate solitamente per ascoltare i podcast e iscrivetevi facendo così riceverete settimanalmente le notifiche sui nuovi episodi.Se poi vi è piaciuto davvero tanto beh potete lasciare una recensione su iTunes.Per qualunque cosa non esitate a scrivermi.Prima vi ho detto l'handle twitter e l'indirizzo email per cui iscrivetevi pure io vi risponderò nel minor tempo possibile.detto questo noi ci diamo appuntamento alla prossima settimana da lione ancora per poco tempo è tutto ciao gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brain repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e degli strumenti mancabili nella cassetta delle attrezzi dei Full Stack Dev.[Musica] [SILENZIO]
