El consejo siempre tuvo la misma forma. Tu tráfico de autenticación llega en picos. Tu clúster de Kubernetes está mayormente en silencio. Azure Container Apps escala a cero y te cobra por lo que usas. Estás pagando las 24 horas del día por un clúster que pasa la mayor parte de su vida esperando.
Lo tomamos en serio hasta el punto de calcular correctamente el costo de la migración. Luego la descartamos. No por el precio de la transición, ni por los arranques en frío, aunque los arranques en frío solos deberían haber sido suficientes. La descartamos porque al vocabulario de la plataforma le falta un número, y es el único número que realmente le importa a nuestro núcleo de autenticación.
Serverless cuenta hasta cero y hasta N
Los runtimes de scale-to-zero conocen dos números. Cero, cuando nadie llama. N, cuando lo hacen, con N flotando según la demanda. Para el manejo de solicitudes sin estado, ese vocabulario es perfecto, razón por la cual el consejo suena tan bien. La mayoría de los backends web realmente tienen esa forma: cada solicitud independiente, cada instancia desechable, cero tráfico mereciendo una factura de cero.
La cara pública de un sistema de autenticación se ve así también. Puntos finales de tokens, páginas de inicio de sesión, JWKS. Sin estado, con picos, amigable con la caché.
Debajo hay una capa que no es nada de eso.
El número es uno
Bajo los puntos finales, nuestra backplane ejecuta una capa de coordinación. En cualquier momento, exactamente una réplica tiene el arrendamiento de liderazgo del clúster (un arrendamiento de blob hoy en día, ya no gossip, que es una historia para otra publicación) y ejecuta los trabajos singleton: el barrido de retención, el pase de entrega de webhooks, el trabajo donde dos ejecutores concurrentes significan efectos secundarios disparados por duplicado y cero ejecutores significa que las cosas, silenciosamente, no suceden nunca.
El número que esa capa necesita es uno. No cero cuando todo está tranquilo. No N bajo carga. Uno, mantenido continuamente, con una transferencia verificable cuando el titular muere. El scale-to-zero no tiene forma de decir "uno, siempre". Puede decir "al menos uno mientras haya tráfico", lo cual es una promesa diferente, y la diferencia entre esas dos promesas es exactamente el modo de fallo que una elección de líder existe precisamente para prevenir.
Por eso el gráfico de utilización nos estaba mintiendo. Un clúster de autenticación tranquilo no está de brazos cruzados. Está manteniendo un arrendamiento, manteniendo las claves de firma calientes y listo para responder a la siguiente validación de token en milisegundos de un solo dígito. Silencioso e inactivo son estados diferentes, y los paneles de facturación solo te muestran uno de ellos.
Puedes fingirlo, y eso es peor
Puedes forzar "exactamente uno" en un runtime serverless. Fija las réplicas mínimas en uno y has comprado un servidor siempre activo en una plataforma cuyo instinto completo es quitarte las instancias silenciosas. Cada evento de escalado, cada reinicio iniciado por la plataforma, cada cambio de revisión se convierte en una cuestión de liderazgo cuyo momento no controlas. Estaríamos luchando contra el comportamiento central del runtime para preservar el nuestro, para siempre, y pagando por el privilegio.
Y el fallo recae sobre la peor persona posible. La solicitud que paga un arranque en frío es un humano tratando de iniciar sesión. "Tu inicio de sesión fue lento porque nuestro servicio de autenticación estaba dormido" no es una frase que nadie debería llegar a publicar.
La factura tuvo una solución aburrida
¿Y el dinero con el que empezó todo esto? Bastaron un planificador y una SKU. El clúster de desarrollo ahora se desasigna cuando nadie lo está usando, y el grupo de nodos pasó a una SKU más barata. Un párrafo es todo lo que eso merece, y ese es el punto: "dejar de pagar por inactividad" es un objetivo, no una arquitectura, y la mayor parte del objetivo era alcanzable con un cambio de configuración en lugar de un cambio de plataforma.
La prueba de forma
La regla que nos quedamos: hacer coincidir el runtime con la forma real de la carga de trabajo, no con su gráfico de tráfico. Serverless recompensa lo que es sin estado y a ráfagas. Castiga cualquier cosa que deba mantener un rol continuo y exclusivo, y un núcleo de autenticación que protege las claves de firma y elige quién ejecuta los trabajos destructivos es el ejemplo más puro de ese segundo tipo que conocemos.
No estamos en contra del serverless. Gran parte de nuestra superficie sin estado viviría felizmente en él. Pero la capa que tiene que contar exactamente hasta uno se queda en una infraestructura aburrida, siempre activa e inspeccionable.
Esa capa es también precisamente lo que dejas de operar cuando ejecutas la autenticación en Authagonal en lugar de ejecutar la backplane tú mismo.
Top comments (0)