Contenedorización de aplicaciones monolíticas

Sugerencia

Este contenido es un extracto del libro electrónico, ".NET Microservices Architecture for Containerized .NET Applications" (Arquitectura de microservicios de .NET para aplicaciones de .NET contenedorizadas), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Es posible que quiera compilar una única aplicación web o un servicio web implementados de forma monolítica e implementarla como un contenedor. Es posible que la propia aplicación no sea monolítica internamente, pero estructurada como varias bibliotecas, componentes o incluso capas (capa de aplicación, capa de dominio, capa de acceso a datos, etc.). Sin embargo, externamente es un único contenedor: un único proceso, una sola aplicación web o un único servicio.

Para administrar este modelo, implemente un único contenedor para representar la aplicación. Para aumentar la capacidad, escale horizontalmente, es decir, agregue más copias con un equilibrador de carga delante. La simplicidad procede de administrar una sola implementación en un único contenedor o máquina virtual.

Figura 4-1. Ejemplo de la arquitectura de una aplicación monolítica en contenedor

Puede incluir varios componentes, bibliotecas o capas internas en cada contenedor, como se muestra en la figura 4-1. Una aplicación en contenedor monolítica tiene la mayor parte de su funcionalidad dentro de un único contenedor, con capas internas o bibliotecas, y se escala horizontalmente mediante la clonación del contenedor en varios servidores o máquinas virtuales. Sin embargo, este patrón monolítico podría entrar en conflicto con el principio de contenedor "un contenedor hace una cosa y lo hace en un proceso", pero podría ser correcto para algunos casos.

La desventaja de este enfoque es evidente si la aplicación crece, lo que requiere que se escale. Si toda la aplicación puede escalar, no es realmente un problema. Sin embargo, en la mayoría de los casos, solo algunas partes de la aplicación son los puntos de ahogamiento que requieren escalado, mientras que otros componentes se usan menos.

Por ejemplo, en una aplicación típica de comercio electrónico, es probable que tenga que escalar el subsistema de información del producto, ya que muchos más clientes examinan productos que comprarlos. Más clientes usan su cesta que usar la canalización de pago. Menos clientes agregan comentarios o ven su historial de compras. Y es posible que solo tenga unos pocos empleados que necesiten administrar el contenido y las campañas de marketing. Si escala el diseño monolítico, todo el código de estas diferentes tareas se despliega varias veces y se escala al mismo nivel.

Hay varias maneras de escalar una duplicación horizontal de la aplicación, dividir diferentes áreas de la aplicación y crear particiones de datos o conceptos empresariales similares. Pero, además del problema de escalar todos los componentes, los cambios en un único componente requieren una nueva prueba completa de toda la aplicación y una reimplementación completa de todas las instancias.

Sin embargo, el enfoque monolítico es común, ya que el desarrollo de la aplicación es inicialmente más fácil que para los enfoques de microservicios. Por lo tanto, muchas organizaciones desarrollan el uso de este enfoque arquitectónico. Aunque algunas organizaciones han tenido buenos resultados, otros están alcanzando límites. Muchas organizaciones diseñaron sus aplicaciones con este modelo porque las herramientas y la infraestructura hicieron que fuera demasiado difícil compilar arquitecturas orientadas a servicios (SOA) hace años, y no vieron la necesidad hasta que creció la aplicación.

Desde la perspectiva de la infraestructura, cada servidor puede ejecutar muchas aplicaciones dentro del mismo host y tener una proporción aceptable de eficiencia en el uso de recursos, como se muestra en la figura 4-2.

Figura 4-2. Enfoque monolítico: host que ejecuta varias aplicaciones, cada aplicación que se ejecuta como un contenedor

Las aplicaciones monolíticas de Microsoft Azure se pueden implementar mediante máquinas virtuales dedicadas para cada instancia. Además, mediante conjuntos de escalado de máquinas virtuales de Azure, puede escalar fácilmente las máquinas virtuales. Azure App Service también puede ejecutar aplicaciones monolíticas y escalar fácilmente instancias sin necesidad de administrar las máquinas virtuales. Desde 2016, Azure App Services también puede ejecutar instancias únicas de contenedores de Docker, lo que simplifica la implementación.

Como entorno de control de calidad o un entorno de producción limitado, puede implementar varias máquinas virtuales host de Docker y equilibrarlas con el equilibrador de Azure, como se muestra en la figura 4-3. Esto le permite administrar el escalado con un enfoque general, ya que toda la aplicación reside dentro de un único contenedor.

Figura 4-3. Ejemplo de varios hosts que escalan verticalmente una sola aplicación contenedora

La implementación en los distintos hosts se puede administrar con técnicas de implementación tradicionales. Los hosts de Docker se pueden administrar con comandos como docker run o docker-compose, realizados manualmente, o mediante la automatización, como las canalizaciones de entrega continua (CD).

Implementación de una aplicación monolítica como contenedor

Existen ventajas para usar contenedores para administrar implementaciones de aplicaciones monolíticas. El escalado de instancias de contenedor es mucho más rápido y sencillo que la implementación de máquinas virtuales adicionales. Incluso si usa conjuntos de escalado de máquinas virtuales, las máquinas virtuales tardan tiempo en iniciarse. Cuando se implementa como instancias de aplicación tradicionales en lugar de contenedores, la configuración de la aplicación se administra como parte de la máquina virtual, lo que no es ideal.

La implementación de actualizaciones como imágenes de Docker es mucho más rápida y eficiente en cuanto a la red. Las imágenes de Docker normalmente se inician en segundos, lo que acelera los despliegues. Eliminar una instancia de imagen de Docker es tan fácil como emitir un comando docker stop y normalmente se completa en menos de un segundo.

Dado que los contenedores son inmutables por diseño, nunca debe preocuparse por las máquinas virtuales dañadas. Por el contrario, es posible que los scripts de actualización de una máquina virtual se olviden de tener en cuenta alguna configuración específica o archivo dejado en el disco.

Aunque las aplicaciones monolíticas pueden beneficiarse de Docker, solo mencionamos las ventajas. Las ventajas adicionales de administrar contenedores proceden de la implementación con orquestadores de contenedores, que administran las distintas instancias y el ciclo de vida de cada instancia de contenedor. Dividir la aplicación monolítica en subsistemas que se pueden escalar, desarrollar e implementar individualmente es el punto de entrada en el dominio de los microservicios.

Publicación de una aplicación basada en un solo contenedor en Azure App Service

Tanto si quiere obtener la validación de un contenedor implementado en Azure como si una aplicación es simplemente una aplicación de contenedor único, Azure App Service proporciona una excelente manera de proporcionar servicios escalables basados en contenedores únicos. El uso de Azure App Service es sencillo. Proporciona una excelente integración con Git para facilitar la toma del código, compilarlo en Visual Studio e implementarlo directamente en Azure.

Figura 4-4. Publicación de una aplicación de contenedor único en Azure App Service desde Visual Studio 2022

Sin Docker, si necesitaba otras funcionalidades, marcos o dependencias que no se admiten en Azure App Service, tenía que esperar hasta que el equipo de Azure actualizara esas dependencias en App Service. O bien, tenía que cambiar a otros servicios, como Azure Cloud Services o máquinas virtuales, donde tenía más control y podía instalar un componente o marco necesarios para la aplicación.

La compatibilidad con contenedores en Visual Studio 2017 y versiones posteriores le ofrece la posibilidad de incluir lo que desee en el entorno de la aplicación, como se muestra en la figura 4-4. Como lo está ejecutando en un contenedor, si agrega una dependencia a la aplicación, puede incluir la dependencia en el Dockerfile o en la imagen de Docker.

Como también se muestra en la figura 4-4, el flujo de publicación inserta una imagen a través de un registro de contenedor. Puede ser Azure Container Registry (un registro cercano a las implementaciones en Azure y protegidas por grupos y cuentas de Azure Active Directory) o cualquier otro registro de Docker, como Docker Hub o un registro local.

Siguiente anterior