Crea una cuenta o inicia sesión

¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera

Stateless y statefull en alta concurrencia

4/17
Recursos

Aportes 8

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Para construir una arquitectura de alta concurrencia no cabe duda que tambien es necesario ayuda de los devs, ya que las apps a desplegar escalaran mejor si son stateless (no siempre se puede pero se prefiere que sean asi).

Una buena practica para que las app que los devs construyan sean escalables (por ende que soporten la alta concurrencia) es que sean Dockerizables, para esto existe una serie de “normas” que deben cumplir llamada The twelve-factor app https://12factor.net/es/

en la recomendacion 6, es donde se menciona que sean stateless

Stateless y statefull en alta concurrencia

Stateless: El estado está fuera de la aplicación.
Statefull: El estado está dentro de la aplicación.

Un servidor stateless lo puedo crear sin el servidor viejo, pero un servidor statefull como el de una base de datos se necesitan los registros del historial, es decir, guarda ESTADOS como lo podrían ser los registros.

Es preferible que una aplicación sea stateless.

Stateless(fuera de la aplicación) no necesito historial del servidor para crear un replica y Statefull, necesito el historial como bd.

Stateless significa que el estado, como su nombre lo indica, está fuera de la aplicación; y stateful, lo contrario.

Pongamos como ejemplo un servicio de procesamiento de datos: este servicio recibe un dato, lo procesa, y cuando termina lo entrega a un recurso externo o lo devuelve. Hubo un momento en el flujo en donde el dato estuvo en el servidor, pero sencillamente podríamos reemplazar ese servidor por uno nuevo y debería ser capaz de manejar cualquier petición que reciba sin necesidad de tener un historial de los servidores antiguos.

Podemos crear un servidor stateless sin necesidad de tener el servidor viejo; un servidor stateful necesita sí o sí el historial del servidor anterior (por ejemplo, una base de datos).

Como SREs, queremos que las aplicaciones siempre sean stateless.

Un ejemplo claro para un servidor stateful, sería un servidor de Wordpress que almacena tanto la base de datos como los archivos multimedia dentro de su disco duro. En caso de que se quisiera reemplazar ese servidor, tendríamos que copiar toda su información para llevarla al servidor nuevo; y si quisiéramos escalarlo horizontalmente, necesitaríamos que toda esa información esté en todos los servidores.

Para el equipo de infraestructura siempre va a ser más fácil manejar servidores stateless, porque así pueden escalar muy fácilmente.

Que excelente este curso

Entendido y a ponerlo en práctica

Me encanta como explica estos dos conceptos que suelen ser complejos, parafraseando dijo:
Stateless significa que el estado esta fuera de la aplicación (ej. servicio de procesamiento de datos) donde un servidor deberia poder manejar cualquier request sin tener el historial de los request anteriores y Statefull lo contrario (ej. base de datos).