¡Participa de la Maratón Behind the Code, la competencia de programación más desafiante! Inscríbete aqui

Microservicios

Microservicios

La arquitectura de microservicios es un enfoque en el que una sola aplicación se compone de muchos servicios más pequeños ligeramente acoplados y desplegables de manera independiente.

¿Qué son los microservicios?

Los microservicios (o arquitectura de microservicios) son un enfoque arquitectónico nativo de la nube en el que una sola aplicación se compone de muchos componentes o servicios más pequeños, ligeramente acoplados y desplegables de manera independiente. Estos servicios normalmente

  • tienen su propia pila tecnológica, que incluye la base de datos y el modelo de gestión de datos;

  • se comunican entre sí a través de una combinación de API Rest, transmisión de eventos y message brokers; y

  • se organizan por capacidad empresarial, con la línea que separa los servicios a menudo denominada contexto delimitado.

Aunque gran parte del debate acerca de los microservicios ha girado en torno a las definiciones y características arquitectónicas, su valor se puede entender más comúnmente a través de beneficios empresariales y organizacionales bastante sencillos:

  • Es posible actualizar el código más fácilmente: se pueden agregar nuevas funciones o funcionalidades sin modificar toda la aplicación.

  • Los equipos pueden utilizar diferentes pilas y diferentes lenguajes de programación para componentes distintos.

  • Los componentes se pueden escalar independientemente unos de otros, lo que reduce el desperdicio y el costo asociados con tener que escalar aplicaciones completas porque una sola función podría estar soportando demasiada carga.

Los microservicios también pueden entenderse por lo que no son. Las dos comparaciones más frecuentes 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 sola aplicación a partir de muchos servicios más pequeños y de ligeramente acoplados, en lugar del enfoque monolítico, que implica una aplicación grande y muy acoplada. Para aprender más sobre las diferencias entre los microservicios y la arquitectura monolítica, ve el siguiente video (6:37):


Las diferencias entre los microservicios y la arquitectura orientada a servicios pueden ser un poco menos claras. Si bien se pueden establecer contrastes técnicos entre los microservicios y la arquitectura orientada a servicios, especialmente en torno al rol del bus de servicios empresariales (ESB), es más fácil considerar la diferencia como una cuestión de alcance. La arquitectura orientada a servicios fue un esfuerzo de toda la empresa para estandarizar la manera en que todos los servicios web de una organización se comunican e integran entre sí, mientras que la arquitectura de microservicios es específica de la aplicación. El artículo «SOA vs. Microservicios: ¿Cuál es la diferencia?» entra en más detalles.

Cómo benefician los microservicios a la organización

Es probable que los microservicios sean al menos tan populares entre los ejecutivos y los líderes de proyectos como entre los desarrolladores. Esta es una de las características más inusuales de los microservicios, ya que el entusiasmo arquitectónico suele limitarse 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 dirigir sus equipos y procesos de desarrollo. Dicho de otro modo, los microservicios son un modelo arquitectónico que facilita en mayor medida el modelo operativo deseado. En una reciente encuesta realizada por IBM realizada a más de 1200 desarrolladores y ejecutivos de TI, el 87 % de los usuarios de microservicios estuvo de acuerdo en que la adopción de microservicios compensa el gasto y el esfuerzo. Con la siguiente herramienta interactiva se pueden explorar más perspectivas sobre los beneficios y desafíos de los microservicios:

¿Qué opinan los profesionales de TI y desarrollo?

Los no usuarios están de acuerdo Los usuarios están de acuerdo (Fuente: ‘Microservicios en la empresa 2021: Beneficios reales, desafíos que valen la pena‘.) Estos son algunos de los beneficios empresariales de los microservicios.

Se pueden desplegar de forma independiente

Quizá la característica más importante de los microservicios es que, al ser más pequeños y poder desplegarse de forma independiente, ya no se requieren enormes esfuerzos para cambiar una línea de código o agregar una nueva función en la aplicación. Los microservicios ofrecen a las organizaciones un remedio contra las frustraciones viscerales asociadas a los pequeños cambios que requieren enormes cantidades de tiempo. No se requiere un doctorado en Computación para ver o entender el valor de un enfoque que facilita y promueve la velocidad y la agilidad. Pero la velocidad no es el único valor de diseñar servicios de esta manera. Un modelo organizativo emergente habitual es reunir a los equipos multifuncionales en torno a un problema empresarial, servicio o producto. El modelo de microservicios encaja perfectamente con esta tendencia porque permite a una organización crear equipos pequeños y multifuncionales en torno a un servicio o conjunto de servicios y hacer que funcionen de forma ágil. El acoplamiento flexible de los microservicios también crea un grado de aislamiento de errores y una mejor resistencia en las aplicaciones. Además, el pequeño tamaño de los servicios, combinado con sus límites y patrones de comunicación claros, facilita que los nuevos miembros de los equipos puedan comprender la base de código y contribuir a ella rápidamente, lo que supone un claro beneficio en términos de velocidad y moral de los empleados.

La herramienta adecuada para el trabajo

En los patrones tradicionales de arquitectura de n niveles, una aplicación normalmente comparte una pila común, con una gran base de datos relacional que respalda toda la aplicación. Este enfoque tiene varios inconvenientes obvios, siendo el más importante que todos los componentes de una aplicación deben compartir una pila común, un modelo de datos y una base de datos, incluso aunque exista una herramienta clara y mejor para el trabajo para ciertos elementos. Esto da lugar a una mala arquitectura, y es frustrante para los desarrolladores que constantemente son conscientes de que existe una forma mejor y más eficiente de 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 alguna combinación de REST, transmisión de eventos y message brokers, por lo que es posible optimizar la pila de cada servicio individual para ese servicio. La tecnología cambia constantemente, y una aplicación compuesta por múltiples servicios más pequeños es mucho más fácil y menos costosa de adaptar a una tecnología más adecuada conforme esté disponible.

Escalabilidad precisa

Con los microservicios, los servicios individuales se pueden desplegar individualmente, pero también se pueden escalar individualmente. El beneficio resultante es obvio: si se utilizan correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas porque permiten una escalabilidad precisa de únicamente los componentes que lo requieren, en lugar de toda la aplicación en el caso de las aplicaciones monolíticas.

También hay desafíos

Los beneficios significativos de los microservicios vienen acompañados de grandes desafíos. Pasar de los monolitos a los microservicios significa 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 causar, o ser causados por, 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 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 problemas de latencia y conectividad. Un enfoque de DevOps (como leerás a continuación) puede abordar muchos de estos problemas, pero la adopción de DevOps tiene sus propios desafíos. Sin embargo, estos desafíos no impiden que los usuarios que no adoptan los microservicios lo hagan, ni que los que los adoptan intensifiquen su apuesta por ellos. Un nuevo estudio de IBM revela que es probable o muy probable que el 56 % de los no usuarios actuales adopten microservicios en los próximos dos años, y el 78 % de los usuarios actuales de microservicios probablemente aumentarán el tiempo, el dinero y el esfuerzo que han invertido en microservicios (ver Figura 1).

Porcentajes de usuarios que hacen uso de microservicios, dependiendo de sus variedades

Figura 1: Los microservicios han llegado para quedarse. En los próximos dos años, es probable que el 56 % de los no usuarios adopten los microservicios, el 78 % de los usuarios aumentará su inversión en microservicios y el 59 % de las aplicaciones se crearán utilizando los microservicios. (Fuente: ‘Microservicios en la empresa 2021: Beneficios reales, desafíos que valen la pena’.)

Los microservicios habilitan y requieren DevOps

La arquitectura de microservicios a menudo se describe como optimizada para DevOps y la 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 realmente requieren DevOps para tener éxito. Si bien las aplicaciones monolíticas tienen una serie de inconvenientes que se han tratado 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 el contrario, dado el enorme aumento de la complejidad, las partes móviles y las dependencias que conllevan los microservicios, no sería prudente abordar los microservicios sin realizar inversiones significativas en el despliegue, la supervisión y la automatización del ciclo de vida. Andrea Crawford profundiza en DevOps en el siguiente video:


Tecnologías y herramientas clave

Aunque casi cualquier herramienta o lenguaje moderno se puede utilizar en una arquitectura de microservicios, hay unas cuantas herramientas básicas que se han convertido en esenciales y prácticamente determinantes para los microservicios:

Contenedores, Docker y Kubernetes

Uno de los elementos clave de un microservicio es que generalmente es bastante pequeño (no hay ninguna cantidad arbitraria de código que determine si algo es o no un microservicio, pero la palabra «micro» está en el nombre). Cuando Docker inauguró la era moderna de los contenedores en 2013, también introdujo el modelo de computación que se asociaría más estrechamente con los microservicios. Dado que los contenedores individuales no tienen la sobrecarga de su propio sistema operativo, son más pequeños y ligeros que las máquinas virtuales tradicionales y pueden flexibilizarse más rápidamente, lo que los convierte en un complemento perfecto 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 gestión de grandes grupos de contenedores se convirtió rápidamente en uno de los desafíos críticos. Kubernetes, una plataforma de orquestación de contenedores open source, se ha convertido en una de las soluciones de orquestación más populares porque desempeña muy bien ese trabajo. En el video «Explicación sobre Kubernetes», Sai Vennam ofrece una visión completa de todo lo relacionado con 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 de una aplicación crece con el tiempo. Un gateway de API actúa como un proxy inverso para los clientes mediante el enrutamiento de solicitudes, la distribución de solicitudes entre varios servicios y el suministro de recursos adicionales de seguridad y autenticación. Hay varias tecnologías que se pueden usar para implementar gateways de API, incluidas las plataformas de API Management, pero si la arquitectura de microservicios se implementa mediante contenedores y Kubernetes, el gateway se implementa normalmente utilizando Ingress o, más recientemente, Istio.

Mensajería y transmisión de eventos

Si bien la mejor práctica podría ser diseñar servicios sin estado, el estado existe y los servicios deben conocerlo. Y aunque una llamada a la API suele ser una forma eficaz de establecer inicialmente el estado de un servicio determinado, no es una forma particularmente eficaz de mantenerse actualizado. Un enfoque de sondeo constante para mantener los servicios actualizados simplemente no es práctico. En su lugar, es necesario acoplar las llamadas a la API que establecen el estado con la mensajería o la transmisión de eventos para que los servicios puedan difundir los cambios en el estado y las partes interesadas puedan escuchar esos cambios y ajustarse en consecuencia. 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 transmisión de eventos, como Apache Kafka, podría ser una buena opción. Al combinar los microservicios con una arquitectura basada en eventos, los desarrolladores pueden crear sistemas distribuidos, altamente escalables, tolerantes a errores y extensibles que pueden consumir y procesar grandes cantidades de eventos o información en tiempo real.

Serverless

Las arquitecturas serverless llevan algunos de los patrones principales de nube y los microservicios a su conclusión lógica. En el caso de serverless, la unidad de ejecución no es solo un pequeño servicio, sino una función, que a menudo puede ser solo unas pocas líneas de código. La línea que separa una función serverless de un microservicio es difusa, pero se entiende que las funciones son aún más pequeñas que un microservicio. Las arquitecturas serverless y las plataformas de funciones como servicio (FaaS) comparten afinidad con los microservicios, ya que ambos están interesados en crear unidades de despliegue más pequeñas y escalar con precisión según la demanda.

Microservicios y servicios en la nube

Los microservicios no son necesariamente relevantes de forma exclusiva para la computación en la nube, pero hay algunas razones importantes por las que suelen ir juntos, razones que van más allá de que los microservicios sean un estilo arquitectónico popular para las nuevas aplicaciones y que la nube sea un destino de alojamiento popular para las nuevas aplicaciones. Entre las principales ventajas de la arquitectura de microservicios se encuentran los beneficios de utilización y costo asociados con el despliegue y la escalabilidad individual de los componentes. Si bien estas ventajas todavía estarían presentes hasta cierto punto con la infraestructura on-premises, la combinación de componentes pequeños e independientemente escalables junto con la infraestructura bajo demanda y de pago por uso es donde se pueden encontrar verdaderas optimizaciones de costos. En segundo lugar, y tal vez más importante, otro beneficio principal de los microservicios es que cada componente individual puede adoptar la pila más adecuada para su trabajo específico. La proliferación de pilas puede conducir a una gran complejidad y sobrecarga cuando las gestiona uno mismo, pero el consumo de la pila de soporte como servicios en la nube puede minimizar drásticamente los desafíos de gestión. Dicho de otro modo, aunque no es imposible desarrollar una infraestructura de microservicios propia, no es aconsejable, especialmente cuando se está empezando.

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 para frontend (BFF): Este patrón inserta una capa entre la experiencia del usuario y los recursos a los que recurre esa experiencia. Por ejemplo, una aplicación usada en un dispositivo desktop tendrá límites de tamaño de pantalla, visualización y rendimiento diferentes a los de un dispositivo móvil. El patrón BFF permite a los desarrolladores crear y dar soporte a un tipo de backend por interfaz de usuario utilizando las mejores opciones para esa interfaz, en lugar de intentar dar soporte a un backend genérico que funcione con cualquier interfaz pero que pueda afectar negativamente al rendimiento del frontend.

  • Patrones de entidad y agregados: Una entidad es un objeto que se distingue por su identidad. Por ejemplo, en un sitio de comercio electrónico, el objeto Producto puede distinguirse por el nombre, el tipo y el precio del producto. Un agregado es una colección de entidades relacionadas que deben tratarse como una unidad. Por lo tanto, para el sitio de comercio electrónico, un Pedido sería una colección (agregado) de productos (entidades) ordenados por un comprador. Estos patrones se utilizan para clasificar los datos de manera significativa.

  • Patrones de descubrimiento de servicios: Estos patrones ayudan a que las aplicaciones y los servicios se encuentren entre sí. En una arquitectura de microservicios, las instancias de servicio cambian dinámicamente debido a la escalabilidad, las actualizaciones, los errores del servicio e incluso la finalización de este. Estos patrones proporcionan mecanismos de descubrimiento para hacer frente a esta transitoriedad. El balanceo de carga puede usar patrones de descubrimiento de servicios mediante el empleo de verificaciones de estado y fallas del servicio como desencadenantes para reequilibrar el tráfico.

  • Patrones de microservicios adaptadores: Se debe pensar en los patrones de adaptadores de la misma manera que se piensa en los adaptadores de enchufes que se utilizan cuando se viaja a otro país. El propósito de los patrones de adaptadores es ayudar a traducir las relaciones entre clases u objetos que de otro modo serían incompatibles. Una aplicación que depende de 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 ayudan a gestionar la refactorización de una aplicación monolítica en aplicaciones de microservicios. Su llamativo nombre (Strangler significa “estrangulador”) hace referencia a cómo una enredadera, que serían los microservicios, va ganando terreno lentamente y con el tiempo estrangulando al árbol, que sería la aplicación monolítica.

Aprende más sobre estos patrones en «Como usar los patrones de desarrollo con microservicios (parte 4)«. IBM Developer también proporciona mucha información si deseas aprender más sobre otros code patterns de microservicios.

Anti-patrones

Aunque hay muchos patrones para hacer un buen uso de los microservicios, hay un número igualmente significativo de patrones que pueden meter rápidamente a cualquier equipo de desarrollo en problemas. Algunos de ellos, expresados como “lo que no se debe hacer con los microservicios”, son los siguientes:

  • La primera regla de los microservicios es no crear microservicios: Dicho con mayor precisión: no comiences por los microservicios. Los microservicios son una forma de gestionar la complejidad una vez que las aplicaciones se han vuelto demasiado grandes y difíciles como para poder actualizarlas y mantenerlas fácilmente. Solamente cuando empiezan a aparecer los problemas y la complejidad del monolito, vale la pena considerar cómo se puede refactorizar esa aplicación en servicios más pequeños. Mientras no se experimenten dificultades, en realidad no es un monolito que necesite ser refactorizado.

  • No crear microservicios sin DevOps o servicios en la nube: La creación de microservicios significa crear sistemas distribuidos, y los sistemas distribuidos son difíciles, especialmente si se toman decisiones que los hacen aún más difíciles. Intentar crear microservicios sin a) una automatización adecuada del despliegue y supervisión, o b) servicios en la nube gestionados para respaldar tu infraestructura heterogénea, ahora en expansión, buscarse problemas innecesarios. Evita los problemas para poder dedicar tu tiempo en preocuparte por el estado.

  • No crear demasiados microservicios haciéndolos demasiado pequeños: Cuando uno se excede con el «micro» de los microservicios, puede encontrarse fácilmente con una sobrecarga y una complejidad que acaban superando a las ventajas generales de una arquitectura de microservicios. Es mejor inclinarse por servicios más grandes y luego separarlos solamente cuando comiencen a desarrollar características que resuelven los microservicios, como por ejemplo si se vuelve difícil y lento desplegar cambios, si un modelo de datos común se vuelve demasiado complejo o si las diferentes partes del servicio tienen diferentes requisitos de carga o escala.

  • No convertir los microservicios en SOA: Los microservicios y la arquitectura orientada a servicios (SOA) se confunden a menudo entre sí, dado que, en su nivel más básico, ambos están interesados en crear componentes individuales reutilizables que puedan consumir otras aplicaciones. La diferencia entre los microservicios y la arquitectura orientada a servicios es que los proyectos de microservicios normalmente implican la refactorización de una aplicación para que resulte más fácil de gestionar, mientras que la arquitectura orientada a servicios se ocupa de cambiar la forma en que los servicios de TI funcionan en toda la empresa. Un proyecto de microservicios que se transforma en un proyecto de arquitectura orientada a servicios probablemente se hundirá por su propio peso.

  • No intentar ser Netflix: Netflix fue uno de los pioneros de la arquitectura de microservicios al construir y gestionar una aplicación que representaba un tercio de todo el tráfico de Internet, una especie de tormenta perfecta que les obligó a desarrollar mucho código y servicios personalizados que son innecesarios para una aplicación promedio. Es mucho mejor comenzar con un ritmo manejable, evitar la complejidad y utilizar tantas herramientas disponibles como sea posible.

Tutoriales: Desarrollar habilidades de microservicios

Para aprender más sobre el uso de los microservicios, o para mejorar tus conocimientos sobre ellos, consulta uno de estos tutoriales:

Microservicios e IBM Cloud

Los microservicios permiten un desarrollo innovador a la velocidad de los negocios modernos. Aprende a aprovechar la escalabilidad y la flexibilidad de la nube mediante el despliegue de microservicios independientes en entornos de nube. Descubre cómo sería modernizar tus aplicaciones con la ayuda de IBM.  Da el siguiente paso:

Comienza creando una cuenta de IBM Cloud hoy mismo.