Desarrollo de software en Azure: servicios, stack y costes en 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

El desarrollo de software en Azure es el trabajo de diseñar, programar, desplegar y operar aplicaciones en Microsoft Azure, utilizando sus servicios gestionados en lugar de servidores que usted mantiene por su cuenta. Para una empresa que ya trabaja con Microsoft 365, Entra ID, SQL Server y .NET, Azure suele ser el camino más corto desde una idea o un sistema heredado hasta una aplicación cloud segura y escalable.

La plataforma es amplia, así que lo difícil no es empezar, sino elegir bien. La mayoría de los equipos que acuden a nosotros por nuestros servicios de migración y modernización a Azure ya tienen un producto en funcionamiento. Lo que les falta es una decisión clara sobre qué opción de cómputo de Azure utilizar, cómo mantener limpias la identidad y los secretos y cómo evitar que la factura mensual siga subiendo tras el lanzamiento.

La demanda sigue creciendo con rapidez. Microsoft informó de que los ingresos de Azure crecieron un 40% en el ejercicio fiscal 2026, y Synergy Research Group situó la cuota de Microsoft en el mercado de infraestructura cloud en el 19% en el T3 de 2026. Esta guía explica qué incluyen los servicios de desarrollo de software en Azure, el stack principal, una comparativa de cómputo, el proceso de entrega, la seguridad, los plazos de .NET de 2026, los costes, los calendarios y cómo elegir un partner.

¿Qué es el desarrollo de software en Azure?

El desarrollo de software en Azure consiste en crear y ejecutar software en la nube pública de Microsoft, donde Azure proporciona el alojamiento, las bases de datos, la identidad, la mensajería, la monitorización y los servicios de IA, y su equipo escribe la lógica de negocio. La aplicación puede ser un backend web o móvil de cara al cliente, un sistema de gestión interno, un producto SaaS multi-tenant o una capa de integración entre herramientas existentes.

El término abarca tres tipos de trabajo que a menudo se combinan en un mismo proyecto:

• Desarrollo cloud-native: una nueva aplicación diseñada para Azure desde el primer commit, normalmente en App Service, Container Apps o Azure Functions con una base de datos gestionada.
• Modernización y migración: trasladar a Azure una aplicación existente en .NET, Java o PHP y sustituir después, de forma gradual, las piezas autogestionadas por servicios gestionados.
• Ampliación e integración: añadir API, flujos de trabajo, informes o funciones de IA en torno a sistemas como Dynamics 365, SharePoint, Microsoft 365 o un ERP on-premises.

Azure no está ligado a un solo lenguaje. Microsoft admite .NET, Java, Node.js, Python, Go y PHP en sus servicios de cómputo, y los contenedores permiten ejecutar casi cualquier stack. En la práctica, sin embargo, Azure ofrece la mayor ventaja a los equipos que ya han invertido en el ecosistema de Microsoft, porque la identidad, las licencias y las herramientas se conectan sin trabajo adicional.

¿Qué incluyen los servicios de desarrollo de software en Azure?

Los servicios de desarrollo de software en Azure suelen incluir el diseño de la arquitectura y de la zona de aterrizaje, el desarrollo de aplicaciones, el trabajo de datos e integración, la automatización DevOps, el refuerzo de la seguridad y la operación continua. Un buen proveedor cubre todo el ciclo de vida, porque la mayoría de los problemas de Azure aparecen en las juntas entre estos pasos y no dentro de uno de ellos.

Muchos proyectos combinan dos o tres de estos servicios. Un ejemplo típico es una empresa que traslada a Azure un sistema de gestión en .NET y, una vez estable la base, añade por encima un portal de clientes y un asistente de IA. Si su equipo necesita sobre todo ingeniería en C# y ASP.NET Core, nuestra página de servicios de desarrollo .NET explica cómo dotamos de personal ese trabajo.

¿Por qué desarrollar software en Azure?

La razón de más peso para desarrollar en Azure es la integración con lo que ya utiliza: Entra ID para el inicio de sesión único, Microsoft 365 y Teams para los usuarios, licencias de SQL Server y Windows que puede reutilizar, y Visual Studio y GitHub para los desarrolladores. Cuando esas piezas ya están en su sitio, Azure elimina mucho código de enlace y muchas fricciones de compra.

Las principales ventajas para los equipos de software son:

• Identidad integrada. Entra ID y las identidades administradas permiten que los servicios se autentiquen entre sí sin contraseñas en los archivos de configuración.
• Reutilización de licencias. Azure Hybrid Benefit aplica las licencias existentes de Windows Server y SQL Server a los recursos cloud, lo que puede recortar buena parte del gasto en cómputo y bases de datos en entornos con mucho Microsoft.
• Servicios gestionados en cada capa. Desde funciones serverless hasta Kubernetes gestionado y bases de datos distribuidas globalmente, puede elegir el nivel de control que necesite.
• Cobertura de cumplimiento. Azure cuenta con una larga lista de certificaciones (ISO 27001, SOC 2, soporte de HIPAA, PCI DSS) y ofrece el EU Data Boundary para los clientes que deben mantener sus datos en Europa.
• Opciones híbridas. Azure Arc y ExpressRoute ayudan a las empresas que deben mantener algunos sistemas on-premises, como las cargas de trabajo de fábricas u hospitales.
• Acceso a la IA. Microsoft Foundry (antes Azure AI Foundry, renombrado en noviembre de 2025) ofrece un único lugar para usar, evaluar y gobernar modelos y agentes dentro de su tenant de Azure.

Azure no es automáticamente la mejor opción. Si su equipo tiene una amplia experiencia en AWS, ninguna licencia de Microsoft y ninguna dependencia de Microsoft 365, el coste del cambio puede superar estas ventajas. La comparativa que encontrará más abajo le ayudará a decidir.

¿Qué servicios de Azure importan más para el desarrollo de aplicaciones?

En la mayoría de las aplicaciones de negocio, una docena de servicios de Azure hacen el 90% del trabajo: una opción de cómputo, una base de datos relacional o documental, almacenamiento, mensajería, identidad, secretos, monitorización y una puerta de enlace de API. Elegir un núcleo pequeño y aburrido, y añadir servicios solo cuando surge una necesidad real, mantiene bajo control tanto la complejidad como el coste.

Hay dos reglas que ahorran más problemas a largo plazo. Primera: utilice identidades administradas y Key Vault desde el primer día, para que ninguna cadena de conexión acabe nunca en el código fuente. Segunda: defina cada recurso en Bicep o Terraform, para que los entornos puedan reconstruirse y revisarse como código.

App Service frente a Functions, Container Apps y AKS: ¿cuál elegir?

Elija App Service para una aplicación web o API clásica, Azure Functions para trabajo basado en eventos y programado, Container Apps para microservicios en contenedores sin gestionar Kubernetes por su cuenta, y AKS solo cuando necesite el control total de Kubernetes. La mayoría de los productos nuevos que desarrollamos empiezan en App Service o Container Apps y nunca necesitan AKS.

Para el trabajo serverless, Microsoft recomienda ahora el plan Flex Consumption para las nuevas aplicaciones de funciones. Se ejecuta en Linux, admite la integración con redes virtuales e incluye una concesión gratuita mensual de 250,000 ejecuciones y 100,000 GB-segundos por suscripción, según el anuncio de disponibilidad general de Microsoft.

Azure frente a AWS y Google Cloud para el desarrollo de software

Azure, AWS y Google Cloud pueden alojar casi cualquier aplicación, así que las diferencias reales están en el encaje con el ecosistema, las competencias del equipo y el precio de su carga de trabajo concreta. Azure gana en las empresas centradas en Microsoft, AWS por el catálogo de servicios más amplio y la mayor reserva de talento, y Google Cloud en analítica de datos y en equipos que priorizan Kubernetes.

Si ya está en AWS y solo quiere marcharse por el precio, mida primero. Rediseñar la arquitectura rara vez se amortiza, salvo que las licencias, la identidad o el cumplimiento le empujen hacia Azure. Nuestra guía de desarrollo de software cloud trata con más detalle las decisiones de diseño independientes del proveedor.

¿Cómo se lleva a cabo un proyecto de desarrollo de software en Azure?

Un proyecto en Azure se desarrolla en seis etapas: descubrimiento, zona de aterrizaje, arquitectura y backlog, desarrollo iterativo, refuerzo y lanzamiento, y por último operación y optimización de costes. Saltarse la zona de aterrizaje para «avanzar más rápido» es la razón más habitual por la que los proyectos en Azure se ralentizan tres meses después.

1. Descubrimiento (1–4 semanas). Objetivos, usuarios, integraciones, normas de residencia de datos y un modelo de costes. En los sistemas existentes, Azure Migrate mapea servidores y dependencias.
2. Zona de aterrizaje (1–3 semanas). Suscripciones, grupos de administración, redes, Azure Policy, roles de Entra ID y registro de logs, definidos en Bicep o Terraform según el Cloud Adoption Framework.
3. Arquitectura y backlog. Elección de cómputo y datos, estrategia de entornos (desarrollo, pruebas, producción) y un backlog priorizado con el alcance de la primera versión.
4. Desarrollo iterativo. Sprints de dos semanas con CI/CD desde el primer sprint, pruebas automatizadas y un entorno de demostración que las partes interesadas pueden usar.
5. Refuerzo y lanzamiento. Pruebas de carga y de seguridad, recomendaciones de Defender for Cloud, simulacros de copia de seguridad y recuperación ante desastres, runbooks y puesta en producción.
6. Operación y optimización. Monitorización, alertas, guardias, revisiones mensuales de costes y reservas o planes de ahorro cuando el uso se estabiliza.

En un sistema heredado, los pasos 3 y 4 suelen seguir un camino por fases: primero el rehost y después la sustitución, una a una, de las piezas autogestionadas. Nuestra guía sobre la modernización de sistemas heredados explica cómo secuenciar ese trabajo sin un arriesgado cutover de golpe.

¿Cómo se mantiene segura y conforme una aplicación en Azure?

Una aplicación en Azure se mantiene segura diseñándola según el Well-Architected Framework de Microsoft, usando identidades en lugar de secretos, imponiendo guardrails con Azure Policy y monitorizando de forma continua con Defender for Cloud. La seguridad añadida después del lanzamiento cuesta mucho más que la seguridad integrada en la zona de aterrizaje.

El Well-Architected Framework se apoya en cinco pilares: fiabilidad, seguridad, optimización de costes, excelencia operativa y eficiencia del rendimiento. Úselos como lista de comprobación en cada hito. En la ingeniería del día a día, eso se traduce en una breve lista de requisitos innegociables:

• Entra ID con acceso condicional y Privileged Identity Management para cada persona con acceso a producción.
• Identidades administradas para cada servicio, de modo que las aplicaciones accedan a bases de datos, almacenamiento y Key Vault sin credenciales almacenadas.
• Puntos de conexión privados para bases de datos y almacenamiento, que mantienen el tráfico de datos fuera de la internet pública.
• Azure Policy para fijar regiones, exigir etiquetas y bloquear configuraciones inseguras antes de que se desplieguen.
• Defender for Cloud para la gestión del enfoque de seguridad y la detección de amenazas, con su puntuación de seguridad seguida como métrica del equipo.
• Controles de residencia de datos, como las regiones de la UE y el EU Data Boundary, para cargas de trabajo sensibles al RGPD.

Los sectores regulados añaden sus propias capas: acuerdos de socio comercial (business associate agreements) de HIPAA para datos de salud, segmentación PCI DSS para datos de tarjetas y registros preparados para auditoría en los servicios financieros. Planifíquelas en el descubrimiento, porque influyen en el diseño de la red y en la elección de servicios.

¿Cómo deben funcionar CI/CD y DevOps en Azure?

En Azure, CI/CD debe desplegar cada cambio automáticamente a través del mismo pipeline, desde una pull request hasta los entornos de pruebas y producción, con la infraestructura definida como código y sin clics manuales en el portal en producción. GitHub Actions y Azure Pipelines se integran de forma nativa con Azure y se autentican mediante federación de identidades de carga de trabajo en lugar de secretos almacenados.

Un buen pipeline de entrega en Azure suele incluir:

• compilación, pruebas unitarias y análisis estático en cada pull request;
• cambios de infraestructura en Bicep o Terraform, revisados y planificados antes de aplicarlos;
• ranuras de despliegue (deployment slots) o revisiones para versiones sin tiempo de inactividad y una reversión rápida;
• pruebas de humo automáticas después de cada despliegue;
• anotaciones de versión en Application Insights, para que los cambios de rendimiento puedan atribuirse a un despliegue concreto.

Nuestro artículo sobre CI/CD en el desarrollo de software profundiza en el diseño de pipelines, y el equipo de consultoría de cloud y DevOps puede asumir el trabajo de pipelines y plataforma si prefiere que sus desarrolladores se centren en las funcionalidades.

¿Qué cambió para las aplicaciones .NET en Azure en noviembre de 2026?

El 10 de noviembre de 2026, Microsoft puso fin al soporte de .NET 8 y .NET 9, y las aplicaciones de Azure Functions con el modelo en proceso también llegaron al final de su soporte. Las aplicaciones que siguen en esas versiones continúan funcionando, pero ya no reciben parches de seguridad, por lo que actualizar a .NET 10 es ahora una tarea de mantenimiento urgente y no una mejora opcional.

.NET 10 se publicó en noviembre de 2025 como versión de soporte a largo plazo con tres años de soporte. Para las cargas de trabajo en Azure, la ruta de actualización depende del modelo de alojamiento:

Aproveche la actualización para eliminar deuda técnica: quite las dependencias que no se usan, añada las pruebas que faltan y traslade los secretos a Key Vault mientras el código está abierto de todos modos. Nuestra guía de desarrollo de software .NET explica cómo evaluar una base de código .NET antes de una actualización.

¿Cuánto cuesta el desarrollo de software en Azure en 2026?

El coste del desarrollo de software en Azure tiene dos partes: el desarrollo, que se paga una vez, y la factura cloud mensual. En YuSMP Group, las aplicaciones web .NET concretas en Azure parten de unos $4,100, los portales multirrol de $8,100 y las plataformas SaaS multi-tenant de $13,800, mientras que los proyectos de re-platform a Azure parten de $4,100 y un único rehost de $1,800.

El precio del desarrollo depende del número de roles de usuario, las integraciones, el volumen de migración de datos, el alcance del cumplimiento y la parte de la plataforma que hay que desarrollar frente a la que basta con configurar. Un presupuesto escrito de alcance cerrado tras el descubrimiento es la única cifra fiable.

¿Qué determina la factura mensual de Azure?

La factura mensual de Azure depende sobre todo del tamaño y las horas de cómputo, el nivel de la base de datos, la salida de datos, el volumen de logs y cualquier función premium siempre activa. Una aplicación pequeña en producción suele costar unos cientos de dólares al mes, mientras que una plataforma SaaS con mucho tráfico puede llegar a miles. Formas prácticas de mantenerla predecible:

• defina presupuestos y alertas de costes en cada suscripción desde el primer día;
• use opciones de escalado a cero (Container Apps, Flex Consumption) para cargas de trabajo irregulares o internas;
• aplique Azure Hybrid Benefit siempre que sus licencias lo permitan;
• compre reservas o planes de ahorro solo después de tres meses de uso estable;
• limite la ingesta de Log Analytics y fije la retención de forma deliberada, porque los logs son un coste oculto frecuente.

Para experimentos, la cuenta gratuita de Azure incluye actualmente $200 de crédito durante los primeros 30 días, además de un conjunto de servicios siempre gratuitos, lo que basta para crear un prototipo de arquitectura antes de comprometerse.

¿Cómo elegir una empresa de desarrollo de software en Azure?

Elija una empresa de desarrollo de software en Azure comprobando su experiencia real de entrega en Azure, un enfoque disciplinado de la zona de aterrizaje, precios transparentes y condiciones de propiedad claras, no por el número de logotipos de su web. Pida ver cómo estructurarían su entorno antes de firmar.

Una breve lista de comprobación para evaluarla:

1. Referencias relevantes. Proyectos con los mismos servicios de cómputo y datos que usted va a utilizar, idealmente en su sector.
2. Ingenieros certificados. Certificaciones Azure Solutions Architect y Azure Developer en el equipo real, no solo en el perfil de la empresa.
3. Infraestructura como código por defecto. Pregunte si cada entorno se define en Bicep o Terraform y se entrega junto con el código.
4. Enfoque de seguridad. Las identidades administradas, los puntos de conexión privados, Defender for Cloud y Azure Policy deberían surgir sin que usted los mencione.
5. Disciplina de costes. Un modelo de costes en el descubrimiento, presupuestos y alertas, y un plan para Hybrid Benefit y las reservas.
6. Propiedad. Suscripciones bajo su tenant, código en su repositorio y propiedad intelectual asignada a usted desde el primer día.
7. Solapamiento horario. Suficientes horas de trabajo compartidas para las decisiones diarias, sobre todo durante el lanzamiento.

Los modelos de colaboración también importan. Los proyectos de alcance cerrado encajan con un desarrollo o una migración bien definidos, el modelo de tiempo y materiales con productos en evolución, y un equipo dedicado con plataformas a largo plazo en las que la experiencia en Azure tiene que estar cerca de su producto.

¿Cuáles son los errores más comunes en el desarrollo en Azure?

Los errores más comunes en el desarrollo en Azure son saltarse la zona de aterrizaje, elegir AKS demasiado pronto, guardar secretos en la configuración, ignorar las alertas de costes y construirlo todo a mano desde el portal. Cada uno de ellos es barato de evitar al principio y caro de corregir tras el lanzamiento.

• Sin zona de aterrizaje. Los recursos acaban en una sola suscripción con permisos amplios y sin políticas, lo que bloquea las auditorías más adelante.
• Kubernetes por defecto. AKS añade una carga de operación que muchos productos nunca necesitan; bastaría con App Service o Container Apps.
• Secretos en la configuración de la aplicación o en el código. Utilice en su lugar referencias de Key Vault e identidades administradas.
• Cambios solo en el portal. Los cambios manuales se desvían del código y no pueden reproducirse en una nueva región o entorno.
• Sin guardrails de costes. Un clúster de pruebas olvidado o un registro de logs demasiado detallado pueden duplicar la factura mensual.
• Lift-and-shift para siempre. El rehost es un primer paso válido, pero las máquinas virtuales que nunca se modernizan conservan los costes y los problemas del entorno on-premises.
• Monolito dividido demasiado pronto. Dividir un sistema que funciona en decenas de servicios antes de que el dominio esté claro añade latencia y complejidad; consulte nuestra guía sobre la migración de monolito a microservicios.

Fuentes

• Microsoft, FY2026 fourth quarter and full-year results (Form 8-K, Exhibit 99.1) (en inglés), 2026.
• Synergy Research Group, Cloud market growth rate surges; Q3 revenues reach $168 billion (en inglés), octubre de 2026.
• Microsoft Tech Community, Azure Functions Flex Consumption is now generally available (en inglés).
• Microsoft, Azure Well-Architected Framework (en inglés).
• InfoQ, .NET 10 released (en inglés), noviembre de 2025.
• Microsoft Learn, Introduction to Azure for developers (en inglés).

Preguntas frecuentes