Contenido del curso
Costos ocultos de los microservicios
Las arquitecturas orientadas a microservicios se han convertido en una de las decisiones más populares para resolver problemas de rendimiento y complejidad en software. Aquí entenderás cómo funcionan, qué costos ocultos traen y por qué un arquitecto debe pensar dos veces antes de adoptarlas.
¿Qué son las arquitecturas de microservicios y cómo funcionan?
La idea se resume en una frase: uno para todos y todos para uno. Cada microservicio resuelve un único problema, y otros servicios se apoyan en él para construir un contexto global.
Este estilo divide la solución en piezas pequeñas y especializadas. Cada pieza tiene su propio dominio, su propio equipo y, muchas veces, su propio ciclo de despliegue. Eso suena perfecto sobre el papel, pero trae consecuencias reales.
¿Qué es un microservicio? Es un servicio independiente que resuelve un único problema dentro de un sistema más grande, y que se comunica con otros servicios a través de contratos definidos.
La primera consecuencia es la carga cognitiva distribuida: necesitas saber qué hace cada servicio y qué microproblema resuelve. La segunda es la comunicación distribuida, porque varios equipos trabajan simultáneamente en distintos problemas, muchas veces de forma asíncrona, con ventanas de efectividad diferentes.
¿Por qué la independencia entre equipos es una ventaja clave?
Trabajar de forma independiente tiene virtudes claras. Puedes avanzar sin depender de otros servicios o equipos, siempre que los contratos entre servicios se mantengan estables.
Imagina un cliente que consume varios microservicios desplegados por equipos distintos. Mientras el contrato no cambie, cada equipo puede iterar a su ritmo, lanzar versiones nuevas y reemplazar comportamientos sin romper al resto.
¿Cuáles son los costos ocultos de los microservicios?
Uno de los principales problemas es que existen costos que solo aparecen en producción. No hay tal cosa como un almuerzo gratis: cada decisión arquitectónica se paga.
Estos son los costos más frecuentes que enfrentan los equipos:
¿Cuál es el costo más subestimado en microservicios? El intercambio de datos entre servicios. La transferencia se cobra por proveedor y crece rápido cuando hay alta demanda o despliegues multirregión.
En 2015, Netflix mostró una gráfica con las dependencias entre sus microservicios. Eran tantas decenas de conexiones que el diagrama resultaba casi indescifrable, y seguir un solo caso de uso a través de esa red era extremadamente difícil. Es un buen recordatorio de hasta dónde puede crecer la complejidad.
¿Qué ventajas técnicas justifican adoptar microservicios?
Más allá de la independencia, hay beneficios concretos que muchos equipos buscan:
Esta capacidad de innovar es valiosa, pero también obliga a un arquitecto a equilibrar libertad tecnológica con consistencia operativa.
¿Cómo aproximarte a tu primera arquitectura de microservicios?
Una buena forma de empezar es usar el modelo C4 para trabajar en dos niveles de abstracción.
El primer nivel describe el sistema completo: qué hace, quién lo usa y con qué se comunica. El segundo describe los contenedores desplegables: las unidades concretas que ejecutan tu solución, como aplicaciones, bases de datos o servicios.
Al dibujar tu propuesta, hazte una pregunta clave: ¿a qué estilo arquitectónico se parece tu primera aproximación? ¿Es realmente microservicios o se acerca más a un monolito distribuido? Cuéntame tu respuesta en los comentarios y comparte tu diagrama con la comunidad.
Miguel Angel Otero Otero
Estudiante
José Cárdenas
Estudiante
Miguel Angel Reyes Moreno
Estudiante
Kevin Fiorentino
Estudiante
Juan Felipe Rodriguez Valencia
Estudiante
Gustavo García
Estudiante
Gabriel Obregón
Estudiante
Christopher Ramos Hidalgo
Estudiante
Hugo Armando Talledos Rodríguez
Estudiante
Víctor Rolack
EstudianteKevin Fiorentino
EstudianteJosé Cárdenas
Estudiante
Federico Arias
Estudiante
John Eduard Meneses González
Estudiante
Humberto Cruz
Estudiante
Isaac González
Estudiante
jefred bedoya
Estudiante
MARIA TERESA PANIAGUA RIVERA
Estudiante
Lissete Plata Montejano
EstudiantePara gestionar la dependencia entre microservicios y mantener un bajo acoplamiento, considera las siguientes estrategias:
Contratos claros: Define interfaces bien documentadas que cada microservicio debe cumplir, lo que permite que los servicios cambien sin afectar a otros.
Comunicación asíncrona: Utiliza colas o eventos en lugar de llamadas sincrónicas, lo que disminuye las dependencias directas y mejora la resiliencia.
Despliegue independiente: Asegúrate de que cada microservicio pueda actualizarse y desplegarse sin afectar a los demás.
Monitoreo y trazabilidad: Implementa herramientas que te ayuden a rastrear las interacciones entre microservicios, facilitando la identificación de problemas y cuellos de botella.
Estas prácticas ayudan a gestionar la complejidad y a minimizar el impacto de los cambios en un sistema distribuido.
Netflix utiliza múltiples microservicios para manejar su complejidad y escalabilidad. Algunos ejemplos incluyen:
Estos microservicios ayudan a Netflix a resolver problemas de rendimiento y escalabilidad, permitiendo un despliegue y actualización independiente.
Ejemplo de un trello con microservicios:
microservices-app/
├── user-service/
│ ├── src/
│ │ └── index.ts
│ │ └── user.controller.ts
│ └── package.json
├── task-service/
│ ├── src/
│ │ └── index.ts
│ │ └── task.controller.ts
│ └── package.json
├── shared/
│ └── types.ts # Interfaces compartidas entre servicios
├── docker-compose.yml
└── README.md
Estoy de acuerdo, implementaria un microservicio para usuarios, otro para tasks, purchases, theme, etc.
Pero, así como planteas el diagrama, entiendo que tienes todo metido en el mismo repositorio. Puede llegar a escalar a 50 microservicio y tendrás que dividirlo en diferentes repos. Sería conveniente que /shared sea un paquete privado en NPM, para compartirlo.
Imagina que construir una casa es como crear un software. En lugar de hacer una gran casa de una sola pieza, puedes hacer muchas casitas pequeñas. Cada casita tiene una función específica, como la cocina, el baño o la sala. Esto es lo que hacemos con los microservicios.
Cada microservicio es una casita que puede funcionar por sí sola, pero todas se conectan para hacer una gran casa. Esto significa que si quieres mejorar solo la cocina, puedes hacerlo sin afectar el baño. Sin embargo, si todas las casitas hablan entre sí, a veces puede ser complicado entenderse, ¡como cuando los amigos se gritan desde diferentes habitaciones!
Estuve conversando con Grok sobre arquitecturas y en algún punto de la conversación me dijo esto que les comparto y que me pareció interesante, por lo menos.
“Nunca empieces con microservicios a menos que ya hayas fracasado estrepitosamente con un monolito por límites de escalabilidad o dominio” (Y ese fracaso normalmente llega con > 50-100 millones de usuarios o > 15-20 equipos de desarrollo)
🎯Arquitecturas Orientadas a Microservicios
🌐 1. Concepto General
📖 Definición: Dividen sistemas complejos en módulos pequeños e independientes llamados microservicios.
👥 Objetivo: Permitir que los equipos trabajen de forma autónoma, coordinándose solo mediante contratos de comunicación claros.
💬 Idea central:
“Uno para todos y todos para uno” Cada microservicio cumple una función específica, pero todos colaboran en el sistema completo.
⚙️ 2. Características Clave
🔹 Resuelven problemas concretos.
🔹 Varios servicios pueden depender de uno solo para lograr un objetivo mayor.
🔹 Facilitan el despliegue independiente y la gestión por versiones.
🔹 Fomentan escalabilidad, modularidad y flexibilidad.
🧱 Piensa en cada microservicio como una pieza de LEGO: independiente, pero diseñada para encajar con las demás.
🚀 3. Beneficios Principales
✨ Autonomía total de desarrollo y despliegue.
⚡ Avance simultáneo de múltiples equipos.
🧪 Integración de nuevas tecnologías sin afectar al sistema global.
🔄 Versionado paralelo: distintas versiones pueden convivir sin conflicto.
💡 Esto acelera la innovación y reduce los tiempos de entrega.
⚠️ 4. Costos y Desafíos
🧠 Carga cognitiva: cada equipo debe conocer su servicio y su papel dentro del sistema.
☁️ Costos en la nube: la transferencia de datos entre microservicios puede ser costosa.
🕸️ Complejidad de comunicación: la comunicación distribuida (especialmente asíncrona) puede generar errores difíciles de rastrear.
🧩 Rastreo de dependencias: entender cómo interactúan todos los servicios puede volverse complicado.
🔎 La libertad técnica exige una gestión rigurosa.
🔄 5. Comunicación Distribuida
📡 Asincronía: los equipos trabajan con diferentes ritmos y horarios.
🌍 Distribución geográfica: los servicios pueden estar alojados en distintas regiones.
💰 Costos ocultos: la transferencia de datos a gran escala puede aumentar el gasto en producción.
🧭 Planificar la comunicación desde el diseño es esencial para evitar cuellos de botella.
Una consulta, si los microservicios te ofrecen HA(high avalavility) y los clientes siempre desean que sus sistemas tengan HA así solo tengan 1 usuario, porque no empezar a crear el sistema con microservicios¿?
Además siempre en la literatura dice que se debe de empezar siempre con un monolito y luego cuando crezca pensar en alguna otra arquitectura, pero para la HA que siempre siempre debe estar. Esto viene a ser algo contradictorio.
Por lo general esta relacionado con el costo de infraestructura que viene de la mano con los microservicios
Un monolito puede alcanzar perfectamente alta disponibilidad (HA) mediante despliegues en múltiples instancias tras un balanceador de carga, con mecanismos de failover y redundancia adecuados. Por lo tanto, no es necesario aplicar microservicios sí o sí para lograr alta disponibilidad.
Además, antes de considerar usar microservicios, hay varios puntos importantes, como el presupuesto. ¿El cliente cuenta con el dinero suficiente para costearlo? Una arquitectura basada en microservicios puede ser mucho más costosa que una con monolito, debido a que requiere mayor uso de recursos computacionales (como Kubernetes para orquestarlos), más pipelines, servicios de observabilidad para monitorear su comportamiento, e incluso puede implicar incorporar más equipos de desarrollo si el número de microservicios crece. Para una sola persona o un equipo pequeño, esto puede volverse pesado de mantener y desarrollar.
Una infraestructura compleja, en la mayoría de los casos, resulta mucho más costosa.
Otro punto a considerar es el contexto del cliente. Puede ser que, para un proyecto pequeño o una empresa que recién comienza, un monolito bien hecho (sí, uno que aplique buenas prácticas y una arquitectura sólida que permita un crecimiento sano del código, como veremos más adelante en el curso) alcance estándares de disponibilidad bastante buenos sin caer en sobreingeniería.
Usar monolitos puede parecer contradictorio con la idea de HA, pero no lo es. La literatura no está equivocada: se recomienda partir por un monolito bien estructurado, con módulos claramente definidos, para que, si en el futuro se detecta una sobrecarga o un límite claro, se pueda extraer ese módulo y convertirlo —ahora sí— en un microservicio.
Los microservicios pueden ser geniales, pero siguen atados a su contexto. Y como dice el profesor: la mejor solución es la que funciona. Si es un monolito, bien. Si son microservicios, también.
Saludos bro :)
No es lo mismo tener una API con N módulos, que que cada uno de esos módulos sea un microservicio por separado. En el pasado implementé Apache Kafka y NestJS para seguir esta arquitectura donde cada microservicio es independiente. Ahí fue donde nos dimos cuenta de lo costoso que iba a ser para un simple servidor AWS hostear eso con Docker. No nos daba economicamente para más. Fue mejor implementar dos o tres API por separado, cada una con una responsabilidad diferente. Pero lejos de ser microservicios.
Algunos ejemplos de productos que utilizan arquitecturas de microservicios son:
Netflix: Utiliza microservicios para manejar su vasto catálogo de contenido, permitiendo a diferentes equipos trabajar en funcionalidades específicas como recomendaciones o streaming.
Amazon: Su plataforma de comercio electrónico se basa en microservicios, lo que permite la implementación de características como el carrito de compras, procesamiento de pagos y gestión de inventario de forma independiente.
Spotify: Implementa microservicios para gestionar la reproducción de música, listas de reproducción y recomendaciones personalizadas, facilitando el trabajo simultáneo de varios equipos.
Estos ejemplos demuestran cómo los microservicios pueden aumentar la agilidad y escabilidad en grandes sistemas.
no me queda clara la diferencia entre la arquitectura basada en microservicios vs. basada en eventos y arquitectura basada en microservicios vs. basada en servcios. son mutualmente excluyentes_
No son excluyentes; son complementarios. Microservicios define cómo divides el sistema. Eventos define cómo se comunican (asíncronamente). Servicios (SOA) es un predecesor más robusto con contratos estrictos. ¡Puedes combinarlos
🏗️ Estilo Arquitectónico Asociado
Microservicios con orquestación basada en eventos, por las siguientes razones:
🎯 Valor Estratégico del Diseño
La arquitectura de servicios distribuidos y la arquitectura de microservicios son conceptos relacionados, pero no son lo mismo.
La arquitectura de servicios distribuidos se refiere a un enfoque más amplio donde diferentes servicios pueden comunicarse y colaborar a través de redes. Esto incluye sistemas que pueden ser monolíticos o basados en microservicios.
Por otro lado, la arquitectura de microservicios es un tipo específico de arquitectura de servicios distribuidos que se enfoca en dividir aplicaciones en pequeños servicios independientes, cada uno abordando una funcionalidad específica. Esto permite escalabilidad y flexibilidad, pero también introduce desafíos en cuanto a la gestión de la comunicación y las dependencias entre servicios.
¿Cuándo debo elegir implementar microservicios?
Debes dar el salto a microservicios cuando el tamaño de tu equipo y la complejidad del dominio superan la capacidad de un sistema monolítico. Si tienes a 50 desarrolladores pisándose los talones en el mismo repositorio, generando conflictos de código a diario y tardando semanas en coordinar un pase a producción, es el momento ideal.
No lo hagas solo por moda. Utiliza esta arquitectura cuando necesites escalabilidad independiente. Por ejemplo, si en un e-commerce el módulo de procesamiento de imágenes consume demasiada memoria RAM pero el carrito de compras solo necesita CPU, separarlos te permite asignar recursos de hardware específicos a cada uno. Es una decisión organizacional tanto como técnica: te conviene cuando necesitas que múltiples equipos trabajen de forma autónoma, asíncrona y con ciclos de liberación rápidos, asumiendo que estás dispuesto a pagar el precio de una mayor complejidad operativa.
Arquitectura de Microservicios: Realidades y Costos
Ventajas Clave
Costos y Desafíos Ocultos
gracias
Ejemplo práctico:
En la industria (ej. un banco), la arquitectura orientada a microservicios separa el sistema en servicios por dominio (Transferencias, Ledger, Fraude, Auditoría). Y para que no queden acoplados con llamadas directas entre todos, se apoya en arquitectura orientada a eventos (clase anterior): un microservicio produce un evento como “Transferencia aprobada” en un bus (ej. Kafka) y otros microservicios lo consumen y reaccionan a su ritmo. Así se ve que no son excluyentes: microservicios = quién hace qué; eventos = cómo se coordinan sin dependerse
