En 1984, Rob Pike et Brian W. Kernighan ont publié un article intitulé "Program Design in the Unix Environment" dans le AT&T Bell Laboratories Technical Journal, dans lequel ils ont défendu la philosophie Unix, en utilisant l'exemple de cat -v
Cela vous semble familier ?
Ouais je le pensais. C'est à peu près la définition des microservices proposée par James Lewis et Martin Fowler :
En bref, le style architectural de microservice est une approche de développement d'une application unique sous la forme d'une suite de petits services, chacun s'exécutant dans son propre processus et communiquant avec des mécanismes légers, souvent une API de ressource HTTP.
Alors qu'un programme *nix ou un microservice peut être très limité ou même pas très intéressant en soi, c'est la combinaison de ces unités travaillant indépendamment qui révèle leur véritable avantage et, par conséquent, leur puissance.
* nix contre microservices
Le tableau suivant compare les programmes (tels que cat ou lsof ) dans un environnement *nix contre des programmes dans un environnement de microservices.
| *nix | Microservices | |
|---|---|---|
| Unité d'exécution | programme utilisant stdin /stdout | service avec API HTTP ou gRPC |
| Flux de données | Tuyaux | ? |
| Configuration ¶métrage | Arguments de ligne de commande, variables d'environnement, fichiers de configuration | Documents JSON/YAML |
| Découverte | Gestionnaire de package, mec, faire | DNS, variables d'environnement, OpenAPI |
Explorons chaque ligne un peu plus en détail.
Unité d'exécution
En savoir plus sur les microservices
- Aide-mémoire sur les microservices
- Comment expliquer les microservices à votre PDG
- Livre numérique gratuit :microservices et architecture orientée services
- Cours en ligne gratuit :Développer des applications cloud natives avec des architectures de microservices
- Derniers articles sur les microservices
L'unité d'exécution dans *nix (comme Linux) est un fichier exécutable (script binaire ou interprété) qui, idéalement, lit les entrées de stdin et écrit la sortie sur stdout . Une configuration de microservices traite d'un service qui expose une ou plusieurs interfaces de communication, telles que les API HTTP ou gRPC. Dans les deux cas, vous trouverez des exemples sans état (essentiellement un comportement purement fonctionnel) et des exemples avec état, où, en plus de l'entrée, un état interne (persistant) décide de ce qui se passe.
Flux de données
Traditionnellement, les programmes *nix pouvaient communiquer via des pipes. En d'autres termes, grâce à Doug McIlroy, vous n'avez pas besoin de créer des fichiers temporaires à transmettre et chacun peut traiter des flux de données pratiquement sans fin entre les processus. A ma connaissance, il n'y a rien de comparable à un tube standardisé en microservices, à part ma petite expérience basée sur Apache Kafka de 2017.
Configuration et paramétrage
Comment configurez-vous un programme ou un service, soit sur une base permanente ou sur appel ? Eh bien, avec les programmes * nix, vous avez essentiellement trois options :arguments de ligne de commande, variables d'environnement ou fichiers de configuration complets. Dans les microservices, vous traitez généralement des documents YAML (ou pire encore, JSON), définissant la disposition et la configuration d'un seul microservice ainsi que les dépendances et les paramètres de communication, de stockage et d'exécution. Les exemples incluent les définitions de ressources Kubernetes, les spécifications de travail Nomad ou les fichiers Docker Compose. Ceux-ci peuvent être paramétrés ou non; c'est-à-dire que soit vous avez un langage de modèle, tel que Helm dans Kubernetes, soit vous vous retrouvez à faire énormément de sed -i commandes.
Découverte
Comment savez-vous quels programmes ou services sont disponibles et comment ils sont censés être utilisés ? Eh bien, dans *nix, vous avez généralement un gestionnaire de paquets ainsi qu'un bon vieil homme ; entre eux, ils devraient pouvoir répondre à toutes les questions que vous pourriez avoir. Dans une configuration de microservices, la recherche d'un service est un peu plus automatisée. En plus des approches sur mesure comme SmartStack d'Airbnb ou Eureka de Netflix, il existe généralement des approches basées sur les variables d'environnement ou basées sur le DNS qui vous permettent de découvrir des services de manière dynamique. Tout aussi important, OpenAPI fournit une norme de facto pour la documentation et la conception des API HTTP, et gRPC fait de même pour les cas hautes performances plus étroitement couplés. Enfin, tenez compte de l'expérience des développeurs (DX), en commençant par écrire de bons Makefiles et en terminant par écrire vos docs avec (ou dans ?) style .
Avantages et inconvénients
*nix et les microservices offrent un certain nombre de défis et d'opportunités
Composabilité
Il est difficile de concevoir quelque chose qui a une orientation claire et nette et qui peut également bien jouer avec les autres. Il est encore plus difficile de bien comprendre les différentes versions et d'introduire des capacités de gestion des cas d'erreurs respectives. Dans les microservices, cela peut signifier une logique de nouvelle tentative et des délais d'attente. Peut-être est-il préférable d'externaliser ces fonctionnalités dans un maillage de services ? C'est difficile, mais si vous le faites bien, sa réutilisabilité peut être énorme.
Observabilité
Dans un monolithe (en 2018) ou un gros programme qui essaie de tout faire (en 1984), il est assez simple de trouver le coupable quand les choses tournent mal. Mais, dans un
yes | tr \\n x | head -c 450m | grep nou un chemin de requête dans une configuration de microservices qui implique, disons, 20 services, comment pouvez-vous même commencer savoir lequel se comporte mal ? Heureusement, nous avons des normes, notamment OpenCensus et OpenTracing. L'observabilité reste peut-être le principal obstacle si vous envisagez de passer aux microservices.
État global
Bien que ce ne soit pas un si gros problème pour les programmes * nix, dans les microservices, l'état global reste un sujet de discussion. À savoir, comment s'assurer que l'état local (persistant) est géré efficacement et comment rendre l'état global cohérent avec le moins d'effort possible.
Conclusion
Au final, la question demeure :utilisez-vous le bon outil pour une tâche donnée ? Autrement dit, de la même manière qu'un programme * nix spécialisé mettant en œuvre une gamme de fonctions peut être le meilleur choix pour certains cas d'utilisation ou phases, il se peut qu'un monolithe soit la meilleure option pour votre organisation ou votre charge de travail. Quoi qu'il en soit, j'espère que cet article vous aidera à voir les nombreux parallèles solides entre la philosophie Unix et les microservices. Peut-être pouvons-nous apprendre quelque chose de la première au profit de la seconde.