microservicio

Los microservicios dividen el código monolítico en fragmentos fáciles de mantener y son clave para la filosofía de DevOps.

Casi todos los sistemas informáticos realizan múltiples tareas utilizando recursos compartidos, y una de las preguntas de la programación informática es qué tan cerca deben estar vinculados los bits de código que realizan esas tareas. Una respuesta cada vez más popular es el concepto de un microservicio : una pequeña y discreta porción 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 ambas 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 microservicios implica que se trata de pequeñas aplicaciones. Eso a veces es cierto, pero una mejor manera de pensar en ellos es que deberían 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. Como dice Microsoft , “los microservicios deben diseñarse en torno a las capacidades empresariales, 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 puede modificarse o actualizarse radicalmente sin afectar el 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 e independientes, 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 versus 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 componentes para la gestión y el descubrimiento de servicios , así como una puerta de enlace API que maneja la comunicación entre microservicios y el mundo exterior.

Una “aplicación monolítica” es lo contrario de lo que son los microservicios. Es un retrónimo para 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 aplicación cohesiva única, no requiere tanta administración como una arquitectura de microservicios.

Conceptos delimitados: 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 se entrelaza, y dibujar divisiones es más difícil de lo que parece. El análisis de dominios y el diseño basado en dominios son los enfoques teóricos que lo ayudarán a separar su tarea general en problemas individuales que un microservicio puede resolver. En este proceso, descrito en una serie de publicaciones de blog de Microsoft , usted crea un modelo abstracto de su dominio comercial y, en el proceso, descubre los contextos limitados , que agrupan la funcionalidad que interactúa con el mundo de una manera específica.

Por ejemplo, puede tener un contexto limitado para el envío y otro para las 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 limitados representan formas específicas en las que su aplicación piensa e interactúa con esos objetos. Cada microservicio debe existir completamente dentro de un contexto limitado único, aunque algunos contextos limitados pueden abarcar más de un microservicio.

Microservicios vs. arquitectura orientada a servicios vs. servicios web

En este punto, si eres un profesional de TI que ha estado en la industria por un tiempo, podrías pensar que mucho de esto te suena familiar. La idea de que pequeños programas individuales trabajen juntos podría recordarle tanto a SOA (arquitectura orientada a servicios) como a 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 realmente nada nuevo bajo el sol, existen importantes distinciones entre estos conceptos y 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 unidos, 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 livianos. Vale la pena señalar que los microservicios surgieron del entorno SOA, y a veces se los considera una especie de SOA o sucesores 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 frecuente es Google Maps, que el sitio web de un restaurante podría incorporar para proporcionar instrucciones 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á que se usa sobre las arquitecturas de microservicios es que deben presentar ” puntos finales inteligentes y tuberías tontas “. En otras palabras, los microservicios deberían tener como objetivo utilizar métodos de comunicación básicos y bien establecidos en lugar de una integración compleja y estricta. Como se señaló, esta 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 están bloqueados esperando respuestas. (Todavía está bien usar protocolos de comunicaciones síncronas 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 flexible hace que una arquitectura de microservicios sea más flexible ante la falla de componentes individuales o partes de la red, lo cual 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 defensores. Una conferencia Java de 2012 en Polonia presentó una de las primeras presentaciones más importantes sobre el tema, titulada ” Micro servicios: Java, la forma de Unix “. Recomendó aplicar los principios que guiaron el desarrollo de las primeras aplicaciones de Unix en la década de 1970 (“Escribir programas que hacen una cosa y lo 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; Spring Cloud amplía el arranque y, como su nombre lo 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 allá.

La tecnología subyacente que ha ido más lejos para llevar 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 independiente completo, un contenedor es solo un espacio de usuario aislado que utiliza el kernel del sistema operativo host, pero de lo contrario 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 igualar 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 los servicios de administración. La mayoría de las implementaciones de contenedores tienen herramientas de orquestación complementarias que automatizan la implementación, la administració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 implementar lo que hace posible la filosofía devops . Hay varias implementaciones del concepto contenedor, pero con mucho el más popular es Docker , que generalmente se combina con Kubernetes como plataforma de orquestación.

Spring, aunque popular, está vinculada a la plataforma Java. Los sistemas basados ​​en contenedores, por otro lado, son políglotas: cualquier lenguaje de programación compatible con 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 el sistema en su conjunto, siempre que sus API permanezcan estables. DZone tiene un artículo que discute los pros y los contras de Spring Cloud vs. Kubernetes para microservicios. 

Patrones de diseño de microservicios

No importa qué lenguaje use para desarrollar microservicios, enfrentará problemas que otros desarrolladores han encontrado antes. Los patrones de diseño son soluciones formales, abstractas a problemas recurrentes en ciencias de la computación, y varios de ellos son específicamente para microservicios. Devopedia tiene una gran lista , que incluye:

  • Registro de servicio: para conectar clientes a instancias disponibles de microservicios
  • Disyuntor: para evitar que los servicios fallidos se llamen repetidamente
  • Respaldo: por proporcionar una alternativa a un servicio fallido
  • Sidecar: para proporcionar un servicio auxiliar al contenedor principal, como para iniciar sesión, sincronizar servicios o monitorear
  • 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 la conexión de servidores locales a conexiones externas

Microservicios y la nube : AWS y Azure

Como se señaló anteriormente, una de las ventajas de usar contenedores es que pueden implementarse fácilmente en la nube, donde hay recursos de computación flexibles disponibles 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 .

Fuente: https://www.infoworld.com/article/3445043/what-are-microservices-your-next-software-architecture.html

Sobre el Autor

0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments