Sistemele se blochează pe nesimțite. O regiune devine presupunere. Un managed service intră prea adânc în design. O mașină devine prea specială ca să fie înlocuită. Când afacerea are nevoie să se miște, arhitectura a spus deja nu.
Ce înseamnă asta într-o arhitectură
Scopul nu este să alergi după fiecare cloud sau să ascunzi orice alegere în abstracții. Mobilitatea înseamnă să păstrezi deciziile importante despre locul unde rulează sistemul târzii, explicite și reversibile. Ar trebui să poți reveni asupra lor fără să reconstruiești produsul în jurul lor.
- Portabilitate înaintea așezării. Workloads împachetate ca să se poată muta: containers, granițe clare, config și state externalizate.
- Fără rădăcini ascunse. Nicio dependență tăcută de o regiune, de un quirk al unui managed service sau de o mașină pornită de 400 de zile.
- Decizii reversibile. Alegerile scumpe rămân puține, explicite și ieftin de întors din drum.
Testul pe care îl aplicăm
Am putea recrea producția din sursă? Am putea ridica sistemul într-o a doua regiune fără să descoperim jumătate din arhitectură într-un runbook, într-un shell history sau în memoria cuiva? Când răspunsul sincer e nu, de acolo începe munca.
Dacă mutarea sistemului înseamnă rescriere, sistemul nu este încă portabil.
