Aplicaciones con estado y sin estado: cómo afectan a DevOps

Stateful y Stateless son dos tipos diferentes de arquitectura informática que definen cómo una aplicación gestiona los procesos de larga duración. Algunos sistemas son inherentemente sin estado, mientras que otros tienden a ser modelados con estado. Cualquiera que sea el enfoque que elija, afectará la forma en que los equipos de diseño y operaciones construyen y mantienen la solución.

En este artículo, aprenderá sobre las diferencias entre las aplicaciones con estado y sin estado, y cuándo puede usar cada una. También verá cómo los dos modelos afectan los requisitos de una implementación de DevOps.

¿Qué es un estado?

El «estado» de un servicio es información persistente que se registra durante una transacción o evento y luego se llama durante otro. Uno de los ejemplos más simples de estado es un servidor de base de datos: administra los datos almacenados que deben almacenarse de forma segura. Un registro guardado en una sesión debe estar disponible para la próxima sesión.

El estado debe administrarse cuidadosamente para que pueda usarse en el futuro. Los sistemas externos no necesitan proporcionar mucha información para referirse a un evento anterior. Un identificador simple, como un número de transacción de pago, permite que el servicio recupere otros datos asociados con la acción, como el monto del pago y la dirección de envío.

¿Qué son las aplicaciones sin estado?

No todas las aplicaciones tienen un estado. Algunos sistemas no funcionan con datos de larga duración o los almacenan en caché solo para mejorar el rendimiento. Seguirán funcionando si se pierden los datos guardados anteriormente.

Las aplicaciones sin estado manejan cada evento de forma aislada. Los eventos no son conscientes entre sí ni del contexto más amplio en el que se ejecuta la aplicación. Esta cualidad simplifica la consideración de los sistemas sin estado. No hay riesgo de que la actividad anterior afecte la operación actual.

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

Algunas aplicaciones desdibujan las líneas entre modelos con estado y sin estado. Un mismo sistema se puede visualizar con o sin estado, según el punto de vista desde el que se lo aborde.

Las aplicaciones web del lado del cliente generalmente se consideran sin estado desde el punto de vista del operador del servicio. Se pueden alojar en un servidor web estático independiente de cualquier otro componente. La aplicación aún puede acumular estado durante el uso, como la configuración guardada en el dispositivo del usuario y el historial de páginas recientes. Esta forma de estado no es relevante para los equipos de DevOps porque no afecta la implementación de la aplicación.

Puede determinar si una aplicación necesita un modelo de implementación con estado o sin estado observando cómo almacena los datos. No hay estado si no hay persistencia o los datos solo se almacenan en el dispositivo del usuario o en un proveedor de almacenamiento no relacionado, como Amazon S3. Una aplicación persistirá en el estado si cambia directamente su entorno a través de escrituras en el sistema de archivos y otros cambios, y luego requiere que esos cambios persistan indefinidamente.

Estado con contenedores y nube

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

Sin embargo, los contenedores se pueden usar para encapsular sistemas con estado. Los volúmenes persistentes proporcionan un medio para montar un almacenamiento duradero que dura más que 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 interna de administrar el 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 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 garantizar que su aplicación escriba constantemente la ruta al volumen montado, por lo que debe determinar sus 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 utiliza servicios con estado o sin estado. Los modelos de implementación sin estado brindan mucho más margen de maniobra. Puede iniciar fácilmente nuevos contenedores y escalarlos en múltiples nodos distribuidos sin preocuparse por el acceso constante al estado.

Un servicio con estado requiere un enfoque de administración más reflexivo. Cada instancia de la aplicación debe tener acceso al estado compartido. Esto puede imponer restricciones de escala. Pocas distribuciones de Kubernetes permiten , por ejemplo, varios nodos para montar un volumen con acceso de escritura al mismo tiempo.

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 y determinar cuándo el montaje del volumen afecta las opciones de programación de contenedores. Las implementaciones con estado también deben ser compatibles con una estrategia de copia de seguridad normal.

El estado también complica el proceso DevOps al dificultar la reproducción precisa de los entornos. Es posible que el problema exista en la producción, mientras permanece esquivo en la máquina del 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 sobrecarga. Debe configurar y proporcionar soluciones de administración de estado, como volúmenes y bases de datos, lo que hace que las canalizaciones de integración continua sean más complejas y difíciles de mantener. 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 pista falsa 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 más trabajo por delante.

Resumen

La distinción entre aplicaciones con estado y sin estado es importante para el éxito de DevOps. Desde el punto de vista de DevOps, una aplicación con estado será más difícil de implementar y mantener porque necesita otorgar a cada instancia acceso a un almacén de datos persistente.

Las aplicaciones sin estado están completamente separadas de su entorno, lo que normalmente las hace más fáciles de contener y escalar en la nube. Sin embargo, los verdaderos sistemas sin estado son relativamente raros, por lo que generalmente se combinan 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 suele ser la forma más efectiva de equilibrar DevOps optimizado con los requisitos funcionales de su sistema.