Stateful vs stateless

Lo stato di un’applicazione (o qualsiasi altra cosa, in realtà) è la sua condizione o qualità di essere in un dato momento nel tempo – il suo stato di essere. Se qualcosa è stateful o stateless dipende da quanto tempo lo stato dell’interazione con esso viene registrato e da come questa informazione deve essere memorizzata.

Senza stato

Un processo o un’applicazione senza stato può essere compreso in modo isolato. Non c’è alcuna conoscenza memorizzata di o riferimento a transazioni passate. Ogni transazione è fatta come se partisse da zero per la prima volta. Le applicazioni apolidi forniscono un servizio o una funzione e usano la rete di consegna dei contenuti (CDN), il web o i server di stampa per elaborare queste richieste a breve termine.

Un esempio di una transazione apolide sarebbe fare una ricerca online per rispondere a una domanda a cui si è pensato. Si digita la domanda in un motore di ricerca e si preme invio. Se la vostra transazione viene interrotta o chiusa accidentalmente, ne iniziate una nuova. Pensate alle transazioni senza stato come a un distributore automatico: una singola richiesta e una risposta.

Stateful

Le applicazioni e i processi statici, invece, sono quelli a cui si può tornare più volte, come l’online banking o la posta elettronica. Vengono eseguiti con il contesto delle transazioni precedenti e la transazione corrente può essere influenzata da ciò che è successo durante le transazioni precedenti. Per queste ragioni, le app stateful utilizzano gli stessi server ogni volta che elaborano una richiesta da parte di un utente.

Se una transazione stateful viene interrotta, il contesto e la storia sono stati memorizzati in modo da poter più o meno riprendere da dove si era interrotta. Le app stateful tengono traccia di cose come la posizione della finestra, le preferenze di impostazione e l’attività recente. Si può pensare alle transazioni stateful come a una conversazione periodica in corso con la stessa persona.

La maggior parte delle applicazioni che usiamo quotidianamente sono stateful, ma con l’avanzare della tecnologia, i microservizi e i container rendono più facile costruire e distribuire applicazioni nel cloud.

Contenitori e stato

Come il cloud computing e i microservizi crescono in popolarità, così anche la containerizzazione delle applicazioni, sia statiche che senza stato. I contenitori sono unità di codice per un’applicazione che vengono impacchettate, insieme alle loro librerie e dipendenze, in modo che possano essere spostate facilmente e possano essere eseguite in qualsiasi ambiente, sia su un desktop, un’infrastruttura IT tradizionale o su un cloud.

In origine, i container sono stati costruiti per essere senza stato, in quanto questo si adattava alla loro natura portatile e flessibile. Ma man mano che i container sono diventati di uso più diffuso, la gente ha iniziato a containerizzare (riprogettando e reimpacchettando per l’esecuzione dai container) le app statiche esistenti. Questo ha dato loro la flessibilità e la velocità dell’uso dei container, ma con la memorizzazione e il contesto dello statefulness.

A causa di questo, le applicazioni stateful possono assomigliare molto a quelle stateless e viceversa. Per esempio, potreste avere un’applicazione stateless, che non richiede memorizzazione a lungo termine, ma che permette al server di tracciare le richieste provenienti dallo stesso client usando i cookie.

Gestione dei container stateless e stateful

Con la crescita della popolarità dei container, le aziende hanno iniziato a fornire modi per gestire sia i container stateless che quelli stateful utilizzando l’archiviazione dei dati, Kubernetes e StatefulSet. Lo statefulness è ora una parte importante dello storage dei container e la domanda è diventata non se usare container stateful, ma quando.

Se usare o meno i container stateful o stateless si riduce a una questione di che tipo di app state costruendo e cosa avete bisogno di fare. Stateless è la strada da percorrere se avete solo bisogno di informazioni in modo transitorio, velocemente e temporaneamente. Se la vostra applicazione richiede più memoria di ciò che accade da una sessione all’altra, tuttavia, lo stateful potrebbe essere la strada da percorrere.

Stateful, stateless, e Red Hat

Quando si tratta di stateful o stateless, Red Hat vi copre. Che tu stia orchestrando container statici sulla nostra piattaforma Kubernetes, Red Hat OpenShift, pronta per l’impresa, o creando un ambiente unificato per lo sviluppo di app con Red Hat Integration, sarai supportato dal nostro pluripremiato supporto e dal più grande ecosistema di partner del settore.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *