Querido Azure, tenemos que hablar

Trabajé en Amazon varios años. AWS para un dev se siente como casa. Las cosas están donde tienen que estar, los nombres tienen sentido, la consola es navegable. No es perfecto, pero es coherente.

Lo das por hecho hasta que lo pierdes.

Empecé a hacer una app serverless, un backend ligero, nada del otro mundo. El cliente me exigió Azure. ¿Por qué? Porque ya habían usado Azure antes y porque "cuando dices Azure la gente se queda tranquila". No había argumento técnico, era pura inercia corporativa. Debí negociar mejor esa decisión. Me habría ahorrado al menos 30 horas y habría estado mucho más a gusto --> Pero acepté.

Antes de empezar te aclaro una cosa importante: yo no había tocado Azure antes. Lo que dice la literatura es que los servicios son equivalentes a los de AWS.

"Equivalentes" decían.

Estos son los apuntes que llevo recogidos durante el proyecto. Ojalá le sirvan a alguien para evitar lo inevitable.

1. Entrar a Azure ya da una pista de lo que viene

Te creas la cuenta. Si no tienes correo de Microsoft, te crea uno. Y ese correo es del tipo pepe@on.microsoft.com, ¿por qué? Luego, no encuentras el botón para borrar la cuenta por ningún lado.

Y luego está el catálogo de servicios. Por ejemplo, Azure Storage Account: dentro del mismo recurso te mete Blob, Queues, File y Table. ¿Qué son las tablas? ¿Cómo se comparan estas con Cosmos DB? En AWS, Blob es S3, Queues sns sqs, Files es EFS y Tables es DynamoDB. Realmente no hay un equivalente de esas tablas.

Cuatro servicios, cuatro consolas, cuatro APIs, cero confusión. Para mí tiene más sentido. En Azure parece que metieron todo en una caja.

2. CosmosDB

CosmosDB funciona. Pero te obliga a configurar backups por defecto. No digo que los backups sean malos, de hecho los voy a poner yo mismo cuando quiera.

¿Por qué tu plataforma no puede correr con una sola versión de la "tabla"? Ah, perdón, no se llama tabla. Se llama container. ¿?

Cada vez que lees "container" en CosmosDB tu cerebro tiene que parar medio segundo y traducir... y de hecho también hay blob container...

3. Azure Static Web Apps

Static Web Apps parecía ser el equivalente a AWS Amplify. Soporte full stack serverless, frontend más Azure Functions empaquetadas, deploy automático desde GitHub.

Justo lo que quería!

a. No tiene soporte para pnpm

En 2026 Oryx el build tool que Azure Static Web Apps usa por debajo, no detecta pnpm.

La solución son workarounds con .npmrc, flags de skip_app_build, y rezar.

Cuando algo tan básico como tu package manager es un workaround, ya sabes que vas mal.

b. Local es local de verdad y no hay environments en la nube

En AWS Amplify tienes un sandbox que despliega tus cambios a la nube en tiempo real conforme guardas, y cada rama que pusheas se despliega a su propio environment aislado. Puedes probar tu PR en la nube real antes de mergear, con servicios reales conectados.

En SWA no. Cuando desarrollas en local, literalmente se ejecuta en tu ordenador. Punto. No hay sandbox cloud. No hay environments de rama. Lo que tienes en local no es lo que va a haber en la nube cuando despliegues, y solo te enteras cuando ya está roto. Y configurar otro entorno es un extra...

Y para correr ese local necesitas abrir tres terminales. Tres. Si te gusta tmux, perfecto.

1. pnpm run dev del frontend
2. cd api && func start del backend
3. swa start que conecta los dos servicios.

c. La auth es solo para gente de microsoft

El equivalente de Cognito en Azure se llama Microsoft Entra ID.

En Static Web Apps, la autenticación nativa solo funciona bien si tus usuarios tienen cuenta de Azure dentro de tu tenant.

Hacer un signup tradicional con email, contraseña y MFA configurable, que es lo que pide cualquier app, no se puede con SWA

Puedes abrirlo al mundo entero o cerrarlo a tu tenant, y gestionar usuarios... pero si tu correo no esta en microsoft no te deja.

Cognito funciona en 5 minutos como si fuera supabase.

d. Las Azure Functions creadas desde SWA no son Azure Functions de verdad

Cuando creas una función dentro de tu repo de SWA, esa función no aparece en el servicio de Azure Functions. No la puedes ver, no la puedes programar con un schedule, no la puedes invocar desde otro sitio. Si quieres una función con cron, tienes que crear otro repo o desplegar esa función aparte en un Function App separado.

Esto me obligó a montar un repositorio independiente solo para un ETL programado que debería haber sido parte natural de la misma app. En Amplify tienes funciones con triggers de cron, de S3, de DynamoDB Streams, todo dentro del mismo proyecto, todo desplegado junto. Una sola unidad lógica. En Azure todo vive separado.

e. Configurar cualquier servicio adicional es un festival de credenciales

Quieres conectar tu app con Azure AI Foundry. O quieres un CRUDL contra Cosmos. Toca configurar identities, role assignments, connection strings, app settings, decenas de. variables de entorno. En Amplify CDK puedes desplegar prácticamente cualquier servicio AWS desde el mismo repo, con permisos auto-generados según las relaciones que defines en código y ademas hay una API de secretos incluida ya, que son diferente de variables de entorno.

f. Buffering de respuestas: no hay streaming

Esto me decepcionó. Static Web Apps buferiza las respuestas HTTP de sus funciones. Eso significa que si tienes una API que devuelve streaming, como cualquier endpoint que use un LLM con stream: true, no funciona. El usuario espera la respuesta y luego la ve aparecer de golpe.

https://github.com/Azure/static-web-apps/issues/1180

¿La solución? Migrarte a Container Apps o a otra cosa.

Acabé haciendo un fake streaming en el front end para que se vea real.

g. Sin soporte para SSR

Se llama Static Web Apps. Literalmente. Amplify corre Next.js con App Router sin que te enteres y va rápido. Es lo que uso por defecto en cualquier app nueva.

4. Pagas más por lo mismo

Quería asignar una IP fija a una Azure Function y me topé con esto.

El NAT Gateway en sí cuesta lo mismo en AWS y en Azure (~$35/mes base).

Azure te aprieta de verdad es en lo que te obliga a comprar alrededor del NAT.

En Azure, para que una Function pueda integrarse con una VNet y salir por un NAT Gateway, te obliga a estar en plan Premium o en App Service Plan. Y eso, el plan, te dispara la factura a la zona de 150 dólares al mes solo por tener la capacidad de salir por una IP fija.

Es decir, Azure no te cobra el NAT más caro. Te cobra el peaje para acceder al NAT. Es peor, porque queda escondido en otra línea de la factura.

Estuve leyendo que este patrón se repite por todas partes. Quieres una cosa y acabas pagando otra cosa.

5. No puedes crear una Function desde el portal

En Lambda, abres la consola, escribes tu función en el editor integrado, le das a deploy, y está. Para iterar mientras debugueas, perfecto. AWS hasta tiene integrado un fork de VS Code dentro de la consola de Lambda.

Sí, VS Code, el producto de Microsoft. En la consola de AWS.

En Azure Functions no puedes crear una función desde el portal con código. Tienes que usar Visual Studio, VS Code con la extensión, o la Azure Functions Core Tools desde el terminal.

Una cosa rápida no se puede hacer rápido.

6. Azure OpenAI vs Foundry: el lío que se montaron solos

Microsoft se precipitó con Azure OpenAI. Era un servicio dedicado solo a modelos de OpenAI. Después salió Azure AI Studio. Después lo renombraron a Azure AI Foundry. Después metieron Azure OpenAI dentro de Foundry como un subset. Ahora Foundry también vende Mistral, DeepSeek...todo a través de "Foundry Models sold by Azure", que es una marca dentro de otra marca.

Ver las cosas así me hace pensar que no lo hicieron pensando en las cosas. Bedrock desde el primer día ya sabían lo de modelos fundacionales.

Antes de cerrar

Por encima de cada problema individual hay una sensación que persiste durante todo el proyecto: el pánico de tocar algo equivocado. Cualquier servicio de Azure te dispara la factura si configuras mal una propiedad, y entender qué propiedad importa requiere leer documentación que parece traducida del húngaro tres veces, o preguntarle a un LLM en cada paso.

Nueva política de SmarterPath

A partir de hoy tenemos una política nueva: no haremos más aplicaciones en Azure. Si un cliente lo exige, subimos los precios. Para todo lo demás, AWS.

Y si en algún momento de la vida me planteo trabajar en Microsoft o en alguna empresa que use Azure, vendré a este post y lo leeré varias veces antes de continuar con el proceso de selección.

Gracias Microsoft