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.²

Els Costos Ocults

La complexitat té costos que rarament apareixen als pressupostos:

1. Temps de diagnòstic — Cada incident triga més en investigar-se
2. Onboarding — Els nous enginyers necessiten mesos per entendre el sistema
3. Decisions de disseny — Cada canvi requereix considerar més implicacions
4. 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.³

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.