Microservicios

menu icon

Microservicios

La arquitectura de microservicios es un enfoque en el que una única aplicación se compone de muchos servicios más pequeños, acoplados y implementables de forma independiente.

¿Qué son los microservicios?

Los microservicios (o la arquitectura de microservicios) son un enfoque arquitectónico nativo en la nube en el que una única aplicación se compone de muchos componentes o servicios más pequeños, acoplables e implementables de forma independiente. Estos servicios normalmente

  • poseen su propio recurso de tecnología, incluyendo base de datos y modelo de gestión de datos;
  • se comunican entre sí a través de una combinación de API REST, streaming de eventos y message brokers; y
  • están organizados por capacidad de negocio, con la línea que separa los servicios a menudo denominados como un contexto limitado.

Si bien gran parte de la discusión sobre los microservicios ha girado en torno a las definiciones y características arquitectónicas, su valor puede ser más comúnmente entendido a través de beneficios empresariales y organizacionales bastante simples:

  • El código se puede actualizar más fácilmente: se pueden añadir nuevas características o funcionalidades sin intervenir en toda la aplicación
  • Los equipos pueden utilizar diferentes recursos y diferentes lenguajes de programación para diferentes componentes.
  • Los componentes se pueden escalar independientemente uno del otro, reduciendo los residuos y los costos asociados con tener que escalar aplicaciones enteras porque una única característica podría estar enfrentando demasiada carga.

Los microservicios también se pueden entender por lo que no son. Las dos comparaciones que se dibujan con mayor frecuencia con la arquitectura de microservicios son la arquitectura monolítica y la arquitectura orientada a servicios (SOA).

La diferencia entre los microservicios y la arquitectura monolítica es que los microservicios componen una única aplicación de muchos servicios más pequeños y poco acoplados en contraposición al enfoque monolítico de una aplicación grande y bien acoplada.

Para más información sobre las diferencias entre los microservicios y la arquitectura monolítica, vea este video (6:37):

 

Las diferencias entre microservicios y SOA pueden ser un poco menos claras. Aunque se pueden trazar contrastes técnicos entre microservicios y SOA, especialmente en torno al rol del bus de servicio empresarial (ESB), es más fácil considerar la diferencia como estando relacionada al ámbito. SOA fue un esfuerzo de toda la empresa para estandarizar la forma en que todos los servicios web de una organización conversan y se integran entre sí, mientras que la arquitectura de microservicios es específica de la aplicación.

La publicación "SOA vs. Microservicios: ¿Cuál es la diferencia?" muestra más detalles.

Cómo los microservicios benefician a la organización

Es probable que los microservicios sean al menos tan populares entre los ejecutivos y los líderes del proyecto como con los desarrolladores. Esta es una de las características más inusuales de los microservicios porque el entusiasmo arquitectónico es típicamente reservado para los equipos de desarrollo de software. La razón de esto es que los microservicios reflejan mejor la forma en que muchos líderes empresariales quieren estructurar y ejecutar sus equipos y procesos de desarrollo.

Dicho de otro modo, los microservicios son un modelo arquitectónico que facilita un modelo operativo deseado. En una encuesta reciente de IBM a más de 1,200 desarrolladores y ejecutivos de TI, el 87 % de los usuarios de microservicios afirmó que el gasto y el esfuerzo necesarios para adoptar los microservicios valen la pena. Utilice la siguiente herramienta interactiva para revisar más puntos de vista sobre las ventajas de los microservicios y los retos que plantean:

(Fuente: 'Microservicios en la empresa en 2021: beneficios reales que justifican los retos').

Estos son sólo algunos de los beneficios empresariales de los microservicios.

Implementables de forma independiente

Tal vez la característica más importante de los microservicios es que debido a que los servicios son más pequeños e independientemente implementables, ya no es necesario un acto del Congreso con el fin de cambiar una línea de código o añadir una nueva característica a la aplicación.

Los microservicios prometen a las organizaciones un antídoto contra las frustraciones viscerales asociadas con pequeños cambios que toman grandes cantidades de tiempo. No necesita un doctorado en ciencias de la computación para ver o entender el valor de un enfoque que facilita más la velocidad y la agilidad.

Pero la velocidad no es el único valor de diseñar servicios de esta manera. Un modelo organizativo emergente común es reunir equipos multifuncionales en torno a un problema empresarial, servicio o producto. El modelo de microservicios encaja perfectamente con esta tendencia, ya que permite a una organización crear equipos pequeños y multifuncionales en torno a un servicio o una colección de servicios y hacer que funcionen de forma ágil.

El acoplamiento suelto de microservicios también crea un grado de aislamiento de fallas y una mejor resiliencia en las aplicaciones. Y el pequeño tamaño de los servicios, combinado con sus claros límites y patrones de comunicación, hace que sea más fácil para los nuevos miembros del equipo entender la base de código y contribuir con ella rápidamente, un claro beneficio en términos de la velocidad y la moral de los empleados.

Herramienta adecuada para el trabajo

En los patrones de arquitectura tradicionales de n niveles, una aplicación normalmente comparte un lote común, con una gran base de datos relacional que da soporte a toda la aplicación. Este enfoque tiene varios inconvenientes obvios. El más significativo es que cada componente de una aplicación debe compartir un recurso común, un modelo de datos y una base de datos, incluso si hay una herramienta clara y mejor para el trabajo para ciertos elementos. Esto perjudica a la arquitectura y es frustrante para los desarrolladores, que son conscientes en todo momento de que hay una forma mejor y más eficaz crear estos componentes.

Por el contrario, en un modelo de microservicios, los componentes se despliegan de forma independiente y se comunican a través de una combinación de REST, streaming de eventos y message brokers, por lo que es posible que el recurso de cada servicio individual esté optimizado para ese servicio. La tecnología cambia todo el tiempo, y es mucho más fácil y menos costoso que una aplicación formada por múltiples servicios más pequeños evolucione con la tecnología a medida que esta avance.

Escalado preciso

Con los microservicios, los servicios individuales se pueden implementar individualmente, y también se pueden escalar individualmente. El beneficio resultante es evidente: Hecho correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas porque permiten el escalado preciso de sólo los componentes que lo requieren, en lugar de toda la aplicación, como es el caso de aplicaciones monolíticas.

Hay desafíos, también

Los beneficios significativos de los microservicios vienen con desafíos significativos. Pasar de monolito a microservicios significa mucha más complejidad de gestión - muchos más servicios, creados por muchos más equipos, implementados en muchos más lugares. Los problemas en un servicio pueden causar, o ser causados por, problemas en otros servicios. Los datos de registro (utilizados para supervisión y resolución de problemas) son más voluminosos y pueden ser inconsistentes entre los servicios. Las nuevas versiones pueden causar problemas de compatibilidad con versiones anteriores. Las aplicaciones implican más conexiones de red, lo que significa más oportunidades para que ocurran problemas de latencia y conectividad. Un enfoque de DevOps (como se lee más abajo) puede abordar muchos de estos problemas, pero la adopción de DevOps tiene retos propios.

No obstante, estos retos no impiden que los no usuarios adopten el uso de microservicios o que los usuarios aumenten sus compromisos de microservicios. Nuevos datos de una encuesta de IBM revelan que el 56 % de los no usuarios actuales probablemente o muy probablemente adoptarán microservicios en los próximos dos años, y el 78 % de los usuarios actuales de microservicios probablemente aumentará el tiempo, dinero y esfuerzo que han invertido en microservicios (ver Figura 1).

Tres gráficos circulares que muestran 56, 78 y 59 por ciento.

Figura 1: Los microservicios están aquí para quedarse. Dentro de los próximos dos años, el 56 % de los no usuarios probablemente adoptarán microservicios, el 78 % de los usuarios aumentará su inversión en microservicios, y el 59 % de las aplicaciones se crearán con microservicios. (Fuente: 'Microservicios en la empresa en 2021: beneficios reales que justifican los retos').

Los microservicios permiten, y requieren, DevOps

La arquitectura de microservicios se describe a menudo como optimizada para DevOps e integración continua/entrega continua (CI/CD) y, en el contexto de servicios pequeños que se pueden desplegar con frecuencia, es fácil entender por qué.

Pero otra forma de ver la relación entre los microservicios y DevOps es que las arquitecturas de microservicios en realidad requieren DevOps para tener éxito. Mientras que las aplicaciones monolíticas tienen una serie de inconvenientes que se han discutido anteriormente en este artículo, tienen el beneficio de no ser un complejo sistema distribuido con múltiples partes móviles y recursos de tecnología independientes. Por el contrario, dado el aumento masivo de la complejidad, de las partes móviles y de las dependencias que vienen con los microservicios, sería poco prudente acercarse a los microservicios sin inversiones significativas en el despliegue, la supervisión y la automatización del ciclo de vida.

Andrea Crawford ofrece una inmersión más profunda en DevOps en el siguiente video:

Tecnologías y herramientas clave

Mientras que casi cualquier herramienta o lenguaje moderno puede ser utilizado en una arquitectura de microservicios, hay un puñado de herramientas básicas que se tornado esenciales y prácticamente definitivas para los microservicios:

Contenedores, Docker y Kubernetes

Uno de los elementos clave de un microservicio es que por lo general es bastante pequeño. (No hay una cantidad arbitraria de código que determine si algo es o no es un microservicio, pero "micro" está incluido por algo en el nombre).

Cuando Docker inició la era moderna de contenedores en 2013, también introdujo el modelo de computación que se asociaría más estrechamente con los microservicios. Debido a que los contenedores no tienen la sobrecarga de su propio sistema operativo, son más pequeños y más ligeros que las tradicionales máquinas virtuales y pueden girar hacia arriba y hacia abajo más rápidamente, lo que los convierte en la opción perfecta para los servicios más pequeños y ligeros que se encuentran dentro de las arquitecturas de microservicios.

Con la proliferación de servicios y contenedores, la orquestación y la gestión de grandes grupos de contenedores rápidamente se convirtieron en uno de los principales retos. Kubernetes, una plataforma de código abierto de orquestación de contenedor, ha surgido como una de las soluciones de orquestación más populares porque hace ese trabajo muy bien.

En el video "Explicación de Kubernetes", Sai Vennam da una visión integral de todos los aspectos de Kubernetes:

 

Gateways de API

Los microservicios a menudo se comunican a través de API, especialmente cuando se establece el estado por primera vez. Si bien es cierto que los clientes y los servicios pueden comunicarse entre sí directamente, los gateways de API suelen ser una capa intermedia útil, especialmente a medida que el número de servicios en una aplicación crece con el tiempo. Un gateway de API actúa como un proxy inverso para los clientes mediante solicitudes de direccionamiento, distribuyendo las solicitudes por varios servicios y proporcionando seguridad y autenticación adicionales.

Existen varias tecnologías que se pueden utilizar para implementar gateways de API, incluidas las plataformas de gestión de API, pero si la arquitectura de microservicios se está implementando con contenedores y Kubernetes, el gateway se implementa normalmente utilizando Ingress o, más recientemente, Istio.

Mensajería y streaming de eventos

Aunque la práctica recomendada sería el diseño de servicios sin estado, el estado existe y los servicios deben tenerlo en cuenta. Y aunque una llamada de API es a menudo una forma efectiva de establecer inicialmente el estado de un determinado servicio, no es una manera particularmente efectiva de mantenerse al día. Un enfoque que pregunta constantemente "¿hemos llegado?", para mantener los servicios actuales, simplemente no es práctico.

En su lugar, es necesario acoplar las llamadas de API que establecen el estado con la mensajería o el streaming de eventos para que los servicios puedan emitir cambios en el estado y otras partes interesadas puedan escuchar esos cambios y ajustarse a ellos. Es probable que este trabajo sea el más adecuado para un message broker de uso general, pero hay casos en los que una plataforma de streaming de eventos como, por ejemplo Apache Kafka, puede ser una buena solución. Asimismo, la combinación de microservicios con desarrolladores de arquitectura basada en eventos puede crear sistemas distribuidos, altamente escalables, tolerantes a errores y ampliables que pueden consumir y procesar grandes cantidades de eventos o información en tiempo real.

Sin servidor

Las arquitecturas sin servidor llevan algunos de los patrones de nube y microservicios principales a su conclusión lógica. En el caso de arquitecturas sin servidor, la unidad de ejecución no es sólo un pequeño servicio, sino una función, que a menudo puede ser sólo unas pocas líneas de código. La línea que separa una función sin servidor de un microservicio es borrosa, pero comúnmente se entiende que las funciones son incluso más pequeñas que un microservicio.

El aspecto en el cual arquitecturas sin servidor y las plataformas Función como servicio (FaaS) comparten afinidad con los microservicios es que ambos están interesados en crear unidades más pequeñas de implementación y escalado con precisión en relación a la demanda.

Servicios de microservicios y nube

Los microservicios no son necesariamente exclusivamente relevantes para la computación en la nube pero hay algunas razones importantes por las que suelen ir juntos, razones que van más allá del hecho de que los microservicios son un estilo arquitectónico popular para nuevas aplicaciones y la nube es un popular destino de alojamiento para nuevas aplicaciones.

Entre las ventajas principales de la arquitectura de microservicios, se encuentran la utilización y los beneficios de costos asociados a la implementación y la ampliación de componentes de forma individual. Aunque estos beneficios también están presentes en cierta medida en la infraestructura local, la combinación de componentes pequeños y escalables de manera independiente con una infraestructura de pago por uso según demanda es donde se encuentran la verdadera optimización de costos.

En segundo lugar, y quizás más importante, otra ventaja principal de los microservicios es que cada componente individual puede adoptar el recurso más adecuado para su trabajo específico. La proliferación de recursos puede llevar a una grave complejidad y sobrecarga cuando la gestiona usted mismo, pero consumir el recurso de soporte como servicios en la nube puede minimizar drásticamente los retos de la gestión. Dicho de otra manera, aunque no es imposible implementar su propia infraestructura de microservicios, no se recomienda, especialmente cuando se acaba de empezar.

Patrones comunes

Dentro de las arquitecturas de microservicios, hay muchos patrones comunes y útiles de diseño, comunicación e integración que ayudan a abordar algunos de los retos y oportunidades más comunes, incluyendo los siguientes:

  • Patrón de Backend-For-Frontend (BFF): este patrón inserta una capa entre la experiencia del usuario y los recursos que invoca dicha experiencia. Por ejemplo, una aplicación utilizada en un desktop tendrá diferentes tamaños de pantalla, visualización y límites de rendimiento que un dispositivo móvil. El patrón BFF permite a los desarrolladores crear y dar soporte a un tipo de programa de backend por interfaz de usuario utilizando las mejores opciones para esa interfaz, en lugar de intentar dar soporte a un programa de backend genérico que funcione con cualquier interfaz, pero que pueda afectar negativamente al rendimiento de frontend.
  • Patrones de entidad y agregados: una entidad es un objeto distinguido por su identidad. Por ejemplo, en un sitio de comercio electrónico, un objeto de producto puede distinguirse por nombre de producto, tipo y precio. Un agregado es un grupo de entidades relacionadas que deben tratarse como una unidad. Por lo tanto, para el sitio de comercio electrónico, una orden sería un grupo (agregado) de productos (entidades) solicitados por un comprador. Estos patrones se utilizan para clasificar datos de forma significativa.
  • Patrones de descubrimiento de servicios: estas aplicaciones y servicios de ayuda se encuentran entre sí. En una arquitectura de microservicios, las instancias de servicio cambian dinámicamente debido al escalado, las actualizaciones, la anomalía de servicio e incluso el término del servicio. Estos patrones proporcionan mecanismos de descubrimiento para hacer frente a esta transición. Equilibrio de carga puede utilizar patrones de descubrimiento de servicios utilizando comprobaciones de estado y anomalías de servicio como desencadenantes para reequilibrar el tráfico.
  • Patrones de microservicios de adaptador: piense en los patrones de adaptador como si fueran los adaptadores de enchufes que utiliza al viajar a otro país. La finalidad de los patrones de adaptador es ayudar a traducir las relaciones entre clases u objetos que de otro modo son incompatibles. Una aplicación que se basa en las API de terceros puede necesitar utilizar un patrón de adaptador para garantizar que la aplicación y las API puedan comunicarse.
  • Patrón de aplicación estrangulador: estos patrones ayudan a gestionar la refactorización de una aplicación monolítica en aplicaciones de microservicios. El nombre Strangler (estrangulador) se refiere a cómo una vid (microservicios) lentamente y con el tiempo supera y estrangula un árbol (una aplicación monolítica).

Puede obtener más información sobre estos patrones en "Cómo utilizar patrones de desarrollo con microservicios (parte 4) ". IBM Developer también proporciona mucha información si desea aprender sobre otros patrones de código de microservicios.

Antipatrones

Aunque hay muchos patrones para aplicar bien los microservicios, hay un número igualmente grande de patrones que pueden crear problemas rápidamente para cualquier equipo de desarrollo. Algunos de ellos, reformulados como "que no hacer con los microservicios", son los siguientes:

  • La primera regla de los microservicios es, no crear microservicios: dicho de manera más clara, no empezar con microservicios. Los microservicios son una forma de gestionar la complejidad una vez que las aplicaciones se han vuelto demasiado grandes y difíciles de actualizar y mantener. Recién cuando sienta que la dificultad y la complejidad del monolito comienzan a aparecer, vale la pena considerar cómo puede refactorizar esa aplicación en servicios más pequeños. Hasta que sienta esa dificultad, ni siquiera tiene realmente un monolito que necesite refactorización.
  • No realice microservicios sin DevOps ni servicios en la nube: la creación de microservicios significa crear sistemas distribuidos, y los sistemas distribuidos son difíciles (y son especialmente difíciles si se toman decisiones que los dejan aún más complicados). Intentar realizar microservicios sin a) una implementación adecuada y una automatización de supervisión o b) servicios de nube gestionados para dar soporte a su infraestructura heterogénea ahora en expansión, es buscar muchos problemas innecesarios. Ahórrese el dolor de cabeza para que pueda dedicar su tiempo a preocuparse por el estado.
  • No haga demasiados microservicios haciéndolos demasiado pequeños: si va demasiado lejos con el "micro" de los microservicios, podría encontrarse fácilmente sobrecargado y con una complejidad que supera los beneficios generales de una arquitectura de microservicios. Es mejor inclinarse hacia servicios más grandes y luego sólo dividirlos cuando comienzan a desarrollar características que los microservicios solucionan, como el hecho de que se está volviendo difícil y lento implementar cambios, un modelo de datos común se está volviendo demasiado complejo, o que diferentes partes del servicio tienen diferentes requisitos de carga/escala.
  • No convierta los microservicios en SOA: los microservicios y la arquitectura orientada a servicios (SOA) a menudo se confunden entre sí, dado que en su nivel más básico, ambos buscan crear componentes individuales reutilizables que pueden ser consumidos por otras aplicaciones. La diferencia entre microservicios y SOA es que los proyectos de microservicios suelen implicar refactorizar una aplicación para que sea más fácil de gestionar, mientras que SOA se ocupa de cambiar la forma en que los servicios de TI trabajan en toda la empresa. Un proyecto de microservicios que se transforma en un proyecto SOA probablemente se hundirá bajo su propio peso.
  • No trate de ser Netflix: Netflix fue uno de los primeros pioneros de la arquitectura de microservicios en crear y gestionar una aplicación que representaba un tercio de todo el tráfico de Internet, una especie de tormenta perfecta que les obligaba a crear un montón de código personalizado y servicios que son innecesarios para la aplicación media. Se recomienda empezar a un ritmo que puede manejar, evitar la complejidad y utilizar tantas herramientas predefinidas como sea posible.

Tutoriales: Desarrollar habilidades de microservicios

Si está preparado para obtener más información sobre cómo utilizar microservicios, o si necesita desarrollar sus conocimientos de microservicios, pruebe uno de estos tutoriales:

Microservicios e IBM Cloud

Los microservicios permiten un desarrollo innovador a la velocidad de los negocios modernos. Descubra cómo aprovechar la escalabilidad y la flexibilidad de la nube mediante la implementación de microservicios independientes en entornos de nube. Vea cómo sería modernizar sus aplicaciones con la ayuda de IBM. 

Dé el siguiente paso:

  • Libere a sus equipos de desarrollo confiando en la iteración automatizada con la ayuda de las herramientas de desarrollo nativas en la nube de IBM.
  • Obtenga más información sobre los Kubernetes gestionados al empezar con Red Hat OpenShift on IBM Cloud o IBM Cloud Kubernetes Service. Consulte IBM Cloud Code Engine para obtener más información sobre la computación sin servidor.
  • Los microservicios están relacionados tanto con el proceso del equipo y la organización como con la tecnología. Planifique estratégicamente el enfoque de DevOps con la ayuda de IBM DevOps.

Empiece creando una cuenta de IBM Cloud.