Aplicaciones con estado frente a aplicaciones sin estado: cómo afectan a DevOps

Estudio Shutterstock.com/Deemerwha

Stateful y Stateless son dos tipos diferentes de arquitectura informática que determinan cómo una aplicación gestiona los procesos de larga duración. Algunos sistemas son naturalmente sin estado, mientras que otros tienen un sesgo hacia el modelado con estado. Cualquiera que sea el enfoque que elija, afectará la forma en que los equipos de ingeniería y operaciones construyen y mantienen la solución.

En este artículo, aprenderá las diferencias entre aplicaciones con estado y sin estado, así como también cuándo se puede usar cada una. También verá cómo los dos modelos influyen en los requisitos de las implementaciones de DevOps.

Índice de contenidos
  1. ¿Qué es el estado?
  2. ¿Qué son las aplicaciones sin estado?
  3. ¿Mi aplicación es con estado o sin estado?
  4. Estado Con Contenedores y la Nube
  5. Cómo afecta el estado a DevOps
  6. Resumen

¿Qué es el estado?

El "estado" de un servicio es la información persistente que se registra durante una transacción o evento y luego se recupera durante otro. Uno de los ejemplos más simples de estado es un servidor de base de datos: administra los datos almacenados que deben persistir de manera confiable. Un registro guardado en una sesión deberá poder recuperarse en la siguiente.

El estado debe administrarse con cuidado para que se pueda utilizar en el futuro. Los sistemas externos no deberían necesitar proporcionar mucha información para hacer referencia a un evento anterior. Una identificación simple, como un número de transacción de pago, permite que el servicio restaure el resto de los datos asociados con la actividad, como el monto del pago y la dirección de envío.

¿Qué son las aplicaciones sin estado?

No todas las aplicaciones tienen estado. Algunos sistemas no funcionan con datos de larga duración o solo los almacenan en caché para mejorar el rendimiento. Todavía se ejecutarán si se pierden los datos almacenados anteriormente.

Las aplicaciones sin estado manejan cada evento de forma aislada. Los eventos no tienen conocimiento entre sí ni del contexto más amplio en el que opera la aplicación. Esta cualidad hace que los sistemas sin estado sean más fáciles de razonar. No hay riesgo de que la actividad anterior esté afectando una operación actual.

¿Mi aplicación es con estado o sin estado?

Algunas aplicaciones desdibujan las líneas entre los modelos con estado y sin estado. El mismo sistema podría considerarse tanto con estado como sin estado, según la perspectiva desde la que lo aborde.

Las aplicaciones web del lado del cliente generalmente se consideran sin estado desde el punto de vista de un operador de servicios. Pueden estar alojados en un servidor web estático, independientemente de cualquier otro componente. La aplicación aún puede acumular estado durante el uso, como configuraciones guardadas en el dispositivo del usuario y un historial de páginas recientes. Esta forma de estado no es relevante para los equipos de DevOps, ya que no afecta la forma en que se implementa la aplicación.

Puede identificar si una aplicación necesita un modelo de implementación con estado o sin estado observando cómo almacena los datos. El estado no está presente cuando no hay persistencia o los datos solo se almacenan en el dispositivo del usuario o en un proveedor de almacenamiento desacoplado como Amazon S3. La aplicación tendrá estado si modifica directamente su entorno a través de escrituras en el sistema de archivos y otros cambios, luego requiere que esas modificaciones persistan indefinidamente.

Estado Con Contenedores y la Nube

Las aplicaciones modernas a menudo se implementan en la nube como contenedores. Los contenedores están diseñados para ser unidades efímeras de funcionalidad que se pueden reemplazar sin efectos secundarios. Esto significa que son predominantemente componentes informáticos sin estado.

Sin embargo, los contenedores se pueden utilizar para encapsular sistemas con estado. Los volúmenes persistentes proporcionan un medio para adjuntar almacenamiento confiable que sobrevive a las instancias de contenedores individuales. En comparación con las máquinas virtuales tradicionales y las implementaciones completas, la diferencia se reduce a la intencionalidad inherente de la gestión del estado del contenedor.

Contenerizar un sistema con estado requiere que usted anticipe dónde ocurre el estado y cómo se almacena. No puede escribir ingenuamente en rutas arbitrarias del sistema de archivos porque no se asignarán a un volumen. Sin un volumen, los datos se perderán si el contenedor se detiene o se reemplaza. Es posible que se requiera un período de refactorización para que su aplicación escriba constantemente en una ruta de volumen montada, por lo que debe identificar los requisitos de almacenamiento de datos con anticipación.

Cómo afecta el estado a DevOps

Los procesos de DevOps deben ajustarse en función de si está ejecutando servicios con estado o sin estado. Los modelos de implementación sin estado brindan mucha más libertad operativa. Puede lanzar fácilmente nuevos contenedores y escalarlos en varios nodos distribuidos sin tener que pensar en el acceso de estado persistente.

Un servicio con estado requiere un enfoque de administración más reflexivo. Cada instancia de la aplicación debe contar con acceso al estado compartido. Esto puede imponer restricciones en la forma de escalar. Pocas distribuciones de Kubernetes permiten que múltiples Nodos monten simultáneamente un volumen con acceso de escritura, por ejemplo.

Ambos tipos de aplicaciones requieren una supervisión proactiva para que esté al tanto de los problemas antes de que ocurran. Esto es más importante para las soluciones con estado porque necesita adelantarse a los requisitos de almacenamiento e identificar cuándo las opciones de programación de contenedores se ven afectadas por los montajes de volumen. Las implementaciones con estado también deberán estar respaldadas por una estrategia de copia de seguridad regular.

El estado también complica el proceso de DevOps al dificultar la reproducción exacta de los entornos. Es posible que exista un problema en producción mientras permanece esquivo en la máquina de un desarrollador. Estos problemas pueden ser difíciles de diagnosticar. Puede hacerlos más manejables proporcionando mecanismos para que los desarrolladores clonen entornos para que puedan reproducir problemas en un espacio aislado.

El estado siempre agrega complejidad y gastos generales. Debe configurar y proporcionar soluciones de administración de estado, como volúmenes y bases de datos, lo que hace que las canalizaciones de CI sean más complicadas y difíciles de mantener. Sin embargo, el estado es inevitable en la mayoría de las aplicaciones principales, por lo que esforzarse demasiado para mantener los sistemas sin estado puede ser una distracción inútil. Es mejor usar herramientas y capacitación para integrar sin problemas las aplicaciones con estado en sus rutinas de DevOps, incluso si eso significa que habrá más trabajo por adelantado.

Resumen

Distinguir entre aplicaciones con estado y sin estado es importante para el éxito de DevOps. Visto desde una perspectiva de DevOps, una aplicación con estado será más compleja de implementar y mantener porque necesita proporcionar a cada instancia acceso a un almacén de datos persistente.

Las aplicaciones sin estado están completamente desacopladas de su entorno, lo que generalmente las hace más fáciles de contener y escalar en la nube. Sin embargo, los sistemas verdaderamente sin estado son relativamente raros, por lo que normalmente los combinará con almacenes de datos con estado. La refactorización a componentes sin estado siempre que sea posible, mientras se crean herramientas para admitir implementaciones con estado al mismo tiempo, es normalmente la forma más efectiva de equilibrar DevOps optimizado con los requisitos funcionales de su sistema.

Descubre más contenido

Subir Change privacy settings