Arquitectura de microservicios

Una arquitectura de microservicios divide una aplicación en una serie de servicios implementables de forma independiente que se comunican a través de API. Este enfoque permite implementar y escalar cada servicio individual de forma independiente, así como la entrega rápida y frecuente de aplicaciones grandes y complejas. A diferencia de una aplicación monolítica, una arquitectura de microservicios permite a los equipos implementar nuevas funciones y hacer cambios más rápido, sin tener que volver a escribir una gran parte del código existente.

Pongamos como ejemplo un hipotético proyecto de software de comercio electrónico. El siguiente diagrama es de un sitio de comercio electrónico con una aplicación web y una aplicación móvil que interactúan con varios microservicios, cada uno de los cuales proporciona funciones específicas para un dominio.

Las aplicaciones web modernas se ejecutan en navegadores y, a menudo, se sirven desde una red de distribución de contenido (CDN). Las CDN proporcionan la ventaja de poder distribuir aplicaciones web a servidores de todo el mundo, para que los navegadores web las puedan descargar rápidamente. También se utilizan para ofrecer recursos multimedia, como imágenes, audio y vídeo. Por ejemplo, en este sistema las imágenes y los vídeos de los productos a la venta se sirven desde la CDN.

Las aplicaciones interactúan con los microservicios a través de las API de REST que publica cada uno de los microservicios. Una puerta de enlace de API permite que las aplicaciones se basen en las API proporcionadas por los microservicios y permite que se intercambien unos microservicios por otros con la misma API.

Cada microservicio se compone de un servicio y una base de datos. Los servicios gestionan la API de REST, implementan la lógica empresarial y almacenan datos en una base de datos. Los recursos de los distintos microservicios, como bases de datos y colas, se aíslan siguiendo el contrato de 12 Factor App.

Muchas organizaciones empiezan con una arquitectura monolítica. Luego, hay que dividir una base de código en varios servicios, implementar los patrones correctos para fallar de forma limpia y recuperarte de las incidencias en la red, lidiar con la coherencia de los datos, supervisar la carga de servicio, etc. Y esto teniendo en cuenta solo la parte técnica. También hay que reorganizar los equipos y, muy probablemente, adoptar una cultura de DevOps.

Luego viene la parte difícil: descomponer el monolito en microservicios. La refactorización de un esquema de base de datos monolítico puede ser una operación delicada. Es importante determinar con claridad qué conjuntos de datos necesita cada servicio y las superposiciones. La entrega continua ayuda a reducir los riesgos de fallos de publicación, así como a conseguir que el equipo se centre en crear y ejecutar la aplicación, en lugar de quedarse atascado en implementarla.

Una arquitectura monolítica es un modelo tradicional de un programa de software que se compila como una unidad unificada y que es autónoma e independiente de otras aplicaciones. Una arquitectura de microservicios es el concepto opuesto al de la arquitectura monolítica, ya que es un método que se basa en una serie de servicios que se pueden implementar de forma independiente. La arquitectura monolítica puede resultar práctica al principio de un proyecto para aliviar la sobrecarga cognitiva de la gestión de código, así como la implementación. Pero una vez que una aplicación monolítica se vuelve grande y compleja, resulta difícil escalarla, la implementación continua pasa a ser un desafío y las actualizaciones pueden resultar complicadas.

Si bien una aplicación monolítica se crea como una sola unidad indivisible, los microservicios dividen esa unidad en una colección de unidades independientes que contribuyen a un todo más amplio. Una aplicación se construye como una serie de servicios que se pueden implementar de forma independiente, están descentralizados y se desarrollan de forma autónoma.

Los microservicios entran en la categoría de sistema distribuido. Un sistema distribuido es un conjunto de programas informáticos que utilizan recursos computacionales en varios nodos de cálculo distintos para lograr un objetivo compartido común. Estos sistemas consiguen mayor fiabilidad, rendimiento y facilidad de escalabilidad.

Los nodos de un sistema distribuido ofrecen redundancia, de modo que, si un nodo falla, hay otros que pueden sustituirlos y reparar el error. Cada nodo se puede escalar de forma horizontal y vertical, lo que mejora el rendimiento. Si un sistema se somete a una carga extensiva, pueden añadirse nodos adicionales para ayudar a absorber dicha carga.

Docker es una plataforma comercial de contenedorización y un tiempo de ejecución de contenedores que ayuda a los desarrolladores a crear, implementar y ejecutar contenedores. Aunque Docker permite empaquetar y distribuir aplicaciones en contenedores de forma eficaz, es complicado ejecutar y gestionar contenedores a escala solo con esta herramienta.

Kubernetes es una popular plataforma de código abierto que orquesta sistemas de tiempo de ejecución de contenedores en un clúster de recursos en red. Se puede usar con o sin Docker. Docker es un tiempo de ejecución de contenedores, mientras que Kubernetes es una plataforma para ejecutar y gestionar contenedores a partir de muchos tiempos de ejecución de contenedores.

Con el proceso de gestión de configuración de software se administran, organizan, supervisan y controlan los cambios en los metadatos de configuración de un sistema de software. Suele utilizarse junto con la infraestructura de CI/CD y el control de versiones.

La gestión de la configuración ayuda a los equipos de ingeniería a crear sistemas sólidos y estables mediante el uso de herramientas que gestionan y supervisan automáticamente las actualizaciones de los datos de configuración. Mejora la gestión de la expansión de software en una arquitectura de microservicios, al establecer una “fuente de información” con una ubicación central para la configuración.