Inicio

Temas

microservices

¿Qué son los microservicios?
Cree con microservicios e IBM Registrarse para recibir actualizaciones en la nube
Ilustración que muestra cómo la arquitectura de microservicios desglosa una aplicación monolítica en pequeños servicios desplegables
¿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 conforma de muchos componentes o servicios más pequeños poco acoplados y que se pueden desplegar de forma independiente.

Por lo general, los microservicios:

  • Tienen su propia tecnología, 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 de transferencia de estado representacional (REST), transmisión de eventos y agentes de mensajes.
  • Se organizan por capacidad empresarial, y la línea que separa los servicios suele denominarse contexto delimitado.

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

  • 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 usar diferentes pilas y diferentes lenguajes de programación para diferentes componentes.
  • Los componentes se pueden escalar de forma independiente entre sí, lo que reduce el desperdicio y el coste asociados con tener que escalar aplicaciones completas porque una sola característica podría enfrentar demasiada carga.

Qué no son los microservicios

Los microservicios también pueden entenderse en contraste con dos arquitecturas de aplicaciones anteriores: 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 a partir de muchos servicios más pequeños y poco acoplados, frente al enfoque monolítico de una aplicación grande y muy acoplada.

Las diferencias entre los microservicios y la SOA pueden ser un poco menos claras. Si bien se pueden establecer contrastes técnicos entre los microservicios y la SOA, especialmente en torno a la función del bus de servicios empresarial, es más fácil ver la diferencia como una cuestión de alcance. La SOA fue un esfuerzo de toda la empresa para estandarizar la forma en que todos los servicios web de una organización hablan y se integran entre sí, mientras que la arquitectura de microservicios es específica de las aplicaciones.

Logre flexibilidad en el lugar de trabajo con DaaS

Lea cómo el escritorio como servicio (DaaS) permite a las empresas lograr el mismo nivel de rendimiento y seguridad que el despliegue de las aplicaciones on premises.

Contenido relacionado Regístrese para obtener la guía sobre modernización de aplicaciones
Cómo los microservicios benefician a la organización

Es probable que los microservicios sean al menos tan populares entre los ejecutivos y los jefes de proyecto como entre los desarrolladores. Esta es una de las características más inusuales de los microservicios, ya que el entusiasmo por la arquitectura suele estar 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 dirigir sus equipos y procesos de desarrollo.

Dicho de otra manera, los microservicios son un modelo arquitectónico que facilita mejor un modelo operativo deseado. En una encuesta de IBM de 2021 a más de 1200 desarrolladores y ejecutivos de TI, el 87 % de los usuarios de microservicios coincidieron en que la adopción de microservicios vale la pena el gasto y el esfuerzo. 

Estos son solo algunos de los beneficios empresariales de los microservicios:

Desplegable de forma independiente

Quizás la característica más importante de los microservicios es que, debido a que los servicios son más pequeños y se pueden implementar de manera independiente, ya no se requiere una ley del Congreso para cambiar una línea de código o agregar una nueva característica en la aplicación.

Los microservicios prometen a las organizaciones un antídoto contra las frustraciones viscerales asociadas a los pequeños cambios que llevan mucho tiempo. No se requiere un doctorado en informática para ver o comprender el valor de un enfoque que facilita mejor la velocidad y la agilidad.

Pero la velocidad no es el único valor de diseñar los servicios de esta manera. Un modelo organizativo emergente común es reunir equipos multifuncionales en torno a un problema, servicio o producto empresarial. 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 una colección de servicios y hacer que operen de manera ágil.

El acoplamiento flexible de los microservicios también genera un grado de aislamiento de fallos y una mejor resiliencia en las aplicaciones. Además, el pequeño tamaño de los servicios, combinado con sus límites y patrones de comunicación claros, hace que sea más fácil para los nuevos miembros del equipo comprender la base del código y contribuir a ella rápidamente, 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 base de datos relacional grande que soporta toda la aplicación. Este enfoque tiene varios inconvenientes obvios, el más importante de los cuales es que todos los componentes de una aplicación deben compartir una pila, un modelo de datos y una base de datos comunes, incluso si existe una herramienta clara y mejor para el trabajo de determinados elementos. Hace que la arquitectura sea mala y es frustrante para los desarrolladores, que siempre saben 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 una combinación de REST, transmisión de eventos y agentes de mensajes, por lo que es posible que la pila de cada servicio individual se optimice para ese servicio. La tecnología cambia constantemente, y una aplicación compuesta de múltiples servicios más pequeños es mucho más sencilla y económica de evolucionar con tecnología más deseable a medida que está disponible.

Escalado preciso

Con los microservicios, los servicios individuales se pueden desplegar individualmente, pero también se pueden escalar individualmente. El beneficio resultante es obvio: cuando se realizan correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas porque permiten un escalado preciso solo de los componentes que lo requieren, en lugar de toda la aplicación en el caso de las aplicaciones monolíticas.

También existen desafíos para los microservicios:

Los beneficios significativos de los microservicios vienen con desafíos significativos. Pasar de un monolito a un microservicio significa mucha más 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 incoherentes 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 puede abordar muchos de estos problemas, pero la adopción de DevOps tiene sus propios desafíos.

Sin embargo, estos desafíos no están impidiendo que los no adoptantes adopten los microservicios, o que los adoptantes profundicen en sus compromisos con los microservicios. Los datos de la encuesta de IBM mencionada revelan que es probable o muy probable que el 56 % de los no usuarios actuales adopten microservicios en los próximos dos años, y que el 78 % de los usuarios actuales de microservicios probablemente aumentarán el tiempo, el dinero y el esfuerzo que han invertido en microservicios.

Los microservicios habilitan y requieren DevOps

La arquitectura de microservicios se describe a menudo como optimizada para DevOps y una integración continua o entrega continua, y en el contexto de pequeños servicios 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. Aunque las aplicaciones monolíticas tienen una serie de inconvenientes que se han analizado anteriormente en este artículo, cuentan con la ventaja de no ser un sistema distribuido complejo con múltiples partes móviles y pilas tecnológicas independientes. Por el contrario, dado el aumento masivo de la complejidad, las partes móviles y las dependencias que vienen con los microservicios, no sería prudente abordar los microservicios sin inversiones significativas en despliegue, monitoreo y automatización del ciclo de vida.

Rosalind Radcliffe ofrece una inmersión más profunda en DevOps en el video:

Herramientas y tecnologías habilitadoras 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 casi definitorias 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 un microservicio, pero "micro" está ahí, en el nombre.

Cuando Docker avanzó en la era de los contenedores modernos 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 subir y bajar más rápidamente, lo que los convierte en una combinación perfecta para los servicios más pequeños y ligeros encontrados en arquitecturas de microservicios.

Con la proliferación de servicios y contenedores, la organizació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 de código abierto, se ha convertido en una de las soluciones de orquestación más populares porque hace ese trabajo muy bien.

API Gateways

Los microservicios a menudo se comunican a través de la API, especialmente cuando se establece su estado por primera vez. Si bien es cierto que los clientes y los servicios pueden comunicarse entre sí directamente, las pasarelas API suelen ser una capa intermedia útil, sobre todo cuando el número de servicios de una aplicación crece con el tiempo. Una puerta de enlace de API actúa como proxy inverso para los clientes mediante el enrutamiento de solicitudes, la extracción de solicitudes en varios servicios y la prestación de seguridad y autenticación adicionales.

Hay varias tecnologías que se pueden utilizar para implementar puertas de enlace de API, incluidas las plataformas de gestión de API, pero si la arquitectura de microservicios se implementa utilizando contenedores y Kubernetes, la puerta de enlace normalmente se implementa con Ingress o, más recientemente, Istio.

Mensajería y transmisión de eventos

Aunque la mejor práctica podría ser diseñar servicios sin estado, el estado existe y los servicios deben ser conscientes de ello. 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 especialmente eficaz de mantenerse al día. Un enfoque de encuestas constantes para mantener actualizados los servicios, del tipo “¿ya llegamos?”, simplemente no es práctico.

En su lugar, es necesario acoplar las llamadas a la API de establecimiento de estado con la mensajería o la transmisión de eventos para que los servicios puedan difundir los cambios de estado y otras partes interesadas puedan escuchar esos cambios y ajustarse en consecuencia. Es probable que este trabajo se adapte mejor a un corredor de mensajes 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. Y, combinando los microservicios con la arquitectura basada en eventos los desarrolladores pueden construir sistemas distribuidos, altamente escalables, tolerantes a fallas y extensibles que pueden consumir y procesar cantidades muy grandes de eventos o información en tiempo real.

Sin servidor

Las arquitecturas sin servidor llevan algunos de los patrones básicos de nube y microservicios 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 se entiende comúnmente que las funciones son incluso más pequeñas que un microservicio.

En lo que las arquitecturas sin servidor y las plataformas de funciones como servicio comparten afinidad con los microservicios es que ambas están interesadas en crear unidades de despliegue más pequeñas y escalar con precisión en función de la demanda.

Microservicios y servicios en la nube

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

Entre los principales beneficios de la arquitectura de microservicios se encuentran los beneficios de utilización y costo asociados al despliegue y escalado de componentes de forma individual. Si bien estos beneficios aún estarían presentes hasta cierto punto con la infraestructura on premises, la combinación de componentes pequeños y escalables de forma independiente junto con una infraestructura de pago por uso bajo demanda es donde se pueden encontrar optimizaciones de costos reales.

En segundo lugar, y quizás más importante, otro beneficio principal de los microservicios es que cada componente individual puede adoptar la pila que mejor se adapte a su trabajo específico. La proliferación de pilas puede generar una gran complejidad y sobrecarga cuando la gestiona usted mismo, pero consumir la pila de soporte como servicios en la nube puede minimizar drásticamente los desafíos de gestión. Dicho de otra manera, aunque no es imposible implementar su propia infraestructura de microservicios, no es recomendable, especialmente cuando se está empezando.

Patrones comunes

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

Patrón de backend-for-frontend (BFF)

Este patrón inserta una capa entre la experiencia del usuario y los recursos a los que llama la experiencia. Por ejemplo, una aplicación utilizada en un escritorio 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 admitir un tipo de back-end por interfaz de usuario utilizando las mejores opciones para esa interfaz, en lugar de intentar admitir un backend genérico que funcione con cualquier interfaz, pero que pueda afectar negativamente al rendimiento del frontend.

Patrones de entidades 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 el nombre, el tipo y el precio del producto. Un agregado es una colección de entidades relacionadas que deben tratarse como una unidad. Así, para el sitio de comercio electrónico, un pedido sería una colección (agregado) de productos (entidades) encargados por un comprador. Estos patrones se utilizan para clasificar los datos de manera significativa.

Patrones de detección de servicios

Estos ayudan a que las aplicaciones y los servicios se encuentren. En una arquitectura de microservicios, las instancias de servicio cambian de forma dinámica debido al escalado, las actualizaciones, los fallos del servicio e incluso el fin del servicio. Estos patrones proporcionan mecanismos de descubrimiento para hacer frente a esta fugacidad. El equilibrio de carga puede usar patrones de detección de servicios mediante el uso de comprobaciones de estado y errores de servicio como desencadenadores para reequilibrar el tráfico.

Patrones de microservicios de adaptador

Piense en los patrones de adaptadores del mismo modo en que piensa en los adaptadores de enchufe que utiliza cuando viaja a otro país. El propósito de los patrones adaptadores es ayudar a traducir relaciones entre clases u objetos que de otro modo serían incompatibles. Una aplicación que depende de API de terceros podría necesitar usar 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 administrar la refactorización de una aplicación monolítica en aplicaciones de microservicios. El original nombre hace referencia a cómo una enredadera (microservicios) poco a poco y con el tiempo supera y estrangula a un árbol (una aplicación monolítica).

Antipatrones

Aunque hay muchos patrones para hacer bien los microservicios, hay un número igualmente significativo de patrones que pueden meter rápidamente en problemas a cualquier equipo de desarrollo. Algunas de estas cosas (reformuladas como “cosas que no se deben hacer” con los microservicios) son las siguientes:

No cree microservicios

Dicho de manera más precisa, no empiece con microservicios. Los microservicios son una forma de administrar la complejidad una vez que las aplicaciones se han vuelto demasiado grandes y difíciles de gestionar para actualizarlas y mantenerlas fácilmente. Solo cuando sienta que el sufrimiento y la complejidad del monolito empiezan a aparecer, merecerá la pena plantearse cómo podría refactorizar esa aplicación en servicios más pequeños. Hasta que no sienta ese sufrimiento, no habrá realmente un monolito que necesite refactorización.

No cree microservicios sin DevOps o servicios en la nube

Crear microservicios significa construir sistemas distribuidos, y los sistemas distribuidos son difíciles, y son especialmente difíciles si se toman decisiones que los hacen aún más difíciles. Intentar realizar microservicios sin una automatización adecuada del despliegue y el monitoreo, o servicios gestionados en la nube para respaldar su infraestructura heterogénea y ahora en expansión, es generar muchos problemas innecesarios. Ahórrese las molestias y podrá dedicar su tiempo a preocuparse por el estado. 

No cree demasiados microservicios haciéndolos demasiado pequeños

Si se excede con el "micro" de los microservicios, puede encontrarse fácilmente con una sobrecarga y una complejidad que superen las ventajas generales de una arquitectura de microservicios. Es mejor inclinarse por servicios más grandes y separarlos solo cuando empiecen a desarrollar características que los microservicios solucionan, es decir, cuando resulte difícil y lento desplegar cambios, cuando un modelo de datos común resulte demasiado complejo o cuando las distintas partes del servicio tengan requisitos de carga/escala diferentes.

No convierta los microservicios en SOA

Los microservicios y la SOA se confunden a menudo entre sí, dado que en su nivel más básico, ambos están interesados en construir componentes individuales reutilizables que puedan ser consumidos por otras aplicaciones. La diferencia entre 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 la SOA se ocupa de cambiar la forma en que los servicios de TI funcionan en toda la empresa. Un proyecto de microservicios que se transforme en un proyecto SOA probablemente se doblará por su propio peso.

No intente ser Netflix

Netflix fue uno de los pioneros de la arquitectura de microservicios al crear y administrar una aplicación que representaba un tercio de todo el tráfico de Internet, una especie de tormenta perfecta que requirió que crearan una gran cantidad de código y servicios personalizados que son innecesarios para la aplicación promedio. Es mucho mejor empezar a un ritmo que pueda soportar, evitar la complejidad y utilizar tantas herramientas estándar como sea posible.

Tutoriales: Desarrollar habilidades de microservicios
Soluciones relacionadas
Red Hat OpenShift on IBM Cloud

Despliegue clústeres Kubernetes altamente disponibles y totalmente administrados para sus aplicaciones en contenedores con un solo clic.

Explore Red Hat OpenShift en IBM Cloud
IBM Cloud Satellite

Despliegue y gestione aplicaciones en contenedores de forma uniforme en entornos locales, de computación edge y de nube pública de cualquier proveedor.

Explore IBM Cloud Satellite
IBM Cloud Code Engine

Ejecute imágenes de contenedores, trabajos por lotes o código fuente como cargas de trabajo sin servidor, sin necesidad de dimensionar, desplegar, establecer redes o escalar

Conozca BM Cloud Code Engine
Recursos ¿Qué es DevOps?

DevOps acelera la entrega de software de mayor calidad, ya que combina y automatiza el trabajo de los equipos de desarrollo de software y operaciones de TI.

¿Qué son los contenedores?

Los contenedores son unidades ejecutables de software que empaquetan el código de la aplicación junto con sus dependencias de bibliotecas, y pueden ejecutarse en cualquier lugar, ya sea en el escritorio, en la TI tradicional o en la nube.

¿Qué es Kubernetes?

Kubernetes es una plataforma de orquestación de contenedores de código abierto que automatiza la implementación, la administración y el escalamiento de aplicaciones en contenedores.

Más allá de las palabras de moda: una breve historia de los patrones de microservicios

Explore el impacto de los patrones de diseño de software anteriores en la creación de microservicios.

Desafíos y beneficios del estilo arquitectónico de microservicios, Parte 1

Explore las dificultades y los desafíos asociados al uso de los microservicios.

Dé el siguiente paso

Red Hat OpenShift on IBM Cloud ofrece a los desarrolladores una forma rápida y segura de contenerizar e implementar cargas de trabajo empresariales en clústeres de Kubernetes. Descargue tareas tediosas y repetitivas que impliquen gestión de seguridad, gestión de cumplimiento, gestión de implementación y gestión continua del ciclo de vida. 

Explore Red Hat OpenShift en IBM Cloud Empiece sin costo