Després de gairebé dues dècades treballant amb sistemes distribuïts, he arribat a una conclusió que sembla contraintuïtiva: la complexitat és el veritable enemic, no els errors.1
El Paradox de la Complexitat
Quan comencem a construir sistemes, afegir funcionalitats sembla gratuït. Un microservei aquí, una cua de missatges allà, una capa de cache per accelerar les coses. Cada decisió sembla raonable aïlladament.
Un sistema complex que funciona invariablement ha evolucionat d’un sistema simple que funcionava. Un sistema complex dissenyat des de zero mai funciona i no pot fer-se funcionar. Has de començar de nou amb un sistema simple que funcioni.
Però la complexitat no és additiva; és multiplicativa. Cada component nou no només afegeix la seva pròpia complexitat, sinó que multiplica les interaccions possibles amb tots els altres components.2
Els Costos Ocults
La complexitat té costos que rarament apareixen als pressupostos:
- Temps de diagnòstic — Cada incident triga més en investigar-se
- Onboarding — Els nous enginyers necessiten mesos per entendre el sistema
- Decisions de disseny — Cada canvi requereix considerar més implicacions
- Proves — La matriu de possibles interaccions creix exponencialment
Un Exemple Real
Fa anys, vaig treballar en un sistema de processament de pagaments que havia crescut orgànicament durant una dècada. Tenia:
- 47 microserveis
- 12 bases de dades diferents
- 8 cues de missatges
- 3 sistemes de cache
- Aproximadament 150 integracions externes
┌─────────────────────────────────────────────────────┐
│ COMPLEXITAT │
├─────────────────────────────────────────────────────┤
│ Components: O(n) │
│ Interaccions: O(n²) │
│ Modes de fallada: O(2ⁿ) │
└─────────────────────────────────────────────────────┘El temps mitjà de resolució d’incidents havia passat de minuts a hores. No perquè els enginyers fossin menys capaços, sinó perquè entendre què estava passant requeria navegar una xarxa de dependències cada vegada més densa.
Simplicitat Deliberada
La simplicitat no és absència de funcionalitat; és absència de complexitat innecessària. És el resultat de decisions conscients i, sovint, doloroses.
La perfecció s’assoleix, no quan no hi ha res més a afegir, sinó quan no hi ha res més a treure.
Principis Pràctics
He après a aplicar alguns principis:
1. Prefereix el monòlit primer
Comença amb el sistema més simple que pugui funcionar. Només divideix quan tinguis evidència clara que la divisió resoldrà un problema real.3
2. Mesura abans d’optimitzar
La complexitat afegida per “rendiment” sovint no aporta millores mesurables. Fins i tot pitjor, pot afegir latència per la sobrecàrrega de comunicació entre components.
3. Documenta les decisions, no només el codi
Cada decisió arquitectònica hauria de tenir un ADR (Architecture Decision Record) que expliqui:
- El context
- Les alternatives considerades
- La decisió presa
- Les conseqüències esperades
4. Revisa la complexitat periòdicament
El que tenia sentit fa dos anys potser ja no el té. Programa revisions regulars de l’arquitectura amb la pregunta: “Això encara ens aporta valor?”
Conclusió
La simplicitat és una disciplina, no un estat natural. Requereix esforç constant, decisions difícils i la voluntat de dir “no” a funcionalitats que semblen atractives però que afegeixen complexitat innecessària.
Els millors sistemes que he vist no són els més sofisticats; són els que fan una cosa, la fan bé, i són prou simples perquè qualsevol membre de l’equip els pugui entendre en una tarda.
Aquesta és la primera entrada d’una sèrie sobre lliçons apreses després de gairebé dues dècades en SRE. La propera entrada tractarà sobre observabilitat i per què “més mètriques” no sempre és millor.
Això no vol dir que els errors no importin. Òbviament importa quan les coses fallen. Però la complexitat és la font d’on neixen la majoria d’errors difícils de diagnosticar. ↩︎
Si tens n components, tens potencialment n(n-1)/2 interaccions entre parells de components. A la pràctica, no totes les interaccions existeixen, però el creixement segueix sent superlineal. ↩︎
Martin Fowler escriu extensament sobre això al seu article “Monolith First”. ↩︎