Conception de microservices axée sur les objectifs

Les mots à la mode ne sont pas quelque chose à quoi je m'attendais quand j'ai commencé ma carrière. À cette époque, la plupart des nouvelles technologiques arrivaient dans des publications hebdomadaires sur papier comme InformationWeek et Network World. Je me souviens m'être dit: "Mec, ils utilisent ces mêmes mots encore et encore chaque semaine."

Cela s'est traduit par des personnes utilisant des mots à la mode… tout le temps. À l'époque, mes deux mots à la mode favoris étaient des références à Internet en tant que « World Wide Web » et « autoroute de l'information ». Je me suis toujours demandé s'il y aurait une autoroute super-duper à un moment donné.

Cependant, récemment, j'ai remarqué que les mots à la mode sont utilisés comme espaces réservés là où ils n'ont pas tout à fait de sens. Des termes tels que microservices, architecture pilotée par les événements, IA et ML sont utilisés dans des contextes, ce qui m'amène à conclure que de nombreuses personnes ne comprennent pas très bien ces termes. Je ne m'attendais pas à ça non plus...

Imaginez cette simple conversation liée à une question mal comprise :

Personne #1 : À quelle heure part votre vol ?

Personne #2 : Plus tard cette année.

Alors que la Personne #2 fournit une réponse qui n'est pas incorrecte, la réponse ne rapporte pas vraiment de valeur à l'enquête de la Personne #1.

Dans le même ordre d'idées, la quête de migration vers les microservices a connu des défis similaires. Plus souvent qu'autrement, j'ai travaillé avec des clients et des entreprises dont la conception de «microservices» a abouti à un seul monoservice. Fondamentalement, une application monolithique a été remplacée par une très grosse API RESTful.

Pour cette publication, j'ai pensé qu'il serait amusant de parcourir un exemple de création d'une conception de microservice axée sur l'objectif… de la bonne manière.

La conception de microservices axée sur les objectifs

Un microservice axé sur l'objectif est un service qui peut être autonome et qui peut inclure un magasin de persistance dédié si nécessaire. En étant axé sur les objectifs, le microservice fournira un ensemble ciblé d'informations et sera le système d'enregistrement des données régies au sein des API associées.

En adoptant l'approche de microservice axée sur l'objectif, les utilisateurs peuvent ajouter des nœuds supplémentaires et réduire les nœuds existants afin de répondre aux besoins de l'API à ce moment précis.

Par exemple, un microservice axé sur l'objectif et axé sur un aspect de l'impôt sur le revenu peut connaître l'utilisation la plus élevée au cours de la première partie de l'année et nécessiter moins d'instances exécutées au second semestre.

Concentrons-nous sur la création d'une conception de microservice axée sur l'objectif en utilisant un exemple très simple.

Création d'un microservice basé sur Docker

La Prédicteur de genre chinois est un système de grille utilisé pour prévoir le sexe d'un bébé à la naissance. Cela se fait en fournissant le mois de conception et l'âge actuel de la mère au moment de la conception.

La rumeur veut que la famille impériale de la dynastie Qing se soit appuyée sur cette même grille pour la sélection du sexe des fils, qui étaient favorisés pour le travail et l'argent qu'ils pouvaient fournir à leurs familles ainsi que pour perpétuer la lignée familiale.

Ci-dessous une illustration de la grille Chinese Gender Predictor :

Par exemple, une mère de 18 ans qui a conçu un enfant en janvier produirait un bébé de sexe féminin.

Pour cette publication, nous allons créer un microservice axé sur l'objectif qui renvoie une prédiction de genre basée sur les mêmes critères. La charge utile résultante pour l'exemple ci-dessus apparaîtrait comme indiqué ci-dessous :

 { "month": 1, "age": 18, "gender": "female", "errorMessage": null }

Le microservice utilisera Java et Spring Boot et utilisera un Dockerfile en plusieurs étapes pour compiler le service et créer une image Docker pouvant héberger les API de prédiction de naissance.

Le code du service est disponible sur GitLab à l'adresse suivante :

https://gitlab.com/johnjvester/birth-predictor

Création d'un motif reproductible à l'aide de plans de rendu

J'ai écrit sur la __ Render __platform dans les publications suivantes :

• Ne passez aucun temps sur DevOps avec Render PaaS
• Le cloud parfait : AWS, GCP et Azure tout-en-un

Pour mes instances personnelles exécutées sur Render, j'ai utilisé le langage de programmation Go, des sites statiques et une instance Postgres. Cette fois, j'ai écrit le service en Java/Spring Boot. Bien que la prise en charge native de Java n'existe pas encore, la plate-forme Render inclut la prise en charge de tout ce qui s'exécute dans un conteneur Docker.

Étant donné que le service de prédiction des naissances comprend un Dockerfile en plusieurs étapes, je voulais voir à quel point il est facile de déployer un service basé sur Docker sur la plate-forme Render. Cependant, j'ai remarqué la Spécification du plan directeur et je voulais voir comment cela fonctionnait aussi.

Qu'est-ce qu'un plan ?

Un Blueprint est la mise en œuvre par Render de l'infrastructure en tant que code (IaC). IaC est aussi quelque chose que je regroupe dans un concept plus large appelé "* as Code". Les organisations qui doivent gérer un déploiement de plusieurs services ou qui ont des services nécessitant beaucoup d'options peuvent définir leur infrastructure de rendu (services, bases de données et groupes d'environnements) sous forme de code dans un fichier render.yaml.

Utilisation du plan de rendu

S'appuyant sur l'exemple Blueprint fourni ici , j'ai pu créer rapidement un Blueprint pour mes services Spring Boot exécutés via des conteneurs Docker :

 services: - type: web name: restful-api-spring-boot env: docker region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

À partir de là, j'ai personnalisé les données YAML pour le service de prédiction des naissances afin de mettre à jour la propriété name et d'ajouter une propriété repo, comme indiqué ci-dessous :

 services: - type: web name: birth-predictor env: docker repo: https://gitlab.com/johnjvester/birth-predictor region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

Ces informations ont été stockées à la racine du référentiel birth-predictor , dans un fichier appelé render.yaml . Après validation et fusion de cette modification, le service était prêt à être déployé sur la plateforme Render.

Dans le tableau de bord de rendu, j'ai sélectionné le nouveau | Option plan :

Ensuite, j'ai sélectionné le référentiel de prédicteurs de naissance, que j'ai connecté à mon compte GitLab en utilisant les instructions trouvées ici .

Comme j'utilisais un Blueprint, tout ce que j'avais à faire était de fournir un nom de groupe de services pour mon nouveau service :

Après avoir appuyé sur le bouton Appliquer , le processus de déploiement a démarré :

Quelques minutes plus tard, le service était déployé sans problème :

Prédicteur de naissance en action

Avec le service de prédiction de naissance en cours d'exécution, je peux émettre la commande cURL suivante pour obtenir une nouvelle prédiction :

 curl --location --request POST 'https://birth-predictor.onrender.com/predict' \ --header 'Content-Type: application/json' \ --data-raw '{ "conceptionMonth" : 11, "conceptionAge" : 43 }'

La charge utile de réponse résultante ressemble à ceci :

 { "month": 11, "age": 43, "gender": "male", "errorMessage": null }

Il se trouve que cette information correspond au mois de conception et à l'âge de ma femme au moment où notre fils (Finny) a été conçu. En août 2017, il est arrivé !

Tout comme ils l'ont fait pendant la dynastie Qing, nous avons pu compter sur le prédicteur de genre chinois pour prédire avec succès le sexe de notre enfant.

Conclusion

Depuis 2021, j'essaie de vivre selon l'énoncé de mission suivant, qui, selon moi, peut s'appliquer à tout professionnel de l'informatique :

«Consacrez votre temps à fournir des fonctionnalités / fonctionnalités qui étendent la valeur de votre propriété intellectuelle. Tirez parti des cadres, des produits et des services pour tout le reste.

- J.Vester

La spécification Blueprints de Render adhère à mon énoncé de mission en permettant aux équipes de fonctionnalités et de services de se concentrer sur la réalisation des objectifs et cibles établis, sans se soucier de tout ce qui concerne DevOps.

Une fois le service, le composant ou l'application prêt, il suffit aux équipes d'inclure le fichier render.yaml à la racine de leur référentiel, puis de créer un nouveau service sur la plateforme Render à l'aide de l'option Blueprint. À l'avenir, toutes les mises à jour du référentiel connecté se déploieront automatiquement quelques minutes après la validation du code dans la branche indiquée.

La plate-forme Render vit selon une mentalité Zero DevOps, ce qui est évident à l'origine du concept Blueprint. Les développeurs de fonctionnalités et de services veulent et doivent se concentrer sur la fourniture de mises à jour et de fonctionnalités qui offrent le plus de valeur à leurs parties prenantes. Render comprend vraiment cette réalité.

Je suis certain que les mots à la mode feront toujours partie de l'espace technologique. Cependant, comprendre et adopter la véritable intention derrière ces mots à la mode est quelque chose que j'espère que les technologues poursuivront.

Si vous êtes intéressé par le code source de cette publication, vous pouvez le trouver sur GitLab à l'adresse suivante :

https://gitlab.com/johnjvester/birth-predictor

Passez une très bonne journée !