Applicazioni stateful e stateless: come influiscono su DevOps

Stateful e Stateless sono due diversi tipi di architettura di calcolo che definiscono il modo in cui un’applicazione gestisce i processi di lunga durata. Alcuni sistemi sono intrinsecamente apolidi, mentre altri tendono a essere modellati con stato. Qualunque approccio tu scelga, influenzerà il modo in cui i team di progettazione e operazioni costruiscono e mantengono la soluzione.

In questo articolo imparerai le differenze tra app stateful e stateless e quando puoi usarle. Vedrai anche come i due modelli influiscono sui requisiti di un’implementazione DevOps.

Che cos’è uno stato?

Lo “stato” di un servizio è un’informazione persistente che viene registrata durante una transazione o evento e poi richiamata durante un’altra. Uno degli esempi più semplici di stato è un server di database: gestisce i dati archiviati che devono essere archiviati in modo sicuro. Un record salvato in una sessione deve essere disponibile per la sessione successiva.

Lo stato deve essere gestito con attenzione in modo che possa essere utilizzato in futuro. I sistemi esterni non devono fornire molte informazioni per fare riferimento a un evento precedente. Un semplice identificatore, come un numero di transazione di pagamento, consente al servizio di recuperare altri dati associati all’azione, come l’importo del pagamento e l’indirizzo di spedizione.

Cosa sono le applicazioni apolidi?

Non tutte le applicazioni hanno uno stato. Alcuni sistemi non funzionano con dati di lunga durata o li memorizzano nella cache solo per migliorare le prestazioni. Continueranno a funzionare se i dati salvati in precedenza vengono persi.

Le applicazioni stateless gestiscono ogni evento in isolamento. Gli eventi non sono a conoscenza l’uno dell’altro o del contesto più ampio in cui è in esecuzione l’applicazione. Questa qualità semplifica la considerazione dei sistemi senza stato. Non vi è alcun rischio che l’attività precedente influisca sull’operazione in corso.

La mia applicazione è stateful o stateless?

Alcune applicazioni confondono il confine tra modelli stateful e stateless. Lo stesso sistema può essere visualizzato con o senza stato, a seconda del punto di vista da cui ci si avvicina.

Le applicazioni Web lato client sono generalmente viste come stateless dal punto di vista dell’operatore del servizio. Possono essere ospitati su un server Web statico indipendente da qualsiasi altro componente. L’applicazione potrebbe comunque accumulare stato durante l’uso, come le impostazioni salvate sul dispositivo dell’utente e la cronologia delle pagine recenti. Questa forma di stato non è rilevante per i team DevOps perché non influisce sulla distribuzione dell’applicazione.

È possibile determinare se un’applicazione necessita di un modello di distribuzione con stato o senza stato osservando il modo in cui archivia i dati. Non esiste uno stato se non c’è persistenza o se i dati sono archiviati solo sul dispositivo dell’utente o in un provider di archiviazione non correlato come Amazon S3. Un’applicazione manterrà lo stato se cambia direttamente il proprio ambiente tramite scritture di file system e altre modifiche e quindi richiede che tali modifiche persistano a tempo indeterminato.

Stato con container e cloud

Le applicazioni moderne vengono spesso distribuite nel cloud come contenitori. I contenitori sono progettati come unità effimere di funzionalità che possono essere sostituite senza effetti collaterali. Ciò significa che sono componenti computazionali prevalentemente stateless.

Tuttavia, i contenitori possono essere utilizzati per incapsulare sistemi con stato. I volumi persistenti forniscono un mezzo per montare uno storage durevole che sopravvive alle singole istanze di container. Rispetto alle VM tradizionali e alle distribuzioni bare metal, la differenza si riduce all’intenzionalità interna della gestione dello stato del contenitore.

La containerizzazione di un sistema con stato richiede di anticipare dove si verifica lo stato e come viene archiviato. Non puoi scrivere ingenuamente percorsi di filesystem arbitrari perché non verranno mappati su un volume. Senza un volume, i dati andranno persi se il contenitore si interrompe o viene sostituito. Potrebbe essere necessario un periodo di refactoring per garantire che l’applicazione scriva in modo coerente il percorso del volume montato, quindi è necessario determinare in anticipo i requisiti di archiviazione dei dati.

In che modo lo stato influisce su DevOps

I processi DevOps devono essere modificati a seconda che utilizzi servizi con stato o senza stato. I modelli di distribuzione stateless offrono molto più margine di manovra. Puoi facilmente avviare nuovi contenitori e ridimensionarli su più nodi distribuiti senza preoccuparti dell’accesso costante allo stato.

Un servizio con stato richiede un approccio più ponderato alla gestione. A ciascuna istanza dell’applicazione deve essere concesso l’accesso allo stato condiviso. Ciò potrebbe imporre restrizioni di ridimensionamento. Poche distribuzioni Kubernetes consentono , ad esempio, a più nodi di montare un volume con accesso in scrittura contemporaneamente.

Entrambi i tipi di applicazioni richiedono un monitoraggio proattivo in modo da essere a conoscenza dei problemi prima che si verifichino. Questo è più importante per le soluzioni stateful perché è necessario anticipare i requisiti di archiviazione e determinare quando il montaggio del volume influisce sulle opzioni di pianificazione dei container. Le distribuzioni con stato dovrebbero anche essere supportate da una normale strategia di backup.

Lo stato complica anche il processo DevOps rendendo difficile la riproduzione accurata degli ambienti. Diventa possibile che il problema esista in produzione, pur rimanendo sfuggente sulla macchina dello sviluppatore. Questi problemi possono essere difficili da diagnosticare. Puoi renderli più gestibili fornendo agli sviluppatori meccanismi per clonare gli ambienti in modo che possano riprodurre i problemi in una sandbox.

Lo stato aggiunge sempre complessità e sovraccarico. È necessario configurare e fornire soluzioni di gestione dello stato come volumi e database, il che rende le pipeline di integrazione continua più complesse e difficili da mantenere. Lo stato è inevitabile nella maggior parte delle applicazioni principali, quindi cercare di mantenere i sistemi senza stato può essere un’inutile falsa pista. È meglio utilizzare strumenti e formazione per integrare perfettamente le applicazioni stateful nelle routine DevOps, anche se ciò significa più lavoro da fare.

Riepilogo

La distinzione tra applicazioni stateful e stateless è importante per il successo di DevOps. Da un punto di vista DevOps, un’applicazione con stato sarà più difficile da distribuire e mantenere perché è necessario fornire a ciascuna istanza l’accesso a un archivio dati persistente.

Le applicazioni stateless sono completamente separate dal loro ambiente, il che in genere le rende più facili da containerizzare e ridimensionare nel cloud. Tuttavia, i veri sistemi stateless sono relativamente rari, quindi di solito sono combinati con archivi dati con stato. Il refactoring su componenti stateless, ove possibile, durante la creazione di strumenti per supportare le distribuzioni stateful è in genere il modo più efficace per bilanciare DevOps ottimizzati con i requisiti funzionali del sistema.