El agente de AWS ya reescribe código .NET de Azure para AWS: cambiar el SDK es lo fácil

Señale un agente a una aplicación .NET que lee de Azure Blob Storage, procesa mensajes de Azure Queue Storage en Azure Functions y escribe en Cosmos DB. Pídale que haga que la aplicación se ejecute en AWS. El agente localiza cada llamada al SDK de Azure, propone un equivalente en AWS, espera su aprobación y reescribe el código. La aplicación compila. ¿Se comporta igual?

Eso ya es una pregunta real y no un experimento mental. El 16 de octubre AWS puso en disponibilidad general (GA) la conversión de código del SDK de Azure al SDK de AWS en AWS Transform, su agente de modernización para .NET. El agente analiza una aplicación .NET nativa de la nube, localiza las dependencias de Azure compatibles, presenta las opciones de conversión en un informe de evaluación y un plan de modernización que el usuario acepta o ajusta, convierte el código y comprueba que los cambios se hayan incorporado. Tres conversiones están en disponibilidad general (GA): Azure Functions a AWS Lambda, Azure Blob Storage a Amazon S3 y Azure Queue Storage a Amazon SQS. Cosmos DB a DynamoDB está en preview. La función opera en ocho regiones de AWS: EE. UU. Este (N. Virginia), Canadá (Central), Frankfurt, Londres, Mumbai, Tokio, Seúl y Sídney. Frankfurt y Londres están entre esas ocho, así que los equipos de España y del resto de Europa pueden mantener el procesamiento en Europa. Ninguna región de América Latina figura en la lista, de modo que los equipos de México, Colombia, Chile o Argentina enviarían el código a Estados Unidos o a Europa.

Dos nubes, un mismo rumbo

A principios de este mes Google puso un agente detrás de mover cargas de trabajo de Kubernetes de EKS a GKE. Ahora AWS tiene uno apuntando en la dirección contraria, hacia Azure. Los hiperescaladores están construyendo agentes de migración dirigidos a los clientes de los demás, lo que abarata probar un plan de salida de la nube y da a los compradores una alternativa creíble a la hora de renovar. La trampa es la misma en ambas direcciones: un agente convierte lo que ve en el código, y buena parte de lo que hace que una aplicación se comporte como se comporta no está en las llamadas al SDK.

Lo que queda fuera de las llamadas al SDK

Identidad. Una aplicación en Azure suele llegar al almacenamiento y a las colas mediante Microsoft Entra ID e identidades administradas con asignaciones de roles. En AWS ese mismo acceso son roles y políticas de IAM. Convertir llamadas a BlobClient en llamadas a S3 no diseña la política de IAM que debería restringirlas, y el arreglo cómodo, permisos amplios para que las pruebas pasen, es justo la forma en que las migraciones crean cargas de trabajo con privilegios excesivos que después se vuelven incidentes.

Disparadores y gestión de fallos. Una instancia de Azure Functions con un disparador de cola y una función AWS Lambda que lee de SQS procesan mensajes, pero los reintentos, los mensajes envenenados, la visibilidad y el procesamiento por lotes funcionan de otro modo. Las funciones de Azure Queue Storage mueven un mensaje a una cola de mensajes envenenados tras un número determinado de lecturas; SQS se apoya en un timeout de visibilidad y en una política de reenvío (redrive) de la cola de mensajes fallidos que alguien tiene que configurar. Una conversión que conserva el camino feliz puede cambiar lo que ocurre con el mensaje mil que falla, que es cuando las empresas descubren que su proceso era idempotente solo por casualidad.

Modelo de datos. Cosmos DB a DynamoDB está en preview por algo. Pasar de una base de datos documental a otra con modelos de consulta, particionado, indexación y opciones de consistencia distintos es una decisión de diseño de datos, no un cambio de sintaxis. Trate la capa de datos convertida como una propuesta para un arquitecto, no como un cambio terminado.

Red y configuración. Los endpoints privados, las redes virtuales, los almacenes de configuración y los secretos tienen equivalentes en AWS, pero son infraestructura y normalmente se definen fuera del código de la aplicación que el agente reescribe.

Operaciones. Los logs, las métricas, el tracing y las alertas pasan de Azure Monitor y Application Insights a las herramientas de AWS. Los dashboards y los runbooks de guardia no se migran solos, y el primer incidente en la nueva plataforma no es el momento de enterarse.

Cómo verificar una aplicación convertida

La puerta de aprobación del plan de modernización es el diseño correcto: el agente propone y una persona decide. Pero aprobar un plan no es verificar un resultado. En una aplicación que importa, la evidencia debería venir del comportamiento:

• Pruebas de contrato en cada frontera convertida, incluidos los casos de fallo: objetos ausentes, mensajes demasiado grandes, limitación de peticiones (throttling), entrega duplicada.
• Repetición de tráfico real contra los despliegues antiguo y nuevo con las salidas comparadas, el enfoque que hizo creíble Dual Run de Google para mainframes.
• Una revisión de IAM escrita por una persona, no inferida de lo que necesitaban las pruebas.
• Una ruta de rollback mientras ambos despliegues se ejecutan en paralelo.

Agentes como este les quitan de encima a los ingenieros la parte lenta y repetitiva de una migración, localizar y reescribir cientos de llamadas al SDK, el patrón que describimos para agentes de migración que trabajan dentro de playbooks. No eliminan la parte que exige saber qué se supone que debe hacer la aplicación cuando las cosas salen mal. Esa parte siempre fue la cara, y lo sigue siendo.