Circuit Breaker ai tempi del Serverless

Circuit Breaker ai tempi del Serverless

Circuit Breaker, questo sconosciuto

Cos’è esattamente il Circuit Breaker? Beh, quando inizi a sviluppare per microservizi delle applicazioni altamente disaccoppiate il tuo obiettivo è quello di aumentare l’affidabilità e la scalabilità, perché non includere anche del Chaos Engineering. Dato che uno di questi microservizi può iniziare a funzionare male o a rispondere in maniera non idonea, semplicemente non si vuole che gli altri microservizi – che comunicano con quello malfunzionante – aspettino una risposta più del necessario. A questo punto si introduce il concetto di “Circuit Breaker”, in italiano conosciuto come “salvavita” nella terminologia elettrica, che semplicemente “apre il circuito” quando un servizio risponde in maniera non idonea o cessa del tutto di funzionare.

Seriamente?

Se stai leggendo questo articolo senza avere esperienza nello sviluppo per microservizi la cosa potrà sembrare strana, ma sì quello che si vuole in applicazioni strutturate in questo modo è “fallire velocemente” in caso di malfunzionamenti. Questo perché se un microservizio smette di funzionare come da attese, semplicemente quella specifica funzione sarà degradata ma senza impattare l’intero spettro applicativo, ecco perché vogliamo che gli altri servizi rispondano velocemente, senza quindi aspettare una risposta che forse mai arriverà.

Divertente, vero? Sì, lo sappiamo. Tutto torna poi quando ci si confronta sul tema in un ambiente per microservizi “standard” come Kubernetes, Swarm o ECS, che essendo di per loro basati su host (a meno di EKS) ci si aspetta una componente di costo fisso.
Ma come funziona se invece i miei microservizi, o parte di questi, girano su tecnologie Serverless?

…ai tempi del Serverless

Il problema inizia a farsi interessante se si sviluppa in ambiente Serverless. Serverless di per sè significa costi prossimi allo zero in situazioni di IDLE, ma questo dovrebbe valere anche per quei servizi che non sono momentaneamente disponibili. Come si può quindi migliorare il paradigma di sviluppo del Circuit Breaker adattandolo ad una logica Serverless?

Niente di particolarmente complicato, si può utilizzare il Serverless Framework. Dal momento in cui questo può gestire l’intero stack, inclusi template di Cloudformation, risulta abbastanza semplice a pensare una funzione di healthcheck (una per ogni microservizio) che, in caso di malfunzionamento o elevate latenze, inizializza un job di Continuous Integration che “apre il circuito” ma – a differenza del Circuit Breaker tradizionale, questo non avviene a livello codice (tramite contatori) ma avviene a livello di API Gateway. Questo consente di non invocare alcuna funzione a meno che il servizio non funzioni come ci si aspetti, si ha quindi una risposta più veloce in caso di fail e si approssimano a zero i costi dovuti al downtime di una specifica funzionalità dell’applicazione.

Ci piacerebbe discutere sul tema, noi abbiamo risolto così questo problema durante i nostri sviluppi. Pensiamo che il serverless, così come Docker ha già fatto, cambierà il modo in cui si scriverà il codice anche in ottica di ottimizzazione dei costi.

Condividi con noi le tue considerazioni, scrivi a cloud@azatec.com