Cuándo usar contenedores en Windows y cuándo no compensa

Si trabajas con aplicaciones sobre Windows y te estás preguntando cuándo tiene sentido usar contenedores en Windows y cuándo es mejor seguir tirando de máquinas virtuales o incluso de Linux, no eres el único. Cada vez hay más ruido, opiniones encontradas y experiencias muy dispares, sobre todo en torno a los contenedores de Windows Server.

En este artículo vamos a bajar al detalle, con un enfoque muy práctico, para que entiendas qué aportan realmente los contenedores en Windows, en qué escenarios brillan, qué limitaciones tienen y cómo encajan con tecnologías como Docker, Kubernetes, Azure y el resto del ecosistema de Microsoft. La idea es que, cuando lo termines, tengas claro si en tu caso merece la pena apostar por ellos, en qué proyectos y con qué enfoque.

Qué son exactamente los contenedores en Windows

Un contenedor en Windows es, en esencia, un paquete ligero y aislado que incluye una aplicación junto con todas las librerías, dependencias, frameworks, archivos de configuración y componentes de modo usuario que necesita para funcionar, apoyándose en el kernel del sistema operativo host.

A diferencia de una máquina virtual, el contenedor no lleva un sistema operativo completo dentro, sino que comparte el kernel del host (Windows Server o, en escenarios de desarrollo, Windows 10/11). Lo que sí incorpora es una “imagen base” con todos los binarios y API de modo usuario necesarios para proporcionar a la aplicación el entorno que espera.

Ese aislamiento hace que el contenedor vea un sistema de archivos, un registro de Windows, procesos y recursos de red parcial o totalmente virtualizados. Los cambios que se hagan dentro del contenedor, por defecto, se pierden cuando se detiene o se elimina; si quieres persistencia, montas volúmenes o almacenamiento externo (discos de Azure, Azure Files, SMB, etc.).

Gracias a este modelo, los contenedores de Windows se inician y se detienen en cuestión de segundos, consumen muchos menos recursos que una VM completa y permiten tener una densidad muy superior de cargas de trabajo en la misma infraestructura, algo clave en entornos de alta demanda y escalado elástico.

El ecosistema de contenedores de Microsoft

Microsoft ha montado un ecosistema bastante amplio alrededor de los contenedores, cubriendo desde el desarrollo en local hasta el despliegue masivo en la nube. La clave es que puedes ejecutar contenedores de Windows y de Linux sobre sistemas Windows, dependiendo del modo de aislamiento y las herramientas elegidas.

En entornos de desarrollo en Windows 10 u 11, la opción habitual es usar Docker Desktop integrado con las capacidades de contenedores de Windows. Con él puedes trabajar tanto con contenedores Linux (normalmente mediante WSL2 o Hyper-V) como con contenedores nativos de Windows para pruebas y debug.

Para equipos de desarrollo, Visual Studio y Visual Studio Code ofrecen una integración bastante pulida: soportan Docker, Docker Compose, Kubernetes y Helm, además de plantillas de proyectos que ya salen listas para contenerizar aplicaciones .NET, ASP.NET, etc. Desde estos IDEs puedes construir imágenes, lanzarlas en local e incluso hacer push y pull directamente hacia registros remotos.

En el lado del registro de imágenes, puedes optar por publicar en Docker Hub o en un Azure Container Registry privado. Esto te permite tener un flujo CI/CD completo donde tus pipelines construyen imágenes basadas en Windows Server Core, Nano Server o Windows, las suben al registro y, desde ahí, los distintos entornos (dev, pre, prod) tiran de esas imágenes para desplegar.

Cuando necesitas operar a gran escala, el ecosistema de Microsoft gira alrededor de Azure Kubernetes Service (AKS) y de la extensión de AKS hacia entornos on‑premises con Azure Arc, Azure Stack Hub u OpenShift. Aunque la presencia de contenedores Linux es mayoritaria, AKS soporta nodos Windows para ejecutar workloads Windows en clusters Kubernetes mixtos, combinando así lo mejor de ambos mundos.

Cómo funcionan internamente los contenedores de Windows

Detrás de bastidores, un contenedor de Windows se apoya en las mismas ideas básicas que uno de Linux: namespaces para aislar procesos, sistema de archivos, red y otros recursos, y mecanismos tipo cgroups (o equivalentes) para controlar el consumo de CPU, memoria, etc. La implementación es distinta, pero el objetivo es el mismo.

El kernel del host proporciona la base; encima, una imagen base aporta los binarios de modo usuario de Windows necesarios: bibliotecas, servicios, runtimes y demás piezas que la aplicación da por sentadas. Esto convierte la imagen base en la capa fundamental sobre la que se construye el resto de la imagen del contenedor.

Las imágenes se estructuran como una pila de capas inmutables: cada instrucción en el Dockerfile (copiar archivos, instalar dependencias, configurar frameworks) añade una capa adicional. Al lanzar un contenedor, Docker o containerd monta todas esas capas en modo lectura y escritura sobre una capa superior escribible, que es donde se registran los cambios temporales.

Este enfoque por capas permite reutilizar grandes bloques de sistema entre contenedores. Si diez aplicaciones se basan en la misma imagen de Windows Server Core con .NET Framework, el host solo almacena una vez esas capas comunes y cada contenedor añade únicamente su parte diferencial (binaries de la app, configuración, etc.).

Si el contenedor necesita persistir datos, lo normal es montar volúmenes vinculados a discos, recursos compartidos SMB o servicios de almacenamiento en la nube. De esa manera, combinamos un runtime efímero con datos persistentes, evitando acoplar la información de negocio a la vida del contenedor.

Contenedores frente a máquinas virtuales en Windows

Una duda recurrente es si los contenedores de Windows vienen a sustituir por completo a las máquinas virtuales. La respuesta corta es que no: son tecnologías complementarias que resuelven problemas distintos, aunque en muchos escenarios los contenedores aportan una alternativa más ligera y flexible.

Una VM ejecuta un sistema operativo completo, con su propio kernel, servicios, controladores y pila de software. Eso proporciona un aislamiento muy fuerte, ideal para multi‑tenancy hostil, cargas altamente reguladas o escenarios donde quieres ver cada servidor como una unidad “sagrada” y bien delimitada.

Los contenedores, por su parte, se apoyan en el kernel del host. Eso los hace mucho más rápidos de arrancar y apagar, mucho más ligeros y con una gestión de recursos más elástica, pero a costa de compartir una parte crítica del sistema. En muchos despliegues en la nube se combinan ambas cosas: contenerización dentro de máquinas virtuales, de forma que el hypervisor delimita tenants y el orquestador de contenedores organiza workloads dentro de cada VM.

En el mundo Windows, los contenedores son especialmente interesantes cuando tienes aplicaciones que antes ibas a ejecutar en máquinas virtuales Windows tradicionales. En ese contexto, pasar de VM a contenedor suele implicar mejoras claras en densidad, costes de infraestructura, velocidad de despliegue y capacidad de automatización con pipelines DevOps.

Dicho de otra forma: si tienes que seguir en Windows por requisitos de plataforma, licenciamiento o dependencias, el salto natural no es huir a Linux a toda costa, sino reemplazar parte de tu parque de VMs por contenedores de Windows cuando el tipo de aplicación lo permite.

Imágenes base de contenedor en Windows

En el ecosistema de Microsoft existen varias imágenes base oficiales pensadas para distintos tipos de aplicaciones y escenarios. Elegir bien la base es crítico, porque impacta en el tamaño, compatibilidad y rendimiento de los contenedores.

La imagen genérica Windows incluye el conjunto casi completo de API y servicios del sistema (sin roles de servidor), pensada para escenarios donde necesitas una compatibilidad muy amplia con aplicaciones de escritorio o componentes concretos de Windows.

La imagen Windows Server aporta el sistema de servidor completo, con todas las API típicas del entorno Windows Server. Es una base bastante grande, pero a cambio te permite empaquetar aplicaciones que asumen un servidor clásico y que usan APIs avanzadas o librerías específicas.

Windows Server Core es una versión más reducida, centrada en server roles concretos, con consola pero sin entorno gráfico clásico, que sigue incluyendo la versión completa de .NET Framework y la mayor parte de roles habituales. Es una muy buena opción cuando quieres reducir el peso de la imagen sin renunciar a demasiada compatibilidad.

Por último, Nano Server es la imagen más pequeña de la familia Windows Server, orientada a workloads modernos, sin interfaz gráfica y pensada para aplicaciones .NET Core / .NET modernos y ciertos roles especializados. Esta imagen resulta ideal para microservicios muy ligeros que no requieren todo el peso de Server Core.

Cuándo usar contenedores de Windows: casos de uso claros

La pregunta clave es: ¿en qué situaciones tiene sentido usar contenedores de Windows en lugar de pasarse a Linux o seguir con VMs clásicas? Hay una serie de patrones que se repiten en empresas que ya los usan en producción y generan buenos resultados.

El primer gran caso es el de la aplicación heredada en .NET Framework (o en otro stack que solo soporte Windows) que quieres modernizar sin reescribirla desde cero. Migrar esa aplicación a .NET moderno puede ser inviable en coste y riesgo, pero contenerizarla en Windows Server Core o Windows permite ganar en automatización, despliegues consistentes y elasticidad sin tocar demasiado el código.

Otro escenario típico es el de aplicaciones que arrastran dependencias exclusivas de Windows: componentes COM+, librerías antiguas, integraciones con productos Microsoft sólo disponibles en Windows o requisitos de seguridad y autenticación ligados al ecosistema Windows. Cuando esas piezas no tienen equivalentes reales en Linux, mantener la capa de sistema en Windows pero empaquetarla en contenedores es una vía muy razonable.

También hay muchas organizaciones donde el equipo de sistemas y operaciones tiene experiencia casi exclusiva en entornos Windows. En esos casos, apostar por contenedores de Windows encaja mejor con los procesos, herramientas y conocimientos existentes, y reduce la fricción cultural de adoptar modelos DevOps y de infraestructura como código.

En definitiva, si tu aplicación debe seguir en Windows por motivos técnicos o de negocio, los contenedores de Windows te dan una plataforma más ligera y automatizable que las VMs tradicionales. No se trata de competir con los contenedores Linux, sino de ofrecer un camino de modernización realista a las cargas Windows que no pueden o no compensa mover.

En cambio, cuando estás creando una aplicación nueva desde cero y no tienes ninguna dependencia de Windows, lo más sensato es valorar seriamente desarrollar sobre Linux y .NET moderno u otros lenguajes multiplataforma. En esos proyectos, la inercia del ecosistema, el tooling y el soporte de los proveedores juega claramente a favor de Linux.

Ventajas para desarrolladores: por qué te interesa contenerizar en Windows

Desde el punto de vista del equipo de desarrollo, los contenedores de Windows sirven, sobre todo, para reducir fricción entre entornos. La idea de que la aplicación “en mi portátil funciona pero en pre no” se mitiga muchísimo cuando todos los entornos tiran de la misma imagen de contenedor construida en CI.

El hecho de que cada contenedor lleve empaquetadas sus propias librerías, runtimes y dependencias evita que una actualización en el host rompa un servicio en producción. La app se ejecuta siempre con las versiones de bibliotecas que tú has declarado en tu Dockerfile y tu manifest, sin interferir con otras aplicaciones.

Además, los contenedores hacen muy sencillo probar nuevas versiones de una aplicación o de sus dependencias creando imágenes paralelas, lanzando entornos temporales para QA o pruebas A/B, y eliminándolos en cuanto dejen de ser útiles. Todo ello con tiempos de arranque muy reducidos y sin necesidad de pedir nuevas VMs a infraestructura.

Para el día a día, muchos desarrolladores usan Docker Desktop en Windows 10/11 para levantar todo su entorno de desarrollo local en contenedores: bases de datos, colas de mensajes, APIs auxiliares y la propia app, orquestando todo con Docker Compose. Visual Studio y VS Code se integran bien con esta dinámica, permitiendo debug directo sobre contenedores de Windows.

Por último, contenerizar desde el principio facilita muchísimo la adopción de prácticas DevOps y pipelines CI/CD. Compilar la app, construir la imagen, ejecutar baterías de tests en contenedores efímeros y, si todo pasa, desplegar la nueva imagen en Kubernetes o en otra plataforma de orquestación se convierte en un flujo relativamente estándar.

Beneficios para administradores y equipos de operaciones

Para los profesionales de TI e infraestructura, los contenedores de Windows permiten pasar de un modelo basado en servidores “a mano” a un enfoque más declarativo y repetible. En lugar de documentar decenas de pasos para configurar una VM, la configuración se captura de forma explícita en la imagen y en los manifiestos del orquestador.

Esto simplifica las tareas de despliegue, rollback y actualización: si aparece un problema en una nueva versión, basta con volver a desplegar la imagen anterior y el entorno recupera su estado sin necesidad de deshacer cambios manualmente o restaurar snapshots de VMs.

La densidad de contenedores en un host Windows Server suele ser sensiblemente mayor que la de máquinas virtuales completas, lo que se traduce en un mejor aprovechamiento de CPU, memoria y licencias. En proveedores cloud, esto suele repercutir en ahorros directos de coste.

Otro aspecto interesante es el uso de contenedores como herramienta de troubleshooting. Puedes levantar contenedores en modo interactivo con distintas versiones de herramientas de línea de comandos, agentes o utilidades de diagnóstico, sin ensuciar el sistema operativo host y sin que haya conflictos de versiones entre sí.

En entornos híbridos o multicloud, tener las aplicaciones Windows empaquetadas en contenedores facilita también la portabilidad: puedes mover imágenes entre clusters Kubernetes on‑premises, AKS en Azure u otros proveedores que soporten nodos Windows, sin reconstruir desde cero cada entorno.

Orquestación de contenedores de Windows

Cuando pasas de unos pocos contenedores aislados a una aplicación compuesta por docenas o cientos de servicios, un orquestador se vuelve imprescindible. Intentar gestionar manualmente escalados, reinicios, actualizaciones y redes a esa escala es impracticable.

Los orquestadores de contenedores, con Kubernetes a la cabeza, proporcionan mecanismos para describir el estado deseado de la aplicación (réplicas, tolerancias a fallo, reglas de actualización, políticas de red) y se encargan de mantener ese estado de forma automática en el clúster. Si un nodo cae o un contenedor falla, el orquestador lo detecta y programa nuevos pods donde corresponda.

Entre las capacidades que ofrecen estos orquestadores para workloads Windows están la implementación a escala, la programación inteligente de cargas de trabajo y la supervisión de salud de cada servicio. Puedes definir probes de liveness y readiness para controlar cuándo un contenedor está listo para recibir tráfico y cuándo debe reiniciarse.

También manejan la conmutación por error ante fallos de nodo, el escalado automático en base a consumo de CPU o métricas personalizadas, la gestión de redes internas y externas, así como la detección de servicios y el routing de tráfico mediante Ingress o servicios de tipo LoadBalancer.

Otra pieza clave es la capacidad de coordinar actualizaciones sin downtime: despliegues rolling, blue‑green, canary, etc. Esto te permite introducir nuevas versiones de tus contenedores de Windows de forma controlada, minimizando riesgos y con posibilidad de rollback rápido si aparece un bug crítico.

Modos de aislamiento de contenedores en Windows

Windows introduce un matiz importante respecto a Linux: existen dos modos principales de aislamiento para contenedores, cada uno con sus ventajas y compromisos. Entenderlos es clave para decidir cómo ejecutar tus contenedores según el nivel de seguridad y compatibilidad que necesitas.

El modo de aislamiento de procesos es el equivalente más cercano al modelo de contenedor clásico en Linux. En este modo, los contenedores comparten directamente el kernel del host, utilizando mecanismos de aislamiento a nivel de procesos para mantener separadas las distintas cargas de trabajo.

Este modo suele ofrecer un rendimiento excelente y un consumo de recursos muy ajustado, pero a cambio el grado de aislamiento no es tan fuerte como el que proporciona una VM o el modo Hyper‑V. Un fallo en el kernel afecta por igual a host y contenedores, y viceversa.

El otro modo es el aislamiento bajo Hyper‑V. En este caso, cada contenedor se ejecuta en realidad dentro de una mini máquina virtual ligera, con su propio kernel, aunque la experiencia de uso para el usuario sea la misma que la de un contenedor normal.

La ventaja de este enfoque es que el aislamiento se refuerza de manera sustancial, tanto entre host y contenedores como entre contenedores entre sí. También mejora la compatibilidad en algunos escenarios, a costa de un consumo de recursos algo mayor y un arranque un poco más pesado que en el modo de proceso puro.

Limitaciones y aplicaciones que no encajan en contenedores de Windows

No todas las cargas de trabajo son buenas candidatas a contenerizarse en Windows. Hay servicios y tipos de aplicaciones que, hoy por hoy, no se admiten o no tiene sentido intentar empaquetar en un contenedor, bien por limitaciones técnicas o por el tipo de interacción que requieren.

Por ejemplo, actualmente no está soportado ejecutar en contenedores Windows servicios como Microsoft Distributed Transaction Coordinator (MSDTC), que tienen un modelo de operación complejo y un fuerte acoplamiento con el sistema host.

Lo mismo sucede con aplicaciones como Microsoft Office y otras suites de productividad orientadas al usuario final, donde la interfaz gráfica y la experiencia de escritorio son parte esencial del producto. Tampoco encajan bien las aplicaciones cliente con UIs ricas que esperan un entorno de escritorio completo.

En el ámbito de la infraestructura, tampoco es posible hoy contenerizar roles como controladores de dominio, servidores DNS, DHCP, servidores de impresión, servidores de archivos o determinados servicios de sincronización de hora y gestión de identidades. Estos roles siguen estando pensados para ejecutarse directamente en servidores (físicos o virtuales).

En general, una buena regla práctica es asumir que los contenedores están pensados para servicios de backend, APIs, aplicaciones web, workers, tareas en background y componentes similares, preferiblemente sin UI o con UI mínima basada en web. Cuando la aplicación requiere controladores de hardware específicos o integración muy baja con el sistema, es probable que una VM siga siendo la mejor opción.

Comparativa Windows vs Linux en contenedores

La mayor parte del ecosistema de contenedores nació y maduró primero en Linux. Docker, Kubernetes, la mayoría de imágenes oficiales y gran parte del tooling se han centrado tradicionalmente en el mundo Linux, que ha ido por delante en adopción y soporte por parte de los proveedores cloud.

Esto implica que, en términos de tamaño de las imágenes, ecosistema de herramientas, ejemplos disponibles y número de workloads reales, Linux lleva ventaja. Es más fácil encontrar imágenes listas para usar de casi cualquier cosa en Linux, desde bases de datos hasta proxies o servicios de mensajería.

Aun así, los contenedores de Windows han ido recortando distancia. A día de hoy puedes ejecutar contenedores Windows de forma nativa en hosts Windows, y contenedores Linux en esos mismos hosts mediante WSL2 o aislamiento Hyper‑V, con un nivel de integración cada vez mejor.

La compatibilidad cruzada no es total: un host Linux no puede ejecutar nativamente contenedores Windows, ni un host Windows puede ejecutar nativamente contenedores Linux sin un layer intermedio como Hyper‑V o WSL2. Por eso, lo habitual en producción es tener nodos Linux para workloads Linux y nodos Windows para workloads Windows en el mismo clúster de Kubernetes.

Sabiendo esto, el criterio habitual es sencillo: cuando tu aplicación puede vivir en Linux sin fricciones, es lógico aprovechar la madurez del ecosistema Linux. Pero cuando tu negocio depende de tecnologías Windows, usar contenedores de Windows en lugar de VMs te ofrece mejoras claras, incluso aunque el ecosistema sea algo más pequeño.

Instalación y primeros pasos con Docker en Windows Server

Para trabajar con contenedores en Windows Server (2016, 2019, 2022 y posteriores), el flujo típico pasa por instalar el rol o característica de contenedores y un runtime compatible, normalmente Docker Engine o containerd, en función de la estrategia de producción que vayas a seguir.

En muchos casos, se utiliza el proveedor DockerMsftProvider desde PowerShell para instalar Docker. El proceso consiste en añadir el módulo correspondiente desde la galería de PowerShell y luego solicitar la instalación del paquete docker a través de ese proveedor.

Tras la instalación, es necesario reiniciar el servidor para que todos los componentes del runtime de contenedores se registren correctamente y la característica de contenedores quede activa. A partir de ahí, puedes comprobar el estado del paquete y empezar a usar comandos como docker version o docker info para verificar la configuración.

Si más adelante quieres actualizar Docker en ese servidor, puedes volver a usar el mismo proveedor indicando que se fuerce la actualización del paquete. De este modo mantienes el motor alineado con las versiones que necesitas para las imágenes y orquestadores que estés usando.

En Windows 10/11 en modo desarrollo, el camino más simple suele ser instalar Docker Desktop desde su instalador gráfico, permitiendo que habilite, si hace falta, las características de Hyper‑V o WSL2. Después bastará con ajustar si quieres el backend WSL2 o Hyper‑V, y alternar entre contenedores Linux o Windows según tus necesidades.

Ejemplo práctico: un contenedor web en Windows

Un ejemplo muy ilustrativo para entender la dinámica es construir un contenedor con una sencilla aplicación web en IIS sobre Windows Server Core. El flujo básico pasa por crear un Dockerfile, una imagen y uno o varios contenedores basados en ella.

Primero, preparas un directorio de trabajo en el servidor y creas en él un archivo llamado Dockerfile (sin extensión). Este archivo contendrá las instrucciones para que Docker sepa qué imagen base usar y qué pasos ejecutar al construir la nueva imagen.

En el Dockerfile indicas, por ejemplo, que la imagen base debe ser una plantilla de Windows Server Core con IIS ya instalado desde el registro oficial de Microsoft, que debe ejecutar PowerShell al iniciarse el contenedor y que debe copiar un archivo index.html desde el host a la carpeta web por defecto de IIS dentro del contenedor.

A continuación, creas ese index.html con una página de “Hola mundo” muy simple. Con ambos archivos en la carpeta (Dockerfile e index.html), ejecutas un docker build con una etiqueta, por ejemplo webserver, apuntando al directorio actual. El motor descargará, si no la tiene, la imagen base de Windows Server Core con IIS y aplicará tus instrucciones.

Una vez construida la imagen, puedes listar las imágenes disponibles y arrancar tu primer contenedor con un comando docker run, asignándole un nombre, pidiéndole que se ejecute en segundo plano y haciendo un mapeo de puertos entre el puerto 80 del contenedor y el puerto 80 del host.

En ese momento, si abres un navegador y te conectas a localhost, estarás llegando a IIS dentro del contenedor, no al host, y verás la página HTML que copiaste. Puedes crear un segundo contenedor a partir de la misma imagen, esta vez mapeando el puerto 8080 del host al 80 del contenedor, y tendrás dos instancias independientes sirviendo contenido distinto desde la misma máquina.

Todo esto se consigue sin instalar IIS directamente en el host, sin crear VMs adicionales ni asignar memoria fija a cada instancia. Los contenedores usan los recursos que necesitan, se crean y destruyen en segundos y permiten tener varias versiones de la misma aplicación conviviendo sin conflictos.

En definitiva, los contenedores en Windows son una pieza muy potente cuando necesitamos modernizar aplicaciones que no pueden abandonar el ecosistema Windows: ofrecen un entorno ligero, reproducible y fácil de automatizar, mejoran claramente respecto a las máquinas virtuales clásicas en velocidad y densidad, permiten adoptar prácticas DevOps y orquestadores como Kubernetes, y, aunque no sustituyen a Linux donde éste encaja mejor, sí proporcionan una vía realista y madura para dar una segunda vida a muchas cargas de trabajo críticas basadas en Windows.