Microservicios
Fondo azul y negro
¿Qué son los 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.

Los microservicios (o la arquitectura de microservicios) son un enfoque arquitectónico nativo de 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 lote de tecnología, incluyendo base de datos y modelo de gestión de datos;
se comunican entre sí mediante una combinación de API REST, transmisión de eventos, y Message Brokers; y
están organizados por capacidad de negocio, con la línea que separa los servicios a menudo denominada contexto delimitado.

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 agregar nuevas características o funcionalidades sin tocar 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 hacen 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.

Las diferencias entre microservicios y SOA pueden ser un poco menos claras. Si bien se pueden establecer contrastes técnicos entre microservicios y SOA, especialmente en torno al rol del Enterprise Service Bus (ESB), es más fácil considerar la diferencia como una de alcance. SOA fue un esfuerzo de toda la empresa para estandarizar la forma en que todos los servicios web en una organización se comunican e 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?" entra en más detalles.

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

Microservicios en la empresa, 2021: una nueva investigación de IBM revela los beneficios y desafíos de la adopción de microservicios.

Regístrese para descargar el e-book


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 estuvo de acuerdo en que la adopción de microservicios vale la pena el gasto y el esfuerzo. Utilice la siguiente herramienta interactiva para revisar más puntos de vista sobre las ventajas de los microservicios y los retos que plantean.

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 da 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 implementan 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 lote 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. 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.

Sin embargo, estos desafíos no impiden que los no adoptantes adopten microservicios, o que los adoptantes profundicen sus compromisos con los 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.

Modernice sus aplicaciones para la interoperabilidad y el ROI: mejore el valor de sus aplicaciones existentes y reduzca el costo de mantenimiento.

Conozca más


Los microservicios permiten, 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 pequeños servicios que se pueden implementar 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. 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 la implementación, 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:

Productos destacados

Red Hat OpenShift on IBM Cloud

IBM Cloud Kubernetes Service

IBM Cloud Code Engine


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 han vuelto esenciales y prácticamente definitivas para los microservicios:

Contenedores, Docker y Kubernetes

Uno de los elementos clave de un microservicio es que, en general, es bastante pequeño. (No hay una cantidad arbitraria de código que determine si algo es o no un microservicio, pero "micro" está ahí 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. Porque contenedores individuales no tienen la sobrecarga de su propio sistema operativo, son más pequeños y livianos que las tradicionales maquinas virtuales y pueden girar hacia arriba y hacia abajo más rápidamente, lo que los convierte en una combinación perfecta para los servicios más pequeños y livianos 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 orquestación de contenedores de fuente abierta, se ha convertido en 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 implementa mediante contenedores y Kubernetes, el gateway se implementa normalmente mediante 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 de sondeo constante, "¿ya llegamos?" para mantener los servicios actualizados 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. Y con la combinación de microservicios con la arquitectura impulsada por eventos, los desarrolladores pueden 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 sin servidor, 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 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 las arquitecturas sin servidor y las plataformas Functions-as-a-Service (FaaS) comparten afinidad con los microservicios es que ambas están interesadas en crear unidades de implementación más pequeñas y escalar 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 hospedaje 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 para frontend (BFF):  este patrón inserta una capa entre la experiencia del usuario y los recursos que la experiencia solicita. 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 con 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 que se distingue 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:  estos 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 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. El equilibrio de carga puede utilizar patrones de descubrimiento de servicios mediante comprobaciones de estado y fallos del servicio como desencadenantes para reequilibrar el tráfico.
  • Patrones de microservicios del adaptador:  piense en los patrones de los adaptadores de la misma manera que piensa en los adaptadores de enchufe que usa cuando viaja 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 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 del 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 usar patrones de desarrollo con microservicios (parte 4)". IBM Developer también proporciona mucha información si desea conocer más acerca de 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 a 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 con más precisión, no empieces a trabajar 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 haga microservicios sin DevOps o servicios en la nube: desarrollar microservicios significa crear sistemas distribuidos, y los sistemas distribuidos son difíciles (y son especialmente difíciles si toma decisiones que lo hacen aún más difícil). 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 cree demasiados microservicios haciéndolos demasiado pequeños: si va demasiado lejos con lo "micro" en los microservicios, podría encontrarse fácilmente con una sobrecarga y una complejidad que superan las ganancias 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 intentes 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 pueda manejar, evitar la complejidad y utilizar tantas herramientas predefinidas como sea posible.

Tutoriales: Desarrolle habilidades de microservicios

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 al confiar en la iteración automatizada con la ayuda de las herramientas de desarrollo nativas de la nube de IBM.
  • Descubra más acerca de Kubernetes gestionado al empezar a usar Red Hat OpenShift on IBM Cloud o IBM Cloud Kubernetes Service. Además, eche un vistazo a IBM Cloud Code Engine para obtener más información sobre la informática 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 con una cuenta de IBM Cloud hoy mismo.   


Soluciones relacionadas

Soluciones de modernización de aplicaciones

Cree, modernice y gestione aplicaciones de forma segura en cualquier nube, con confianza.


Soluciones nativas en la nube

Una plataforma nativa en la nube escalable y rica en seguridad.


Red Hat OpenShift

Implemente clústeres altamente disponibles y completamente gestionados con un clic


Servicio de Kubernetes

Implemente clústeres seguros y con alta disponibilidad en una experiencia nativa de Kubernetes


Soluciones de Code Engine

Ejecute su contenedor, código de aplicación o trabajo por lotes en un tiempo de ejecución de contenedor completamente administrado.


Servicios DevOps

Cree, implemente y gestione aplicaciones nativas en la nube ricas en seguridad en múltiples dispositivos, entornos y nubes con las mejores prácticas de DevOps.