Gitbaritalian
developer
podcast
14

Programmazione o infrastruttura. La mia esperienza con serverless e Lambda

Serie 1
Episodio 14
Durata 26 minuti

Quando sviluppiamo le nostre applicazione spendiamo tanto tempo nello sviluppo dell'infrastruttura. Dovremmo investire più tempo nella logica di business o nel provisioning dei nostri server? In questo episodio ho parlato di BaaS e FaaS, serverless e amazon lambda e di come sto realizzando il sistema automatico di trascrizione degli episodi del podcast senza i mal di testa e costi dati da docker e kubernetes.

Link

Contatti

@brainrepo su twitter o via mail a info@gitbar.it

Crediti

Le sigle sono state prodotte da MondoComputazionale Registrato negli studi di Radio Nuoro Centrale Le musiche da Blan Kytt - RSPN e Broke For Free - Something Elated

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

benvenuti su bar di podcast dedicato al mondo dei full stack developer di mezzo artigiani mezzo artistiche ogni giorno infilavano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.
Bene, Benvenuti! Questa è la quattordicesima puntata di Bari, il podcast dei funghi developer italiani e oggi ho tante novità da raccontarvi, in primis il nuovo sito E' online www it' e avrete modo di accedere alle informazioni di tutti gli episodi.
Ci sto ancora lavorando, però intanto è già online e sta iniziando a prendere forma.
È una applicazione progressiva, una progressiva.
Quindi potete aggiungerla alla home del vostro dispositivo e rimanere sempre aggiornati.
Per ora è attiva solo la funzione offline, quindi anche se perdete la connessione, avete aperto un articolo all'interno del sito.
Beh, potrete continuare a leggerlo per ora.
Insomma, ho implementato questa funzionalità e poi avete le varie puntate dove potrete ascoltarle e mandare un capitolo specifico per quello.
Il di Brickell per ora finche' non sviluppato uno tutto mio e sto continuando a lavorare per inseguire delle nuove funzionalità l'ho sviluppata, come vi avevo detto con Gatsby.
E devo dire che l'utilizzo di quel framework per lo sviluppo di siti statici mi ha entusiasmato per le realtà i dati li vada a prendere dalle per ora che vengono generate tutta una serie di pagine che sono la pagina per il bisogno.
Sto però questo periodo lavorando a una nuova funzionalità che è quella dei trans cry.
Per farla ho dovuto mettere le mani su una nuova tecnologia, anzi, più che un di una tecnologia su un nuovo approccio allo sviluppo delle applicazioni.
Ma ve ne voglio parlare subito dopo avervi salutato e ricordati i nostri contatti potete entrare in contatto con me e quindi a non convince bar scrivendo mia è trovare il repo oppure a in it' mi raccomando, fateci sapere le vostre opinioni.
Se avete anche qualche tecnologia in particolare che volete approfondire, siamo sempre disponibili a nuove, a nuovi dall'esterno e altra cosa importante e mi raccomando, iscrivetevi nel podcast con il vostro client podcast preferito, quindi cercate bar e cliccate sul pulsante più in modo da rimanere aggiornati sui nuovi episodi che settimanalmente escono.
Comunque, detto questo, possiamo partire.
Ormai sono davvero tanti anni che sviluppo e ricordo quando i primi anni pubblicava ricorda ancora le pagine su Aruba Chi è che ne ha mai fatto uso.
Penso che siano ancora in tanti quelli che utilizzano i servizi hosting di Aruba.
Poi però mi sono evoluto e ho iniziato ad acquistare servizi che mi permettessero di avere delle macchine virtuali dove ci andava installare la mia mio stack lampo, quindi quelle php.
E questo è durato per tanto tempo.
E piano piano che ciò che ho preso più confidenza con le tecnologie e ho iniziato a utilizzare va grant che con dei file di configurazione in automatico, come faceva il provisioning della macchina dapprima su macchine virtuali che giravano con VirtualBox nel mio computer per poi arrivare a lanciare dei comandi direttamente dalla grande.
Quindi lanciato.
Il provvigione indirettamente dava gran remote che ospitava digital ossea.
Naturalmente la tecnologia si è evoluta tirare su una macchina con va.
Grant presupponeva di avere a disposizione tanto tempo libero perché il provisioning non era poi così veloce visto che andava installato il sistema operativo allora da prima in ambiente di development e poi in ambiente di Stagg, per poi arrivare nei mezzi di produzione e ho iniziato a utilizzare.
Devo dire che l'esperienza con doc è stata bellissima perché molto tempo perso a scrivere i file di configurazione, per esempio quelli di vagante, veniva completamente eliminato da un sacco di file disponibili dalla comunità che potevi riutilizzare i famosi fai che potevi di utilizzare per fare appunto in modo molto rapido nel settore dei container.
Però quando ho iniziato a sviluppare delle applicazioni che insomma ci sono un po' complicate l'esempio era appunto di politica, un servizio di media che ho lanciato qualche tempo fa.
Mi sono reso conto che forse lo il deploy di servizi un pochino articolati con una orchestrazione di tipo da prima con un composto orribile.
Però devo ammetterlo, sono andato in produzione pomposa, poi con un broker, suor Mary per per arrivare a tirar su mi portava via un sacco di tempo.
Io non sono un grande appassionato di operations, quindi sì, devo ops per esigenza, ma non ne vado pazzo e sono andato a cercare per un nuovo servizio che voglio lanciare una soluzione e cercando una soluzione mi sono avvicinato al mondo il nuovo servizio che voi vorrei lanciare un servizio di trascrizione automatica per podcast, quindi inserisci il tuo feed RSS automaticamente Hai un servizio che ti genera i transcript Non è niente di speciale e voglio fare un esperimento col mio podcast per poi vedere se ha senso lanciare un prodotto commerciale.
Però mi rendo conto che tirare su un'infrastruttura con container per stare di nuova fare le battaglie con l'orchestra e' superfluo, tanto più che superfluo nella fase in cui mi trovo, cioè quella di realizzare uno script che lo fa per me, per il mio podcast per bar.
Quindi mi sono avvicinato al mondo e ho scoperto veramente una serie di molto interessanti che vi voglio condividere.
Quando si parla di si parla in realtà di cose diverse e per capirlo è necessario fare due passi indietro.
Infatti il nome risale a diversi anni fa, attorno al duemila dieci, quando ci fu la trasmigrazione dai servizi.
Un premi quindi installati all'interno dell'azienda a servizi che si trovavano sui server remoti di prestatori terzi.
Un esempio è appunto il passaggio dei depositi di codice da i propri repository o un premi sai servizi come GitHub, oppure tutti i servizi di sì ai che attorno al duemila dieci hanno fatto, appunto, sono apparsi nel panorama della tecnologia per le aziende.
In realtà, però, la parola Charles appare attorno al duemila quindici, quando Amazon lancia nei suoi servizi e Ida la funzionalità il servizio landa, infatti, questo servizio smuove le acque, inizia a dar vita a un movimento chiamato Movimento che fa la prima conferenza attorno al Duemila sedici.
Però adesso abbiamo fatto un po' di storia, ma entriamo infonde proviamo a capire che cos'è la realtà quando si parla di in realtà ci si può riferire a due elementi diversi.
Il primo è il backend service bassa, il secondo è il service già nella puntata precedente, quindi nella tredicesima quando vi ho parlato di Graff, quel che ho detto anche che il duemila quindici è stato un anno che ha visto questa esplosione così potente delle api bene sempre duemila quindici è stato anche l'anno che ha visto la nascita di questi servizi di backend.
In realtà qual era il concetto che stava alla base se aveva la necessità di tirar su delle applicazioni da poter pubblicare negli store in modo molto rapido, degli inviti che potessero andare in produzione in tempi super contenuti? Per farlo bisognava concentrarsi sugli elementi che sono quelli attività all'interno del, per cui si è sentita la necessità di delegare la gestione la allo sviluppo di tutta la parte infrastrutturale a servizi terzi.
Ed ecco che nella scena sono apparsi servizi come Parsa o come Google fai Bays, che mettevano a disposizione dei servizi di storia legge di gestione degli utenti, di gestione delle funzioni, quindi di logica e di logica, di processo e delle gestioni di notifiche direttamente in server gestiti da terzi, senza la necessità di fare provisioning o di gestirne la sicurezza.
Questo è stato senza dubbio una grande rivoluzione, una grande rivoluzione, anche spinta dalle esigenze di questi piccoli di queste piccole api di avere un backend semplice, non complesso, perché tutta la complessità, in realtà di tipo processo, veniva spostata sul demandata sul Klein, alleggerendo il server di tutta la parte di renderti dell'anima dell'applicazione di attività.
Se aveva questo punto semplicemente di leggere e scrivere dei dati poco più di questo.
In realtà in questo caso noi stiamo parlando di quindi società che mettono a disposizione tutta una serie di servizi facilmente accessibili, spesso attraverso delle gay che si possono includere nel codice sorgente delle applicazioni per avere un accesso ancora più semplificato a questi servizi e nulla e in pochissime righe di codice si può andare in produzione.
Alcuni di questi esempi sono per esempio Google Bays, dove ci sono delle librerie Giava, Scripta o il linguaggio nativo, quindi sui per accedere direttamente ai servizi di Google per fare lo store per gestire gli accessi.
La stessa cosa ha fatto Amazon, lanciando il servizio e gli che fa la medesima cosa offrendo sempre queste librerie che ne semplificano l'accesso e l'utilizzo.
Di queste funzionalità e di queste di queste impalcatura anche strutturali, di quelli di questi servizi che il provider mette a disposizione.
Un altro era ormai il defunto apparse, dico defunto, ma non è poi così defunto.
Perche' nasce come servizio service ed e' un servizio molto potente e molto seguito, solo che ne è stato poi dismesso come servizio a pagamento e adesso però è sempre presente in una sua versione open-source installabile con i vari moduli e gestito da una comunità che ho visto, devo dire non lo guardavo da tempo per preparare questa puntata.
Un occhio visto abbastanza attiva.
Questo è un approccio, un punto di vista del mondo.
Punto di vista è appunto il concetto di fanfiction service.
Con il termine fast invece si identifica tutta una serie di servizi che permettono del codice il server terzi revisionati da terzi gestiti da terzi, dove noi semplicemente concentriamo tutti i nostri sforzi su un unico elemento che la nostra logica applicativa.
Quindi in realtà non dobbiamo più pensare alle infrastrutture per pensare all'infrastruttura.
Ci sono tutta una serie di tecnici dedicati che la il fornitore di servizi ci mette a disposizione.
Esperti di sicurezza, esperti, sistemisti, ops, superski, Pillati.
Dobbiamo semplicemente mettere il focus sul nostro codice, sulla nostra logica di business, la nostra logica applicativa.
Una cosa molto interessante che entra in gioco quando si realizzano dei prodotti.
E ve lo dico perché ne ha avuto esperienza.
È quella che, almeno in una fase iniziale dove non si può monetizzare da subito, ma si sta andando a tirar su un il costo e' uno dei magazzini di costruire in dei dei vincoli maggiori in fase di realizzazione che ha avuto con la platform di media che abbiamo lanciato politica Bennett è stata quella, insomma, di di di, di essere quasi stritolati da dei costi iniziali l'abbia lanciata su cui no.
Quindi abbiamo fatto partire tutto su un piccolo cluster classe che aveva già solo di startup dei costi perché era necessario un nodo master che potesse gestire poi tutti i nodi dove andavano a girare i nostri container, tra l'altro presupponeva o di conoscenza, di cui la cui curva d'apprendimento non è poi morbida e soprattutto partiva da un concetto principale che quello della capacità riservata.
Quindi in realtà il concetto di Cabernet, se è quello di avere tutta una serie di macchine che possono anche essere delle macchine virtuali dove girano appunto i tool che permettono al cluster di vivere e poi i miei diversi con container che fanno girare la nostra applicazione, vengono disposti direttamente da un orchestratore all'interno di questi nodi, per cui è comunque una capacità riservata.
Ci sono dei costi di startup anche importanti con cui siamo riusciti a contenerli, ma ricordo quando ho fatto un workshop es mi ricordo che il lancio di un cluster mi costava qualcosa tipo sessanta euro al mese, che in realtà per fare dei test è un prezzo spropositato.
E oltre a questo, per il lancio di questo cluster c era bisogno anche tu di tutto un un bel po' di tempo da dedicare proprio per il settore.
Quindi insomma, tutto sembrava giocare contro di noi, adesso il servizio sta girando, sta girando su un cluster.
Abbiamo anche fatto un po' di esperienza, però per il nuovo servizio che volevo lanciare, che voglio lanciare che quella appunto della trascrizione i podcast non mi va di mettermi in mezzo e dentro a tutti questi problemi che abbiamo già vissuto.
Per cui l'idea è quella di utilizzare queste labbra fanfiction le lame da fanciulla dove il concetto cambia completamente e dal concetto di orchestrazione di micro servizi si passa appunto al concetto di coreografia.
Quindi ormai non devi gestire tutti i micro servizi e tutto il cluster che stai andando a tirar su, ma devi invece più che altro immaginare la tua architettura a progettarla bene prima e immaginare un'architettura di tipo evento dove appunto tutte le comunicazioni e tutte le azioni sono degli eventi.
A questo punto, utilizzando questo approccio e la possibilità di utilizzare appunto le tecnologie landa che ti permettano intanto di pagare solo quello che usi.
Quindi non scali da un'unità minima di in macchine per il cluster a y macchine ma parti da zero cioè se la tua landa non va in esecuzione perché magari mancano gli eventi per andare in esecuzione, un evento può essere anche una chiamata, a quel punto non paghi niente tra l'altro il tempo in realtà per tirar su questo servizio è semplicemente il tempo di partenza.
La tua funzione non devi settare il cluster, fare mille casini no semplicemente carichi la funzione del provider che ce l'hai bella pronta.
Insomma un approccio un po' reddit ugo e tra l'altro approccio anche garantito da dei che ti permettono di farlo come che sta utilizzando e', di cui vi parlerò tra qualche minuto, per cui appunto cioè il concetto portato all'ennesima potenza di micro servizi quindi e ti eviti praticamente di pensare a tutta l'infrastruttura naturalmente l'utilizzo delle landa fanciulla e quindi delle fanciulle sa dei pro e dei contro il pro sono kai un'architettura una un'architettura legata agli eventi che comunque permette la la la la la tua applicazione di essere super performante hai un'auto scaling senza pensarci, nel senso che ci pensa poi il tuo provider e paghi solo il consumo.
Questi sono i concetti e principali pro principali dell'utilizzo di infrastrutture, di idea di approccio, appunto la funzionalità landa e cioè proprio il concetto non che si passa da Monolith a micro servizio a funzioni, quindi alla fine ci pensi e strutture la tua applicazione anche in funzione di questo, cercando di disaccoppiare al massimo i tuoi servizi.
E questo anche a livello di progettazione, ti dà dei vantaggi.
Esistono però dei contro quando tu sviluppi utilizzando queste architetture landa che possono essere lei fondi AWS oppure le fan Shawn di Google Claud.
Beh, in qualche modo hai un problema di venderlo, quindi utilizzando appunto l'infrastruttura in modo così forte e i tipi agganci in qualche modo al provider diventa più difficile starti a svincolare.
Naturalmente.
Un altro problema è che se si ha in mano una applicazione che è un in qualche modo devi andartene da riscrivere.
Perché? Perché dovresti dividere il monolite in funzioni e quindi diciamo che questo presuppone un processo di hardware e factoring.
Un altro problema che ho riscontrato come esperienza personale con le landa francia un diavolo se anche il problema dei quattro secondi di time-out, nel senso che la tua fanfiction a quattro secondi per essere eseguita e poi viene sigillata è questo sai delle n delle applicazioni che presuppongono il calcolo intensivo.
Bene, qualche problema telo, telo, telo generano e un'altra un'altra.
Cosa importante è che in queste funzioni vengono eseguite in ambienti effimeri, quindi in realtà gestire lo stato diventa un pochino complesso.
Detto questo, vi voglio raccontare quello che sono riuscita a fare fino a oggi.
Allora, come vi dicevo, il concetto era quello di creare un sistema automatico per i trascritti.
Io ho il mio feed del podcast e avevo bisogno di qualcosa che girasse in completa autonomia, che mi generasse queste trascrizioni e pronte per essere poi messe pubblicate all'interno del sito in modo da un busto in termini.
Disse Oh allora com'e' strutturato l'applicazione beh, innanzitutto utilizzato un framework che mi semplifica casse l'approccio ai provider e il f l utilizzo si chiama che con la sola configurazione di un fagli Amal mi permette con veramente pochissimi dighe di fare il provvigioni di tutta una serie di servizi di Amazon, quindi basta che tutti i generi un utente con Dawson è che ha una serie di diritti.
A questo punto associ questo utente a un comando che lancia linea di comando alla tua stanza server les alla tua applicazione serve l'esca e gira nella tua macchina.
Da quel momento in poi tu con un solo file gli amal ti configuri la tua infrastruttura che nel mio caso vai a indicare a anche un servizio che si occupa di provvigioni di vari e servizi di amazon.
Quindi, che ne so, ti tira su i bacchette se tre per salvare i dati i tipi da sul servizio di trascrizioni si collegati imposta i diritti, fa tutto quello che deve fare.
A quel punto ho generato diverse land.
Sono tre la prima che gira a un intervallo di tempo, che è quello di un giorno e va a controllare sul feed.
Se ci sono dei nuovi episodi paragonandoli con gli episodi che ho già salvato nel a tre, se ci sono dei nuovi episodi si va a scaricare su se a questo punto un'altra landa che va ad ascot rimane in ascolto sul book ed degli episodi.
Quindi sullo spazio fisico.
Quando un nuovo episodio nuovo file mp tre viene messo in quello spazio fisico, si avvia e lancia un comando e servizi di trascrizione di amazon servizi che una volta terminati vanno a salvare il file su un altro bucket.
Quindi mi salva, non fa semplicemente un file e jeison una volta che io ho salvato questo file o un'altra landa che rimane in ascolto di questo bucket e quando vede che c' è una nuova trascrizione disponibile non fa altro che chiamare un look e rilanciare la compilazione statica del sito con Gatsby.
Ve ne ho parlato nella puntata dove mi parlava appunto di cms headless ed i motori per la generazione di siti web statici.
Quindi mi viene compilato completamente il sito mi vengono generate le pagine statiche che includono no, la trascrizione e' tutto automatizzato, un unico processo che in un solo colpo mi permette di mettere online la trascrizione utilizzando una infrastruttura che è complessa ma per la quale io non ho avuto il minimo mal di testa, il minimo problema di seta e soprattutto dei costi base di di di struttura.
Perché se io domani mattina fermo le landa o se non pubblico nessuno episodio, io non pago proprio un bel niente.
È questo il vantaggio veramente in poche ore.
Un servizio, per quanto artigianale, che mi permettesse di raggiungere l'obiettivo senza tirare su cluster, avere macchine su amazon, su digital anche hanno dei costi fissi, ma semplicemente pagando quello che consumo.
Quello che consumo sono i servizi di trascrizione, queste landa e lo spazio fisico.
Se i tre che mi costa un'inezia veramente pochissimi, tanto che sono ancora credo nel piano gratuito.
Sono ancora coperto dal piano gratuito e quindi nulla.
Tutto funziona tra un po', un po' tra qualche giorno tempo permettendo, riusciro' ad in produzione con il minimo sforzo.
Spero che questa puntata vi sia piaciuta.
Oltre a essere una puntata tecnica, era anche una puntata dove vi ho raccontato un po' di fatti miei.
In realtà mi piaceva proprio a partire dalla mia esperienza ed e', una cosa che mi piacerebbe tirar dentro sempre di più all'interno del poker.
Se poi voi avete delle esperienze da condividere bene, potete farlo e inviandoci una mela tweet oppure scrivendo mi a heartbreak repo su twitter perche' no, saremo.
Siamo sempre disponibili ad ascoltarvi e a condividere il nostro spazio all'interno del podcast e anche con voi.
Vi ricordo che per rimanere aggiornati su tutte le novità di bar potete iscrivervi con il vostro cliente di podcast direttamente nel nostro feed in modo che ogni settimana riceviate la notifica è stiate al passo con gli episodi anche per oggi da tutto un saluto da repo e ci sentiamo la prossima settimana.
Il circolo dei fusti da bere una volta a settimana ci troviamo davanti a due birre e comprerebbe.
Parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta degli attrezzi di Foster
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄