Rivisitazione della filosofia Unix nel 2018

In breve, lo stile dell'architettura del microservizio è un approccio allo sviluppo di una singola applicazione come una suite di piccoli servizi, ciascuno in esecuzione nel proprio processo e in comunicazione con meccanismi leggeri, spesso un'API di risorse HTTP.

Mentre un programma *nix o un microservizio possono essere molto limitati o addirittura non molto interessanti di per sé, è la combinazione di tali unità di lavoro indipendenti che rivela il loro vero vantaggio e, quindi, la loro potenza.

*nix e microservizi

La tabella seguente confronta i programmi (come cat o lsof ) in un ambiente *nix rispetto ai programmi in un ambiente di microservizi.

Esploriamo ogni riga in modo leggermente più dettagliato.

Unità di esecuzione

Maggiori informazioni sui microservizi

• Cheat sheet sui microservizi
• Come spiegare i microservizi al tuo CEO
• EBook gratuito:microservizi e architettura orientata ai servizi
• Corso online gratuito:sviluppo di applicazioni cloud native con architetture di microservizi
• Ultimi articoli sui microservizi

L'unità di esecuzione in *nix (come Linux) è un file eseguibile (script binario o interpretato) che, idealmente, legge l'input da stdin e scrive l'output su stdout . Una configurazione di microservizi si occupa di un servizio che espone una o più interfacce di comunicazione, ad esempio API HTTP o gRPC. In entrambi i casi, troverai esempi stateless (essenzialmente un comportamento puramente funzionale) ed esempi stateful, dove, oltre all'input, uno stato interno (persistente) decide cosa succede.

Flusso di dati

Tradizionalmente, i programmi *nix potevano comunicare tramite pipe. In altre parole, grazie a Doug McIlroy, non è necessario creare file temporanei da trasferire e ciascuno può elaborare flussi di dati praticamente infiniti tra i processi. Per quanto ne so, non c'è niente di paragonabile a una pipe standardizzata nei microservizi, a parte il mio piccolo esperimento basato su Apache Kafka del 2017.

Configurazione e parametrizzazione

Come si configura un programma o un servizio, su base permanente o su chiamata? Bene, con i programmi *nix hai essenzialmente tre opzioni:argomenti della riga di comando, variabili di ambiente o file di configurazione in piena regola. Nei microservizi, in genere gestisci documenti YAML (o, peggio ancora, JSON), definendo il layout e la configurazione di un singolo microservizio, nonché le dipendenze e le impostazioni di comunicazione, archiviazione e runtime. Gli esempi includono le definizioni delle risorse Kubernetes, le specifiche del lavoro Nomad o i file Docker Compose. Questi possono o non possono essere parametrizzati; ovvero, o hai un linguaggio di creazione di modelli, come Helm in Kubernetes, o ti ritrovi a fare un sacco di sed -i comandi.

Scoperta

Come fai a sapere quali programmi o servizi sono disponibili e come dovrebbero essere utilizzati? Bene, in *nix, di solito hai un gestore di pacchetti oltre a un buon vecchio; tra di loro, dovrebbero essere in grado di rispondere a tutte le domande che potresti avere. In una configurazione di microservizi, c'è un po' più di automazione nella ricerca di un servizio. Oltre ad approcci su misura come SmartStack di Airbnb o Eureka di Netflix, di solito esistono approcci basati su variabili di ambiente o basati su DNS che ti consentono di scoprire i servizi in modo dinamico. Altrettanto importante, OpenAPI fornisce uno standard di fatto per la documentazione e la progettazione dell'API HTTP e gRPC fa lo stesso per casi ad alte prestazioni più strettamente accoppiati. Ultimo ma non meno importante, prendi in considerazione l'esperienza degli sviluppatori (DX), iniziando con la scrittura di buoni Makefile e finendo con la scrittura dei tuoi documenti con (o in?) stile .

Pro e contro

Sia *nix che i microservizi offrono una serie di sfide e opportunità

Componibilità

È difficile progettare qualcosa che abbia una messa a fuoco chiara e nitida e possa anche giocare bene con gli altri. È ancora più difficile farlo funzionare correttamente su diverse versioni e introdurre le rispettive capacità di gestione dei casi di errore. Nei microservizi, ciò potrebbe significare riprova logica e timeout, forse è un'opzione migliore esternalizzare queste funzionalità in una rete di servizi? È difficile, ma se lo fai bene, la sua riusabilità può essere enorme.

Osservabilità

In un monolito (nel 2018) o in un grande programma che cerca di fare tutto (nel 1984), è piuttosto semplice trovare il colpevole quando le cose vanno male. Ma, in un

yes | tr \\n x | head -c 450m | grep n

o un percorso di richiesta in una configurazione di microservizi che coinvolge, ad esempio, 20 servizi, come si fa a avviare per capire quale si sta comportando male? Fortunatamente abbiamo degli standard, in particolare OpenCensus e OpenTracing. L'osservabilità potrebbe ancora essere il più grande blocco singolo se stai cercando di passare ai microservizi.

Stato globale

Anche se potrebbe non essere un grosso problema per i programmi *nix, nei microservizi, lo stato globale rimane una sorta di discussione. Vale a dire, come assicurarsi che lo stato locale (persistente) sia gestito in modo efficace e come rendere coerente lo stato globale con il minor sforzo possibile.

Conclusione

Alla fine, la domanda rimane:stai usando lo strumento giusto per un determinato compito? Cioè, allo stesso modo un programma *nix specializzato che implementa una gamma di funzioni potrebbe essere la scelta migliore per determinati casi d'uso o fasi, potrebbe essere che un monolito sia l'opzione migliore per la tua organizzazione o carico di lavoro. In ogni caso, spero che questo articolo ti aiuti a vedere i molti, forti parallelismi tra la filosofia Unix e i microservizi, forse possiamo imparare qualcosa dai primi a beneficio dei secondi.