Le , illustré ci-dessous, peut être appliqué à la plupart des aspects de la technologie : cycle de battage médiatique de Gartner Au fur et à mesure que de nouvelles innovations entrent dans leurs cycles respectifs, les attentes sont finalement réalisées, ce qui conduit à un certain niveau d'adoption. L'objectif de chaque innovation est d'atteindre le plateau de productivité où les consommateurs ont déterminé que la récompense de l'adoption de l'innovation l'emporte de loin sur les risques connus. En même temps, il y a un point où le plateau de productivité commence à diminuer, conduisant à un exode loin de cette innovation. Un exemple simple serait (ou bips), qui étaient courants avant que les téléphones/appareils mobiles n'atteignent le plateau de productivité. les téléavertisseurs En tant que technologues, nous nous efforçons de fournir des fonctionnalités, des cadres, des produits ou des services qui augmentent le plateau de productivité. Il en va de même pour ceux que nous utilisons. Récemment, j'ai eu l'impression que ma plate-forme d'hébergement actuelle commençait à tomber du plateau de productivité. En fait, une m'a fait me demander s'il était temps d'envisager d'autres options. annonce récente Comme j'ai eu une expérience positive avec PaaS, je voulais voir avec quelle facilité je pouvais convertir une de mes applications Heroku, adopter PostgreSQL et migrer vers Render. Je décris ce voyage dans cette série en deux parties : Render Partie 1 : Nous nous concentrerons sur la migration de mes services backend (Spring Boot et ClearDB MySQL). Partie 2 : Nous allons nous concentrer sur le portage et la migration de mon client Angular frontal. Pourquoi j'ai choisi le rendu Si vous n'avez jamais entendu parler de Render auparavant, consultez certaines de mes publications précédentes : Ne passez aucun temps sur DevOps avec Render PaaS Le cloud parfait : AWS, GCP et Azure tout-en-un Conception de microservices axée sur les objectifs Lancez votre idée de startup en un jour Comment j'ai utilisé Render pour faire évoluer facilement mon application de microservices Ce que je trouve passionnant à propos de Render, c'est qu'ils continuent à gravir la pente de l'illumination tout en fournissant activement une solution solide aux adoptants reconnaissant le plateau de la productivité. Comme je l'ai noté dans mes articles, Render offre une promesse « Zero DevOps ». Cela correspond parfaitement à mes besoins puisque je n'ai pas le temps de me concentrer sur les tâches DevOps. La plateforme Heroku a plusieurs choses que je n'aime pas trop : Les redémarrages quotidiens ont entraîné des temps d'arrêt inattendus pour l'un de mes services. Postgres d'entrée de gamme (tout ce dont j'ai vraiment besoin) sur Heroku permet quatre heures d'indisponibilité par mois. Les niveaux de prix, du point de vue du consommateur, ne s'adaptent pas bien. Du point de vue des prix, je m'attends à réaliser des économies importantes après la migration de toutes mes applications et services de Heroku vers Render. Ce qui est plus étonnant, c'est que j'obtiens une meilleure mémoire et un meilleur processeur pour ce prix, avec une mise à l'échelle linéaire à mesure que l'empreinte de mon application doit augmenter. Conversion d'un service unique Comme je l'ai indiqué ci-dessus, il s'agit de la première partie d'une série en deux parties, et je vais me concentrer sur le niveau de service dans cet article. Le service que je souhaite convertir possède les attributs suivants : Service d'API RESTful Spring Boot Courtier de messages Heroku CloudAMQP (RabbitMQ) Base de données Heroku ClearDB (MySQL) (schéma unique) Intégration Okta Du côté de Render PaaS, la nouvelle conception du service ressemblera à ceci : Render Web Service hébergeant Spring Boot RESTful API Service (via Docker) Render Private Service hébergeant RabbitMQ Message Broker (via Docker) Rendre Postgres avec la possibilité pour plusieurs schémas d'exister Intégration Okta Vous trouverez ci-dessous une comparaison côte à côte des deux écosystèmes : Mon plan d'attaque de haut niveau pour la conversion est le suivant : Préparer Heroku pour la conversion Avant de commencer, il est recommandé de mettre tous les services Heroku existants en . Cela interdira à tout consommateur d'accéder aux applications ou aux services. mode maintenance Bien que le code source doive déjà être sauvegardé et stocké dans un référentiel basé sur git, il est judicieux de s'assurer qu'une sauvegarde de la base de données a été créée avec succès. Conversion des services Heroku Du point de vue de la conversion, j'avais deux éléments à convertir : le service lui-même et la base de données ClearDB (MySQL). La conversion de mon service Spring Boot RESTful n'a pas impliqué beaucoup de travail. En fait, j'ai pu tirer parti de l'approche que j'ai utilisée pour un de mes . projets précédents Pour la base de données, j'avais besoin de convertir de MySQL à PostgreSQL. Mon objectif était d'utiliser de Render pour migrer facilement Heroku Postgres vers Render Postgres, mais je devais d'abord convertir de MySQL à PostgreSQL. Heroku Migrator Au départ, j'ai commencé par le chemin , qui semblait être une approche courante pour la conversion de la base de données. Cependant, l'utilisation de mon MacBook Pro à puce M1 a entraîné des problèmes inattendus. pgloader Au lieu de cela, j'ai choisi d'utiliser pour convertir MySQL en PostgreSQL. Pour plus d'informations, veuillez consulter la section « » ci-dessous. NMIG Faits saillants de la conversion de la base de données Créer des services dans Render Après avoir converti la base de données et le service Spring Boot RESTful exécuté dans Docker, l'étape suivante consistait à créer un service Web de rendu pour le service Spring Boot RESTful API. C'était aussi simple que de créer le service, de lui donner un nom et de pointer vers le référentiel approprié pour mon code dans GitLab. Comme j'avais également besoin d'un service RabbitMQ, j'ai suivi pour créer un service privé RabbitMQ exécuté sur Render. Cela comprenait l'établissement d'une petite quantité de stockage sur disque pour conserver les messages qui n'ont pas été traités. ces instructions Enfin, j'ai créé les nécessaires dans le tableau de bord de rendu pour le service Spring Boot RESTful API et le courtier de messages RabbitMQ. variables d'environnement Initialiser et valider les services La prochaine étape consistait à démarrer mes services. Une fois qu'ils étaient en cours d'exécution et que les API ont été validées à l'aide de ma collection Postman, j'ai mis à jour mon application cliente pour qu'elle pointe vers le nouvel emplacement du service Render. Une fois que tout était opérationnel, mon tableau de bord de rendu est apparu comme indiqué ci-dessous : Prochaines étapes Il ne restait plus qu'à supprimer les bases de données toujours en cours d'exécution sur Heroku et à supprimer les services migrés de l'écosystème Heroku. Lorsque j'utilisais Heroku, chaque fois que je fusionnais du code dans la branche principale de mon référentiel de services, le code était automatiquement déployé, à condition que j'utilise dans mon référentiel source. GitLab CI/CD pour le déployer sur Heroku Cependant, il n'est pas nécessaire d'ajouter du code au référentiel de fichiers source avec Render. J'avais simplement besoin de spécifier la branche Build & Deploy dans le tableau de bord de rendu pour le service : J'adore la promesse Zero DevOps. Faits saillants de la conversion de la base de données En suivant les étapes ci-dessus, la conversion de Heroku vers Render s'est déroulée sans heurts et avec succès. Le plus grand défi pour moi était la conversion des données. À un niveau élevé, cela se résumait principalement à une série de commandes exécutées à partir du terminal de mon MacBook Pro. Tout d'abord, j'ai démarré une instance Postgres locale via Docker : docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres Ensuite, j'ai créé une base de données appelée "exemple" en utilisant la commande suivante (ou pgAdmin) : createdb example Pour convertir mon instance ClearDB (MYSQL) exécutée sur Heroku en mon exemple de base de données Postgres exécutée localement, j'ai utilisé , qui est un utilitaire de conversion de base de données basé sur Node.js. NMIG Après avoir installé NMIG, j'ai configuré le fichier config.json avec les informations et les informations d'identification du point de terminaison de la base de données, puis j'ai exécuté : /path/to/nmig$ npm start Ensuite, j'ai sauvegardé les données dans un fichier à l'aide de la commande suivante : pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump Plutôt que de créer une URL signée dans AWS, j'ai simplement utilisé le client pour importer la sauvegarde dans une instance Postgres nouvellement créée sur Heroku. pgAdmin Avec l'instance Postgres en cours d'exécution et les données validées, j'ai sur le Render PaaS. Ensuite, tout ce que j'avais à faire était de lancer la commande suivante : créé une nouvelle base de données Postgres pg_restore --verbose --no-acl --no-owner -d postgres://username:password@hostname.zone-postgres.render.com/example example.dump Leçons apprises en cours de route En repensant à ma conversion de Heroku à Render, voici quelques leçons que j'ai apprises en cours de route : J'ai eu un problème mineur avec la base de données Postgres mettant à jour la valeur date/heure pour inclure le décalage DST. Cela a peut-être été un problème avec ma conception de base de données d'origine, mais je voulais le transmettre. Dans mon cas, la colonne impactée n'est utilisée que pour les valeurs Date, ce qui n'a pas changé pour moi. J'ai inclus une colonne de base de données nommée END dans l'une de mes tables, ce qui a causé un problème lorsque Postgres ou Hibernate ont tenté de renvoyer une requête native. Le service a vu le nom de la colonne END et l'a injecté en tant que mot-clé SQL. J'ai simplement renommé la colonne pour résoudre ce problème, ce que j'aurais dû savoir ne pas faire en premier lieu. Avec Render, j'avais besoin de faire du service RabbitMQ un service privé car l'option Web Service n'exposait pas le port attendu. Cependant, avec cette approche, j'ai perdu la possibilité d'accéder à l'interface d'administration de RabbitMQ, car les services privés ne sont pas exposés en externe. Il semble que Render prévoit de répondre à cette . demande de fonctionnalité Dans l'ensemble, ces obstacles mineurs n'étaient pas suffisamment importants pour influencer ma décision de migrer vers Render. Conclusion L'aspect le plus important du plateau de productivité de Gartner est de fournir des produits, des cadres ou des services qui permettent aux consommateurs de prospérer et d'atteindre leurs objectifs. Le plateau de la productivité n'est pas destiné à être flashy ou à la mode - dans un sens métaphorique. Lorsque j'ai partagé cette conclusion avec Ed, un Developer Advocate chez Render, sa réponse était quelque chose que je voulais partager : "Render n'essaie manifestement pas d'être" à la mode ". Nous essayons d'être sans surprise et fiables. La réponse d'Ed a profondément résonné en moi et m'a rappelé une époque où mon m'avait dit que mon code lui paraissait «ennuyeux». Son commentaire s'est avéré être le plus grand compliment que j'aurais pu recevoir. Vous pouvez en savoir plus . ancien collègue ici Dans tous les aspects de la technologie, la décision sur le fournisseur à sélectionner doit toujours correspondre à votre position technologique. Si vous n'êtes pas sûr, le cycle de battage publicitaire de Gartner est un excellent point de référence, et vous pouvez commencer par vous abonner à leur service . ici Je me suis concentré sur l'énoncé de mission suivant, qui, selon moi, peut s'appliquer à tout professionnel de l'informatique : « Consacrez votre temps à fournir des caractéristiques/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 Lorsque je regarde l'écosystème Render PaaS, je vois une solution qui adhère à mon énoncé de mission tout en résidant dans ma préférence de cycle de battage médiatique. Ce qui améliore les choses, c'est que je m'attends à voir une économie de 44 % sur mes frais personnels, d'autant plus que mes services doivent évoluer verticalement. Pour ceux qui envisagent des solutions d'hébergement, je recommande d'ajouter Render à la liste des fournisseurs pour examen et analyse. Vous pouvez commencer gratuitement en suivant . ce lien La deuxième partie de cette série sera passionnante. Je montrerai comment éviter de payer pour mon client statique écrit en Angular et profiter du service gratuit Static Sites de Render en utilisant Vue ou Svelte. Quel framework vais-je choisir… et pourquoi ? Passez une très bonne journée !

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

Making security fun one episode at a time

Il est temps pour moi de voler… de rendre

Il est temps pour moi de voler… de rendre

Trop long; Pour lire

John Vester

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Il est temps pour moi de voler… de rendre

Trop long; Pour lire

John Vester

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES