Salta al contenuto principale

Terminologia

BFF (Backend for Frontend)

BFF sta per Backend for Frontend, un pattern in cui ogni esperienza client (web, mobile, API partner) ha un proprio backend dedicato che aggrega e adatta i dati per quel client. Evita una singola API generica e gonfia e permette ai team client di iterare in modo indipendente. Ogni BFF è a sua volta un piccolo servizio posto davanti ai servizi condivisi a valle.

DDD (Domain-Driven Design)

DDD sta per Domain-Driven Design, un approccio alla progettazione del software che mette al centro il modello del dominio di business e un linguaggio ubiquo condiviso. I suoi pattern strategici, specialmente i bounded context, sono la tecnica più comune per decidere i confini dei microservizi. I suoi pattern tattici plasmano il modello interno di ciascun servizio.

DLQ (Dead Letter Queue)

DLQ sta per Dead Letter Queue, una destinazione per i messaggi che non possono essere elaborati dopo il numero configurato di retry. Isola i messaggi velenosi così che smettano di bloccare un consumatore e li conserva per ispezione o riesecuzione successiva. Gestire una DLQ con alerting è una pratica di affidabilità di base per i sistemi event-driven.

CQRS (Command Query Responsibility Segregation)

CQRS sta per Command Query Responsibility Segregation, la separazione del modello di scrittura (comandi) da quello di lettura (query) così che ciascuno possa essere ottimizzato in modo indipendente. Nei sistemi distribuiti guida comunemente read model denormalizzati aggiornati da eventi. Aggiunge complessità operativa ed è giustificato solo quando bisogni di lettura e scrittura divergono davvero.

2PC (Two-Phase Commit)

2PC sta per Two-Phase Commit, un protocollo di commit atomico distribuito con una fase di prepare e una di commit coordinate da un transaction manager. Garantisce l'atomicità tra risorse ma si blocca in caso di fallimento del coordinatore e scala male, perciò viene generalmente evitato tra microservizi. Le saga con compensazione sono l'alternativa usuale.

SLA (Service-Level Agreement)

SLA sta per Service-Level Agreement, un impegno formale, spesso contrattuale, sul livello di servizio atteso, come la disponibilità mensile, con conseguenze in caso di violazione. È la promessa esterna fatta ai consumatori. È sostenuto internamente da SLO più stringenti e misurato dagli SLI.

SLO (Service-Level Objective)

SLO sta per Service-Level Objective, un obiettivo interno per una metrica di affidabilità come disponibilità o latenza su una finestra temporale. Gli SLO si fissano più stretti di qualsiasi SLA esterno per avere un margine di sicurezza e per guidare gli error budget. Trasformano l'affidabilità in un obiettivo ingegneristico misurabile.

SLI (Service-Level Indicator)

SLI sta per Service-Level Indicator, la quantità effettivamente misurata di cui uno SLO è l'obiettivo, come la percentuale di richieste con successo o la latenza p99. Va definita con cura, incluso cosa conti come richiesta e come successo. Un buon SLI riflette l'esperienza dell'utente del servizio.

RPC (Remote Procedure Call)

RPC sta per Remote Procedure Call, uno stile di comunicazione tra servizi che fa apparire una chiamata a un servizio remoto come una chiamata di funzione locale. Le implementazioni moderne come gRPC usano HTTP/2 e serializzazione binaria per l'efficienza. RPC è comodo ma può nascondere il costo e le modalità di fallimento della rete.

REST (Representational State Transfer)

REST sta per Representational State Transfer, uno stile architetturale per API di rete basato su risorse, metodi HTTP uniformi e interazioni stateless. È lo stile più comune per le API pubbliche e sincrone dei microservizi. I suoi vincoli favoriscono cacheabilità, evolvibilità e accoppiamento lasco.

gRPC

gRPC è un framework RPC ad alte prestazioni che usa HTTP/2 e Protocol Buffers. La g viene spesso letta come un richiamo ricorsivo a gRPC stesso più che come un'espansione fissa. Genera stub tipizzati da uno schema e supporta lo streaming, il che lo rende popolare per chiamate interne ad alto throughput tra servizi.

API (Application Programming Interface)

API sta per Application Programming Interface, il contratto attraverso cui un servizio viene invocato da un altro, che definisce operazioni, input, output e semantica degli errori. Nei microservizi l'API è l'unico modo sancito per usare le capacità o i dati di un altro servizio. API stabili e versionate sono ciò che rende possibile il deployment indipendente.

SAGA

Una saga è una sequenza di transazioni locali, ciascuna in un servizio diverso, che insieme implementano una transazione di business che attraversa più servizi, con transazioni compensative per annullare i passi completati in caso di fallimento. Sostituisce le transazioni ACID distribuite con la consistenza eventuale. Le saga sono coordinate per orchestration o per choreography.

ACL (Anti-Corruption Layer)

ACL sta per Anti-Corruption Layer, un pattern DDD in cui uno strato di traduzione protegge un bounded context dal modello di un sistema esterno o legacy. Mappa i concetti estranei nel linguaggio ubiquo locale così che il modello legacy non vi penetri. È particolarmente utile durante una migrazione strangler-fig.

OTel (OpenTelemetry)

OTel sta per OpenTelemetry, uno standard e un toolkit neutrali rispetto al vendor, ospitati dalla CNCF, per generare, raccogliere ed esportare la telemetria: tracce, metriche e log. Fornisce SDK per i vari linguaggi e un collector così che la strumentazione sia disaccoppiata dal backend di osservabilità. È lo standard dominante per strumentare i microservizi.

CNCF (Cloud Native Computing Foundation)

CNCF sta per Cloud Native Computing Foundation, l'ente della Linux Foundation che ospita e cura molti dei progetti centrali per i microservizi, tra cui Kubernetes, Prometheus, Envoy e OpenTelemetry. I suoi livelli graduated e incubating segnalano la maturità dei progetti. Di fatto cura l'ecosistema cloud-native.

mTLS (Mutual TLS)

mTLS sta per Mutual Transport Layer Security, una configurazione in cui sia client sia server presentano e verificano certificati così che ciascuno autentichi l'altro. In un service mesh protegge e autentica per impostazione predefinita tutto il traffico servizio-servizio. È un meccanismo centrale per il networking zero-trust tra servizi.

HPA (Horizontal Pod Autoscaler)

HPA sta per Horizontal Pod Autoscaler, il controller di Kubernetes che regola automaticamente il numero di repliche di pod di un workload in base a metriche osservate come l'utilizzo della CPU o metriche custom. Scala verso l'esterno sotto carico e verso l'interno quando è inattivo. È il modo standard per scalare microservizi stateless su Kubernetes.

CI/CD (Continuous Integration / Continuous Delivery)

CI/CD sta per Continuous Integration e Continuous Delivery (o Deployment), la pipeline automatizzata che costruisce, testa e rilascia ogni modifica. La distribuibilità indipendente dei microservizi dipende dal fatto che ogni servizio abbia la propria pipeline veloce e affidabile. Una CI/CD matura è un prerequisito per gestire molti servizi in sicurezza.

P99 (99° percentile di latenza)

P99 indica la latenza al 99° percentile, il tempo di risposta sotto cui si completa il 99% delle richieste; solo l'1% più lento è al di sopra. I percentili di coda come p95 e p99 rivelano le esperienze peggiori che le medie nascondono. Sono le latenze che contano per gli SLO perché plasmano l'affidabilità percepita.

TTL (Time To Live)

TTL sta per Time To Live, una durata trascorsa la quale una voce in cache, un messaggio o un record è considerato scaduto. Nei microservizi limita quanto può diventare obsoleto un dato di un altro servizio messo in cache e aiuta a ripulire lo stato transitorio. Scegliere un TTL baratta freschezza contro carico sulla fonte di verità.

NFR (Non-Functional Requirement)

NFR sta per Non-Functional Requirement, un vincolo di qualità su un sistema come prestazioni, scalabilità, disponibilità o sicurezza, contrapposto a una funzionalità specifica. Le architetture a microservizi sono in larga parte una risposta a NFR come la scalabilità indipendente e l'autonomia dei team. Vanno resi espliciti e misurabili.

VM (Virtual Machine)

VM sta per Virtual Machine, un computer emulato via software con il proprio sistema operativo guest in esecuzione su un hypervisor. Le VM forniscono un forte isolamento ma sono più pesanti e lente da avviare rispetto ai container. I container, che condividono il kernel dell'host, sono l'unità di deployment più comune per i microservizi.

ESB (Enterprise Service Bus)

ESB sta per Enterprise Service Bus, un backbone di integrazione centralizzato dell'era SOA che esegue routing, trasformazione e orchestrazione. I microservizi spostano deliberatamente la logica fuori da tale middleware intelligente verso smart endpoint e dumb pipe. L'ESB è spesso citato come l'anti-pattern a cui i microservizi reagiscono.

SOA (Service-Oriented Architecture)

SOA sta per Service-Oriented Architecture, uno stile precedente di costruire sistemi a partire da servizi riusabili e accessibili in rete, spesso integrati tramite un ESB. I microservizi sono spesso descritti come un'evoluzione a grana fine e decentralizzata della SOA. Mantengono l'idea di servizio ma rifiutano middleware condiviso pesante e database condivisi.

YAGNI (You Aren't Gonna Need It)

YAGNI sta per You Aren't Gonna Need It, il principio di non costruire una funzionalità finché non serve davvero. Nei microservizi argomenta contro lo split speculativo dei servizi o l'aggiunta speculativa di cache, code e CQRS. La decomposizione prematura è una violazione frequente e costosa di YAGNI.

RTO / RPO (Recovery Time / Recovery Point Objective)

RTO e RPO sono obiettivi di disaster recovery: RTO è quanto velocemente il servizio deve essere ripristinato dopo un'interruzione, RPO è quanta perdita di dati, misurata in tempo, è accettabile. Guidano frequenza dei backup, replica e progettazione del failover per lo store di ciascun servizio. La proprietà dei dati per servizio permette che questi obiettivi differiscano da servizio a servizio.