Stateless e Stateful: cosa sono e quali le differenze

Stateless e stateful descrivono come una macchina o un’applicazione conservano i precedenti eventi in una sequenza di interazioni con un utente, un dispositivo informatico o un’applicazione. Stateless e stateful sono definiti in base al loro stato in un determinato momento.

Stateless e stateful hanno assunto una particolare attenzione nella letteratura informatica nell’ambito delle applicazioni in cloud computing, soprattutto quando si parla dei container, gli ambienti di esecuzione utilizzati dagli sviluppatori per creare software basato su architetture a microservizi.

Vediamo cosa si intende nel glossario IT per stateless e stateful, facendo particolare riferimento alle applicazioni, nel contesto del loro sviluppo, della loro esecuzione e della loro gestione.

Stateless e Stateful: cosa significa Stateless

Un’applicazione stateless è definita “senza stato” in quanto non salva i dati generati in una determinata sessione per utilizzarli nel corso di quelle successive. Ogni sessione viene pertanto eseguita senza alcuna memoria del pregresso, come se fosse sempre la sua prima volta.

Gli eventi di una sessione non dipendono mai dai dati generati in una sessione precedente. Come facilmente intuibile dall’etimologia stessa, il suo comportamento è diametralmente opposto rispetto ad una applicazione stateful.

Durante l’esecuzione di un’applicazione stateless, il server non procede alla memorizzazione di alcun stato relativo alla sessione vigente. I dati rimangono sul client e vengono messi a disposizione del server soltanto se richiesto da determinati eventi.

Tale aspetto risulta ad esempio efficace quando si tratta di dover sviluppare applicazioni a cui si richiede di lavorare offline, quindi in grado di salvare i dati sul client senza la stretta necessità di sincronizzarli continuamente con un server in remoto. La sincronia file potrebbe ad esempio avvenire periodicamente o nelle circostanze in cui si rende disponibile una connessione ad Internet, senza che ciò vada a discapito della regolare operatività.

L’attenzione verso le applicazioni stateless è ovviamente cresciuta, come vedremo, nel contesto della containerizzazione, in quanto sono proprio i container stateless ad abilitare i concetti del Function-as-a-Service (FaaS) e delle architetture serverless, indipendenti da uno stato specifico, ove ogni sessione di esecuzione dipende nello specifico da un evento.

Dal punto di vista dello sviluppo, la particolarità dello stateless è data dal fatto che se i microservizi che compongono l’applicazione sono “senza stato”, questi non sviluppano dipendenze, pertanto gli sviluppatori possono combinare in vari modi le funzioni con un approccio estremamente agile.

Un esempio di applicazione stateless è dato da una ricerca online. La domanda al motore di ricerca costituisce un processo effimero. Se accidentalmente chiudessimo la pagina web, dovremmo aprirne un’altra e digitare nuovamente ciò che ci occorre ricercare. Il momento nudo e puro della ricerca corrisponde ad una specifica domanda a cui viene data una specifica risposta. Dopodiché l’evento cessa, e non rimane traccia alcuna.

L’eventuale esistenza di uno storico o di una cronologia di ricerca è data dal fatto che oltre alla condizione stateless esiste anche una condizione stateful, che consente ad esempio al browser di salvare sul server i dati inseriti dall’utente. Si tratta però di una ulteriore funzione, che va prevista in aggiunta rispetto alla condizione stateless della funzione di base.

Stateless e Stateful: cosa significa Stateful

Le applicazioni stateful, contrariamente a quelle definite stateless, conservano i dati di una sessione per renderli disponibili anche alle sessioni successive. Tali dati sono proprio quelli che in gergo definiscono lo stato dell’applicazione. I dati possono essere salvati in locale, su una macchina client, o in remoto, su un server fisico o virtuale, e pertanto resi disponibili anche per ulteriori applicazioni.

Nel caso di un’applicazione stateful, anche interrompendo accidentalmente una sessione, è possibile riavviare l’applicazione per riprendere grosso modo dal punto in cui era in precedenza avvenuta l’interruzione.

La stessa cosa avviene quando sospendiamo una sessione di esecuzione di un sistema operativo. Quando la riavvieremo, ritroveremo esattamente tutto come l’avevamo lasciato. Questa condizione di persistenza è garantita dalla conservazione dello stato della sessione precedente. Le tradizionali applicazioni monolitiche sono quasi tutte stateful, mentre in cloud lo scenario si presenta molto più vario.

La condizione stateful non appare infatti ottimale nel contesto dello sviluppo cloud native, ma la tecnologia basata sui container ha ridefinito lo scenario, risolvendo moltissimi problemi pratici relativi alla disponibilità dei dati da parte delle applicazioni, che nella maggior parte dei casi potrebbe richiedere una condizione stateful.

Il container stateful carica, infatti, i dati all’avvio di ogni istanza e ne consente la modifica e il salvataggio al termine di una sessione. La gestione di dati persistenti è notevolmente agevolata dalle tecnologie di orchestrazione dei container stateful in multicloud. La più popolare tra queste è indubbiamente Kubernetes.

Un esempio che viene proposto piuttosto frequentemente per focalizzare i concetti stateless e stateful è relativo alle sessioni di navigazione sul web. Una comunicazione basata su protocollo http è fondamentalmente stateless, così come la ricerca citata nel precedente paragrafo, in quanto un web server, in una condizione di default, legata ad una singola interazione, non avrebbe alcun motivo di conservare i dati derivanti dalle varie sessioni. Ciò corrisponderebbe ad un inutile dispendio di risorse.

Per conservare lo stato di un’applicazione è necessario avvalersi anche di una condizione persistente, che nel caso delle pagine web è ad esempio garantita dai cookie di navigazione, che consentono di tracciare le interazioni e conservarle per renderle disponibili anche alle successive sessioni, rendendole più rapide o evitando di dover inserire nuovamente dati che sono già stati inseriti in precedenza.

Altri esempi di applicazioni stateful sono i servizi di online banking, in grado di tenere traccia delle precedenti transazioni, in grado di influenzare a loro volta quelle svolte successivamente. Questo è possibile in quanto i dati delle interazioni vengono conservati sul server che eroga il servizio.

Quale soluzione scegliere

La maggior parte delle applicazioni e dei sistemi operativi è tradizionalmente stateful, ma è evidente come la diffusione delle applicazioni cloud native abbia favorito la diffusione delle applicazioni stateless, in quanto più facilmente scalabili in funzione dei carichi di lavoro. Abbiamo accennato, ed approfondiremo nel corso del successivo paragrafo come la containerizzazione consenta di utilizzare in cloud entrambe le tecnologie facendo tesoro delle loro rispettive qualità.

Senza perderci in inutili divagazioni filosofico-concettuali, la domanda da porsi è: perché dover scegliere? Una volta noto il tipo di applicazione che si intende progettare e l’uso che si intende farne, appare decisamente intuitivo come la condizione stateless si riveli particolarmente idonea quando le informazioni sono necessarie in modo transitorio e limitato all’esecuzione di una singola sessione. Se l’applicazione deve invece conservare in memoria ciò che accade tra una sessione iniziale e quelle successive, la condizione stateful è la più appropriata per via della sua definizione tecnologica.

Per offrire una percezione concreta di quali e quante possano essere gli impieghi delle applicazioni stateless e stateful, possiamo formulare una rapida sintesi. Pur non esaustiva, appare prontamente evidente quali contesti risultino maggiormente funzionali alla condizione stateless e quali invece siano espressamente orientate alla presenza di uno stato ben specifico, che deve essere garantito dall’accesso a dati persistenti.

Esempi di applicazioni stateless

• Applicazioni dipendenti da una singola funzione, come quelle eseguite su molti device connessi a sistemi IoT, che rispondono ad uno specifico evento, e soltanto a quello

• Web print e server CDN (Content Distribution Network), utilizzati per rendere più rapida ed efficiente la distribuzione di contenuti online, soprattutto nei servizi che richiedono uno streaming di dati continuativo

• Server che elaborano le richieste soltanto in funzione di una specifica richiesta (es. ricerca online), senza richiedere alcuna conoscenza relativa a precedenti richieste e pertanto non necessitano di salvare alcuna informazione di stato

• Differenti richieste elaborate da differenti server, tra loro funzionalmente indipendenti

• Applicazioni basate su microservizi eseguite in modalità serverless, in cui l’allocazione delle risorse si dimostra scalabile

• Applicazioni basate su microservizi eseguite su architettura serverless, in cui l’allocazione delle risorse necessarie per eseguire i carichi di lavoro sono estremamente scalabili

Esempi di applicazioni stateful

• Sistemi operativi e applicazioni installate in locale su server e client

• Database e sistemi di dati che prevedono la loro conservazione persistente

• Applicazioni basate sulle transazioni, come il banking online

• Mail server

• Server che elaborano richieste a loro volta basate su una condizione di stato relativa ad una richiesta precedentemente svolta. Tramite l’accesso ad alcuni dati persistenti, il server deve necessariamente usufruire di uno stato precedente

• Sistemi server-client in cui viene fatto riferimento sempre agli stessi server, che condividono i dati necessari a garantire la presenza di stato richiesta dalle applicazioni

Stateful, stateless e container

L’esplosione dirompente del cloud computing ha generato un’autentica escalation di applicazioni a microservizi, la cui architettura risulta assolutamente ottimale al contesto cloud native. Per facilitare lo sviluppo in questo frangente sono state implementate tecnologie specifiche, come i container, gli ambienti di esecuzione dei microservizi che compongono le applicazioni cloud native, note ai più per essere la tecnologia che ha dato i natali al Software-as-a-Service (SaaS), che sta letteralmente rivoluzionando l’IT sia a livello consumer che a livello enterprise.

I container sono delle virtualizzazioni al livello del sistema operativo, pertanto del tutto indipendenti dal comparto hardware sottostante. Corrispondono sostanzialmente ad unità di codice di un’applicazione oltre alle librerie e alle dipendenze. Essendo isolati e indipendenti, i container godono di ottima portabilità e possono essere eseguiti in qualsiasi ambiente IT (on-premise e in cloud pubblico o privato).

Nella loro concezione originale, i container, per via del loro isolamento, erano essenzialmente stateless. I container stateless sono tuttora alla base del funzionamento delle architetture serverless.

Tuttavia, la crescente diffusione delle applicazioni SaaS ha ben presto richiesto la disponibilità di container capaci di migrare in cloud le applicazioni stateful già esistenti. Pur riprogettate in maniera più o meno profonda per adattarle al cloud, le applicazioni eseguite dai container necessitano di una condizione stateful almeno per quanto riguarda lo storage dei dati, pur senza rinunciare all’innata scalabilità e portabilità nativamente garantita dalla tecnologia container based.

Nell’ambito dello sviluppo in cloud, come era del resto lecito attendersi, si è pertanto creata una condizione di notevole ibridazione, tant’è che in certi casi, anche per l’occhio allenato, diventa oggettivamente tedioso trovare una distinzione netta tra un’applicazione stateless ed un’applicazione stateful. Ma a valle delle scelte tecnologiche, sarebbe come porsi un non problema, in quanto le applicazioni possono sfruttare entrambe le condizioni di stato.

Ancora una volta possiamo citare come esempio una sessione relativa ad una pagina web, nativamente stateless, che può essere resa a sua volta stateful grazie alla presenza dei cookie di navigazione. Tale condizione associa operativamente i punti di forza di stateless e stateful per migliorare l’esperienza dell’utente.

La crescente complessità e varietà dei container stateful e stateless ha reso sempre più frequente il ricorso alle tecnologie di orchestrazione, tra cui il già citato Kubernetes, che rende di fatto quasi sempre possibile l’ausilio di un container stateful a meno che uno non decida strategicamente di volersi avvalere nello specifico dei vantaggi caratteristici di un container stateless, come l’impiego di un’architettura serverless.

Kubernetes consente di gestire un’ampia varietà tipologica di container, rendendo di fatto influente la condizione stateless o stateful del container. Tale aspetto consente agli sviluppatori di effettuare le loro scelte soltanto in funzione delle qualità richieste ai container dai loro progetti, scegliendo di volta in volta la condizione di stato più favorevole.

Oggi i container stateful e i container stateless non vanno pertanto visti come un aut aut categorico, ma possono essere sfruttati sinergicamente per sfruttare i loro pro in qualsiasi contesto lo renda necessario.