Serverless application ovvero applicazioni che non richiedono la necessità di associare il supporto di un server per garantire il servizio. In realtà il concetto è che le macchine, in realtà, ci sono ma non vengono gestite dagli sviluppatori. I programmatori che vogliono cogliere tutti i vantaggi di un’elaborazione senza server hanno diverse opzioni per garantire carichi di lavoro in tempo reale e ad alta densità di dati.
Come scegliere, dunque, la migliore configurazione e perfezionare le prestazioni delle serverless application e stateful (ovvero sviluppate su funzioni senza server)? Gli esperti fanno il punto, offrendo alcune importanti linee guida.
Cosa sono le funzioni senza stato
Innanzitutto bisogna inquadrare il tema. Le funzioni sono essenzialmente blocchi di codice indipendenti che eseguono un’attività specifica in modo preciso. Ad esempio, eseguire uno script o trasferire i dati di registro da un’applicazione all’altra.
Le funzioni serverless, proprio come quelle di un programma Java, hanno input e output dedicati. Il che significa che possono connettersi e formare una catena in cui l’output di una funzione è l’input di un’altra. Questa dinamica aiuta a gestire l’architettura dell’applicazione in modalità distribuita.
Sebbene la progettazione senza server di una Funzione as a Service (FaaS) sia adatta alle applicazioni basate su eventi, la natura effimera delle funzioni la rende inadeguata quando si tratta di applicazioni in tempo reale e incentrate sui dati.
Le istanze di funzione sono volatili e hanno una durata compresa tra 5 e 15 minuti.
I carichi di lavoro in tempo reale e nativi in cloud avrebbero bisogno di ripristinare lo stato dell’applicazione in un lasso di tempo di pochi minuti se distribuiti in un modello FaaS puro. Sebbene un’applicazione possa archiviare gli stati di queste funzioni stateless nel back-end, quando si tratta di serverless application è consigliabile evitare scenari in cui l’app deve caricare frequentemente lo stato dalla memoria. Questo non solo perché l’operazione risulta costosa, ma anche perché comporta una latenza che influenza la velocità effettiva delle richieste di rete.
Attenzioni alle funzioni ma anche alla latenza
Le funzioni dovrebbero essere direttamente accessibili l’una all’altra. Senza connessioni immediate, le funzioni dipendono da un supporto di archiviazione che, risultando lento nel trasportare i dati da una funzione all’altra, aumenta la latenza.
La latenza, però, è una condizione inaccettabile in presenza di scenari applicativi in tempo reale come possono essere i sistemi di monitoraggio 24/7.
Le funzioni serverless sono alla base dei carichi di lavoro a breve termine, il che significa che le risorse sono allocate su di loro ed eliminate al termine della richiesta.
Le applicazioni stateful, sviluppate su funzioni senza server, non possono utilizzare i meccanismi tradizionali per operare come, ad esempio, le variabili globali che possono contenere dati per tutta la vita dell’applicazione. È impossibile per le funzioni senza stato leggere e scrivere su disco, ma l’applicazione non può mantenere una connessione costante al database.
Per creare applicazioni con stato, gli sviluppatori di applicazioni serverless possono gestire lo stato del programma con connessioni al database, un payload di eventi o un back-end come servizio (BaaS) da integrare all’applicazione. I programmatori dovrebbero utilizzare questi approcci per sfruttare appieno l’architettura serverless che, se eseguita correttamente, permette di gestire lo stato dell’applicazione senza degradare le prestazioni.
Come gestire la connessione diretta al database
Chi sceglie la modalità della serverless application può archiviare lo stato dell’applicazione in un database e quindi collegare le funzioni al database per gestire l’accesso.
In questa configurazione, gli sviluppatori devono preoccuparsi della scalabilità. Per evitare stress sul database e garantire un accesso frequente e continuo allo stato dell’applicazione, è necessario seguire le linee guida del fornitore in merito alle modalità di connessione al database, tenendo conto di tutte le specifiche della sua piattaforma cloud come, ad esempio, quelle di AWS Lambda ad Amazon Relational Database Service.
Creare e archiviare lo stato all’inizio dello sviluppo di una serverless application aiuta i programmatori ad evitare di sostenere i costi legati alle chiamate costanti al database. Le transazioni del database, infatti, sono costose e non sono scalabili. Anziché gestire la concorrenza delle transazioni insieme allo sviluppo delle applicazioni, meglio utilizzare un agente di pool di connessioni esterno: ad esempio un driver JDBC (Java Database Connectivity). I fornitori di servizi cloud offrono questi driver come può essere il driver Microsoft JDBC per un server SQL utile alla connessione a un database SQL di Azure. I prodotti software di terze parti, come Progress DataDirect, possono anche fungere da agenti di pooling.
Il consiglio degli esperti è di evitare la mappatura relazionale degli oggetti (Object Relational Mapping – ORM), ovvero il processo di conversione dei dati tra due sistemi incompatibili. ORM richiede modelli individuali per ciascuna funzione utilizzata in un’applicazione, il che crea semplicemente più codice da scrivere per il programmatore di serverless application.
Trasformare il back-end in un servizio
Il back-end come servizio è un altro importante meccanismo per la realizzazione di serverless application statefull. Le funzioni senza server utilizzano API HTTP senza stato mentre il BaaS si occupa di problemi come la concorrenza e le prestazioni astraendo l’intera architettura a supporto delle serverless application, gestendo anche lo stato indipendentemente dal carico di lavoro.
Le API BaaS possono essere richiamate all’interno di una funzione senza server attraverso una riga di codice, che mantiene pulita la base di codice dell’app e consente alle funzioni di agire senza stato. Le opzioni BaaS, tra le varie opzioni, includono Progress Kinvey e Google Firebase.
