¿Qué son los microservicios? Tu próxima arquitectura de software

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 qué tan estrechamente deben estar vinculados los bits de código que realizan esas tareas entre sí. Una respuesta cada vez más popular es el concepto de microservicio : una parte pequeña y discreta 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 dos aplicaciones modernas basadas en la nube. Los microservicios también encajan con la filosofía de devops, que fomenta la implementación rápida y continua de nuevas funciones.

¿Qué son los microservicios?

El "micro" en los microservicios implica que se trata de pequeñas aplicaciones. A veces eso es 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 debería ser conceptual, no técnico. Como dice Microsoft, "los microservicios deben diseñarse en torno a las capacidades comerciales, no a capas horizontales como el acceso a datos o la mensajería". Se comunican con otros microservicios y usuarios externos a través de API relativamente estables para crear una aplicación más grande.

Por lo tanto, la funcionalidad interna de un microservicio individual se puede modificar o actualizar radicalmente sin afectar al resto del sistema. Esto, a su vez, se relaciona con la forma en que las tiendas devops buscan operar: si las funciones específicas de una aplicación más grande se segmentan en piezas de código discretas que operan de forma independiente, es más fácil vivir el mantra devops de CI / CD (integración continua y entrega continua) . Además, las API bien definidas hacen que los microservicios sean fáciles de probar automáticamente.

Arquitectura de microservicios frente a arquitectura monolítica

A menudo escuchará hablar de microservicios en términos de una "arquitectura de microservicios ". Esta frase abarca no solo los microservicios en sí, sino también los componentes para la administración y el descubrimiento de servicios, así como una puerta de enlace API que maneja la comunicación entre los microservicios y el mundo exterior.

Una "aplicación monolítica" es lo opuesto a lo que son los microservicios. Es un retrónimo de una aplicación donde todo el código está en un archivo ejecutable binario grande. 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á construido como una sola aplicación cohesiva, no requiere tanta administración como una arquitectura de microservicios.

Conceptos limitados: cómo definir un microservicio

Retrocedamos por un momento a nuestro mandamiento anterior de que los microservicios deberían hacer una cosa específica. Eso es fácil de decir, pero en la práctica, la funcionalidad a menudo está entrelazada y dibujar divisiones es más difícil de lo que parece. El análisis de dominio y el diseño impulsado por el dominio son los enfoques teóricos que lo ayudarán a dividir su tarea general en problemas individuales que un microservicio puede resolver. En este proceso, descrito en una serie esclarecedora de publicaciones de blog de Microsoft, usted crea un modelo abstracto de su dominio empresarial y, en el proceso, descubre los contextos delimitados , que agrupan la funcionalidad que interactúa con el mundo de una manera específica.

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

Microservicios frente a arquitectura orientada a servicios frente a 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 pequeños programas individuales trabajen juntos puede recordarle tanto a SOA (arquitectura orientada a servicios) como a los servicios web , dos palabras de moda de los embriagadores días de la Web 2.0 de la década de 2000. Si bien en cierto sentido no hay nada nuevo bajo el sol, existen importantes distinciones 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 estrechamente acoplados, a menudo comparten 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. Vale la pena señalar que los microservicios surgieron del entorno SOA y, a veces, se consideran una especie de SOA o un sucesor del concepto.
  • Un servicio web es un conjunto de funcionalidades de acceso público al que otras aplicaciones pueden acceder a través de la web; probablemente el ejemplo más común es Google Maps, que el sitio web de un restaurante podría incorporar para proporcionar direcciones a los clientes. Esta es una conexión mucho más flexible de la que vería en una arquitectura de microservicios.

Comunicación de microservicios

Un eslogan que a menudo escuchará sobre las arquitecturas de microservicios es que deben incluir "puntos finales inteligentes y tuberías tontas". En otras palabras, los microservicios deben apuntar a utilizar métodos de comunicación básicos y bien establecidos en lugar de una integración compleja y estrecha. Como se señaló, esto es otra cosa que distingue a los microservicios de SOA.

En general, la comunicación entre microservicios debe ser asincrónica , en el sentido de que los subprocesos de código no se bloquean en espera de respuestas. (Todavía está bien usar protocolos de comunicaciones síncronos como HTTP, aunque los protocolos asincrónicos como AMQP (Protocolo de cola de mensajes avanzado) también son comunes en las arquitecturas de microservicios). Este tipo de acoplamiento flexible hace que una arquitectura de microservicios sea más flexible ante la falla. de componentes individuales o partes de la red, que es un beneficio clave.

Microservicios, Java y Spring Boot y Spring Cloud

Algunos de los primeros trabajos en microservicios surgieron en la comunidad Java; Martin Fowler fue uno de los primeros proponentes. Una conferencia de Java de 2012 en Polonia contó con una de las primeras presentaciones más importantes sobre el tema, titulada "Micro servicios: Java, la forma Unix". Recomendó aplicar los principios que guiaron el desarrollo de las primeras aplicaciones Unix en la década de 1970 ("Write programas que hacen una cosa y la hacen bien. Escribir programas para trabajar juntos ”) al desarrollo de Java.

Como resultado de esta historia, hay muchos marcos de Java que le permiten crear microservicios. Uno de los más populares es Spring Boot, que está diseñado específicamente para microservicios; El arranque es extendido por Spring Cloud, que como su nombre indica, también le permite implementar esos servicios en la nube. Pivotal Software, el desarrollador de Spring, tiene un buen tutorial sobre cómo comenzar con el desarrollo de microservicios utilizando estos marcos.

Microservicios y contenedores: Docker, Kubernetes y más

La tecnología subyacente que ha avanzado más en la incorporación de microservicios a la corriente principal son los contenedores .  Un contenedor es similar a una instancia de VM, pero en lugar de incluir un sistema operativo autónomo completo, un contenedor es solo un espacio de usuario aislado que hace uso del kernel del sistema operativo host, pero por lo demás mantiene el código ejecutándose dentro de él de manera autónoma. 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 los recursos disponibles.

El atractivo de los contenedores para microservicios debería ser obvio: cada microservicio individual puede ejecutarse en su propio contenedor, lo que reduce significativamente la sobrecarga de administración de servicios. La mayoría de las implementaciones de contenedores tienen herramientas de orquestación complementarias que automatizan la implementación, administración, escalado, redes y disponibilidad de aplicaciones basadas en contenedores. Es la combinación de microservicios pequeños y fáciles de construir y contenedores fáciles de implementar 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á vinculado a la plataforma Java. Los sistemas basados ​​en contenedores, por otro lado, son políglotas: cualquier lenguaje de programación que admita el sistema operativo puede ejecutarse en un contenedor, lo que brinda más flexibilidad a los programadores. De hecho, una gran ventaja de los microservicios es que cada servicio individual se puede escribir en el 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 por completo en un nuevo idioma sin afectar al sistema en su conjunto, siempre que sus API permanezcan estables. DZone tiene un artículo que analiza los pros y los contras de Spring Cloud frente a Kubernetes para microservicios. 

Patrones de diseño de microservicios

Independientemente del lenguaje que use para desarrollar microservicios, enfrentará problemas que otros desarrolladores han encontrado antes. Los patrones de diseño son soluciones abstractas y formalizadas para problemas recurrentes en la informática, y algunos de ellos son específicamente para microservicios. Devopedia tiene una gran lista, que incluye:

  • Registro de servicios: para conectar clientes a instancias disponibles de microservicios
  • Disyuntor: 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 registro, sincronización de servicios o monitoreo
  • Adaptador: para estandarizar o normalizar la interfaz entre el contenedor principal y el mundo externo
  • Embajador: para conectar el contenedor principal al mundo exterior, por ejemplo, para hacer proxy de conexiones de host local a conexiones externas

Microservicios y la nube : AWS y Azure

Como se señaló anteriormente, una de las ventajas de usar contenedores es que se pueden implementar fácilmente en la nube, donde se encuentran disponibles recursos informáticos flexibles para que pueda maximizar la eficiencia de su aplicación. Como puede imaginar, los principales proveedores de nube pública están ansiosos por que use sus plataformas para ejecutar sus aplicaciones basadas en microservicios. Para obtener más información, consulte los recursos de Amazon, Microsoft y Google.