Microservicios

menu icon

Microservicios

La arquitectura de microservicios es un enfoque en el que una única aplicación está formada por muchos servicios más pequeños, desplegables de forma independiente y de acoplamiento ligero.

¿Qué son los microservicios?

Los microservicios (o la arquitectura de microservicios) son un enfoque de arquitectura nativa en cloud en el que una única aplicación está formada por muchos componentes o servicios más pequeños, desplegables de forma independiente y de acoplamiento ligero. Estos servicios normalmente

  • tienen su propia pila de tecnología, que incluye la base de datos y el modelo de gestión de datos;
  • se comunican entre si a través de una combinación de API REST, transmisión de sucesos e intermediarios de mensajes, y
  • se organizan por capacidad de negocio, donde la línea que separa los servicios a menudo se denomina un contexto limitado.

Aunque gran parte de la discusión sobre los microservicios ha girado en torno a las definiciones y las características arquitectónicas, su valor se entiende mejor a través de unos beneficios empresariales y organizacionales bastante simples:

  • El código se puede actualizar más fácilmente: se pueden añadir nuevas características o funciones sin intervenir en toda la aplicación
  • Los equipos pueden utilizar diferentes pilas y diferentes lenguajes de programación para diferentes componentes.
  • Los componentes se pueden escalar independientemente unos de otros, lo que reduce el desperdicio y los costes asociados a tener que escalar aplicaciones enteras porque una única característica esté soportando demasiada carga.

Los microservicios también se pueden entender por lo que no son. Las dos comparaciones que se realizan más a menudo 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 forman una única aplicación a partir de muchos servicios más pequeños y de acoplamiento ligero, a diferencia del enfoque monolítico de una aplicación grande y de acoplamiento completo.

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

 

Las diferencias entre los microservicios y SOA pueden ser un poco menos claras. Aunque se pueden establecer diferencias técnicas entre los microservicios y SOA, especialmente en torno al rol del bus de servicio empresarial (ESB), es más fácil considerar la diferencia de ámbito. SOA fue una iniciativa de toda la empresa para estandarizar la forma en la 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.

En la publicación "SOA o microservicios: ¿cuál es la diferencia?" se profundiza en más detalles.

Cómo benefician los microservicios a la organización

Es probable que los microservicios sean al menos tan conocidos entre los ejecutivos y los líderes del proyecto como entre los desarrolladores. Esta es una de las características más inusuales de los microservicios, porque el entusiasmo por la arquitectura se reserva normalmente para los equipos de desarrollo de software. La razón es que los microservicios reflejan mejor la forma en que muchos líderes empresariales desean estructurar y ejecutar sus equipos y procesos de desarrollo.

Dicho de otro modo, los microservicios son un modelo de arquitectura que facilita un modelo operativo deseado. En una encuesta reciente de IBM realizada 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 solo algunos de los beneficios empresariales de los microservicios.

Desplegables de forma independiente

Tal vez la característica más importante de los microservicios es que como los servicios son más pequeños e desplegables de manera independiente, ya no requieren una Ley del Congreso para cambiar una línea de código o añadir una nueva característica en una aplicación.

Los microservicios prometen a las organizaciones un antídoto contra la frustración asociada con realizar pequeños cambios que requieren grandes cantidades de tiempo. No se necesita un doctorado en informática para ver o entender el valor de un enfoque que aumenta la velocidad y la agilidad.

No obstante, la velocidad no es la única ventaja que tiene diseñar servicios de esta manera. Un modelo organizativo emergente común es reunir equipos multifuncionales en torno a un problema de negocio, 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 operen de forma ágil.

El acoplamiento ligero de los microservicios también crea un grado de aislamiento de errores y ofrece una mejor resiliencia en las aplicaciones. Asimismo, el pequeño tamaño de los servicios, combinado con sus claros límites y patrones de comunicación, permite a los nuevos miembros del equipo entender la base de código y modificarla rápidamente, lo que supone una clara ventaja en términos de velocidad y moral de los empleados.

La herramienta adecuada para el trabajo

En los patrones de arquitectura tradicionales de n niveles, una aplicación normalmente comparte una pila 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 importante es que cada componente de una aplicación debe compartir una pila común, un modelo de datos y una base de datos, aunque haya una herramienta mejor para el trabajo para determinados 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, transmisión de sucesos e intermediarios de mensajes, lo que permite optimizar la pila de cada servicio individual en 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 desplegar uno a uno, y también se pueden escalar individualmente. El beneficio resultante es evidente: Si se hace correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas, ya que permiten un escalado preciso solo de los componentes que lo requieran, en lugar de toda la aplicación, como ocurre con las aplicaciones monolíticas.

También existen algunos retos

Las importantes ventajas de los microservicios también llevan asociadas algunos retos significativos. Cambiar de una aplicación monolítica a los microservicios implica una mayor complejidad de gestión: muchos más servicios, creados por muchos más equipos, desplegados en muchos más lugares. Los problemas en un servicio pueden provocar o deberse a problemas en otros servicios. Los datos de registro (utilizados para la supervisión y la resolución de problemas) son más voluminosos y pueden ser incoherentes entre los distintos servicios. Las nuevas versiones pueden generar problemas de compatibilidad con las versiones anteriores. Las aplicaciones requieren más conexiones de red, lo que significa más oportunidades de problemas de latencia y conectividad. Un enfoque de DevOps (como se describe a continuación) puede solucionar muchos de estos problemas, pero la adopción de DevOps tiene sus propios retos.

No obstante, estos retos no impiden que los no usuarios adopten el uso de microservicios o que los usuarios aumenten sus compromisos de microservicios.Los nuevos datos de la 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 que el 78 % de los usuarios actuales de microservicios es muy probable que aumenten el tiempo, el dinero y el esfuerzo que han invertido en los microservicios (consulte la Figura 1).

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

Figura 1: Los microservicios están aquí para quedarse.En 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 habilitan y requieren DevOps

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

No obstante, otra forma de ver la relación entre los microservicios y DevOps es que las arquitecturas de microservicios en realidadrequierenDevOps para tener éxito. Mientras que las aplicaciones monolíticas tienen una serie de inconvenientes que se han descrito anteriormente en este artículo, tienen la ventaja de no ser un sistema distribuido complejo con múltiples partes móviles y pilas de tecnología independientes. Por su parte, teniendo en cuenta el gran aumento de la complejidad, las partes móviles y las dependencias que implican los microservicios, sería poco prudente adoptar el uso de microservicios sin una inversión significativa en el despliegue, la supervisión y la automatización del ciclo de vida.

En el siguiente vídeo, Andrea Crawford analiza en profundidad DevOps:

Tecnologías y herramientas clave

Aunque casi cualquier herramienta o lenguaje moderno puede utilizarse en una arquitectura de microservicios, hay varias herramientas básicas que se han convertido en esenciales y que definen los límites de 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 dio inicio a la era moderna de los contenedores en 2013, también introdujo el modelo de cálculo que se asociaría más estrechamente con los microservicios. Como los contenedores individuales no tienen la sobrecarga de su propio sistema operativo, son más pequeños y más ligeros que las máquinas virtuales tradicionales, y pueden activarse y desactivarse más rápidamente, lo que les convierte en la solución perfecta para los servicios de peso más ligero y pequeños que se encuentran en las arquitecturas de microservicios.

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

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

 

Pasarelas de API

Los microservicios a menudo se comunican a través de una 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, las pasarelas de API suelen ser una capa intermedia útil, especialmente a medida que el número de servicios crece con el tiempo en una aplicación. Una pasarela de API actúa como proxy inverso para los clientes al direccionar las solicitudes, distribuir abanico las solicitudes en varios servicios y proporcionar seguridad y autenticación adicionales.

Existen varias tecnologías que pueden utilizarse para implementar pasarelas de API, por ejemplo, las plataformas de gestión de API, pero si la arquitectura de microservicios se está implementando utilizando contenedores y Kubernetes, la pasarela se implementa normalmente utilizando Ingress o, más recientemente, Istio.

Mensajería y transmisión de sucesos

Aunque la práctica recomendada sería el diseño de servicios sin estado, el estado existe y los servicios deben tenerlo en cuenta. Asimismo, aunque una llamada de API es a menudo una forma eficaz de establecer inicialmente el estado de un determinado servicio, no es una manera particularmente eficaz de mantenerse al día. El enfoque "¿Hemos llegado ya?" de sondeo constante para mantener los servicios actualizados no resulta práctico.

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

Sin servidor

Las arquitecturas sin servidor llevan algunos de los patrones básicos de cloud y microservicios a su conclusión lógica. En el caso de las arquitecturas sin servidor, la unidad de ejecución no es sólo un pequeño servicio, sino una función, que a menudo puede estar formada solo por unas pocas líneas de código. La línea que separa una función sin servidor de un microservicio es difusa, pero normalmente se entiende que las funciones son incluso más pequeñas que un microservicio.

Donde las arquitecturas sin servidor y plataformas de Funciones como servicio (FaaS) comparten afinidad con los microservicios es en que ambas están interesadas en crear unidades más pequeñas de despliegue y un escalado preciso según demanda.

Servicios de microservicios y cloud

Los microservicios no son necesariamente relevantes para cloud computing de manera exclusiva, pero hay varias razones importantes por las que suelen ir juntos, que van más allá de que los microservicios sean un estilo de arquitectura reconocido para las nuevas aplicaciones y que el cloud sea un destino de alojamiento popular para las nuevas aplicaciones.

Entre los principales beneficios de la arquitectura de microservicios se encuentran las ventajas económicas y de uso asociadas con el despliegue y escalado individual de componentes. 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 costes.

En segundo lugar, otro de los principales beneficios, y quizás más importante, es que cada componente individual puede adoptar la pila más adecuada para su trabajo específico. La proliferación de pilas puede aumentar significativamente la complejidad y generar una sobrecarga cuando gestiona su propia infraestructura, pero el consumo de la pila de soporte como servicios en cloud puede minimizar drásticamente los retos de gestión. Dicho de otra manera, aunque no es imposible desplegar su propia infraestructura de microservicios, no se recomienda, especialmente si está empezando.

Patrones comunes

En las arquitecturas de microservicios, hay muchos patrones de diseño, comunicación e integración comunes y útiles, que permiten abordar algunos de los retos y oportunidades más comunes, por ejemplo:

  • 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 escritorio tendrá diferentes límites de tamaño de pantalla, visualización y rendimiento que un dispositivo móvil. El patrón BFF permite a los desarrolladores crear y dar soporte a un tipo de programa de fondo por interfaz de usuario utilizando las mejores opciones para esa interfaz, en lugar de intentar dar soporte a un programa de fondo 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 e-commerce, un objeto de producto puede distinguirse por nombre de producto, tipo y precio. Un agregado es una colección de entidades relacionadas que deben tratarse como una unidad. Por lo tanto, para el sitio de e-commerce, una orden será una colección (un agregado) de productos (entidades) ordenados por comprador. Estos patrones se utilizan para clasificar los 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 la terminación del servicio. Estos patrones proporcionan mecanismos de descubrimiento para gestionar esta transitoriedad. El 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 en los adaptadores de enchufes que utiliza al viajar a otro país. La finalidad de los patrones de adaptador es ayudar a convertir relaciones entre clases u objetos que de otro modo son incompatibles. Una aplicación que se basa en 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 Strangler: estos patrones permiten gestionar la refactorización de una aplicación monolítica en aplicaciones de microservicios. El nombre Strangler (estrangulador) hace referencia a cómo una vid (microservicios) estrangula lentamente y con el tiempo un árbol (una aplicación monolítica).

Puede obtener más información sobre estos patrones en "Cómo utilizar patrones de desarrollo con los microservicios (parte 4)". IBM Developer también proporciona mucha información si desea obtener información 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 estos, reformulados como "usos a evitar de microservicios", son los siguientes:

  • La primera regla de los microservicios es "no crear microservicios": o más precisamente,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. Solo cuando sienta que la dificultad y la complejidad de las aplicaciones monolíticas son relevantes será recomendable 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 cree microservicios sin DevOps o servicios de cloud: la creación de microservicios significa construir sistemas distribuidos, y los sistemas distribuidos son complejos (y especialmente complejos si se toman decisiones que aumentan su complejidad). Si intenta aplicar microservicios sin un a) despliegue adecuado y una automatización de la supervisión, o b) servicios cloud gestionados para dar soporte a su infraestructura heterogénea en constante expansión, está buscando problemas innecesarios. Ahórrese esos problemas y dedique su tiempo a preocuparse por el estado.
  • No aplique demasiados microservicios creándolos demasiado pequeños: si se excede con el "micro" de microservicios, podría generar fácilmente una sobrecarga y una complejidad que no compensen los beneficios generales de una arquitectura de microservicios. Es mejor inclinarse por servicios más grandes y solo dividirlos cuando comiencen a desarrollar características que los microservicios puedan resolver, es decir, que cada vez sea más difícil y lento desplegar cambios, que un modelo de datos común se esté volviendo demasiado complejo, o que diferentes partes del servicio tengan 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 están interesados en crear componentes individuales reutilizables que puedan consumirse en por tras aplicaciones. La diferencia entre los microservicios y SOA es que los proyectos de microservicios suelen implicar la refactorización de una aplicación para que sea más fácil de gestionar, mientras que SOA cambia la forma en la que los servicios de TI trabajan en toda la empresa. Un proyecto de microservicios que se transforme en un proyecto SOA probablemente cederá bajo su propio peso.
  • No intente ser Netflix: Netflix fue uno de los pioneros de la arquitectura de microservicios al crear y gestionar una aplicación que englobaba un tercio de todo el tráfico de Internet, una especie de tormenta perfecta que les obligaba a crear una gran cantidad 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.

Guías de aprendizaje: Desarrollar habilidades de microservicios

Si está preparado para obtener más información sobre cómo utilizar microservicios, o si necesita desarrollar sus habilidades de microservicios, pruebe una de estas guías de aprendizaje:

Microservicios e IBM Cloud

Los microservicios permiten un desarrollo innovador a la velocidad de los negocios actuales. Descubra cómo aprovechar la escalabilidad y la flexibilidad del cloud desplegando microservicios independientes en entornos de cloud. Vea cómo sería modernizar sus aplicaciones con ayuda de IBM.

Dé el siguiente paso:

  • Confíe en la iteración automática con ayuda de las herramientas de desarrollo nativas de IBM Cloud para que sus equipos de desarrollo puedan dedicarse a tareas más importantes.
  • Obtenga más información sobre el entorno Kubernetes gestionado con una introducción a Red Hat OpenShift on IBM Cloud o IBM Cloud Kubernetes Service. Asimismo, consulte IBM Cloud Code Engine para obtener más información sobre la informática sin servidor.
  • Los microservicios consisten tanto en la organización y el proceso de equipo como en la tecnología. Planifique estratégicamente el enfoque de DevOps con la ayuda de IBM DevOps.

Empiece con una cuenta de IBM Cloud hoy mismo.