Es difícil asistir hoy a una presentación técnica de una startup sin escuchar la palabra "microsservicios". El término se volvió sinónimo de modernidad, escalabilidad y buenas prácticas de ingeniería. El problema: para la mayoría de las startups en etapa inicial, los microsservicios son la elección equivocada, y esa elección tiene un costo que aparece en la velocidad de entrega semanas, no años, después.
Qué son los microsservicios
Microsservicios es un estilo arquitectónico en el que una aplicación se compone de servicios pequeños e independientes, cada uno ejecutando su propio proceso y comunicándose vía APIs o mensajes. Cada servicio es responsable de una capacidad de negocio específica y puede desarrollarse, desplegarse y escalarse de forma independiente.
Esa definición suena atractiva. Lo que la definición no incluye: el overhead operativo, la complejidad de la comunicación distribuida, la necesidad de infraestructura especializada y el costo cognitivo de mantener múltiples sistemas que necesitan funcionar en conjunto.
Por qué Netflix, Amazon y Google lo hacen
El origen popularizado de los microsservicios viene de empresas como Netflix y Amazon, que migraron de monolitos a servicios distribuidos a medida que crecían. La lección que muchas startups sacan: "Si les funciona a ellos, debería empezar así."
El razonamiento ignora el contexto. Netflix migró desde un monolito que estaba frenando el crecimiento con cientos de ingenieros y décadas de deuda. Amazon tiene equipos de plataforma dedicados a abstraer la complejidad de los servicios distribuidos.
Tú estás con 3 a 8 ingenieros intentando validar un producto en el mercado. El contexto es radicalmente diferente.
El costo que nadie cuenta
Cuando una startup de 5 ingenieros elige microsservicios, esto es lo que ocurre:
- El deploy se vuelve complejo inmediatamente. Necesitas coordinar deploys de múltiples servicios, versionar APIs entre ellos y garantizar compatibilidad backward. Lo que era un deploy se convierte en una operación de orquestación.
- El debugging requiere rastreo distribuido. Un bug que antes exigía un stack trace ahora requiere correlacionar logs de 4 servicios diferentes para entender qué pasó.
- Los tests de integración explotan en complejidad. Garantizar que los servicios funcionan juntos exige infraestructura de test local sofisticada o entornos de staging que cuestan.
- Toda feature nueva involucra múltiples repositorios. Un cambio que sería una PR se convierte en 3 PRs coordinadas en repositorios diferentes, con dependencias entre ellas.
- La curva de onboarding de nuevos ingenieros aumenta. Entender el sistema como un todo requiere entender múltiples contextos, no uno.
Cuándo los microsservicios tienen sentido
Los microsservicios resuelven problemas reales: los problemas de las empresas que los crearon. Tienen sentido cuando:
- Equipos independientes necesitan desplegar y escalar partes del sistema sin coordinación
- Partes del sistema tienen requisitos de escala radicalmente diferentes (una API de búsqueda que necesita escalar 100x más que el CRUD de registro)
- La empresa tiene plataforma de infraestructura propia capaz de absorber la complejidad operativa
- El producto es lo suficientemente maduro como para que los límites de los dominios de negocio estén claros
Ninguno de esos criterios aplica a una startup de menos de 50 ingenieros que todavía está encontrando su product-market fit.
El monolito modular: el término medio que mucha gente ignora
Entre "monolito legacy desorganizado" y "microsservicios distribuidos", existe una opción que combina los beneficios de ambos: el monolito modular.
Un monolito modular es un único sistema, pero con fronteras de dominio claras internamente. Cada módulo tiene su propia capa de datos, interfaces bien definidas, y puede desarrollarse casi de forma independiente, pero sin la complejidad de comunicación distribuida ni el overhead operativo de múltiples servicios.
Cuando el producto crezca y se alcancen los límites de escala del monolito, extraer servicios es mucho más fácil cuando el código interno ya está bien organizado por dominio.
El patrón que funciona
El patrón que veo funcionar para startups en crecimiento es consistente: empezar con un monolito modular bien hecho, crecer hasta sus límites naturales (que son mayores de lo que la mayoría imagina) y extraer servicios quirúrgicamente donde la necesidad técnica lo justifique.
La decisión de extraer un servicio debe venir de un problema real, no de una preferencia arquitectónica ni de una aspiración de parecer más "enterprise". Problemas reales incluyen: equipos que necesitan desplegar independientemente, componentes con requisitos de escala radicalmente diferentes, o partes del sistema que necesitan un stack técnico diferente.
Empezar con microsservicios por defecto es cambiar problemas del futuro por problemas del presente. Y los problemas del presente, para las startups, cuestan más caros.
