Hola cracks, estamos en pleno feriado y es hora de un artículo técnico, esta vez te hablaré de AOT.

Durante años, el rendimiento en .NET se apoyó principalmente en el JIT (Just-In-Time): el código se compila a nativo en tiempo de ejecución. Eso funciona bien para aplicaciones largas, pero tiene un problema claro en escenarios modernos: el arranque.

Aquí es donde entra AOT (Ahead-of-Time).

Qué es AOT

AOT significa que tu aplicación se compila a código nativo en el build, no en runtime.

Es decir que en lugar de:

Haces:

El resultado es simple:

• la app arranca mucho más rápido
• usa menos memoria
• no necesita JIT en ejecución

Esto no es nuevo en la industria: C/C++, iOS, Android, Java (GraalVM) lo usan desde hace años.
Lo nuevo es que .NET lo volvió viable y usable.

Desde cuándo existe AOT en .NET

• .NET Framework: no tiene AOT
• .NET Core / .NET 5–6: intentos parciales, osea que no tiene en la práctica
• .NET 7: Native AOT usable pero limitado (no recomendado)
• .NET 8 en adelante: Native AOT estable y soportado

Es decir estimado dev, en la práctica, AOT empieza a ser serio en .NET 8.

¿En qué tipo de aplicaciones se usa?

AOT no es solo para APIs.

Funciona muy bien en:

• APIs REST
• microservicios
• workers
• funciones serverless
• CLIs
• servicios de fondo

Ejemplo real:

• AWS Lambda con .NET AOT reduce el cold start de cientos de ms a decenas.
• Microservicios en Kubernetes arrancan más rápido y consumen menos memoria por pod.

¿Conviene usar AOT siempre?

No. Y este punto es importante dev. AOT optimiza el arranque, no hace magia.

Conviene usar AOT cuando:

• El tiempo de inicio importa (cold start)
• La app es “cerrada” (sin plugins dinámicos)
• Usas DI, endpoints y tipos conocidos
• Estás en cloud, serverless o contenedores

No conviene cuando:

• Cargas assemblies dinámicamente
• Usas plugins
• Dependes mucho de reflection dinámica
• Ejecutas reglas o código que recién es “descubierto” en runtime

¿Cómo saber si una aplicación es AOT-friendly?

No tienes que revisar línea por línea.
Se hace así en la práctica:

Mira el tipo de app

• ¿Es una API cerrada? → entonces es un buen candidato
• ¿Es un framework extensible? → uhmmm mal candidato

Revisa puntos críticos

• La clase Program.cs
• Serialización
• Reflection
• Carga dinámica
• Librerías antiguas

Como este es un blog pragmático, aunque no puedo abarcar todos porque sería interminable pero para que te des una mejor idea te daré un ejemplo real:

Este es un ejemplo de código problemático para AOT:

var type = Type.GetType(nombreDesdeBD);
Activator.CreateInstance(type);

Y este es AOT-friendly por así decirlo: 🙌

services.AddScoped<IService, Service>();

¿Qué pasa si mi app no es compatible?

Importante:
la app no se rompe silenciosamente en producción.

Lo normal es que:

• falle al publicar, con errores claros
• o falle exactamente en el punto donde falta metadata

Entonces para probar es mejor ejecutar

dotnet publish

Si no es compatible con AOT obtendrás el error: Reflection call not supported in Native AOT.

Así te enteras antes del deploy, no después.

Como ejemplos reales AOT-friendly tienes a:

• APIs corporativas
• Microservicios de negocio
• Workers de colas
• Gateways
• CLIs internas

Y usualmente no son compatibles éstas:

• CMS
• ERPs extensibles
• Sistemas con plugins
• Engines de reglas dinámicas
• Sistemas legacy

En conclusión dev...

Así que estimado dev, ahora ya lo sabes: AOT no es una optimización automática. Es una decisión arquitectónica.

Si tu aplicación es predecible y cerrada, AOT te da arranques rápidos y menor consumo.
Si tu aplicación es dinámica, JIT sigue siendo la mejor opción.

En mi experiencia en proyectos reales, muchos equipos usan AOT donde importa y JIT donde necesitan flexibilidad así que tenlo en cuenta.

Finalmente mi recomendacion es que si estás trabajando en microservicios que escalan horizontalmente en Kubernetes o funciones en la nube, puedes considerar aprovechar AOT. Si tienes una aplicación monolítica tradicional con muchas librerías antiguas, quédate con el modelo JIT clásico, ya que el esfuerzo de migración a AOT podría no valer la pena por la ganancia de rendimiento.

Ahora te toca compartir este artículo crack! 😜

Créditos de imagen de portada: Foto de Steve LEDEME en Unsplash