No es microservicio ni monolito; es carga cognitiva
La carga cognitiva, y no palabras de moda como “microservicios” o “monolito”, se presenta como la verdadera restricción en las decisiones de arquitectura de software. Los comentaristas sostienen que ambos patrones pueden funcionar o fallar según el tamaño del equipo, los límites del dominio, las herramientas y los incentivos organizativos, y muchos advierten que los microservicios añaden complejidad operativa y de coordinación que los equipos pequeños o inmaduros no pueden manejar. Varias voces enfatizan empezar por las necesidades del producto y un diseño modular claro (a menudo mediante un monolito bien estructurado) y pasar a servicios distribuidos solo cuando la escala, la estructura del equipo o las necesidades de autonomía lo exijan de verdad.
Meta: clasificación de HN y sospechas
- Algunos comentarios cuestionan cómo la publicación llegó rápidamente a la portada con pocos puntos/comentarios.
- El algoritmo de clasificación se describe como favorable a publicaciones recientes con puntos en aumento; otros especulan sobre bots o impulsos/reducciones manuales, pero esto sigue sin probarse y es motivo de controversia.
La carga cognitiva como lente de diseño
- A muchos les gusta “carga cognitiva” como una forma centrada en las personas de pensar sobre la arquitectura.
- Hay desacuerdo sobre su medibilidad: algunos dicen que no puede/no debe cuantificarse; otros señalan la investigación de factores humanos en otros ámbitos.
- La mala interpretación de “diseñar para la carga cognitiva máxima”: algunos lo leen como empujar a los equipos a sus límites; otros como “no exceder lo que los equipos realmente pueden manejar”.
- Ejemplos de refinerías de petróleo y software médico destacan que las “refinerías de datos” no documentadas y con múltiples servicios pueden superar la comprensión humana y crear riesgos reales.
Microservicios vs. monolito: compensaciones
- Opinión firme: la arquitectura debería seguir un buen diseño (autonomía, límites claros) más que objetivos arbitrarios como “N servicios por equipo” o “siempre un monolito”.
- Varios sostienen que los microservicios son principalmente una estrategia organizativa/de despliegue; técnicamente, un proceso único o un monolito modular suele ser más simple, rápido y confiable.
- Los microservicios pueden funcionar bien cuando: los límites están bien diseñados, los servicios son testeables de forma independiente, el CI/CD y la observabilidad son sólidos, y los equipos son grandes.
- Muchos relatan modos de fallo: demasiados servicios, interfaces difíciles de cambiar, cuellos de botella de coordinación entre equipos, largas cadenas de depuración y “monolitos distribuidos”.
Estructura de equipos, Conway y Team Topologies
- Debate sobre si los microservicios existen para “cumplir con” o “abrazar” la Ley de Conway frente a tratarla como una advertencia.
- Algunos ven útil el servicio-por-equipo y la autonomía al estilo de “Team Topologies”; otros dicen que fomenta feudos, fragmentación y una carga cognitiva disparada entre equipos.
- Varios comentarios subrayan que los incentivos, el liderazgo y las habilidades blandas importan más que el patrón elegido.
Componentización, modularidad y terreno intermedio
- Muchos enfatizan que los monolitos modulares pueden lograr límites claros mediante bibliotecas, paquetes e interfaces estrictas.
- “Monolito vs microservicios” se ve como una falsa dicotomía; hay un espectro: aplicaciones modulares de proceso único, diseños “mesolíticos/gabion”, bases de datos compartidas con propiedad estricta y servicios extraídos selectivamente.
- Un largo subhilo discute la partición extrema (cientos de componentes/repos pequeños) frente a un único monolito, con partidarios que citan productividad en lotes pequeños y críticos que señalan mantenimiento y presunta sobreingeniería.
Prioridad del producto frente a la arquitectura
- Varios fundadores argumentan que las startups en etapas tempranas deberían priorizar el descubrimiento del producto y la velocidad; las escalas/reescrituras son un “buen problema” que pocos alcanzan.
- Otros responden que los sistemas de larga vida exigen refactorización continua, simplificación y respeto por la complejidad esencial frente a la accidental.
Formas prácticas de reducir la carga cognitiva
- Tácticas sugeridas: encapsulación sólida, APIs bien definidas, contextos acotados, buena documentación, menos lenguajes/pilas tecnológicas y extraer bibliotecas autocontenidas.
- Tema recurrente: no puedes evitar la complejidad, pero sí puedes elegir dónde vive y cuánta de ella debe tener cada persona en la cabeza.