La arquitectura es cuestión de compromisos, no de moda
Las buenas decisiones de arquitectura son aburridas de defender y fáciles de revisar. Las de moda no son ninguna de las dos.
Las buenas decisiones de arquitectura son aburridas de defender y fáciles de revisar. Las de moda no son ninguna de las dos.
Cada pocos años la industria acuerda una respuesta por defecto. Microservicios. Serverless. Event sourcing. Monorepos. Rara vez están mal en sí mismos; el daño viene de adoptarlos como identidad en lugar de como una decisión con costes.
Suelo empezar con un monolito modular porque preserva opciones y evita la complejidad de los sistemas distribuidos. Eso es un compromiso, no una doctrina. Si un equipo está realmente limitado por el despliegue independiente o por perfiles de escalado muy distintos, separar es lo correcto, y lo he hecho.
Ese último punto es el que más se omite y el más valioso. Una arquitectura con condiciones explícitas de reversión se puede revisar sin que parezca una confesión de fracaso.
Todo equipo puede cargar una cantidad finita de complejidad sin dejar de ser productivo. Transacciones distribuidas, un service mesh, tres almacenes de datos y un bus de eventos se pueden justificar uno a uno. Juntos pueden consumir el presupuesto completo y no dejar nada para la complejidad del dominio de negocio, que es la única que el cliente paga.
Gasta tu presupuesto de complejidad en el problema, no en la infraestructura alrededor del problema.
La propiedad más importante de una arquitectura casi nunca es el rendimiento: es cuánta gente tiene que estar de acuerdo para poder entregar un cambio. Unas fronteras de módulo bien trazadas permiten avanzar sin pedir permiso. Mal trazadas, cada funcionalidad se convierte en una negociación.
Por eso la arquitectura es un asunto de liderazgo y no solo técnico. La estructura del software acaba convirtiéndose en la estructura de la jornada de trabajo.
Escrito por Jesús Ibáñez, líder de ingeniería.
El modelo es un componente. Trátalo como tal y las funcionalidades de IA vuelven a ser ingeniería normal.
Leer el artículoA un engineering manager no le faltan tareas. La pregunta es cuáles de esas tareas son de verdad suyas.
Leer el artículo