Los microservicios se han convertido en el ejemplo por defecto tanto de "buena arquitectura" como de "sobreingeniería", según a quién se pregunte. Lo paradójico es que todo el mundo reconoce un microservicio al verlo, pero casi nadie puede explicar qué lo define como tal. La industria ha intentado definirlos durante años por sus características técnicas, pero esas características son sorprendentemente vagas: no existen umbrales claros de tamaño, número de responsabilidades o líneas de código.
La clave está en que los microservicios no son principalmente una abstracción técnica, sino una solución a un cuello de botella organizativo. Cuando una empresa crece y docenas o cientos de ingenieros necesitan trabajar de forma independiente, los equipos requieren autonomía, propiedad sobre su código y la capacidad de desplegar sin coordinarse constantemente con los demás. Los microservicios crean fronteras que reflejan las fronteras de la organización, y ahí reside su verdadero valor. Las razones técnicas habituales para abandonar un monolito —despliegues lentos, pruebas largas, compilaciones dolorosas— pueden resolverse sin fragmentar la arquitectura.
No obstante, cada beneficio llega con su factura. La autonomía implica perder centralización: responder preguntas como "qué dependencias enviamos" o "qué código sigue usándose" resulta mucho más difícil cuando el código está repartido en decenas de servicios independientes. Una llamada a un método se convierte en una petición HTTP, un error de compilación en un fallo en tiempo de ejecución, y todos los problemas típicos de los sistemas distribuidos —latencia, reintentos, fallos parciales, serialización, consistencia— pasan a formar parte de la aplicación.
Además, la comunicación entre equipos se vuelve tan costosa como la comunicación entre APIs. Cambiar una API deja de ser una refactorización para convertirse en una negociación que exige versionado, períodos de convivencia y migraciones coordinadas. La toma de decisiones también se distribuye.
Los microservicios son una elección arquitectónica excelente en el entorno adecuado, pero conviene ser honesto sobre sus motivos: si el problema principal es de escala organizativa, pueden ser la respuesta correcta; si es puramente técnico, probablemente se está recurriendo a una solución desproporcionada. Son, en definitiva, herramientas organizativas con consecuencias técnicas.