Definición rápida
Los Microservicios son un estilo de arquitectura de software donde una aplicación se construye como un conjunto de servicios pequeños e independientes, cada uno ejecutándose en su propio proceso y comunicándose a través de APIs, permitiendo escalar y desplegar cada componente de forma autónoma.
¿Qué son los Microservicios?
Imagina una aplicación monolítica como una sola pieza de código enorme donde el catálogo de productos, el sistema de pagos, el servicio de notificaciones y el módulo de inventario están todos mezclados. Cambiar el sistema de pagos requiere desplegar toda la aplicación. Si hay un bug en notificaciones, puede caer toda la plataforma.
Los Microservicios resuelven esto dividiendo esa aplicación en servicios independientes: el servicio de catálogo, el servicio de pagos, el servicio de notificaciones. Cada uno tiene su propia base de datos, su propio ciclo de deployment, y su propio equipo. Se comunican entre sí a través de APIs REST o mensajería asíncrona.
El término fue popularizado por Martin Fowler y James Lewis en 2014, aunque la arquitectura ya existía antes. Netflix fue uno de los pioneros —cuando migraron de monolito a microservicios alrededor de 2009, pasaron de deployments trimestrales a miles de deployments diarios.
¿Cómo funcionan los Microservicios en la práctica?
Los Microservicios requieren infraestructura específica para funcionar bien:
- Contenedores: Cada microservicio corre en un contenedor Docker, que lo hace portátil y consistente entre ambientes.
- Orquestación: Kubernetes gestiona el despliegue, escalado y recuperación automática de los contenedores.
- API Gateway: Un punto de entrada único que enruta las solicitudes al microservicio correcto.
- Service Discovery: Los servicios se encuentran entre sí dinámicamente (ej: Consul, Eureka).
- Observabilidad: Logging centralizado, distributed tracing y métricas para entender el comportamiento del sistema distribuido.
Ejemplos reales en LATAM
Mercado Libre (Argentina): MeLi fue uno de los primeros en LATAM en adoptar microservicios a gran escala. Hoy tienen miles de microservicios independientes que permiten a equipos autónomos desarrollar y desplegar sin coordinación central.
Nubank (Brasil): La arquitectura de Nubank está basada en microservicios desde sus inicios, lo que les ha permitido escalar de 0 a 90M+ de clientes manteniendo alta disponibilidad.
Rappi (Colombia): La super-app necesitaba microservicios para escalar en múltiples países simultáneamente, con servicios independientes por vertical (restaurantes, mercado, farmacias).
Microservicios vs Monolito
| Característica | Microservicios | Monolito |
|---|---|---|
| Escalabilidad | Por servicio individual | Toda la aplicación |
| Deployment | Independiente por servicio | Todo junto |
| Fallo | Aislado al servicio | Puede afectar todo |
| Complejidad | Alta (distribuida) | Baja inicialmente |
| Ideal para | Sistemas grandes, equipos grandes | Startups tempranas |
Errores comunes con Microservicios
- Adoptar microservicios prematuramente: Para una startup con 3 developers y 1,000 usuarios, un monolito es más productivo. Los microservicios añaden complejidad operacional que no se justifica temprano.
- Microservicios demasiado granulares: Dividir demasiado crea una explosión de servicios con demasiada comunicación entre ellos (chattiness).
- Ignorar la consistencia de datos: Sin transacciones distribuidas bien diseñadas, los datos pueden quedar inconsistentes entre servicios.
- No invertir en observabilidad: Sin buenas herramientas de logging y tracing, debuggear un sistema de microservicios es una pesadilla.
Preguntas Frecuentes (FAQ)
¿Cuándo debería migrar de monolito a microservicios?
Señales de que es hora: el deployment es doloroso y frecuente fuente de bugs, diferentes partes del sistema tienen requerimientos de escala muy distintos, los equipos están pisándose entre sí al trabajar en el mismo codebase. No migres por hype —migra cuando el pain sea real.
¿Los microservicios requieren obligatoriamente Kubernetes?
No. Puedes correr microservicios en AWS ECS, Azure Container Instances, o incluso en VMs tradicionales. Kubernetes añade complejidad pero ofrece más poder para gestión de contenedores a escala.
¿Qué es un «distributed monolith» y por qué es peor?
Un distributed monolith es cuando divides el código en servicios separados pero estos están tan acoplados (se llaman síncronamente, comparten base de datos) que no puedes deployarlos de forma independiente. Tienes la complejidad de los microservicios sin sus beneficios.
