Cloud Edición diaria
CLOUD KUBERNETES Y PLATAFORMAS
La nube de agentes debe gobernar el estado, además del cómputo
Las novedades de Azure y las propuestas de ejecución sobre GKE revelan una tensión común: aprovechar sesiones persistentes sin convertirlas en depósitos de permisos y datos olvidados.
La semana ha llevado a primer plano las plataformas que ejecutan herramientas y código para agentes. Azure ha comunicado la disponibilidad general de Container Apps Sandboxes, mientras Agent Substrate para GKE, anunciado el 15 de septiembre, aporta otro enfoque sobre el mismo problema. No son lanzamientos simultáneos ni productos intercambiables. Comparten, sin embargo, una pregunta operativa: cómo sostener muchas sesiones que alternan trabajo y espera sin reservar una máquina completa para cada una durante toda su vida.
Google describe un entorno abierto sobre Kubernetes que suspende sesiones y libera recursos, con opciones de aislamiento mediante microVMs o gVisor. La disponibilidad para producción en GKE requiere acceso mediante lista autorizada, un límite que impide tratarlo como una sustitución inmediata para cualquier cliente. Azure ofrece una vía gestionada con control del ciclo de vida y de la red. Las cifras de densidad o reanudación anunciadas por los proveedores son referencias de producto, no compromisos de rendimiento para una carga empresarial concreta.
El atractivo económico resulta comprensible. Un agente puede pasar más tiempo esperando una respuesta que ejecutando instrucciones. Mantener CPU y memoria asignadas durante esa espera parece innecesario, pero retirarlas exige conservar lo que necesita para continuar. Aparece así una separación entre sesión lógica y recurso físico. Esa separación mejora la utilización si está bien resuelta; también introduce almacenamiento, coordinación, recuperación y políticas de caducidad que no existían en un proceso efímero sencillo.
La recuperación de una sesión también es una decisión de seguridad
La primera decisión es qué estado merece sobrevivir. Un archivo de trabajo puede ser necesario; una credencial temporal no debería conservarse sin revisar su vigencia. Una instantánea de memoria puede contener datos que el usuario esperaba transitorios. Por eso el diseño debe distinguir resultados, caché, información personal y secretos, con reglas propias de retención. Guardar todo para acelerar la próxima respuesta es una comodidad técnica que puede convertirse en deuda operativa cuando se multiplican usuarios y sesiones.
La segunda decisión afecta a la identidad. Al reanudar una tarea, la plataforma debe conocer quién la inició, bajo qué permisos y para qué finalidad. Si esos permisos han cambiado, restaurar el estado antiguo no debería restaurar también la autorización anterior. Un patrón defendible consiste en obtener credenciales breves cuando se necesita actuar y validarlas fuera del entorno generado. La sesión conserva contexto de trabajo; el sistema de identidad conserva la decisión sobre el acceso que sigue permitido.
La tercera frontera es la salida de red. Separar procesos evita algunas interferencias, pero no determina qué servicios externos pueden recibir datos. Una lista de destinos autorizados y registros de conexión aporta control verificable. Aun así, permitir un dominio amplio puede abrir más operaciones de las previstas. El contrato de las herramientas debe complementar al control de red y limitar recursos, métodos y efectos. Es la combinación de capas la que reduce el riesgo, no la confianza depositada en un único aislamiento.
La operación diaria necesita ensayos de recuperación que incluyan fallos poco cómodos: pérdida del nodo, instantánea incompleta, dependencia retirada o cambio de versión durante una espera. Debe comprobarse que el trabajo no se duplica y que el usuario recibe un estado comprensible. Si una tarea ya envió un mensaje antes de suspenderse, la reanudación no puede inferir que debe enviarlo de nuevo sólo porque no conserva la respuesta. El vínculo entre acción y confirmación necesita persistencia propia.
Comparar plataformas requiere una carga representativa y un horizonte suficiente. Una prueba de arranque mide apenas una fase. El coste completo incorpora almacenamiento, transferencia, observabilidad, soporte y limpieza de sesiones abandonadas. También cuenta el conocimiento que ya posee el equipo. Una organización con Kubernetes maduro puede aceptar más responsabilidad a cambio de portabilidad; otra puede valorar una interfaz gestionada. No existe una elección universal separada de las capacidades humanas que sostendrán el servicio.
En la próxima fase conviene vigilar cuotas, disponibilidad regional, condiciones de producción y comportamiento bajo concurrencia real. Antes de ampliar un piloto, el equipo debería poder responder cuántas sesiones mantiene, a quién pertenecen, cuánto cuestan y cómo se eliminan o recuperan. La nube de agentes será operable cuando esas preguntas tengan respuestas rutinarias. Conseguir que un entorno arranque deprisa es útil; conseguir que su estado y sus permisos sigan siendo correctos semanas después es lo que permite convertirlo en una plataforma fiable.
Etiquetas
- Cloud
- arquitectura
BOLDERROR Edición diaria Rubén Campoy