En los años 60 y 70, arquitectura monolítica era el enfoque preferido para desarrollar aplicaciones, debido a los recursos de cómputo limitados de la época, que obligaban a reunir todas las funcionalidades en una sola unidad cohesionada.
Eso cambió a finales de los 90 y en la década de 2000, cuando la estructura monolítica empezó a quedarse corta frente al crecimiento y la complejidad cada vez mayores de las aplicaciones, impulsados especialmente por la expansión de internet y los sistemas distribuidos.
Esto llevó al desarrollo de enfoques más modulares, como las arquitecturas orientadas a servicios (SOA) y, posteriormente, la arquitectura de microservicios (MSA), que acabó consolidándose a principios de la década de 2010.
Dicho esto, lo anterior es solo una introducción básica al concepto y uso de los microservicios. A continuación veremos cómo reemplazaron a la arquitectura monolítica, cómo funcionan y algunos ejemplos prácticos. También abordaremos los aspectos clave de su despliegue y los pasos a seguir si quieres desplegar microservicios.
¿Qué son los microservicios? ¿Cómo funcionan?
Como mencioné antes, los microservicios surgieron como respuesta al aumento de la complejidad y el tamaño de las aplicaciones, permitiendo a las empresas dividir sus funcionalidades en servicios desplegables de forma independiente.
El término «microservicios» fue popularizado por expertos del sector como Martin Fowler y James Lewis, quienes lo introdujeron formalmente en una entrada de blog en 2014. Su trabajo definió principios y características clave: la necesidad de servicios desplegables de forma independiente, la gestión de datos descentralizada y la independencia tecnológica.
Desde entonces, los microservicios se han convertido en una opción arquitectónica de referencia, respaldada por los avances en tecnologías de contenedores como Docker, herramientas de orquestación como Kubernetes y plataformas de computación serverless. Pero ¿cómo funcionan los microservicios?
¿Cómo funcionan los microservicios?
En esencia, una arquitectura de microservicios divide una aplicación grande en servicios más pequeños e independientes, cada uno responsable de una capacidad de negocio concreta. Estos servicios se comunican entre sí a través de la red, normalmente mediante REST APIs, gRPC o brokers de mensajería como RabbitMQ o Apache Kafka.
Según la definición de Martin Fowler y James Lewis, todos los microservicios comparten cuatro características clave:
- Responsabilidad única: Cada microservicio está diseñado para realizar una tarea o función específica, lo que permite la especialización y reduce la complejidad.
- Independencia: Los microservicios pueden desarrollarse, desplegarse y escalarse de forma independiente entre sí, lo que aporta flexibilidad y resiliencia.
- Gestión de datos descentralizada: Los microservicios suelen tener sus propias bases de datos, lo que elimina la dependencia de una única base de datos centralizada.
- Independencia tecnológica: Los equipos pueden elegir la tecnología más adecuada para cada servicio sin estar condicionados por las decisiones tomadas en otros servicios.
Este enfoque contrasta con la arquitectura monolítica tradicional, en la que todos los componentes de la aplicación están estrechamente integrados en una única unidad cohesionada.
Etapas clave del despliegue de microservicios
La arquitectura de microservicios ofrece múltiples ventajas, como alta escalabilidad, flexibilidad, eficiencia y aislamiento de fallos, pero también exige saber cómo desplegarlos correctamente y una planificación cuidadosa para que funcione.
Por eso es fundamental conocer los conceptos clave, las etapas y las buenas prácticas del despliegue de microservicios para lograr una arquitectura exitosa. A continuación, exploramos cada una de esas etapas y lo que implican.
Planificación y preparación del despliegue de microservicios
Todo buen proyecto requiere planificación y paciencia. Desplegar microservicios con éxito no es una excepción: necesitarás dedicar tiempo a planificar y preparar cada detalle. Por eso es importante seguir las buenas prácticas y tener claro todo lo necesario antes de comenzar el despliegue.
Como se mencionó anteriormente, uno de los principios y características clave de los microservicios es el Principio de Responsabilidad Única. Respetar este principio, asegurándose de que cada microservicio se centre y sea responsable de una sola función y capacidad, permite al equipo desarrollar, desplegar y escalar los servicios de forma independiente.
Además, una derivación de este principio es el principio de diseño de acoplamiento débil. Esto significa que cada servicio puede funcionar de forma autónoma en cuanto a comunicación y depende mínimamente de otros servicios. Como resultado, los cambios o actualizaciones en un servicio no afectan a los demás, lo que permite escalar los microservicios de forma independiente.
Esto reduce el riesgo de fallos en cascada, en los que un problema en una parte del sistema desencadena una reacción en cadena que provoca fallos en todo el sistema y termina por derribar el servicio completo.
Una buena práctica en microservicios es asignar almacenamiento de datos dedicado a cada servicio durante el despliegue, como extensión del principio de acoplamiento débil. Esto evita conflictos y mejora la escalabilidad de cada servicio.
Además, necesitarás patrones de comunicación asíncrona entre microservicios, como colas de mensajes, para garantizar que cada servicio pueda comunicarse sin dependencias directas.
El último elemento es implementar pipelines de Integración Continua y Entrega Continua (CI/CD) para microservicios. Estos pipelines permiten a los equipos desplegar nuevas funciones o correcciones mediante herramientas de CI/CD como Jenkins y GitLab, lo que permite a las organizaciones mantener la estabilidad del sistema mientras publican nuevas funcionalidades de forma continua.
Ahora que tienes una visión general de la planificación y preparación necesarias para el despliegue de microservicios, hablemos de las estrategias de despliegue.
Estrategias de despliegue de microservicios
Al desplegar microservicios, la estrategia que elijas depende de la función del servicio, el tráfico, la infraestructura, la experiencia del equipo y los costes. En términos generales, las estrategias de despliegue de microservicios son las siguientes:
- Instancia de servicio por contenedor: En este enfoque, cada microservicio se ejecuta en su propio contenedor, lo que ofrece mejor aislamiento que el modelo de múltiples instancias por host. Los contenedores facilitan el escalado y mejoran la asignación de recursos.
- Instancia de servicio por máquina virtual: Cada servicio se ejecuta en una máquina virtual (VM) independiente, lo que proporciona un aislamiento aún mayor que los contenedores. Aunque esto mejora la seguridad y la estabilidad, generalmente implica una mayor sobrecarga.
- Lanzamientos por fases: Primero, despliega las versiones del microservicio a un pequeño grupo de usuarios para comprobar su estabilidad antes del lanzamiento completo. Esto reduce el impacto ante posibles problemas y permite realizar reversiones rápidas para mantener la integridad del sistema.
- Despliegue azul-verde: Este método utiliza dos entornos de producción idénticos: uno sirve el tráfico real mientras el otro se usa para probar la siguiente versión. El despliegue azul-verde permite reversiones sencillas y actualizaciones sin tiempo de inactividad, ya que el tráfico puede conmutarse entre ambos entornos sin interrupciones.
- Lanzamientos progresivos: Esta estrategia consiste en distribuir las actualizaciones gradualmente entre distintos segmentos de usuarios o entornos. Normalmente comienza en entornos internos antes de llegar a producción, lo que limita el alcance de cualquier problema potencial y permite a los equipos resolverlos por etapas.
- Despliegue sin servidor: Este enfoque se apoya en plataformas serverless como AWS Fargate y Google Cloud Run, que automatizan la gestión de la infraestructura ocupándose del escalado y la asignación de recursos. Con el despliegue serverless, no es necesario administrar los servidores subyacentes, lo que te permite centrarte en tus propios microservicios.
Una vez que hayas elegido una de las estrategias anteriores para desplegar tus microservicios, necesitarás una herramienta de orquestación de microservicios.
Orquestación de microservicios
Después de elegir una estrategia de despliegue de microservicios, necesitarás algo que actúe como director de orquesta para coordinar los microservicios. Las herramientas de orquestación de microservicios, como Kubernetes, ayudan a automatizar el despliegue, el escalado, la monitorización y la gestión de microservicios en contenedores.
Airbnb, por ejemplo, usa Kubernetes, lo que permite a sus ingenieros desplegar cientos de cambios en sus microservicios sin supervisión manual. Una característica clave de herramientas de orquestación como Kubernetes es el balanceo de carga integrado.
Un balanceo de carga eficaz distribuye el tráfico entrante entre múltiples instancias de un microservicio. Esto evita que una sola instancia se convierta en un cuello de botella y mejora la capacidad del sistema para absorber picos de demanda.
Kubernetes desempeña un papel fundamental en la gestión de microservicios gracias a sus capacidades de autocorrección: los contenedores fallidos se reemplazan y reinician automáticamente. The New York Times utiliza esta función para mantener sus microservicios en funcionamiento sin afectar la experiencia del usuario ni sufrir tiempos de inactividad.
Además, Kubernetes refuerza la seguridad de los microservicios gestionando configuraciones y secretos, como credenciales de base de datos o claves API, mediante ConfigMaps y Secrets. Esto es especialmente importante para empresas y servicios como Uber, que manejan información sensible de clientes y usuarios.
Por último, las herramientas de orquestación de microservicios como Kubernetes son especialmente útiles en estrategias que implican actualizaciones progresivas y reversiones, como los lanzamientos progresivos. Las actualizaciones progresivas permiten desplegar nuevas versiones de un microservicio sin interrupciones, manteniendo en funcionamiento algunas instancias de la versión anterior.
Una vez que hayas configurado tu herramienta de orquestación de microservicios, tendrás que construir y automatizar pipelines de CI/CD para el despliegue de microservicios.
Pipelines CI/CD para el Despliegue de Microservicios
Como mencionamos antes, los pipelines de Integración Continua y Entrega Continua son elementos clave en el despliegue de microservicios. La parte de CD del pipeline se encarga de desplegar automáticamente los cambios de código en producción en cuanto superan las fases de pruebas e integración.
A continuación, la parte de CD del pipeline CI/CD entra en acción: cada vez que los cambios de código superan las fases de pruebas e integración, el servicio se despliega en una herramienta de orquestación de microservicios, como un clúster de Kubernetes.
Además, las fases de pruebas e integración se ejecutan de forma completamente automática, ya que el pipeline incorpora pruebas unitarias, pruebas de integración y pruebas end-to-end.
Esto permite a los equipos validar actualizaciones en cada fase sin comprometer la estabilidad del sistema. Por otra parte, si algún cambio de código presenta problemas a pesar de todas las pruebas, los rollbacks automáticos permiten volver a la versión estable anterior.
Por último, implementar pipelines CI/CD para microservicios siguiendo las buenas prácticas del sector ayuda a los equipos a acelerar el desarrollo, reducir errores manuales y mantener estándares de calidad altos.
Empresas como Spotify, Expedia, iRobot, Lufthansa, Pandora, entre otras, utilizan pipelines CI/CD para microservicios con herramientas como CircleCI, AWS CodePipeline y GitLab para automatizar los procesos de despliegue, garantizar una calidad de código consistente y publicar nuevas funcionalidades con rapidez sin sacrificar la estabilidad del sistema.
Patrones de Comunicación en Microservicios
La forma en que los microservicios se comunican entre sí depende por completo de la función de cada servicio, la arquitectura global, la escalabilidad deseada y la fiabilidad de tu sistema. En general, se emplean dos tipos principales de patrones de comunicación: síncrona y asíncrona patrones de comunicación en microservicios.
En los patrones de comunicación síncrona, los servicios interactúan en tiempo real: un servicio envía una solicitud y espera la respuesta antes de continuar. Los patrones síncronos más utilizados son REST (Transferencia de Estado Representacional) APIs, gRPC (Llamada de Procedimiento Remoto de Google), y GraphQL.
Este tipo de patrones de comunicación se utiliza habitualmente en sectores y empresas que necesitan procesamiento de datos en tiempo real y respuestas inmediatas. Industrias como las finanzas, la sanidad y el comercio electrónico recurren a la comunicación síncrona para garantizar que las transacciones, la recuperación de datos o las interacciones ocurran de forma instantánea, ofreciendo así una experiencia de usuario fluida y reactiva.
Dicho esto, aunque los patrones de comunicación síncrona ofrecen ventajas como las respuestas en tiempo real y la simplicidad, también presentan inconvenientes: posibles cuellos de botella por el acoplamiento estrecho, baja escalabilidad bajo cargas elevadas, tiempos de respuesta lentos y alta latencia durante picos de tráfico.
Por otro lado, los patrones de comunicación asíncrona suelen ser más adecuados para microservicios, ya que se basan en el principio de acoplamiento débil que mencionamos anteriormente.
Este tipo de patrón desacopla los servicios al permitirles enviar y recibir mensajes a través de un broker como Kafka o RabbitMQ. Al enviar mensajes a una cola que actúa como buffer, los servicios se comunican de forma independiente sin esperar una respuesta, como ocurriría en la comunicación síncrona. Ese buffer permite que otros servicios procesen los mensajes a su propio ritmo, de modo que el emisor puede continuar con su trabajo sin esperar al receptor.
Los patrones de comunicación asíncrona no solo ofrecen una estructura desacoplada para el despliegue de microservicios, sino que también proporcionan la misma capacidad de respuesta en tiempo real que los patrones síncronos.
Esto se debe a la arquitectura orientada a eventos de los patrones de comunicación asíncrona: los servicios se comunican emitiendo eventos cuando ocurre una acción concreta, y otros servicios pueden suscribirse a esos eventos y reaccionar en consecuencia. El resultado son sistemas altamente reactivos que responden a los cambios en tiempo real sin necesidad de acoplamiento directo entre servicios.
Además, en la comunicación asíncrona Publicación-Suscripción (Pub/Sub) En los patrones de comunicación de microservicios, los servicios (publicadores) envían mensajes a un tema, y otros servicios (suscriptores) escuchan ese tema para recibir actualizaciones. Este modelo admite múltiples suscriptores y puede transmitir mensajes a muchos servicios de forma simultánea.
Por último, al igual que los patrones orientados a eventos, los patrones asíncronos de saga basada en coreografía en comunicación de microservicios también utilizan eventos para comunicarse entre sí; sin embargo, en este patrón existe un orden definido: cada evento desencadena el siguiente paso y activa el servicio correspondiente.
La diferencia es que en los patrones orientados a eventos no hay una secuencia ni un flujo de trabajo fijo, y múltiples servicios pueden reaccionar a un evento, a diferencia del proceso y orden específicos del patrón de saga basada en coreografía.
El patrón de comunicación asíncrona de microservicios que elijas dependerá de la tarea y la función general de tus microservicios. Las colas de mensajes como RabbitMQ y Amazon SQS se utilizan habitualmente para la programación de tareas, la distribución de carga y el comercio electrónico en sistemas de procesamiento de pedidos y notificaciones.
Los brokers de mensajes orientados a eventos, como Apache Kafka y AWS EventBridge, se usan principalmente para procesar flujos de eventos a gran escala en tiempo real y para enrutar eventos entre microservicios en sectores como servicios financieros y entornos AWS.
En cuanto a los brokers de mensajes Publicar-Suscribir (Pub/Sub), como Google Cloud Pub/Sub y Redis Streams, suelen emplearse para mensajería distribuida a gran escala, análisis en tiempo real, ingesta de eventos y aplicaciones de notificaciones y chat en tiempo real.
Por último, los brokers de mensajes de saga basada en coreografía se usan principalmente en procesamiento de pedidos de comercio electrónico, sistemas de reservas de viajes y casos de uso donde es necesario coordinar transacciones complejas y de múltiples pasos entre varios servicios sin un control centralizado.
Descubrimiento de Servicios en Microservicios
Una vez que hayas configurado e implementado un patrón de comunicación que se ajuste a tus necesidades, tendrás que asegurarte de que tus servicios puedan localizarse entre sí. Como mencioné antes, las herramientas de orquestación de microservicios como Kubernetes desempeñan un papel fundamental en el descubrimiento de servicios.
Esto se logra mediante el descubrimiento de servicios integrado que ofrecen Kubernetes y DNS, que actualiza dinámicamente las direcciones IP y los registros DNS a medida que los servicios escalan o cambian de ubicación dentro del clúster.
Este método de descubrimiento de servicios en microservicios se denomina descubrimiento del lado del servidor, ya que la responsabilidad del enrutamiento se delega a un balanceador de carga, que consulta el registro y dirige el tráfico hacia la instancia adecuada.
Por otro lado, también existe el método de descubrimiento del lado del cliente, donde el servicio o la pasarela API consulta un registro de servicios como Consul o Eureka para encontrar las instancias disponibles.
La elección del método de descubrimiento de servicios más adecuado para tu despliegue de microservicios dependerá de los requisitos y la escala del sistema.
Con el descubrimiento de servicios del lado del cliente, el cliente tiene control total sobre con qué instancia se comunica. Esto no solo permite mayor personalización, sino que también reduce la complejidad, ya que no se necesita un servicio de descubrimiento centralizado.
Por ejemplo, el despliegue de microservicios de Netflix utiliza el descubrimiento del lado del cliente con Eureka y Ribbon para el balanceo de carga, lo que permite al cliente elegir la mejor instancia según criterios como la latencia y la carga del servidor.
Sin embargo, el descubrimiento de servicios del lado del servidor es más adecuado para entornos de mayor escala, ya que un servicio de descubrimiento centralizado puede mejorar la eficiencia y garantizar un balanceo de carga consistente en sistemas distribuidos.
Soluciones de descubrimiento del lado del servidor como Kubernetes, AWS Elastic Load Balancing y las pasarelas API (Kong, NGINX, etc.) permiten enrutar el tráfico de forma eficiente y mantener una alta disponibilidad. Las utilizan empresas como Airbnb, Pinterest, Expedia y Lyft, entre otras.
Seguridad en Microservicios
Aunque la arquitectura monolítica es inferior a la MSA en la mayoría de los aspectos, la seguridad era uno de sus puntos fuertes. Dado que los microservicios se basan en el principio de acoplamiento débil y son distribuidos por naturaleza, no es posible implementar una única medida de seguridad general.
Como cada servicio debe protegerse de forma independiente, se necesitan salvaguardas adicionales, ya que la superficie de ataque es mucho mayor en microservicios. Para ello, estándares como OAuth2 y los tokens JSON Web (JWT) se utilizan habitualmente para autenticación y autorización.
Además, una pasarela API también se emplea con frecuencia para gestionar la seguridad en los microservicios, ya que aplica la autenticación y autorización en el punto de entrada. Las pasarelas API también pueden implementar limitación de velocidad, registro de actividad y monitorización, lo que añade capas adicionales de seguridad.
Si bien estas medidas protegen el punto de entrada principal, son necesarias más medidas de seguridad para cubrir la comunicación entre servicios.
Aquí es donde entran en juego los service meshes: añaden una capa de seguridad de red para los microservicios, cifran el tráfico entre servicios y aplican políticas como la autenticación mutua TLS. Básicamente, estos service meshes establecen un cifrado extremo a extremo completo que mejora considerablemente la seguridad de los microservicios.
Escalado de microservicios
Una de las principales ventajas de la MSA, y la razón por la que se desarrolló para sustituir a la arquitectura monolítica, es su alta capacidad de escalado. Generalmente, el escalado de microservicios puede producirse de dos formas: vertical y horizontal.
En términos generales, el escalado vertical de microservicios (scale up) consiste en añadir más recursos, como CPU o memoria, a una instancia existente. El escalado horizontal (scale out), por su parte, distribuye la carga y aumenta la capacidad.
En cuanto a la implementación, el escalado vertical es el más sencillo de los dos, ya que solo requiere modificar una única instancia: actualizar a un servidor más potente, aumentar la memoria o la capacidad de procesamiento en una instancia cloud, o ampliar el almacenamiento.
Este tipo de escalado se utiliza habitualmente en casos donde aumentar la RAM o la potencia de CPU puede mejorar el rendimiento de las consultas y el procesamiento de datos, como en servicios encargados del caché en memoria.
Dicho esto, aunque el escalado vertical es más sencillo y ofrece una mejora de rendimiento inmediata, también tiene sus limitaciones. Está acotado por la capacidad hardware del servidor, por lo que en algún momento necesitarás pasarte al escalado horizontal para seguir creciendo.
Además, el escalado vertical conlleva costes elevados, ya que el hardware y las instancias más grandes suelen tener un precio alto. Por último, si la instancia escalada falla, el servicio cae por completo, ya que no hay instancias adicionales que absorban la carga.
En el escalado horizontal de microservicios, en lugar de ampliar los recursos de una única instancia, se despliegan nuevas instancias de ese servicio. Aunque estas instancias funcionan de forma independiente, todas atienden el mismo servicio y partes de la misma carga de trabajo.
A diferencia del escalado vertical, el escalado horizontal de microservicios no tiene límite: puedes añadir tantas instancias como necesites para gestionar cargas de trabajo crecientes y picos de tráfico, lo que ofrece una mayor capacidad de escalado.
Además, al contar con varias instancias, si una falla no te quedas sin servicio, ya que las demás siguen atendiendo las peticiones. Por último, el escalado horizontal resulta mucho más rentable a largo plazo, ya que puedes combinar varias instancias más pequeñas y económicas para obtener un rendimiento más fiable y potente.
Sin embargo, el escalado horizontal y la incorporación de más instancias requieren más balanceadores de carga, mecanismos de service discovery y herramientas de orquestación de microservicios, lo que aumenta considerablemente la complejidad de tu arquitectura.
El escalado horizontal se adapta mejor a casos de uso como servicios web y aplicaciones de comercio electrónico o redes sociales, que suelen experimentar tráfico variable y un alto volumen de peticiones.
Dicho esto, no se trata realmente de elegir uno u otro, ya que ambos tipos de escalado son compatibles con los microservicios y necesarios en muchas situaciones. Normalmente, las organizaciones más pequeñas optan por el escalado vertical por ser más sencillo de implementar y gestionar, pero con el tiempo, a medida que la aplicación crece, se introduce el escalado horizontal para hacer frente a la mayor demanda.
Por último, las plataformas cloud ofrecen servicios de auto-scaling que añaden o eliminan instancias automáticamente según la demanda en tiempo real, lo que ayuda considerablemente a las organizaciones a equilibrar el escalado vertical y horizontal.
Monitorización de microservicios
En este punto, el despliegue de tus microservicios está prácticamente completado. Solo queda asegurarse de que funcione de forma consistente y fiable. Para eso están las herramientas de monitorización de microservicios como Prometheus y Grafana .
Estas herramientas proporcionan información en tiempo real sobre las métricas de los servicios, de modo que los equipos pueden hacer seguimiento del uso de recursos, la latencia y las tasas de error. Además, ofrecen trazado distribuido (Jaeger, Zipkin, etc.), que ayuda a visualizar el flujo de peticiones entre servicios y resulta enormemente útil para diagnosticar problemas.
Por último, dado que los fallos pueden propagarse entre servicios debido al diseño distribuido de los microservicios, la agregación de logs es una práctica fundamental en su monitorización. Al centralizar los logs en una plataforma unificada y configurar alertas en tiempo real, siempre irás un paso por delante de los problemas y podrás anticiparte a ellos antes de que afecten a los usuarios.
Conclusiones
El mundo de los microservicios no es sencillo de entender, pero conocer los fundamentos y las etapas clave del despliegue puede facilitar mucho todo el proceso. Además, con el paso del tiempo, dispones de cada vez más herramientas con más funcionalidades, lo que hace que desplegar microservicios sea más accesible que nunca.
Preguntas frecuentes
¿Qué estrategias de despliegue se utilizan habitualmente en microservicios?
Aunque existen muchas estrategias distintas para el despliegue de microservicios, las más utilizadas son: instancias de servicio por contenedor, lanzamientos graduales, despliegue blue-green y despliegue serverless. Cada una ofrece distintos niveles de aislamiento, flexibilidad y capacidad de escalado.
¿Qué papel desempeña Kubernetes en la orquestación de microservicios?
Los microservicios dependen de herramientas de orquestación como Kubernetes para automatizar el despliegue, el escalado y la gestión de servicios en contenedores. Estas herramientas ofrecen balanceo de carga, escalado automático y autocorrección para garantizar microservicios resilientes y eficientes.
¿Cómo puedo garantizar la seguridad en un entorno de microservicios?
Por su naturaleza distribuida, la seguridad en los microservicios es más compleja que en la arquitectura monolítica. Implica autenticar y autorizar solicitudes, cifrar la comunicación entre servicios, e implementar pasarelas API y mallas de servicios como Istio para una gestión centralizada de la seguridad.
