Microservicios: Su próxima arquitectura de software

0
34

Casi todos los sistemas informáticos realizan múltiples tareas utilizando recursos compartidos, y una de las cuestiones de la programación informática es cuán estrechamente los bits de código que realizan esas tareas, deben estar vinculados entre sí. Una respuesta cada vez más popular es el concepto de microservicio, un pequeño y discreto pedazo de funcionalidad que interactúa con otros microservicios para crear un sistema más grande.

Aunque la idea básica de tener componentes tan discretos no es nueva, la forma en que se implementan los microservicios los convierte en una base natural para las aplicaciones modernas basadas en la nube. Los microservicios también encajan con la filosofía de devops, que fomenta el desarrollo rápido y continuo de nuevas funcionalidades.

¿Qué son los microservicios?
El «micro» en microservicios implica que se trata de pequeñas aplicaciones. Eso es a veces cierto, pero una mejor manera de pensar en ellos es que deben ser tan grandes como sea necesario para hacer una cosa específica o resolver un problema en particular. Ese problema debe ser conceptual, no técnico. Según Microsoft, «los microservicios deben diseñarse en torno a las capacidades empresariales, no a capas horizontales como el acceso a los datos o la mensajería». Se comunican con otros microservicios y usuarios externos a través de APIs relativamente estables para crear una aplicación más grande.

De este modo, la funcionalidad interna de un microservicio individual se puede ajustar o mejorar radicalmente sin afectar al resto del sistema. Esto, a su vez, se relaciona con la forma en que los departamentos devops tratan de operar: Si las funciones específicas de una aplicación más grande se segmentan en partes de código discretas e independientes, es más fácil vivir el mantra del desarrollo de CI/CD (integración continua y entrega continua). Además, unas API bien definidas hacen que los microservicios sean fáciles de probar automáticamente.

Arquitectura de microservicios vs. arquitectura monolítica
A menudo se habla de microservicios en términos de una «arquitectura de microservicios». Esta frase abarca no solo los microservicios en sí mismos, sino también los componentes para la gestión y descubrimiento de servicios, así como una puerta de enlace de la API que maneja la comunicación entre los microservicios y el mundo exterior.

Una «aplicación monolítica» es lo contrario de lo que son los microservicios. Es un ‘retronym‘ de una aplicación donde todo el código está en un gran archivo binario ejecutable. Como explica TechTarget, una aplicación monolítica es más difícil de escalar y más difícil de mejorar. Pero debido a que está construida como una sola aplicación cohesiva, no requiere tanta administración como una arquitectura de microservicios.

Conceptos delimitados: Cómo definir un microservicio
Volvamos por un momento a nuestro anterior mandamiento de que los microservicios deben hacer una cosa específica. Eso es fácil de decir, pero en la práctica, la funcionalidad está a menudo entrelazada, y dibujar divisiones es más difícil de lo que parece. El análisis de dominio y el diseño basado en el dominio son los enfoques teóricos que le ayudarán a separar su tarea de gran imagen en problemas individuales que un microservicio puede resolver. En este proceso, esbozado en una iluminadora serie de entradas de blog de Microsoft, se crea un modelo abstracto del dominio de su negocio y, en el proceso, se descubren los contextos delimitados, que agrupan funcionalidades que interactúan con el mundo de una manera específica.

Por ejemplo, puede tener un contexto delimitado para el envío y otro para las cuentas. Un objeto físico del mundo real tendría un precio y un lugar a donde ir, por supuesto, pero los contextos delimitados representan maneras específicas en las que su aplicación piensa e interactúa con esos objetos. Cada microservicio debe existir enteramente dentro de un único contexto limitado, aunque algunos contextos limitados pueden abarcar más de un microservicio.

Microservicios vs. arquitectura orientada a servicios vs. servicios Web
En este punto, si es un profesional de TI que ha estado en la industria por un tiempo, puede pensar que mucho de esto le suena familiar. La idea de que los pequeños programas individuales trabajen juntos podría recordarle tanto a SOA (arquitectura orientada a servicios) como a los servicios Web, dos palabras de moda de los embriagadores días Web 2.0 de la década del 2000. Aunque en cierto sentido no hay nada nuevo bajo el sol, hay distinciones importantes entre estos conceptos y los microservicios. Datamation tiene un buen desglose de las diferencias, pero aquí hay una versión corta:

  • En una arquitectura orientada a servicios, los componentes individuales están relativamente bien acoplados, a menudo compartiendo activos como el almacenamiento, y se comunican a través de un software especializado llamado bus de almacenamiento empresarial. Los microservicios son más independientes, comparten menos recursos y se comunican a través de protocolos más ligeros. Cabe destacar que los microservicios surgieron del entorno SOA, y a veces son considerados como una especie de SOA, o sucesores del concepto.
  • Un servicio Web es un conjunto de funcionalidades a las que otras aplicaciones pueden acceder a través de la Web; probablemente el ejemplo más frecuente es Google Maps, que el sitio web de un restaurante podría incrustar para proporcionar indicaciones a los clientes. Esta es una conexión mucho más floja de lo que se vería en una arquitectura de microservicios.

Comunicación de microservicios
Un eslogan que a menudo se oye hablar de las arquitecturas de microservicios, es que deberían incluir «puntos finales inteligentes y pipes tontos«. En otras palabras, los microservicios deben tratar de utilizar métodos de comunicación básicos y bien establecidos en lugar de una integración compleja y estrecha. Como se ha señalado, esto es otra cosa que distingue a los microservicios de SOA.

En general, la comunicación entre microservicios debe ser asíncrona, en el sentido de que los hilos de código no se bloquean a la espera de respuestas. (Todavía está bien usar protocolos de comunicaciones síncronos como HTTP, aunque los protocolos asíncronos como AMQP (Advanced Message Queuing Protocol) también son comunes en las arquitecturas de microservicios). Este tipo de acoplamiento suelto hace que la arquitectura de los microservicios sea más flexible ante la falla de componentes individuales o partes de la red, lo que constituye una ventaja clave.

Microservicios, Java, y Spring Boot y Spring Cloud
Algunos de los primeros trabajos en microservicios surgieron en la comunidad de Java; Martin Fowler fue uno de los primeros defensores. En la conferencia Java 2012 realizada en Polonia se presentó una de las primeras presentaciones más importantes sobre el tema, titulada «Micro servicios – Java, el camino de Unix«. Recomendaba aplicar los principios que guiaron el desarrollo de las primeras aplicaciones de Unix en los años 70 («Escribir programas que hacen una cosa y la hacen bien»). Escribir programas para trabajar juntos») para el desarrollo de Java.

Como resultado de esta historia, hay muchos frameworks Java que le permiten construir microservicios. Uno de los más populares es Spring Boot, que está diseñado específicamente para microservicios; Boot se amplía con Spring Cloud, que, como su nombre indica, le permite desplegar esos servicios también en la nube. Pivotal Software, el desarrollador de Spring, tiene un buen tutorial para iniciarse en el desarrollo de microservicios utilizando estos frameworks.

Microservicios y contenedores: Docker, Kubernetes, y más allá
La tecnología subyacente que ha ido más lejos en la incorporación de los microservicios a la corriente dominante son los contenedores. Un contenedor es similar a una instancia de VM, pero en lugar de incluir todo un sistema operativo autónomo, un contenedor es solo un espacio de usuario aislado que hace uso del núcleo del sistema operativo del host, pero que mantiene el código ejecutándose dentro de él. Los contenedores son mucho más pequeños que las instancias de VM y son fáciles de implementar rápidamente, ya sea localmente o en la nube, y se pueden girar hacia arriba o hacia abajo para adaptarse a la demanda y a los recursos disponibles.

El atractivo de los contenedores para microservicios debe ser obvio: cada microservicio individual puede funcionar en su propio contenedor, lo que reduce significativamente los gastos generales de gestión de los servicios. La mayoría de las implementaciones de contenedores tienen herramientas de orquestación complementarias que automatizan la implementación, la gestión, el escalado, la creación de redes y la disponibilidad de aplicaciones basadas en contenedores. Es la combinación de microservicios pequeños y fáciles de construir y contenedores fáciles de desplegar lo que hace posible la filosofía de devops. Hay varias implementaciones del concepto de contenedor, pero la más popular es Docker, que generalmente se combina con Kubernetes como plataforma de orquestación.

Spring, aunque popular, está ligado a la plataforma Java. Los sistemas basados en contenedores, por otro lado, son políglota: Cualquier lenguaje de programación que soporte el sistema operativo puede ejecutarse en un contenedor, lo que proporciona más flexibilidad a los programadores. De hecho, una gran ventaja de los microservicios es que cada servicio individual puede ser escrito en cualquier idioma que tenga más sentido, o con el que los desarrolladores se sientan más cómodos. De hecho, un servicio podría reconstruirse completamente en un nuevo idioma sin afectar al sistema en su conjunto, siempre y cuando sus APIs permanezcan estables. DZone tiene un artículo que discute los pros y contras de Spring Cloud vs. Kubernetes para microservicios.

Patrones de diseño de microservicios
No importa el lenguaje que utilice para desarrollar microservicios, se enfrentará a problemas que otros desarrolladores han encontrado antes. Los patrones de diseño son soluciones abstractas y formalizadas a problemas recurrentes de la informática, y algunos de ellos son específicos para microservicios. Devopedia tiene una gran lista, que incluye:

  • Service Registry: Para conectar a los clientes con las instancias disponibles de microservicios.
  • Circuit Breaker: Para evitar que los servicios fallidos sean llamados repetidamente.
  • Fallback: Para proporcionar una alternativa a un servicio fallido
  • Sidecar: Para proporcionar un servicio auxiliar al contenedor principal, como por ejemplo para registrar, sincronizar servicios o monitorear
  • Adapter: Para estandarizar o normalizar la interfaz entre el contenedor principal y el mundo exterior.
  • Ambassador: Para conectar el contenedor principal al mundo exterior.

Microservicios y la nube: AWS y Azure
Como se ha indicado anteriormente, una de las ventajas de utilizar contenedores es que pueden desplegarse fácilmente en la nube, donde se dispone de recursos informáticos flexibles para que pueda maximizar la eficiencia de su aplicación.Como puede imaginar, los principales proveedores públicos de cloud computing están deseosos de que usted utilice sus plataformas para ejecutar sus aplicaciones basadas en microservicios. Para obtener más información, consulte los recursos de AmazonMicrosoft y Google.

Josh Fruhlinger, InfoWorld.com