[ad_1]
Stateful e Stateless são dois tipos diferentes de arquitetura de computação que determinam como um aplicativo lida com processos de longa execução. Alguns sistemas são naturalmente sem estado, enquanto outros têm uma tendência para a modelagem com estado. Qualquer que seja a abordagem escolhida, afetará como as equipes de engenharia e operações constroem e mantêm a solução.
Neste artigo, você aprenderá as diferenças entre aplicativos com e sem estado, bem como quando cada um pode ser usado. Você também verá como os dois modelos influenciam os requisitos das implementações de DevOps.
Qual é o estado?
O “estado” de um serviço é a informação persistente que é registrada durante uma transação ou evento e então recuperada durante outra. Um dos exemplos mais simples de estado é um servidor de banco de dados: ele gerencia dados armazenados que devem ser persistidos de forma confiável. Um registro salvo em uma sessão deve poder ser recuperado na próxima.
O estado deve ser administrado com cuidado para que possa ser usado no futuro. Os sistemas externos não precisam fornecer muitas informações para fazer referência a um evento anterior. Uma simples identificação, como um número de transação de pagamento, permite que o serviço restaure o restante dos dados associados à atividade, como o valor do pagamento e o endereço de entrega.
O que são aplicativos sem estado?
Nem todos os aplicativos têm estado. Alguns sistemas não funcionam com dados de longa duração ou apenas os armazenam em cache para melhorar o desempenho. Eles ainda serão executados se os dados armazenados anteriormente forem perdidos.
Os aplicativos sem estado lidam com cada evento isoladamente. Os eventos não têm conhecimento um do outro ou do contexto maior no qual o aplicativo opera. Essa qualidade torna os sistemas sem estado mais fáceis de raciocinar. Não há risco de que a atividade anterior esteja afetando uma operação atual.
Meu aplicativo é com estado ou sem estado?
Alguns aplicativos confundem as linhas entre modelos com e sem estado. O mesmo sistema pode ser considerado com e sem estado, dependendo de qual perspectiva você o aborda.
Os aplicativos da Web do lado do cliente são geralmente considerados sem estado do ponto de vista de um operador de serviço. Eles podem ser hospedados em um servidor web estático, independente de quaisquer outros componentes. O aplicativo ainda pode acumular estado durante o uso, como configurações salvas no dispositivo do usuário e histórico de páginas recentes. Essa forma de status não é relevante para equipes de DevOps, pois não afeta como o aplicativo é implantado.
Você pode identificar se um aplicativo precisa de um modelo de implantação com ou sem estado observando como ele armazena dados. O estado não está presente quando não há persistência ou os dados são armazenados apenas no dispositivo do usuário ou em um provedor de armazenamento desacoplado, como o Amazon S3. O aplicativo terá estado se modificar diretamente seu ambiente por meio de gravações do sistema de arquivos e outras alterações e, em seguida, exigir que essas modificações persistam indefinidamente.
Estado com contêineres e a nuvem
Os aplicativos modernos geralmente são implantados na nuvem como contêineres. Os contêineres são projetados para serem unidades de funcionalidade de curta duração que podem ser substituídas sem efeitos colaterais. Isso significa que eles são predominantemente componentes de computação sem estado.
No entanto, os contêineres podem ser usados para encapsular sistemas com estado. Volumes persistentes fornecem um meio de anexar armazenamento confiável que dura mais que instâncias de contêiner individuais. Em comparação com máquinas virtuais tradicionais e implantações completas, a diferença se resume à intencionalidade inerente do gerenciamento de estado do contêiner.
A conteinerização de um sistema com estado requer que você antecipe onde o estado ocorre e como ele é armazenado. Você não pode gravar ingenuamente em caminhos de sistema de arquivos arbitrários porque eles não serão mapeados para um volume. Sem um volume, os dados serão perdidos se o contêiner for interrompido ou substituído. Um período de refatoração pode ser necessário para que seu aplicativo grave consistentemente em um caminho de volume montado, portanto, identifique seus requisitos de armazenamento de dados com antecedência.
Como o status afeta o DevOps
Os processos de DevOps precisam ser ajustados com base no fato de você estar executando serviços com ou sem estado. Os modelos de implantação sem estado fornecem muito mais liberdade operacional. Você pode facilmente iniciar novos contêineres e escalá-los em vários nós distribuídos sem ter que pensar em acesso de estado persistente.
Um serviço com estado requer uma abordagem de gerenciamento mais cuidadosa. Cada instância do aplicativo deve ter acesso ao estado compartilhado. Isso pode impor restrições sobre como você dimensiona. Poucas distribuições do Kubernetes permitem que vários nós montem simultaneamente um volume com acesso de gravação, por exemplo.
Ambos os tipos de aplicativos exigem monitoramento proativo para que você esteja ciente dos problemas antes que eles ocorram. Isso é mais importante para soluções com estado porque você precisa estar à frente dos requisitos de armazenamento e identificar quando as opções de agendamento de contêiner são afetadas pelas montagens de volume. As implantações com estado também precisarão ser apoiadas por uma estratégia de backup regular.
O estado também complica o processo de DevOps, dificultando a reprodução precisa de ambientes. É possível que um problema exista na produção enquanto permanece indescritível na máquina de um desenvolvedor. Esses problemas podem ser difíceis de diagnosticar. Você pode torná-los mais gerenciáveis fornecendo mecanismos para os desenvolvedores clonarem ambientes para que possam reproduzir problemas em um sandbox.
O estado sempre adiciona complexidade e sobrecarga. Você deve configurar e provisionar soluções de gerenciamento de estado, como volumes e bancos de dados, o que torna os pipelines de CI mais complicados e difíceis de manter. No entanto, o estado é inevitável na maioria dos aplicativos convencionais, portanto, tentar muito manter os sistemas sem estado pode ser uma distração inútil. É melhor usar ferramentas e treinamento para integrar perfeitamente aplicativos com estado em suas rotinas de DevOps, mesmo que isso signifique mais trabalho inicial.
Resumo
A distinção entre aplicativos com estado e sem estado é importante para o sucesso do DevOps. Visto da perspectiva do DevOps, um aplicativo com estado será mais complexo de implantar e manter porque precisa fornecer a cada instância acesso a um armazenamento de dados persistente.
Os aplicativos sem estado são completamente desacoplados de seu ambiente, o que geralmente os torna mais fáceis de conter e dimensionar na nuvem. No entanto, sistemas realmente sem estado são relativamente raros, então você normalmente os combina com armazenamentos de dados com estado. Refatorar para componentes sem estado sempre que possível, enquanto cria ferramentas para dar suporte a implantações com estado ao mesmo tempo, é normalmente a maneira mais eficaz de equilibrar o DevOps otimizado com os requisitos funcionais do seu sistema.
[ad_2]
