Los microservicios son un enfoque arquitectónico para crear aplicaciones en la nube. Cada aplicación se construye como un conjunto de servicios y cada servicio se ejecuta en sus propios procesos y se comunica a través de API. 

La evolución que llevó a la arquitectura de microservicios en la nube comenzó hace más de 20 años. El concepto de estructura de servicios es más antiguo que los contenedores y data de antes de la era de las aplicaciones web modernas. Una arquitectura de microservicios es una forma de desarrollar aplicaciones que se ha convertido en una práctica recomendada con el tiempo.

¿Cómo funcionan los microservicios?

Para comprender las ventajas de las arquitecturas de microservicios en la actualidad, es fundamental comprender dónde comenzó todo.

Aplicaciones monolíticas

Inicialmente, cada aplicación, que reside en un solo servidor, constaba de tres capas:

•         Presentación
•         Aplicación / lógica empresarial
•         Base de datos

Estas capas se construyeron en una sola pila entrelazada ubicada en un único servidor monolítico en un centro de datos. Este patrón era común en todas las arquitecturas verticales y tecnológicas de la industria. En términos generales, una aplicación es una colección de módulos de código que cumplen una función particular, por ejemplo, una base de datos, varios tipos de lógica empresarial, código de representación de gráficos o registro.

En esta arquitectura monolítica, los usuarios interactúan con la capa de presentación, que hablaba con la capa de lógica empresarial y la capa de base de datos; la información luego viajaba de regreso a la pila hasta el usuario final. Aunque esta era una forma eficiente de organizar una aplicación, creaba muchos puntos únicos de falla, que podían resultar en interrupciones prolongadas si había una falla de hardware o un error de código. 

Desafortunadamente, la “autocuración” no existía en esta estructura. Si una parte del sistema se daña, debe ser reparada por intervención humana en forma de reparación de hardware o software. Además, escalar en cualquiera de estas capas significaba comprar un servidor completamente nuevo. 

Tenías que comprar una aplicación monolítica que se ejecutará en un solo servidor y segmentar una parte de los usuarios al nuevo sistema. Esta segmentación dio como resultado silos de datos de usuario que tuvieron que conciliarse mediante informes de lotes nocturnos. Afortunadamente, la necesidad del cliente se redujo a medida que las páginas web y las aplicaciones móviles se hicieron más populares, por lo que comenzaron a tomar forma nuevos métodos de desarrollo de aplicaciones.

Arquitectura orientada a servicios (SOA)

A mediados de la década de 2000, las arquitecturas comenzaron a cambiar de modo que existían varias capas fuera de un solo servidor y como silos de servicio independientes. Las aplicaciones se diseñaron para integrar estos servicios mediante el uso de un bus de servicio empresarial para la comunicación. Este enfoque permite a los administradores escalar estos servicios de forma independiente agregando servidores a través de capacidades de proxy. 

El enfoque también permitió ciclos de desarrollo más cortos al permitir a los ingenieros enfocarse en solo una parte de la estructura de servicio de la aplicación. 

Las SOA también coincidieron con el auge de la máquina virtual (VM), que hizo que los recursos del servidor físico fueran más eficientes. Los servicios se podrían implementar mucho más rápidamente en máquinas virtuales más pequeñas que las aplicaciones monolíticas anteriores en servidores bare-metal. 

Microservicios

Hoy en día, los microservicios en la nube desglosan aún más la estrategia SOA como una colección de servicios funcionales granulares. Las colecciones de microservicios se combinan en grandes macroservicios, lo que brinda una capacidad aún mayor para actualizar rápidamente el código de una sola función en un servicio general o una aplicación de usuario final más grande. 

Un microservicio intenta abordar una única preocupación, como una función de búsqueda de datos, una función de registro o una función de servicio web. Este enfoque aumenta la flexibilidad y crea una oportunidad para que los microservicios se recuperen automáticamente. 

Las arquitecturas de microservicios se han utilizado junto con los contenedores Docker, una construcción de empaquetado e implementación. Las imágenes de VM se han utilizado como mecanismo de implementación preferido durante muchos años. Pero los contenedores son incluso más eficientes que las máquinas virtuales, lo que permite implementar el código (y las bibliotecas de código necesarias) en cualquier sistema Linux (o cualquier sistema operativo que admita contenedores Docker). 

Los contenedores son el vector de implementación perfecto para los microservicios. Se pueden iniciar en segundos, por lo que se pueden volver a implementar rápidamente después de una falla o migración, y se pueden escalar rápidamente para satisfacer las demandas. Debido a que los contenedores son nativos de Linux, el hardware básico se puede aplicar a vastas granjas de microservicios en cualquier centro de datos, nube privada o multi nube híbrida.

Beneficios de usar microservicios en la nube

Los microservicios están descentralizados y se ejecutan en diferentes servidores, pero aún funcionan juntos para una aplicación. Idealmente, cada microservicio tiene una sola función, lo que permite un enrutamiento simple entre servicios con comunicación API. Éstos son algunos de los otros beneficios:

-Puede actualizar el código en cualquier momento mediante la integración continua, puede liberar pequeñas cantidades de código en lugar de paquetes gigantes.

-A medida que ocurren cambios en el back-end, el usuario no ve que sucedan.

-Los equipos de desarrollo pueden trabajar en paralelo. Los equipos pequeños pueden moverse más rápido que los equipos grandes.

-Los componentes del servicio de aplicaciones están aislados. Si uno falla, el resto continúa funcionando, lo que permite una graciosa degradación.

-La única vez que se requiere que un humano reaccione a una alerta es cuando hay un error del sistema.

-Si una función de back-end (como una llamada a la base de datos) falla, devuelve algo útil. 

Los microservicios están diseñados para manejar errores de manera lógica.

Debido a que los componentes de las arquitecturas de microservicios son granulares, es más fácil mejorar y mantener el código.

Contenedores

Los contenedores son inmutables: una vez que se implementan, no pueden (o no deben) modificarse. Si hay una nueva versión de código disponible, el contenedor se destruye y en su lugar se implementa un nuevo contenedor con el último código. 

Los contenedores se pueden lanzar en segundos o milisegundos, por lo que los componentes de servicio adicionales se pueden implementar inmediatamente cuando y donde se necesiten. Debido a su escasa huella de recursos en relación con las máquinas virtuales o bare metal, los contenedores son el mejor mecanismo de implementación para los microservicios.  

Orquestación

Las herramientas de orquestación de contenedores han existido casi tanto tiempo como los propios contenedores. Miles de microservicios trabajan juntos para formar servicios y aplicaciones, y administrarlos manualmente sería casi imposible incluso con un ejército de administradores. 

Dado que la mayoría de los presupuestos de personal de TI se mantienen planos, el aumento de la automatización y la adopción de prácticas de DevOps, la necesidad de buenas herramientas de orquestación es primordial.

La primera versión de Kubernetes (K8s) se lanzó en 2015, poco después del auge de los contenedores Docker, y rápidamente se ha convertido en la herramienta de orquestación dominante en el panorama de contenedores. Kubernetes permite a los desarrolladores registrar una aplicación basada en contenedor o un microservicio en una biblioteca común y proporcionar un archivo de manifiesto al controlador de Kubernetes. 

Luego, Kubernetes implementa la aplicación en sus nodos trabajadores de acuerdo con las especificaciones del archivo de manifiesto, utilizando la imagen del contenedor en el registro común. El “estado deseado”, un concepto clave en Kubernetes, permite que la funcionalidad de recuperación y actualización automática sea parte integral de la solución.