Arquitectura de contenedores y microservicios

Introducción

Docker y la contenedorización en general, se han convertido en una práctica habitual y han resuelto muchos problemas desde la aparición de estas tecnologías: despliegue, aislamiento de aplicaciones, entorno homogéneo, etc. Si su aplicación funciona en su máquina con contenedores, sin duda funcionará en sus entornos de despliegue.

La tecnología de contenedores es similar a la virtualización, pero mucho más ligera: un contenedor no lleva necesariamente un sistema operativo. Debido a esta característica tan importante, los contenedores son más apropiados para hacer que las aplicaciones sean más portables (de una máquina a otra o de una nube a otra) que las máquinas virtuales.

En este capítulo analizaremos una de las tecnologías de contenedorización más populares: Docker. Nativo de Linux y recientemente portado a Windows, Docker está ahora muy extendido y ayuda a las empresas en sus despliegues. Docker también permite construir arquitecturas empresariales más complejas basadas en contenedores, gracias a los orquestadores. En este capítulo se analizará el orquestador de código abierto más conocido: Kubernetes. Con todo ello, las arquitecturas de microservicios cobran cada vez más importancia en el mundo empresarial. Por último, en este capítulo veremos...

Las ventajas de Docker

Docker es básicamente una tecnología de código abierto. La empresa de Silicon Valley utiliza varios componentes del núcleo Linux para diseñar sus contenedores (LXC, Libvirt...).

Arquitectura Docker

Lanzado por el francés Solomon Hykes, Docker facilita el despliegue de aplicaciones y la gestión del tamaño de las infraestructuras. La tecnología se basa en una pieza de API estándar (LXC en Linux y Windows Server Container en Windows) para ofrecer una capa de abstracción que permita ejecutar contenedores en cualquier máquina. Docker tiene la ventaja de ser mucho más ligero que una máquina virtual. Lanzar un contenedor también es más rápido, lo que lo convierte en la solución preferida para desplegar aplicaciones.

Docker no solo ayuda a las empresas en sus despliegues, sino que también acelera la evolución de los ecosistemas en la nube y Microsoft, Amazon y Google lo han entendido. Los contenedores facilitan el despliegue de servicios cloud on-demand. Por ejemplo, tiene sentido contenerizar bases de datos (MySQL, SQL Server, etc.) para que se puedan desplegar muy rápidamente en función de la demanda de los usuarios.

Esta tecnología ofrece una respuesta concreta a determinados escenarios de desarrollo. Por ejemplo, ¿quiere probar una nueva versión de un framework en su aplicación? Muy sencillo, Docker se compone de varias imágenes Docker que se apilan para crear su imagen Docker, de modo que lo único que tiene que hacer es sustituir la capa que desee por la nueva versión para probar su aplicación. Con una VM, resulta complicado cambiar de versión, porque hay que desinstalar y luego instalar la nueva versión. La pérdida de tiempo puede ser considerable.

Lo mismo ocurre con la puesta en producción de aplicaciones. Con Docker, si la aplicación funciona en su máquina, puede estar seguro de que funcionará en el entorno de producción. Docker le permite encapsular todas las dependencias relativas al sistema de información, conservando sus propios sistemas subyacentes (su máquina de desarrollo, por ejemplo). No necesita instalar las dependencias, todo está incrustado en el contenedor.

La gran ventaja de Docker...

Elija Kubernetes como orquestador

Docker es una tecnología que nos permite construir aplicaciones encapsuladas en contenedores que se pueden exportar de un entorno a otro con muy poca dificultad. Así que estamos empezando a construir un tipo de unidad de aplicación que se puede manejar muy fácilmente, arrancando y parando con un simple comando de Docker. Esta sencillez en la gestión de contenedores nos está llevando a construir cada vez más aplicaciones utilizando Docker, llevando a los equipos de desarrollo a diseñar un nuevo tipo de arquitectura: los microservicios. 

Los microservicios nos permiten diseñar aplicaciones más pequeñas, centradas en un área funcional muy concreta del sistema en su conjunto. Dada la naturaleza ligera de los contenedores, el objetivo de los microservicios es conseguir que varios contenedores trabajen codo con codo, de forma que absorban la mayor parte posible de la carga generada por el uso del sistema de información.

Por tanto, gestionar varios contenedores se está convirtiendo en un problema mucho mayor que en el pasado. ¿Se pueden ejecutar varios contenedores diferentes uno al lado del otro? ¿Cómo se puede gestionar la creación/eliminación automática de contenedores en función de la carga? Para abordar estas cuestiones, Google ha transformado en código abierto una herramienta que permitía a la empresa gestionar los contenedores internos en los que se ejecutaban sus aplicaciones: Kubernetes.

Kubernetes es una plataforma de orquestación de contenedores de código abierto que automatiza el despliegue y la gestión de aplicaciones multicontenedor escalables. Kubernetes funciona en tándem con Docker: su aplicación se ejecuta en una imagen Docker y esta imagen es gestionada por Kubernetes para garantizar que la imagen, replicada X veces en función del uso, funciona correctamente.

Sin embargo, el orquestador es compatible con cualquier tecnología de contenedores que cumpla el estándar Open Container Initiative. Docker también ha desarrollado su propio orquestador: Swarm. Sin embargo, Kubernetes se ha hecho más popular y parece haber sido adoptado más ampliamente por la comunidad. 

La arquitectura de Kubernetes se representa en el siguiente diagrama:

Arquitectura Kubernetes

Un clúster...

¿Cómo diseña su arquitectura de microservicios?

La arquitectura de microservicios es un tipo emergente de arquitectura de software que intenta resolver los problemas asociados a las llamadas aplicaciones monolíticas: desarrollo tedioso, nula flexibilidad, dificultad de despliegue, escalabilidad nula, etc. El principio de los microservicios es sencillo: la aplicación se descompone en varias aplicaciones más pequeñas y autónomas que giran en torno a un Business Domain. El objetivo de los microservicios es volver a centrarse en el negocio y en los problemas funcionales que la aplicación intenta resolver.

Diferencias entre aplicaciones monolíticas y microservicios

Los microservicios tienen la ventaja de ser más pequeños y, por tanto, más flexibles en términos de desarrollo, despliegue y mantenimiento. Cada microservicio debe responder a un aspecto del negocio, lo que llamamos un contexto delimitado (Boundary Context en inglés). En este caso, el reto de la arquitectura de microservicios consiste en garantizar que la delimitación del dominio funcional sea lo suficientemente pertinente y coherente como para garantizar microservicios lo más pequeños posible, pero suficientemente autónomos. 

El tamaño de los microservicios es el problema de esta arquitectura. Parece obvio que cuanto más pequeños sean los microservicios, más fáciles serán de gestionar. Sin embargo, pronto se hace evidente que algunos microservicios se comunican mucho entre sí ya que, a menudo, si no sistemáticamente, necesitan la información de los demás para funcionar. Si se observa este comportamiento, significa que dos microservicios deberían formar una sola entidad.

En esto consisten...

Utilizar Remote Procedure Calls

En el contexto de una arquitectura de microservicios, el uso de las API REST para las llamadas entre servicios presenta varias desventajas notables que es importante tener en cuenta, a la hora de diseñar la arquitectura.

En primer lugar, hay que tener en cuenta que el uso de la tecnología REST para las API requiere que los llamantes pasen por toda la capa de red, así como una costosa deserialización y serialización, lo que puede dar lugar a una alta latencia, por no hablar del código, que también puede degradar los tiempos de respuesta (con motivo o sin él). En el contexto de las API expuestas al mundo exterior o para clientes técnicos, las API REST que devuelven JSON son relevantes, ya que el formato es legible y fácilmente comprensible por un cliente. Sin embargo, en el contexto de la comunicación entre servicios, esta comprensión no es necesaria.

Por supuesto, el contenido de la petición y la respuesta se transporta en formato de texto (JSON u otro formato) y, por tanto, sobrecargará el ancho de banda mientras que, en la comunicación entre servicios, esta sobrecarga no es necesaria: simplemente queremos intercambiar datos entre dos servicios técnicos sin preocuparnos del formato, siempre que el intercambio sea eficiente.

Aquí es donde entran en juego las Remote Procedure Calls. Las Remote Procedure Calls (RPC) son un tipo de protocolo de comunicación que permite a una aplicación llamar a funciones o procedimientos ejecutados en un servicio remoto, como si se estuvieran ejecutando localmente. Las RPC suelen utilizar un sistema cliente-servidor, en el que la aplicación que desea ejecutar una función remota (el cliente) envía una petición al servidor, que ejecuta la función y devuelve el resultado al cliente.

Las RPC se basan en un modelo de programación similar al de las llamadas a funciones estándar, pero permiten ejecutar funciones en un ordenador remoto, abierto a una red. Esto permite a los desarrolladores crear aplicaciones distribuidas que se comunican entre...