Il est temps pour moi de voler… de rendre

Le cycle de battage médiatique de Gartner , illustré ci-dessous, peut être appliqué à la plupart des aspects de la technologie :

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 les téléavertisseurs (ou bips), qui étaient courants avant que les téléphones/appareils mobiles n'atteignent le plateau de productivité.

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 annonce récente m'a fait me demander s'il était temps d'envisager d'autres options.

Comme j'ai eu une expérience positive avec Render 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 :

• 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 mode maintenance . Cela interdira à tout consommateur d'accéder aux applications ou aux services.

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 Heroku Migrator de Render pour migrer facilement Heroku Postgres vers Render Postgres, mais je devais d'abord convertir de MySQL à PostgreSQL.

Au départ, j'ai commencé par le chemin pgloader , 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.

Au lieu de cela, j'ai choisi d'utiliser NMIG pour convertir MySQL en PostgreSQL. Pour plus d'informations, veuillez consulter la section « Faits saillants de la conversion de la base de données » ci-dessous.

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 ces instructions 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.

Enfin, j'ai créé les variables d'environnement nécessaires dans le tableau de bord de rendu pour le service Spring Boot RESTful API et le courtier de messages RabbitMQ.

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 GitLab CI/CD pour le déployer sur Heroku dans mon référentiel source.

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é NMIG , qui est un utilitaire de conversion de base de données basé sur Node.js.

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 pgAdmin pour importer la sauvegarde dans une instance Postgres nouvellement créée sur Heroku.

Avec l'instance Postgres en cours d'exécution et les données validées, j'ai créé une nouvelle base de données Postgres sur le Render PaaS. Ensuite, tout ce que j'avais à faire était de lancer la commande suivante :

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/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 ancien collègue 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 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 !