Todos decían que fuéramos serverless. Nos quedamos con el clúster de Kubernetes que casi siempre está parado

El consejo está por todas partes y suena obviamente correcto. Gestionas autenticación para tenants cuyo tráfico es irregular. Pagas por un clúster de Kubernetes las veinticuatro horas. Azure Container Apps te escala a cero y solo te cobra por lo que usas. Deja de pagar por estar parado.

Nos lo tomamos en serio. Calculamos el coste de migrar a Azure Container Apps, examinamos a fondo qué nos aportaría y nos quedamos en AKS. Este es el razonamiento, porque no es el que adivinarías mirando el gráfico de utilización del clúster.

El consejo es correcto, para una carga de trabajo que no tenemos

Los contenedores serverless encajan a la perfección con el manejo de peticiones sin estado y a ráfagas: cada petición es independiente, las instancias son ganado y cero tráfico debería significar cero factura. Eso describe a muchísimos backends web.

No describe a un backplane de autenticación. El nuestro no está parado de la misma manera en que lo está una app sin estado. Mantiene el liderazgo del clúster y ejecuta la capa de coordinación que decide qué réplica realiza el trabajo singleton, como el barrido de retención y la pasada de webhooks. (Ese líder ahora lo elegimos con un lease de blob, ya no con gossip, lo cual es una historia aparte.) Que el clúster esté tranquilo no significa que no tenga nada que hacer; significa que está listo para validar el siguiente token y para seguir siendo el líder. Tranquilo e inactivo no son el mismo estado.

Eliminamos la factura de inactividad sin mudarnos

Aquí está la parte que lo decidió: el coste del que intentábamos escapar tenía un arreglo mucho más barato que replataformar.

Lo que drenaba el dinero eran nodos corriendo 24/7 mientras el tráfico se concentraba en horario laboral. Así que hicimos que el clúster de desarrollo se desasignara cuando nadie lo usa (apagado por la noche y los fines de semana, y de vuelta bajo demanda) y cambiamos el grupo de nodos a una SKU más barata. Eso eliminó la mayor parte del gasto de inactividad que el serverless prometía quitar, y nos costó un cambio de configuración en lugar de una migración. Cuando los ahorros que quieres se pueden lograr in situ, replataformar para perseguir la misma cifra es mucho riesgo por una diferencia que ya capturaste.

La lección se generaliza: pon precio al arreglo antes de poner precio a la replataformación. «Deja de pagar por estar parado» es un objetivo, no una arquitectura, y la forma más barata de alcanzarlo suele ser un planificador y una SKU, no un runtime nuevo.

El escalado a cero pelea contra un backplane que tiene que mantener un lease

Incluso dejando de lado el coste, el escalado a cero es directamente erróneo para esta carga de trabajo en dos sentidos.

Primero, los arranques en frío caen en el peor camino posible. La petición que paga el impuesto del arranque en frío es la de alguien que intenta iniciar sesión, y «tu inicio de sesión fue lento porque nuestro servicio de autenticación estaba dormido» no es una frase que quieras enviar.

Segundo, el liderazgo y el escalado a cero están en conflicto directo. No puedes mantener un lease desde una instancia que ha sido escalada hasta desaparecer. Un backplane cuyo único trabajo es tener siempre exactamente un líder vivo no quiere un runtime cuyo único trabajo es eliminar instancias cuando parecen tranquilas. Estaríamos peleando contra el comportamiento central de la plataforma para preservar el nuestro.

El runtime nos habría quitado tres cosas que usamos

Migrar no es gratis ni siquiera donde funciona; heredas el sandbox del runtime gestionado, y el nuestro bloquea cosas de las que dependemos:

• Twingate. Llegamos a los recursos privados a través de un conector de Twingate. El sandbox de contenedores gestionados no lo ejecuta, así que estaríamos reinventando un acceso a red privada que ya tenemos.
• Nuestra ruta de build. Partes de nuestro pipeline se apoyan en Docker-in-Docker y az acr build contra un registro privado, ambas cosas que el sandbox prohíbe. Eso es un sistema de build que reconstruir, no solo un destino de despliegue que cambiar.
• El control cross-cloud. Ejecutamos un standby en AWS que valida tokens emitidos por el primario de Azure, mediante JWKS federados, con Cloudflare como árbitro de failover. Eso requiere un control de red y de ubicación que un runtime gestionado oculta deliberadamente.

Cada una de estas es una solución alternativa que tendríamos que escribir solo para volver a donde ya estamos. El verdadero coste de la migración no es el cambio; es volver a ganar cada capacidad que el sandbox quita.

Ahorrar coste tiene su cola, y la pagamos

Quedarse tampoco es libre de consecuencias, y lo honesto es decirlo. Desasignar nodos por la noche nos dio un fallo que nunca habríamos visto en un clúster siempre encendido: una carrera por el token del primer pull de imagen en nodos fríos (la del issue 4052 de AKS) que de vez en cuando atascaba el arranque de un pod tras encender de nuevo el clúster. Lo arreglamos con un timeout de rollout más largo y, en producción, no desasignando como hace desarrollo.

Esa es la verdadera forma del compromiso. Cada camino tiene su cola de modos de fallo; la pregunta es si puedes verlos y arreglarlos. En AKS, la carrera de nodos fríos era inspeccionable y reparable. Las clases de rarezas que heredas de las entrañas de un runtime gestionado son de las que abres un ticket de soporte y esperas.

La regla que nos llevamos

Dos cosas, reutilizables más allá de nosotros. No migres para escapar de un coste que puedes matar donde estás; pon precio primero al arreglo in situ, porque un planificador y una SKU más barata le ganan a una replataformación la mayoría de las veces. Y haz que el runtime encaje con la forma de la carga de trabajo: el serverless premia lo sin estado y a ráfagas y castiga lo con estado y siempre encendido, y un núcleo de autenticación que guarda tus claves de firma y el liderazgo de tu clúster es firmemente del segundo tipo.

No estamos en contra del serverless. Buena parte de nuestra superficie sin estado estaría bien ahí. Pero la parte que guarda tus claves y decide quién ejecuta los trabajos destructivos va a seguir corriendo sobre una infraestructura aburrida, siempre encendida e inspeccionable. A veces el clúster que parece parado es la opción barata, una vez que cuentas todo lo que tendrías que reconstruir para abandonarlo.

La infraestructura siempre activa e inspeccionable bajo tus inicios de sesión es una función, no un descuido. Es exactamente lo que delegas cuando ejecutas la autenticación con Authagonal en lugar de operar el backplane tú mismo.