.NET Core vs .NET Framework for Docker Containers

¿Por qué Docker y qué es?

Docker se está convirtiendo en el estándar de facto en la industria de los contenedores y su popularidad crece constantemente día a día. Según Docker, se han colocado más de 3,5 millones de aplicaciones en contenedores utilizando la tecnología Docker y se han descargado más de 37.000 millones de aplicaciones en contenedores. Se sorprenderá de la cantidad de tecnologías populares que se ejecutan en Docker: NGINX, Redis, Postgres, Elasticsearch, MongoDB, MySQL, RabbitMQ – ¡y ni siquiera es una lista completa!

Obviamente, se puede trabajar sin Docker. Muchas aplicaciones se ejecutan con éxito sin él y todo parece ir bien. Por lo general, detrás de la escena, la situación es bastante diferente. Si usted es un desarrollador o un DevOps, realmente entiende que no es tan fácil y bueno como parece a primera vista. ¿Cuántas veces ha trabajado en algunas características y todo lo hizo muy bien en su máquina local, y justo después de desplegar a la puesta en escena o la producción, te das cuenta, que algo salió mal. Con Docker, nunca oirá hablar de tales problemas, porque la aplicación empaquetada en Docker puede ser ejecutada en cualquier entorno Docker soportado, y se ejecutará de la forma prevista en todos los objetivos de despliegue. Puede desarrollarla y depurarla en su máquina y luego desplegarla en otra máquina con el mismo entorno, garantizado.

Aquí, en Redwerk, utilizamos Docker con bastante frecuencia en los últimos tiempos, tanto para los proyectos internos, como para los personalizados. Diciendo esto, hemos aprendido de nuestra propia experiencia que el uso de Docker puede hacer su vida más fácil.

Con la ayuda de Docker, hemos reducido con éxito el tiempo de inactividad de nuestros sitios de prueba durante el despliegue con la capacidad de Docker para utilizar el contenedor actual mientras se crea una nueva construcción. Esto definitivamente ayuda en varios casos: su equipo de control de calidad no esperará hasta que despliegue nuevos cambios; sus clientes ni siquiera entenderán que algo se estaba desplegando mientras usaban su sitio web. En el mundo moderno, esta cuestión es bastante importante.

Docker permite empaquetar una aplicación o servicio, sus dependencias y su configuración, como una imagen de contenedor portátil y autosuficiente que puede ejecutarse en la nube o en las instalaciones. En resumen, los contenedores ofrecen las ventajas del aislamiento, la portabilidad, la agilidad, la escalabilidad y el control en todo el flujo de trabajo del ciclo de vida de la aplicación. Nos permite empaquetar nuestras aplicaciones con todas sus dependencias en un contenedor Docker y desplegarlo cómodamente en entornos de prueba o de trabajo. Simplifica nuestro proceso de desarrollo, facilita la transición del trabajo del proyecto a otra máquina, y permite reducir el tiempo de inclusión de nuevos desarrolladores en un proyecto .

Docker a veces suena como una máquina virtual, y hay muchas similitudes entre ambas. En particular, ambas permiten crear una imagen y escalarla a unas pocas instancias, que trabajan de forma segura y aislada entre sí. Sin embargo, los contenedores tienen más ventajas que los hacen más apropiados para construir y desplegar aplicaciones.

A diferencia de las máquinas virtuales, los contenedores comparten el núcleo del sistema operativo y todas las bibliotecas entre sí, no requieren un sistema operativo invitado completo y se ejecutan como procesos aislados (una excepción son los contenedores Hyper-V). Por ello, son fáciles de desplegar y se ponen en marcha muy rápidamente, lo que en última instancia es importante para la producción. Además, los contenedores son más ligeros que las imágenes de máquinas virtuales. Las aplicaciones en contenedores son fáciles de escalar porque los contenedores pueden añadirse o sustraerse rápidamente de un entorno. Es como instanciar un proceso como una aplicación o servicio web. Los desarrolladores pueden utilizar diferentes entornos de desarrollo: en Mac, en Linux se pueden utilizar imágenes de Linux, en Windows – o Linux o Windows. No afecta a la consistencia de los contenedores, por lo que son más portátiles.

Las máquinas virtuales siguen teniendo un papel importante, ya que se utilizan muy a menudo para ejecutar contenedores entre máquinas virtuales, incluso cuando se utiliza la infraestructura de la nube de proveedores como Amazon, Google y Microsoft.

Terminología de Docker

Esta es una breve lista de términos de Docker, necesaria para entender algunos detalles y profundizar en Docker.

Imagen de contenedor: las imágenes Docker son la base de los contenedores. Una imagen es una colección ordenada de cambios en el sistema de archivos raíz y los parámetros de ejecución correspondientes para su uso dentro de un tiempo de ejecución del contenedor (en otras palabras, todas las dependencias más la configuración de despliegue y ejecución). Una imagen suele contener una unión de sistemas de archivos en capas apilados unos sobre otros. Una imagen es inmutable y no tiene estado.

Contenedor: es una instancia de ejecución de una imagen Docker. Consta de una imagen, un entorno de ejecución y un conjunto de instrucciones estándar. Según Docker, el concepto se toma prestado de los contenedores de transporte, que definen un estándar para enviar mercancías a nivel mundial. Docker define un estándar para enviar software.

Tag: una etiqueta, que se puede aplicar a las imágenes para que las diferentes imágenes o versiones de un repositorio se distingan unas de otras.

Dockerfile: un documento de texto que contiene todos los comandos que normalmente ejecutaría manualmente para construir una imagen Docker. Las imágenes pueden ser construidas automáticamente por Docker, utilizando estas instrucciones.

Repositorio: es un conjunto de imágenes Docker. Un repositorio puede compartirse enviándolo a un servidor de registro. Puede contener múltiples variantes de una imagen específica (variantes de plataforma, variantes más pesadas o más ligeras de una imagen).

Docker Hub: es un recurso centralizado para trabajar con Docker y sus componentes. Proporciona alojamiento de imágenes, autenticación de usuarios, las construcciones de imágenes automatizadas y las herramientas de flujo de trabajo (como los disparadores de construcción y los webhooks), la integración con GitHub y Bitbucket.

Kitematic: una interfaz gráfica de usuario heredada, incluida en Docker Toolbox, para gestionar los contenedores Docker.

Cluster: una colección de hosts Docker expuestos como uno solo. Puede crearse con Docker Swarm, Mesosphere DC/OS, Kubernetes y Azure Service Fabric

Orquestador: una herramienta que simplifica la gestión de clusters y hosts Docker. Los orquestadores incluyen una serie de características que permiten gestionar imágenes, contenedores y hosts, redes de contenedores, configuraciones, equilibrio de carga, descubrimiento de servicios, alta disponibilidad y mucho más. Normalmente, los productos orquestadores son los mismos que proporcionan la infraestructura de clúster.

.NET Core frente a .NET Framework para contenedores Docker

Hay dos marcos compatibles para crear aplicaciones Docker en contenedores del lado del servidor con .NET: .NET Framework y .NET Core. Hay diferencias fundamentales entre ellos, y la respuesta a la pregunta “¿Qué marco debe utilizarse?” dependerá de lo que quiera conseguir. Así pues, hablemos de qué elegir: .NET Core o .NET Framework para Docker Containers.

Cuándo se debe utilizar .NET Core para los contenedores Docker

La respuesta más rápida se basará en las ventajas enumeradas anteriormente, obviamente debería elegir .NET Core cuando necesite una plataforma multiplataforma, rápida y ligera y si la arquitectura de su aplicación se basa en microservicios. Pero profundicemos en los detalles.

Así, el primer punto es que debe utilizar .NET Core si su objetivo es tener una aplicación que pueda ejecutarse en múltiples plataformas. No hacen falta explicaciones: si necesita desplegar aplicaciones de servidor con imágenes de contenedor de Linux o Windows, su elección es obvia.

En segundo lugar, cuando su objetivo es crear y desplegar microservicios en contenedores – su elección preferida es .NET Core. Y de nuevo se puede explicar por la ligereza de la plataforma. Un microservicio debe ser lo más pequeño posible: ser ligero al girar, tener una pequeña huella, tener un pequeño Contexto Limitado, representar una pequeña área de preocupaciones, y ser capaz de arrancar y parar rápidamente. Para esos requisitos, querrá utilizar imágenes de contenedor pequeñas y rápidas de iniciar, como lo es la imagen de contenedor de .NET Core. Por el contrario, para utilizar .NET Framework para un contenedor, deberá basar su imagen únicamente en la imagen Windows Server Core, que es mucho más pesada de lo que son las imágenes Windows Nano Server o Linux, que se utilizan para .NET Core.

En tercer lugar, si es importante para usted tener una actualización regular de los paquetes. Si su proyecto tiene actualizaciones periódicas, con lo que se ahorra dinero y también se reducen los riesgos, este punto tiene un papel fundamental. .NET Core ofrece la posibilidad de instalar diferentes versiones del tiempo de ejecución dentro de la misma máquina. Esta ventaja es más importante para los servidores o máquinas virtuales que no utilizan contenedores, porque los contenedores aíslan las versiones de .NET que la aplicación necesita. Por supuesto, si son compatibles con el sistema operativo subyacente.

Por último, si tiene un sitio web basado en contenedores, su mejor opción sería .NET Core y ASP.NET Core para la pila de tecnologías a fin de obtener la mejor densidad, granularidad y rendimiento posibles para su sistema. ASP.NET Core es hasta diez veces más rápido que ASP.NET en el .NET Framework tradicional. Y, además, volviendo a las arquitecturas de microservicios, es especialmente relevante para ellas. Cuando se tienen cientos de microservicios (contenedores) en ejecución, o se planea aumentar su número en el futuro, con las imágenes de ASP.NET Core (basadas en el tiempo de ejecución de .NET Core) en Linux o Windows Nano, se puede ejecutar el sistema con un número mucho menor de servidores o máquinas virtuales, lo que en última instancia ahorra costes en infraestructura y alojamiento.

Cuándo se debe utilizar .NET Framework para los contenedores Docker

.NET Core tiene muchas ventajas, pero a pesar de ello, .NET Framework sigue siendo una buena opción para muchos escenarios existentes.

Algunos paquetes NuGet necesitan Windows para ejecutarse y pueden no ser compatibles con .NET Core. Y a pesar de que las bibliotecas de terceros están adoptando rápidamente el estándar .NET, que permite compartir el código en todos los sabores de .NET, incluido .NET Core, ese problema sigue existiendo. Si esos paquetes son críticos para su aplicación y son muy necesarios, entonces tendrá que utilizar .NET Framework en Windows Containers. En el caso de algunos paquetes, el problema ya está resuelto, porque recientemente se ha publicado el paquete de compatibilidad con Windows para ampliar la superficie de la API disponible para .NET Standard 2.0 en Windows. Este paquete permite recompilar la mayor parte del código existente a .NET Standard 2.x con poca o ninguna modificación, para que funcione en Windows. Pero la posibilidad de que exactamente su paquete no sea compatible sigue existiendo y en esta situación, su elección es definitivamente .NET Framework.

    Algunas tecnologías de .NET Framework no están disponibles en la versión actual de .NET Core (versión 2.1 en el momento de escribir este artículo). Algunas de ellas estarán disponibles en versiones posteriores, pero otras podrían no estarlo nunca. He aquí la lista oficial de las tecnologías más comunes que no se encuentran en .NET Core de Microsoft:

  • Aplicaciones ASP.NET Web Forms: Los formularios web ASP.NET sólo están disponibles en .NET Framework y no se puede utilizar ASP.NET Core para ellos. No hay planes para llevar los formularios web ASP.NET a .NET Core.
  • Aplicaciones ASP.NET Web Pages: no están incluidas en ASP.NET Core. Las Razor Pages de ASP.NET Core tienen muchas similitudes con las Web Pages.
  • Implementación de servicios WCF. Aunque existe una biblioteca WCF-Client para consumir servicios WCF de .NET Core, la implementación del servidor WCF sólo está disponible actualmente en .NET Framework. Este escenario no forma parte del plan actual de .NET Core, pero se está considerando para el futuro.
  • Servicios relacionados con el flujo de trabajo: Windows Workflow Foundation, los servicios de flujo de trabajo (WCF + WF en un único servicio) y los servicios de datos WCF sólo están disponibles en .NET Framework. No hay planes para llevarlos a .NET Core.
  • Soporte de lenguajes: Visual Basic y F# están actualmente soportados en .NET Core, pero no para todos los tipos de proyectos. Ambos están soportados (en el momento de escribir este artículo) para la aplicación de consola, la biblioteca de clases classlib, el proyecto de pruebas unitarias mstest, el proyecto de pruebas xUnit. Y F# también está soportado para ASP.NET Core vacío, ASP.NET Core Web App (Modelo-Vista-Controlador) y ASP.NET Core Web API. Todos los demás no están soportados.

Y obviamente, si tiene un proyecto estable, sin necesidad de ampliarlo y no tiene problemas, por ahora, no necesita migrar su proyecto a .NET Core. Un enfoque recomendado es utilizar .NET Core a medida que amplía una aplicación existente, como por ejemplo escribiendo un nuevo servicio en ASP.NET Core. Puede utilizar contenedores Docker sólo para simplificar el despliegue. Por ejemplo, los contenedores proporcionan entornos de prueba mejor aislados y también pueden eliminar los problemas de despliegue causados por la falta de dependencias cuando se pasa a un entorno de producción. En casos como estos, tiene sentido utilizar Docker y Windows Containers para sus aplicaciones actuales de .NET Framework.

Entonces, ¿por qué .NET Core es tan genial?

Ahora que hemos hablado de los principales pros y contras de ambos marcos, queremos compartir algunos detalles más sobre por qué .NET Core es tan bueno y lo que necesita saber para trabajar con él.

La plataforma .NET se introdujo en 2002 y ha sufrido enormes transformaciones desde entonces. Durante mucho tiempo .NET fue un entorno multiplataforma, pero no multiplataforma y sobre todo una cosa de Windows.

.NET Core fue un nuevo aliento para la plataforma .NET. Se reescribió completamente desde cero para ser un marco de trabajo de código abierto, modular, ligero y multiplataforma para crear aplicaciones y servicios web que se ejecuten en Windows, Linux y Mac. Los siguientes son datos clave que debe conocer sobre .NET Core de Microsoft.

.NET Core es multiplataforma. Si está acostumbrado a pensar que la plataforma .NET está diseñada únicamente para Windows, ahora, con .NET Core, la realidad cambia. Este marco ya funciona en Windows, Mac OS X y Linux. En nuestra empresa, tenemos un exitoso proyecto ASP.NET Core, dentro del cual nuestro equipo utiliza diferentes plataformas de SO: el equipo de frontend utiliza el SO Linux para el desarrollo, uno de nuestros desarrolladores de backend utiliza MacOS, y otros dos desarrolladores trabajan en máquinas Windows. Y todo funciona como un mecanismo suizo, sin ningún problema, como si todos tuvieran el mismo sistema operativo. Si hace un par de años parecía algo increíble, hoy en día es una realidad. Por supuesto, algunos componentes individuales, por ejemplo, algo específico del sistema operativo como un sistema de archivos, requieren una implementación independiente. El modelo de entrega a través de NuGet permite borrar estas diferencias. Para los desarrolladores, se trata de una única API, que se ejecuta en diferentes plataformas, no necesitan ocuparse de ello, porque el paquete ya contiene diferentes implementaciones para cada uno de los entornos.

En nuestra empresa, tenemos un par de proyectos exitosos de ASP.NET Core, dentro de los cuales nuestro equipo está utilizando diferentes plataformas de SO: el equipo de frontend utiliza el SO Linux para el desarrollo, uno de nuestros desarrolladores de backend utiliza MacOS, y otros dos desarrolladores trabajan en máquinas Windows. Y todo funciona como un mecanismo suizo, sin ningún problema, como si todos tuvieran el mismo sistema operativo. Si hace un par de años parecía algo increíble, hoy en día es una realidad

Soporte de contenedores. La modularidad y la naturaleza ligera de .NET Core lo hacen perfecto para los contenedores. Está optimizado para cargas de trabajo específicas de la nube, y Microsoft Azure incluso tiene soporte para desplegar su aplicación en contenedores y Kubernetes. Cuando crea y despliega un contenedor, su imagen es mucho más pequeña con .NET Core que con .NET Framework. Además, se adapta mejor a la filosofía y el estilo de trabajo de los contenedores.

.NET Core es de código abierto. Utilizar la plataforma de código abierto tiene muchas ventajas: es más transparente, se tiene más control a la hora de utilizarla y modificarla y, obviamente, proporciona un ecosistema más sólido.

Alto rendimiento..NET Core es también el .NET más rápido de la historia. Y lo mejor de todo es que no necesita cambiar su código. El compilador, por naturaleza, optimizará su código con las nuevas mejoras del lenguaje. El nuevo servidor web Kestrel ha sido rediseñado desde cero para aprovechar los modelos de programación asíncrona, para ser más ligero y rápido. Se ha demostrado que la combinación de Kestrel y ASP.NET Core es muchas veces más rápida.

Esto es sólo un resumen muy rápido de todas las bondades que tiene .NET Core.

En este artículo, hemos intentado explicar algunos detalles de Docker y la plataforma .NET Core, mostrar las ventajas de utilizar Docker con .NET Core y ayudar a los desarrolladores a elegir la plataforma adecuada para desarrollar. Para resumir, la siguiente tabla de decisiones, proporcionada por Microsoft, resume si se debe utilizar .NET Framework o .NET Core. Recuerde que para los contenedores Linux, necesita hosts Docker basados en Linux (VMs o servidores) y que para los contenedores Windows necesita hosts Docker basados en Windows Server (VMs o servidores).

Arquitectura / Tipo de aplicación Contenedores Linux Contenedores Windows
Microservicios en contenedores .NET Core .NET Core
Aplicación monolítica .NET Core .NET Framework .
NET
Core
El mejor rendimiento y escalabilidad de su clase .NET Core .NET Core
Migración de aplicaciones heredadas de Windows Server (“brown-field”) a contenedores .NET Framework
Nuevo desarrollo basado en contenedores (“green-field”) .NET Core .NET Core
ASP.NET Core .NET Core .NET Core (recomendado) .NET
Framework
ASP.NET 4 (MVC 5, Web API 2 y formularios web) marco de trabajo de .NET
Servicios SignalR .NET Core 2.1 o versión superior .NET Framework .
NET
Core 2.1 o versión superior
WCF, WF y otros marcos heredados WCF en .NET Core (sólo la librería clienteWCF) .NET Framework
WCF en .NET Core (sólo la biblioteca cliente WCF)
Consumo de servicios Azure .NET Core (eventualmente todos los servicios de Azure proporcionarán SDKs de cliente para .NET Core) .NET Framework .NET Core (eventualmente todos los servicios de Azure proporcionarán SDKs de cliente para .NET Core
)

Acerca de Redwerk

Nuestro equipo incluye programadores ASP.NET que tienen una sólida experiencia en la creación de aplicaciones en plataformas relacionadas con Microsoft. Como agencia de modelo de externalización de desarrollo de software, proporcionamos servicios completos de desarrollo relacionados con el comercio electrónico, la automatización de negocios, la salud electrónica, los medios de comunicación y el entretenimiento, el gobierno electrónico, el desarrollo de juegos, las startups y la innovación. Más de una década de experiencia con cientos de proyectos exitosos – es la empresa de desarrollo de software de Microsoft Redwerk.

Vea cómo desarrollamos una solución para la logística de fitness clara utilizando el marco .NET

Este campo es obligatorio. no es un correo electrónico comercial

See how we developed a solution for clear-cut fitness logistics on .NET framework