Entrare in un ecosistema di quaranta microservizi
Il conteggio dei servizi dice poco. Cosa conta davvero quando si entra in un sistema di questa taglia?
Quaranta microservizi possono essere un'architettura o quaranta modi diversi di fare la stessa cosa. La differenza sta nelle librerie condivise, nelle convenzioni e nel modo in cui i servizi si parlano. Un ecosistema cresciuto bene ha pacchetti interni per HTTP, logging, cache, autenticazione e dominio, pubblicati su un registro privato e usati da tutti. È lì che si legge la vera architettura, prima ancora che nel codice dei singoli servizi.
Come si entra
Le prime settimane servono a leggere: i pacchetti condivisi, il flusso degli eventi tra servizi, lo schema del database, le pipeline e gli ambienti di collaudo. Poi si prende un pezzo vero, dentro il flusso di lavoro del team: stesse convenzioni, stesso strumento di ticket, stessi rilasci settimanali. La misura di quanto si è dentro è semplice: dopo otto settimane, su quanti repository si è il primo contributore.
La regola del primo refactor è ferma: input e output non cambiano di una virgola, cambia solo come è fatto dentro. Un servizio da quattromila righe in un file diventa una struttura a oggetti per categoria, con contenitori tipizzati al posto di array passati di mano in mano, e ogni passaggio conserva il comportamento osservabile.
La parità si misura sui dati veri
Quando il nuovo catalogo deve restituire gli stessi prezzi del vecchio, la parità si misura confrontando gli output per utenti e mercati reali. È così che si scopre che per lo stesso utente il vecchio sistema dava undici promozioni e il nuovo quattordici, per una differenza nel modo di collassare i gruppi e nell'instradamento per provincia. Trovato prima del rilascio, è un bug. Trovato dopo, è un cliente che paga una cifra diversa.
Descrivici il sistema. Ti diciamo cosa vediamo.
Dieci minuti, una domanda alla volta. Alla fine, la nostra lettura onesta del caso. È il filtro, prima ancora della call.