De multiples raisons conduisent à migrer une base de données. On peut chercher à réduire les coûts, augmenter la performance, passer dans le cloud ou lâcher une technologie datée. En janvier, Gartner prédisait que d’ici 2025, la moitié des fournisseurs indépendants de système de gestion de base de données (SGBD) allaient s’arrêter, amenant leurs clients à migrer vers d’autres solutions. Certaines bases de données ancrées dans le paysage, comme Oracle, sont défiées depuis des années par des alternatives bien connues, au premier rang desquelles PostgreSQL, un choix vers lequel se tournent de façon affichée un certain nombre de projets de migration. Mais l’inverse peut aussi se produire, en particulier lorsqu’Oracle est lui-même concerné au premier chef. Ainsi, l’éditeur, qui reste en tête des bases de données les plus populaires - quoique perdant du terrain - devant MySQL, et Microsoft SQL Server (cf le dernier classement de db-engines), vient-il d’exposer dans un blog les bénéfices d’une migration opérée de PostgreSQL sur Rackspace et RDS sur AWS vers sa base de données autonome dans le cloud. Le projet a porté sur l’infrastructure des solutions de supply chain natives cloud de LogFire, un éditeur spécialisé dans l’optimisation logistique acquis par Oracle en 2016. Depuis leur rachat, les applications de LogFire ont été renommées Oracle Warehouse Management Cloud.  

Pour transformer la gestion de la chaîne d’approvisionnement en aidant les entreprises à passer dans le cloud, LogFire a développé une application SaaS permettant d'intégrer divers systèmes et données pour supprimer les silos, explique Diego Pantoja-Navajas, fondateur de l’entreprise. « Elle devait être à l’épreuve des balles parce que de nombreuses catégories d’entreprises allaient en dépendre ». Au départ, les base de données de production s’exécutaient sur PostgreSQL dans l’infrastructure cloud de Rackspace. Puis les bases de test ont été migrées vers Amazon RDS pour PostgreSQL pour réduire les coûts tout en conservant les databases de production sur Rackspace avec une gestion managée puisque LogFire n’avait pas d’équipes de DBA en interne. « Bien que RDS ait simplifié la mise à l’échelle, il y avait des problèmes de performance et de fiabilité qui le rendait inadapté à nos bases de production », indique de son côté,Arun Murugan, VP, responsable du développement produit WMS chez LogFire. Il cite, entre autres, le réglage manuel de nombreux paramètres pour maintenir les niveaux de performance, l’absence de réplication bidirectionnelle automatisée de la base de données, ainsi que des temps d’arrêt pour appliquer les correctifs et pour la maintenance.  

Une migration engagée à l'été 2019

Si la pandémie de Covid-19 a exposé d’un seul coup l’importance des supply chains à travers l’ensemble des secteurs d’activité, LogFire avait identifié dès 2019 la pression exercée par les pics de demande sur son architecture. L’éditeur ne pouvait pas ajouter de fonctionnalités au rythme qu’exigeait la demande ses clients, explique-t-il. Ses équipes passaient beaucoup trop de temps à gérer manuellement leurs databases pour assurer une disponibilité 24/7. Même si les bases cloud s’ajustaient dynamiquement, leur mise à jour nécessitait des temps d’arrêt, d’où indisponibilité qui ralentissait l’ensemble des processus, explique Oracle. A l’été 2019, LogFire décide de passer son application et ses bases de données sur OCI, le cloud public d’Oracle.

« Après une évaluation approfondie », assure le fournisseur, « des différentes options d'exécution de bases de données PostgreSQL sur OCI, ou Oracle Autonomous Database », l’ensemble des 700 bases de données PostgreSQL ont été migrées vers Autonomous Transaction Processing (ATP), base de données autonome d’Oracle optimisée pour les traitements OLTP. ATP, c’est l'Autonomous Database qui s’exécute sur des serveurs Exadata dans le cloud public d’Oracle avec Real application clusters (RAC) et des fonctionnalités multitenants. La migration a pris un peu plus de 7 mois. Selon l’éditeur, elle aurait pris moins de 3 mois sans les retards pris pour éviter de perturber la supply chain des clients opérant dans la distribution de détail et devant gérer des pics saisonniers.

Traitement des commandes accéléré, recours au ML

En février 2020, l’ensemble de la pile applicative avait été migrée sur Oracle Cloud Infrastructure. La migration a été facilitée par le fait que l’application de LogFire utilisait une architecture cloud native basées sur des services Rest. Des appels API ont permis de se connecter aux systèmes non standards pour automatiser les opérations de logistique (prélèvement, emballage, tri, expédition des colis), sans devoir recourir à des intégrations complexes. Autre point signalé par Oracle, l’architecture d’application de LogFire inclut le mappeur relationnel d’objets Django (ORM) qui fournit une couche d’isolation des databases, ce qui rend les requêtes indépendantes de la base de données. « Cela signifiait que 75% des requêtes SQL générées par ORM pouvaient être apportées telles quelles vers Oracle », explique le billet. Seules un quart des requêtes codées manuellement nécessitaient un certain niveau de réglages pour ATP. Et, enfin, puisque PostgreSQL et ATP sont tous les deux basés sur SQL, la formation des utilisateurs en était d’autant réduite, d’autant que la plupart des fonctions sont automatisées dans ATP.

A l’issue de cette migration, plusieurs bénéfices ont été enregistrés qu’Oracle n’allait évidemment pas se priver d’exposer. Parmi ceux-ci, la rapidité de traitement des commandes a été augmentée de 55%, l’augmentation du nombre d’utilisateurs de 50%, le TCO a été réduit par l’automatisation des tâches permises par Autonomous Transaction Processing, les temps d’interruption des bases de données ont été supprimés et la sécurité a été renforcée. A cela s’est ajouté la capacité de recourir aux algorithmes d’apprentissage machine intégrés à la base de données d’Oracle. Selon le billet, LogFire a pu déployer plus de 150 algorithmes AI/ML différents, notamment pour prédire les pics horaires dans les centres de distribution, pour calculer les temps de prélèvements moyens, pour mettre en place des tâches de réapprovisionnement automatisées ou, encore, créer des ordres de prélèvements prédictifs en fonction des données historiques.