L'argomento di oggi è uno di quelli di cui quasi tutti hanno sentito parlare, ma che quasi nessuno sa spiegare. Serverless. Di cosa si tratta esattamente? È solo codice che gira sul nulla o è qualcosa di molto più grande? Chiariamo subito una cosa. Serverless non significa niente server. Significa che non ci pensi. E questa distinzione cambia tutto nel modo in cui crei software. Alla fine di questo episodio capirai cosa sono effettivamente le funzioni di Azure, come funzionano normalmente i prezzi, quando dovresti usarle. Analizzeremo i componenti di base, iniziando dal mito più grande. Cosa significa effettivamente serverless? Chiariamo subito alcuni miti. Termine serverless è il peggior termine di marketing che Microsoft abbia mai inventato. Fa pensare alle persone che non ci sia letteralmente alcun server coinvolto. Non è vero. Ci sono server, tantissimi. Semplicemente non devi mai toccare.

Vent'anni fa, se volevi eseguire un pezzo di codice su internet dovevi fare un sacco di lavoro, noleggeresti una macchina virtuale, installeresti un sistema operativo, configureresti un server web e distribueresti la tua applicazione. Poi passeresti ogni fine settimana a correggere gli aggiornamenti di sicurezza ed assicurarti che la cosa non si bloccasse letteralmente. Ed ecco il punto. Hai pagato per quel server indipendentemente dal fatto che il tuo codice fosse in esecuzione. Se ne stava lì a ronzare bruciando soldi mentre tu dormivi. Il serverless capovolge l'intero modello. Scrivi il tuo codice, lo carichi e la piattaforma gestisce tutto il resto. Il sistema operativo, le patch di sicurezza, la scalabilità e la disponibilità. Il tuo lavoro è solo scrivere la logica che conta. Pensa alla differenza tra gestire la cucina di un ristorante e usare un distributore automatico. La cucina di un ristorante ha bisogno di uno staff completo, forniture costanti e manutenzione.

Costa soldi ogni singolo giorno, anche se nessuno varca la soglia. Un distributore automatico? Invece se ne sta lì in un angolo a non fare nulla finché qualcuno non preme un pulsante. Poi si accende, fa il suo lavoro e torna a dormire. Paghi l'elettricità solo quando funziona effettivamente. Questa è la tecnologia service in poche però. Funzioni di Azure è la versione di Microsoft di Quest. Esegue piccoli pezzi di codice in risposta a eventi. Il codice è inattivo finché qualcosa non lo riattiva, quindi viene eseguito, terminato e torna in modalità sospensione. Quindi che aspetto è effettivamente quel codice? Cosa sono le funzioni di Azure? Una funzione è un singolo pezzo di codice che esegue un lavoro specifico. Non è un'intera applicazione con una pagina di accesso, un database, 20 schermate. È un'attività mirata. Pensala come un interruttore della luce in casa, che si accende e si spegne mentre lavora, poi si spegne di nuovo.

Un server web tradizionale è l'opposto, come lasciare tutte le luci accese in casa 24 ore dal giorno, 7 giorni su 7 anche quando non c'è nessuno in casa. Funzioni di Azure, supporta diversi linguaggi di programmazione. Puoi usare quello che preferisci, JavaScript, Python, C, Java, PowerShell. Non esiste una risposta giusta. Scegli il linguaggio che conosci già. Ora chiariamo un dubbio comune. Un'app per funzioni non è la stessa cosa di una funzione. L'app per funzioni è il contenitore. Pensala come una cassetta degli attrezzi. Crei un'app per le funzioni e al suo interno aggiungi più funzioni. Ogni funzione è uno strumento separato che svolge il proprio lotto. Potresti avere una funzione che gestisce le registrazioni di utenti, un'altra che lavora le immagini caricate e una terza che inviare a port notturni. Sono tutte nella stessa cassetta degli attrezzi, ma funzionano nel mondo. Un'altra cosa sulle funzioni.

Sono stateless per progettazione. Ciò significa che non ricordano nulla tra un'esecuzione e l'altra. Se la funzione elabora un file e termina, è fatta. La volta successiva che viene eseguita riparte da zero senza memorità. Sembra una limitazione, ma in realtà è la caratteristica che le rende così potenti. Poiché le funzioni non mantengono memoria o stato, Azure può creare 100 copie della funzione all'istante quando il traffico aumenta e restarle altrettanto rapidamente quando il traffico diminuisce. Ecco come ottenere scalabilità senza pagare per server inattivi. Ecco la domanda. Se una funzione rimane lì senza fare nulla finché qualcosa non la reattiva, cosa la reattiva effettivamente? Ecco dove entra in gioco i trigger. I trigger, il quando. Ogni funzione deve avere esattamente un trigger e questo non è facoltativo. Il trigger è l'evento che attiva la funzione. Senza di esso il codice rimane lì senza fare assolutamente nulla.

Pensa ai trigger come un campanello. La funzione è inattesa all'interno della casa. Potrebbe aspettare per sé. Non succede nulla finché qualcuno non suona il campanello. A quel punto la funzione entra in azione, risponde alla porta, fa il suo lavoro e torna ad aspettare. Ci sono quattro trigger che i principianti incontrano più spesso. Il trigger HTTP è il punto di partenza più comune. Qualcuno visita un URL o effetto una chiamata API e la funzione si attiva. Ecco come si crea una API ledger senza dover configurare un server web completo. Poi c'è il trigger del timer che viene eseguito in base alla pianificazione. Imposti un'espressione Chrome. Ad esempio, esegui ogni ora o esegui a mezzanotte ogni notte e la funzione si attiva esattamente a quegli orari. Perfetto per l'attività di manutenzione, lavori di pulizia o generazione di rapporto notturno. Il trigger blob si attiva quando un file viene caricato nell'archivio di agio.

Supponiamo che qualcuno carichi un PDF in una cartella specifica. Il trigger blob rileva tale caricamento ed esegue automaticamente la funzione. Ciò è fondamentale per l'elaborazione delle immagini e la conversione dei documenti e la convalida dei file. Il trigger della coda si attiva quando un messaggio appare in una coda. Le code sono un modo per disaccoppiare del sistema. Un servizio inserisce un messaggio in una coda e la funzione lo preleva e lo elabora quando è pronto. Ciò impedisce a un servizio lento di bloccare tutto il resto. Ecco il punto chiave. Quando un trigger si attiva passa automaticamente i dati alla funzione. Non è necessario interrogarlo o verificare se è successo qualcosa. Il trigger fornisce tutto ciò di cui si ha bisogno e la funzione si limita al lavoro. Una funzione senza trigger è solo codice inutilizzato e ciò che le conferisce uno scopo. Quindi il trigger indica la funzione quando eseguirsi.

Ma da dove provengono i dati e dove vanno? È qui che entra in gioco i binding. Binding, dati in entrata, dati in uscita. I binding sono un modo per comunicare alla funzione quali dati leggere e dove inviare risultati senza dover scrivere tutto il codice aggiuntivo. È un discorso lungo, quindi lascia che lo semplifico. Esistono due tipi. Binding di input inseriscono i dati nella funzione. I binding di output inviano i dati. Senza binding dovresti scrivere codice SDK ogni volta che vuoi comunicare con un account di archiviazione, un database o una coda. Dovresti gestire stringhe di connessione, nuovi tentativi, serializzare i dati e serializzare le risposte. È un sacco di codice standard solo per leggere un file. Con i binding dichiari semplicemente ciò di cui hai bisogno. Dici voglio leggere da questo contenitore blob oppure voglio scrivere in questa coda. Il runtime si occupa del resto. Apre la connessione, legge i dati e li passa la funzione come parametro.

Quando la funzione termina, prende il valore restituito e lo scrive dove è specificato. Tenza i binding come dei pipe. Colleghi la tua funzione a un account di archiviazione, un database o una coda. I dati scorrono automaticamente attraverso WePipe. La funzione ha bisogno di sapere come funziona WePipe. Riceve solo ciò che passa e invia ciò che deve uscire. Ecco un esempio concreto. Supponiamo di avere un binding in input blob. Quando la funzione si avvia, legge automaticamente un file dall'archivio blob e lo passa come parametro. Non scrive alcun codice SDK di archiviazione. Otteni semplicemente i dati da valore. Un altro esempio è un binding di output. La funzione elabora qualcosa e alla fine restituisce un valore. Runtime prende quel valore, lo serializza e lo inserisce nella coda. Non scrivi alcun codice di coda. Restituisci solo un valore. I binding sono facoltativi. Puoi averne 0 o 1 o molti.

Alcune funzioni necessitano solo di un trigger senza alcun binding. Altre potrebbero avere 3 o 4 bindings che si connettono a servizi diversi. La combinazione di trigger e binding è ciò che rende funzioni di Azure così potente. Scrivi la logica aziendale, il codice decisionale effettivo, la piattaforma gestisce ton'integrazione. La funzione rimane piccola, mirata e facile da comprendere. La storia dei prezzi. Il prezzo è ciò che sorprende la maggior parte dei principi. Per la maggior parte delle persone il piano consumo è la scelta predefinita e dovresti iniziare con quello il 90% da voi. Ecco come funziona. Paghi solo quando la tua funzione viene effettivamente eseguita. Quando è inattiva non paghi nulla. Zero, nemmeno un centesimo. Due componenti compongono il conto. Innanzitutto il numero di esecuzioni, ovvero quante volte viene attivata la tua funzione. In secondo luogo il tempo di esecuzione è misurato in qualcosa chiamato gb secondi.

In pratica il tempo di esecuzione della tua funzione è moltiplicato per la quantità di memoria utilizzata. Solvenzione gratuita genera. Ottieni un milione di esecuzioni al mese e 400.000 gigabyte secondi completamente gratuiti. Per la maggior parte dei piccoli progetti, app per hobby e prototipi, non pagherai mai un centesimo. Noi. Se superi la sovvenzione gratuita, le tariffe sono comunque incredibilmente coni. 20 centesimi per un milione di esecuzione. Non è un errore di battito. 20 centesimi per un milione di esecuzione. Pensalo come se pagassi l'elettricità solo quando accendi l'interrutto. Non è previsto alcun canone mensile di base per l'installazione dei cavi nelle pareti. Si paga solo l'energia effettivamente utilizzata. Però ci sono altri piani. Flex Consumption è più recente e offre supporto per la diretta virtù. Premium ma mantiene le funzioni sempre attive, quindi non ci sono ritardi nella via fredda.

Dedicated offre capacità fissa su un tradizionale app service plan. Ma per iniziare, Consumption è la scelta giusta quasi sempre. Un avvertimento però. La concessione gratuita è condivisa tra tutte le app e funzioni nello stesso abbonamento. Se si hanno 10 app per funzioni, tutte attingono allo stesso milione di esecuzioni gratuite. Quindi tenete d'occhio questo aspetto se iniziate a crearne più di una. Prezzi sono ottimi. Ma rendiamolo reale con un esempio concreto. Uno scenario reale. Immaginate di gestire un sito web in cui gli utenti caricano immagini da profilo. Tali immagini sono enormi, circa 10 MB ciascuna. E questo causa alcuni problemi reali. I file di grandi dimensioni costano di più da archiviare e rallentano il sito web ogni volta che qualcuno carica una pagina e frustrano gli utenti che devono aspettare le foto. Quindi bisogna di un modo per ridurre automaticamente quelle immagini.

Senza funzioni di Azure dovresti creare un work in background da zero. Ciò significa procurarti un server separato, impostare una coda per gestire il carico di lavoro e scrivere codice per gestire tutti gli elementi in movimento. Si tratta di una complessità enorme e non necessaria per qualcosa di semplice come la riduzione di un'immagine. Con funzioni di Azure tutto ciò di cui hai bisogno è un trigger blob e una funzione. Nessun server di cui preoccuparti. Lascia che ti spieghi come funziona. Un utente carica una foto tramite il tuo sito web e quel file arriva nell'archivio blob di Azure. Nel momento in cui arriva un trigger blob si attiva automaticamente. La tua funzione si attiva, esegui il codice di compressione e salva la versione più piccola nell'archivio. Tutto questo avviene in pochi secondi. L'utente non attende mai perché l'intero processo viene eseguito dietro le quinte e è completamente invisibile.

Ecco un altro esempio quotidiano. Inviare un'email di benvenuto quando qualcuno si iscrive al tuo servizio. Un trigger a HTTP intercetta le richieste di iscrizione dal tuo sito web. La funzione viene attivata, acquisisce l'indirizzo email dell'utente, invia un messaggio di benvenuto tramite SendGrid e gioco è fatto. L'utente riceve la propria email quasi stantanea. Nessun server di posta elettronica da configurare, nessuna coda di invio da gestire. Solo una funzione, un processo, completato. Questi sono esattamente i processi per cui è stato progettato funzioni di Azure. Quindi quando dovresti ricorrere a una funzione e quando dovresti usare qualcos'altro. Ecco un modo rapido per decidere. Chiediti se l'attività è breve, se è basata sugli eventi e se è senza stato. Se hai risposto sia a tutte e tre le domande. Funzioni di Azure è probabilmente lo strumento giusto. Iniziamo con i casi d'uso positivi.

API e Webhook sono una combinazione perfetta. Hai bisogno di un endpoint leggero che risponda a una richiesta HTTP, esegua una cosa e restituisca un risultato. Ed è esattamente per questo che sono stati creati i trigger, HT, trigger, HTTP. L'elaborazione di file immagini è un altro aspetto importante. Un file arriva in archivio, la funzione si attiva, lo trasforma e salva il risultato, il tutto senza un server. Le attività pianificate come la pulizia notturna o la generazione di report funzionano alla grande con i trigger del timer. Anche la trasformazione dei dati per le pipeline ETL è comune. E le funzioni costituiscono un collante di integrazione perfetto collegando due servizi che non comunicano naturalmente tra loro. Ora parliamo di quando le funzioni non sono adatte. Processi di lunga durata sono un problema perché nel piano di consumo le funzioni hanno un limite di timeout di 5 minuti per impostazione predefinita, fino a 10 se lo configuri.

Se il tuo lavoro richiede più tempo o hai bisogno di qualcosa altro, le applicazioni costato sono altre discrepanze. Le funzioni non ricordano nulla tra un'esecuzione e l'altra. Se hai bisogno di mantenere lo stato della sessione o di tenere traccia dei progressi tra i passaggi stando contro il design. Anche i carichi di lavoro o di lavorazione pesanti sono sbagliati. Se hai bisogno di una CPU sostenuta per minuti o ore, una macchina virtuale o un contenitore sono una scelta migliore. I flussi di lavoro complessi in cui un'attività dipende da un'altra sono gestiti meglio da funzioni durevoli o da app logiche. Ecco una rapida panoramica delle alternative. Agile Logic Apps è l'opzione senza codice per la connessione ai servizi. Se non hai bisogno di scrivere codice personalizzato, Logic Apps può svolgere il lavoro con un progettista. Azure App Service è per applicazioni web complete eseguite 24 ore su 24, 7 giorni su 7, giorni su 7.

Se hai bisogno di un sito web o di un API completo è sempre attivi questo strumento che fa per te. Azure Container Apps ti offre microservizi containerizzati con maggiore controllo sul runtime. Azure Virtual Machines ti offre il controllo completo sul sistema operativo se necessario. Ecco una semplice regola pratica. Se riesci a descrivere il lavoro in una frase è probabilmente un buon candidato per una funzione. Comprimere le immagini quando vengono caricati. Inviare un'email di benvenuto quando qualcuno si iscrive. Eseguire un lavoro di pulizia a mezzanotte. Una frase, un lavoro, una funzione. Errori comuni da evitare per i principianti. Ora parliamo di alcune cose a cui prestare attenzione. Questi sono gli errori in cui inciampano quasi tutti quando iniziano. Un errore comune dei principianti è pensare che le funzioni siano sempre gratuite. La sovvenzione gratuita è generosa, so che un milione di esecuzioni può sembrare molto.

Ma se la tua funzione diventa virale o viene attaccata da un bot, quelle esecuzioni si sommano rapidamente. Quindi il monitor del tuo utilizzo imposta un avviso di budget in Azure e non ricevere una fattura sorpresa alla fine del mese. Un altro errore è ignorare gli avvii a freddo. La prima volta che la tua funzione viene eseguita dopo essere stata inattiva ci vuole più tempo. Con il piano a consumo possono volerci alcuni secondi. Per la maggior parte dei casi d'uso va bene. Ma se stai creando un'api sensibile alla latenza in cui ogni millisecondo è importante e prendi in considerazione il piano premium o abilita le istanze sempre pronte o abilita le istanze sempre pronte, poi c'è la scrittura di funzioni che vengono eseguite dopo l'uno. Piano a consumo on time out, 5 minuti per impostazione predefinita, 10 minuti al massimo. Se la tua funzione impiega 15 minuti per elaborare un file, verrà interrotta a metà.

Soddividi quel processo in parti più piccole e usa un piano di hosting diverso. Un altro errore facile da trascurare è non usare l'esecuzione del pacchetto. È una semplice modifica alla configurazione che migliora gli avvi a freddo e rende distribuzioni più affidabili. Invece di copiare singoli file, distribuisci un pacchetto zip e una casella di controllo nel portale, fallo. Esporre endpoint HTTP senza autenticazione è un'altra trappola. È facile lasciare una funzione in modalità anonima durante il test, quindi dimenticare di bloccarla. Imposta correttamente il livello di autorizzazione fin da lì. Utilizza chiavi di funzione e ti ami solo. Non lasciare la porta aperta. Anche il riutilizzo degli account di archiviazione tra più app di funzione è un problema. Nello sviluppo è possibile condividere. In produzione ogni app di funzione dovrebbe avere il proprio account di archiviazione. Altrimenti si verificano problemi di vicinato rumoroso in cui il traffico di una funzione rallenta un'app.

E infine non abilitare Application Insights. Senza di esso stai volando la CEC. Non vedrai fallimenti, errori o problemi di prestazioni. Non saprai se la tua funzione è in esecuzione da troppo tempo o se si blocca silenziosamente. Abilitalo dal primo giorno. Ci vogliono 30 secondi e risparmi ore di debug. La regola d'oro per tutto questo è mantenere le funzioni piccole, mirate e senza stato. Un lavoro per funzione? Niente di più. Quindi questo è il sistema. Funzioni di Azure è un'elaborazione senza server che esegue piccole porzioni di codice e risposte eventi. Paghi solo quando il codice viene eseguito. I trigger indicano la funzione a quando riattivarsi. I binding la collegano ai dati di cui ha bisogno. Il piano di consumo la mantiene quasi gratuita per i progetti di piccole dimensioni. La mossa migliore al momento è creare una semplice funzione attivata tramite HTTP nel portale di Azure.

Richiede 5 minuti e non costa nulla. Iscriviti a Microsoft Knowledge Nuggets per altre analisi di linguaggio semplice e condividile con qualcuno che continua a chiedere cosa significa senza server. Fraun.