Tu MVP no necesita microservicios: guía de un director técnico para dimensionar adecuadamente la arquitectura

En los últimos tres años hemos auditado el código fuente de más de 30 startups. El patrón más habitual: una arquitectura diseñada para 10 millones de usuarios, pero que solo da servicio a 500.

Una startup que aún no genera ingresos, con un clúster de Kubernetes, 12 microservicios, una cola de mensajes, una malla de servicios y una factura de infraestructura de 3000 dólares al mes. ¿Su competidor? Una aplicación monolítica de Django en un servidor de 50 dólares al mes, que lanza nuevas funciones cuatro veces más rápido.

La sobredimensionación no solo supone un derroche de dinero. También desperdicia el único recurso que las startups no pueden comprar: el tiempo.

Instagram prestaba servicio a 300 millones de usuarios mediante una arquitectura monolítica basada en Django. Shopify funciona con una arquitectura monolítica basada en Rails. Stack Overflow atiende a 100 millones de visitantes al mes mediante una arquitectura monolítica basada en .NET en nueve servidores web.

Una aplicación monolítica bien diseñada con PostgreSQL y Redis gestiona más tráfico del que el 99 % de las startups llegarán a tener jamás. El cuello de botella no es tu arquitectura, sino tus consultas a la base de datos, tus problemas N+1 y la falta de una capa de caché.

Extrae un servicio cuando notes el problema, no antes:

1. Dificultades derivadas del crecimiento del equipo. Si hay más de diez desarrolladores trabajando al mismo tiempo en el mismo código, tiene sentido dividirlo en dos o tres servicios con responsabilidades claras.

2. Dependencia de implementación. Si la implementación del sistema de notificaciones requiere implementar toda la aplicación y ejecutar todas las pruebas, separa las notificaciones en un servicio independiente.

3. Diferentes necesidades de escalabilidad. Si el procesamiento de imágenes requiere 10 veces más potencia de cálculo que tu API, separarlo te permite escalar cada uno de forma independiente.

4. Ritmos de lanzamiento diferentes. Si el equipo de facturación realiza lanzamientos semanales, pero el producto principal lo hace a diario, contar con servicios independientes permite que cada equipo trabaje a su propio ritmo.

Si hoy en día ninguna de estas situaciones se aplica a tu caso, no necesitas microservicios. Y punto.

Tras haber creado más de 65 productos, esta es nuestra recomendación habitual para un MVP:

Esta pila gestiona 100 000 usuarios al mes, cuesta menos de 100 dólares al mes y puede ser mantenida por un solo desarrollador. Cuando sea necesario ampliarla, todos los componentes se pueden actualizar sin necesidad de reescribirlos.

En las más de 50 reuniones de diligencia debida en las que hemos prestado apoyo, los inversores nunca preguntaron: «¿Utilizan microservicios?». Lo que preguntaron fue:

1. ¿Con qué rapidez puedes implementar una nueva función? (Velocidad)

2. ¿Qué pasaría si tu desarrollador principal dejara la empresa? (Factor de riesgo)

3. ¿Es capaz la arquitectura de soportar 10 veces tu carga actual? (No 1000 veces, solo 10 veces)

4. ¿Disponen de pruebas automatizadas y de CI/CD? (Calidad)

Una arquitectura monolítica bien probada con CI/CD obtiene mejores resultados en todos los aspectos que una arquitectura de microservicios mal probada que solo una persona entiende.