Blog

Microservicios: cuándo sí y cuándo no

No siempre son la respuesta. Depende de tu complejidad, equipo y operacin.

Arquitectura

Los microservicios pueden dar escalabilidad y autonomía de equipos, pero también traen complejidad: despliegues, observabilidad, redes y datos distribuidos. Para PYMES peruanas, muchas veces NO son la solución correcta.

¿Qué son Microservicios?

Un microservicio es un servicio independiente y pequeño que hace una cosa bien. Ejemplos:

  • Servicio de Facturación: Solo genera facturas, emite a SUNAT, genera PDF.
  • Servicio de Inventario: Gestiona stock, alertas de bajo stock.
  • Servicio de Pagos: Procesa pagos, integra con bancos y billeteras.
  • Servicio de Usuarios: Autenticación, permisos, roles.

Cada uno se despliega independientemente, corre en su propia BD (idealmente), y se comunica por APIs REST o eventos.

Monolito tradicional: Todo en una sola aplicación. Facturas, inventario, pagos, usuarios, en el mismo código y BD.

Comparación: Monolito vs Microservicios

Aspecto Monolito Microservicios
Complejidad inicial Baja (todos en un código) Alta (múltiples servicios, APIs)
Despliegue Un único release Cada servicio se despliega por separado
Escalabilidad Todo crece junto (ineficiente) Escalas solo lo que necesitas
Equipo Requiere coordinación fuerte Equipos autónomos por servicio
Mantenibilidad Difícil en proyectos grandes Fácil si está bien organizado
Operación (DevOps) Simple (un servidor/BD) Compleja (10+ servicios, distribución)
Latencia Baja (mismo proceso) Mayor (llamadas HTTP entre servicios)

Cuándo SÍ Usar Microservicios

  1. Sistema grande con dominios muy distintos:

    Ejemplo: E-commerce peruano (Amazon Perú). Facturación, catálogo, pagos, envíos, devolución, chat de soporte. Cada uno puede crecer de forma independiente.

  2. Equipos separados por función:

    Tienes equipo de 8+ developers en Perú. Uno maneja pagos, otro inventario, otro facturación. Microservicios evita conflictos de código.

  3. Picos de carga muy desiguales:

    Tu servicio de facturación pide 5 veces más CPU en fin de mes. Microservicios permite escalar solo ese.

  4. Necesitas despliegues rápidos sin downtime:

    Actualizar solo el servicio de pagos sin reiniciar inventario. En monolito, todo cae.

  5. Operación madura con DevOps/SRE:

    Tienes containers (Docker), orquestación (Kubernetes), CI/CD automatizado, monitoreo (Prometheus, Grafana).

Cuándo NO Usar Microservicios (Para PYMES Peruanas)

  1. Equipo pequeño (2-5 developers):

    Microservicios sobrecarga: cada uno requiere DevOps, deploy, monitoreo. 1 developer no puede manejar 8 microservicios solos.

  2. Sistema aún en etapa de descubrimiento:

    Los requisitos cambian cada mes. Microservicios son rígidos: si cambias la estructura, es un dolor migrar.

  3. Infraestructura básica (sin CI/CD, sin containers):

    Si aún estás en servidores Windows/Linux manuales, microservicios es un salto muy grande.

  4. Presupuesto limitado (menos de S/ 200K/año):

    Microservicios requieren más infraestructura, herramientas, expertise. Un monolito cuesta más barato en hosting.

  5. Carga predecible y baja:

    Si 200 usuarios concurrentes es tu máximo, microservicios NO agrega valor.

Costos Reales en Perú (Soles)

Monolito en Cloud (recomendado para PYMES):

  • Servidor en AWS/Google Cloud: S/ 1,500-3,000/mes.
  • BD PostgreSQL: S/ 500-1,500/mes.
  • CDN y almacenamiento: S/ 300-500/mes.
  • Monitoreo básico (Datadog/New Relic): S/ 1,000-2,000/mes.
  • Total: S/ 3,300-7,000/mes (S/ 39,600-84,000/año).
  • Team: 1-2 developers pueden mantenerlo.

Microservicios completo:

  • 5-10 servicios en containers (AWS ECS o Kubernetes): S/ 5,000-15,000/mes.
  • API Gateway, Kafka/RabbitMQ para eventos: S/ 2,000-5,000/mes.
  • 4-5 BDs distribuidas: S/ 2,000-5,000/mes.
  • Monitoreo avanzado (Prometheus, Grafana, ELK Stack): S/ 3,000-8,000/mes.
  • Herramientas de tracing distribuido: S/ 1,000-3,000/mes.
  • Total: S/ 13,000-36,000/mes (S/ 156,000-432,000/año).
  • Team: 4-6 developers + 1-2 SRE/DevOps.

Caso de Estudio: Tienda de E-commerce Peruana (60 empleados)

Situación inicial: Monolito en PHP/Laravel. 500K visitas/mes. Equipos separados: backend, frontend, mobile. Desplegaban todo junto = 4 horas sin servicio por release.

Problema:

  • Despliegue toma 4 horas, afecta facturas (SUNAT se enoja).
  • Bug en catlogo hace caer todo.
  • Picos de tráfico en Black Friday: servidor colapísimo.
  • 3 teams paso a paso mover a Microservicios.

Solución adoptada: MONOLITO MODULAR (no microservicios)

  • Mantuvieron monolito pero restructuraron código en módulos cláros.
  • APIs internas entre módulos.
  • BDs separadas por módulo (BD de Facturas, BD de Catálogo) pero 1 sola aplicación.
  • CI/CD mejorado: deployments cada 30 min sin downtime (blue-green).

Resultados (6 meses):

  • Deployments: 4 horas → 15 minutos.
  • Downtime: 0 (blue-green deployment).
  • Black Friday: escalable a 2M vísitas sin colapísimo.
  • Costo: S/ 5,500/mes (vs S/ 25,000 si fuera microservicios).
  • Team: 5 developers mantienen cómodamente (vs 10-15 en microservicios).

Enseñanza: No necesitaban microservicios. Un monolito bien arquitectado era mejor.

La Opción Ganadora para Muchas PYMES: Monolito Modular

Cómo funciona:

  • Un único código (monolito), pero interno separado por módulos.
  • Módulos se comunican por interfaces limpias (no directamente).
  • BDs pueden estar separadas por módulo (opcional).
  • Se despliega todo junto, pero puedes iterar rápido.

Ventajas vs Microservicios:

  • 80% de los beneficios de microservicios.
  • 20% de la complejidad.
  • No necesitas DevOps experto.
  • Debugging es fácil (todo en un stacktrace).
  • Transacciones de BD son simples.
  • Mucho más barato en infraestructura.

Ejemplo: Odoo, Shopify internamente, WordPress Multisite: todos son monolitos modulares que escalan enormemente.

Checklist: ¿Debemos Migrar a Microservicios?

Responde SÍ o NO
¿Tengo 5+ equipos separados de developers? [ ] SÍ [ ] NO
¿Mi sistema procesa 10M+ transacciones/mes? [ ] SÍ [ ] NO
¿Tengo infraestructura DevOps madura (Docker, K8s, CI/CD)? [ ] SÍ [ ] NO
¿Diferentes dominios con escalabilidad muy desigual? [ ] SÍ [ ] NO
¿Presupuesto > S/ 200K/año para infraestructura? [ ] SÍ [ ] NO
¿Tengo SRE/DevOps dedicado? [ ] SÍ [ ] NO
Si contestaste SÍ a 4+ preguntas: considera microservicios.
Si contestaste SÍ a menos de 4: olvida microservicios por ahora. Usa monolito modular.

Hoja de Ruta Recomendada para PYMES Peruanas

Año 1: Monolito modular bien arquitectado.

  • Separar código en módulos claros (DDD - Domain Driven Design).
  • APIs internas entre módulos.
  • CI/CD básico (GitHub Actions, GitLab).
  • Monitoreo básico (logs, alertas).

Año 2-3: Si creces mucho, evaluá migrar módulos críticos a microservicios.

  • Primero: Servicio independiente más crítico (ej: pagos).
  • Integración lenta con monolito por APIs.
  • Monitoreo distribuido y tracing.

Nota: La mayoría de PYMES peruanas nunca necesitarán llegar al punto 2.

Alternativas a Microservicios

1. Monolito Modular (Recomendado)

Mejor 80% del tiempo para PYMES. Costo: S/ 3K-7K/mes.

2. Serverless (AWS Lambda, Google Cloud Functions)

Cada función en su propio “microservicio”. Pago por uso. Ideal para cargas impredecibles. Costo: S/ 1K-5K/mes (según invocaciones).

3. SaaS modular (Shopify, Odoo Cloud, Salesforce)

No reinventas nada. Todo integrado. Costo: S/ 500-10K/mes según usuarios. Sin DevOps.

4. Event-Driven Monolito

Monolito que se comunica consigo mismo via eventos (Kafka, RabbitMQ). Escalable, moderno, pero simple. Costo: S/ 5K-10K/mes.

Conclusión

Los microservicios son poderosos, pero NO son para todo el mundo. Para la mayoría de PYMES peruanas:

  • Empieza con monolito modular: Simple, barato, escalable.
  • Mejora gradualmente: CI/CD, monitoreo, arquitectura limpia.
  • Migra a microservicios solo si es estrictamente necesario: Múltiples equipos, gigantesco, tormento operacional.
  • 90% de aplicaciones peruanas no lo necesitan. Mejor enfocarse en:
    • Seguridad (OWASP Top 10, SUNAT compliance).
    • Performance (caché, CDN, DB óptimas).
    • Confiabilidad (backups 3-2-1, SLA 99.9%).
    • UX/Product (que los usuarios amen tu app).

¿No estás seguro de qué arquit ectura elegir? Cuentános tu caso:

  • Número de usuarios y transacciones/mes.
  • Tamaño del equipo de developers.
  • Requisitos de escalabilidad y crecimiento esperado.
  • Infraestructura y herramientas que ya tienes.

Te ayudamos a elegir la arquitectura correcta sin sobreingenierizar. En TSDFACT llevamos 8+ años ayudando a PYMES peruanas a construir sistemas que crecen con ellas.