En defensa de las arquitecturas simples (2022)

Artículo original ↗ Discusión en Hacker News ↗

Los ingenieros evalúan los beneficios de las arquitecturas “aburridas” y monolíticas frente a stacks complejos y muy cargados de microservicios, argumentando que la mayoría de los negocios pueden escalar bastante con una sola aplicación bien estructurada respaldada por una base de datos relacional. Muchos culpan al desarrollo orientado al currículum, al entusiasmo por patrones al estilo FAANG y a un liderazgo técnico débil de una complejidad innecesaria que perjudica la fiabilidad, ralentiza la entrega y quema a los equipos. Otros señalan que los microservicios y los diseños orientados a eventos pueden justificarse para el escalado organizativo o necesidades específicas de rendimiento, pero solo cuando están impulsados por restricciones reales y no por moda.

Arquitecturas simples vs. complejas

  • Muchos comentaristas respaldan stacks “aburridos” (Rails/Django o Python+Postgres, plantillas SSR + htmx, una sola VPS) como suficientes para la mayoría de las aplicaciones CRUD/de negocio, especialmente B2B.
  • Subrayan que los sistemas simples son más fáciles de razonar, mantener, depurar y dotar de personal; “viejo y fiable” suele superar a “nuevo y brillante”.
  • Otros sostienen que lo que cuenta como “simple” es subjetivo: contenedores, k8s, GraphQL o E/S asíncrona pueden parecer simples a quienes están familiarizados con ellos y complejos para otros.

Monolitos, microservicios y event sourcing

  • Hay un fuerte apoyo a empezar con un monolito, estructurado con módulos y límites claros; muchos afirman que un monolito disciplinado puede escalar muy lejos.
  • Los críticos de los microservicios dicen que no reducen la complejidad, solo la trasladan a través de la red, haciendo más difíciles la consistencia, las transacciones, la depuración y los despliegues.
  • Quienes defienden los microservicios los presentan principalmente como una herramienta organizativa y de coordinación: permiten equipos independientes, fallos aislados y escalado dirigido.
  • Algunos proponen event sourcing/CQRS como “microservicios bien hechos”, pero otros lo llaman inmaduro y complejo (eliminación de PII, semántica de replay, determinismo).

Elecciones tecnológicas: Python, GraphQL, Kubernetes

  • Algunos piensan que el stack descrito (monolito en Python + Postgres + colas + GraphQL + k8s + protocolo personalizado) no es realmente “simple” y cuestionan varias de esas elecciones.
  • Hay debates sobre Python en finanzas: para algunos, el tipado estático es vital para manejar dinero; otros sostienen que las herramientas modernas de Python (mypy, C FFI, bibliotecas ricas) son suficientes.
  • GraphQL recibe tanto elogios (reduce la proliferación de endpoints REST, esquema compartido, tipado fuerte) como críticas (complejidad conceptual, tamaño de las respuestas, no es estrictamente necesario frente a REST).
  • Algunos ven Kubernetes como una sobrecarga innecesaria para equipos pequeños; otros dicen que un clúster k8s gestionado puede ser una forma sencilla de ejecutar una app “normal” de tres capas.

Factores humanos y organizativos

  • Muchos culpan la complejidad a la ingeniería orientada al currículum o “de urraca”: adoptar Kafka/microservicios/cloud/etc. para aprender o impresionar, no para resolver problemas reales.
  • Otros señalan que la exploración tiene valor, pero debería ocurrir en prototipos, proyectos paralelos o contextos acotados, no en sistemas críticos de producción.
  • Varios enfatizan que la arquitectura debe ajustarse a la realidad de la organización: tamaño del equipo, experiencia, responsabilidad e incentivos importan más que patrones específicos.

Escala, rendimiento y “no lo necesitarás”

  • Un sector sostiene que la E/S síncrona y una sola base de datos manejan “millones de solicitudes al mes” sin problemas; escalar con máquinas más grandes antes que con complejidad distribuida.
  • Otro sector advierte que la E/S bloqueante y los stacks mal elegidos pueden colapsar incluso con poco volumen, especialmente cuando aumenta la latencia aguas abajo.
  • Hay amplio acuerdo en que construir prematuramente “como Netflix” ha hundido o ralentizado a muchas empresas, pero también en que un diseño insuficiente puede ser caro de corregir después.

Carreras, incentivos y valor

  • Algunos temen que centrarse en “tecnología aburrida” perjudique las perspectivas profesionales porque la contratación suele filtrar por stacks de moda.
  • Otros responden que el impacto empresarial cuantificable (“ahorré X, habilité Y ingresos”) es más convincente en niveles senior que el bingo de tecnologías.
  • Varios señalan incentivos desalineados: el capital barato y el crecimiento a cualquier costo fomentaron una complejidad despilfarradora; se sugiere acercar más a los ingenieros a los resultados del negocio como corrección.