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 :    À quelle heure part votre vol ? Personne #1 :    Plus tard cette année. Personne #2 :  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  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.   Prédicteur de genre chinois   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 __   __platform dans les publications suivantes : Render   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  et je voulais voir comment cela fonctionnait aussi.   Spécification du plan directeur  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  , j'ai pu créer rapidement un Blueprint pour mes services Spring Boot exécutés via des conteneurs Docker :   ici   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   , dans un fichier appelé   . Après validation et fusion de cette modification, le service était prêt à être déployé sur la plateforme Render. birth-predictor render.yaml  Dans le tableau de bord de rendu, j'ai sélectionné le   Option   :  nouveau | 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   , le processus de déploiement a démarré :  Appliquer 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 !

Super

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Conception de microservices axée sur les objectifs

Conception de microservices axée sur les objectifs

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps