OCS Inventory : refonte du backend, défis techniques et choix stratégiques

La refonte d’OCS Inventory vers la version 3.0 se poursuit par le backend.

Après avoir abordé la refonte du frontend dans une précédente interview, cet article se concentre sur le backend, composant essentiel d’OCS Inventory. Le backend gère le stockage et la mise en forme des données, rendant celles-ci exploitables par les autres composants comme l’agent et le frontend. Bien que ce composant soit invisible pour l’utilisateur, la refonte du backend est cruciale pour garantir la modularité, la performance et la pérennité de la plateforme, en intégrant des choix technologiques adaptés aux évolutions futures du projet.

Lors de notre précédent article, nous avions parlé du frontend et de son importance dans l’expérience utilisateur. Aujourd’hui, intéressons-nous à la refonte du backend, le cœur du système. Peux-tu nous rappeler en quelques mots quel est son rôle ?

Le backend est le composant permettant de gérer le stockage ainsi que la mise en forme des données afin que celles-ci soient utilisables ainsi qu’injectable pour les autres composants (Agent et Frontend). 

Le backend constitue le cœur de l’application bien que celui-ci reste invisible aux yeux des utilisateurs.

Quel sont les enjeux de la refonte du backend ?

Chaque composant présente à la fois des enjeux globaux, liés à la refonte du produit, et des enjeux propres à sa nature même. 

Certains points ont déjà été abordés dans le précédent article, pour faire un bref rappel :

• Le choix technologique constitue un facteur déterminant. Il doit garantir la pérennité du produit, sa capacité à évoluer et à s’adapter sans contraintes majeures liées à une architecture figée ou à un framework limité. 

  
  

• La manière dont le code est structuré, ainsi que sa qualité, joue un rôle clé dans la réussite du projet. La mise en place de standards de développement permet notamment d’assurer la lisibilité, la maintenabilité et la cohérence du code dans le temps. 

  
  

• Enfin, l’analyse des limites et des difficultés rencontrées sur la solution actuelle est essentielle. Elle permet d’éviter la reproduction d’erreurs passées et de sortir des schémas de conception qui freinent l’évolution du produit.

Il y a également des enjeux spécifiques au composant pour le backend :

• Permettre un interfaçage simple et efficace avec tout type de système de base de données. L’intégration d’un ORM afin que l’application soit agnostique à la technologie de BDD est un point crucial afin de permettre au produit de s’adapter aux standard et contraintes de l’entreprise ou organisation l’utilisant.

  
  

• La modularité du modèle de données ainsi que la gestion des mises à jour par le biais de migration est un enjeu important afin de pouvoir facilement mettre à jour le MCD et de migrer ou mettre à jour de manière simple l’application.

  
  

• Le backend étant un point central de l’application, celui-ci doit être performent et être réactif. Chaque seconde de traitement supplémentaire est directement impactée sur l’affichage utilisateur (frontend) ou sur la réactivité des agents.

  
  

• La mise à disposition d’une API complète permettant de facilement interagir avec l’application pour du BI et de l’import ou export dans une application tierces est également très important. OCS Inventory se positionnant comme une source de données, il est impératif de permettre à disposition un accès simple à celle-ci.

Quel a été le choix technologique pour développer ce nouveau backend ?

Le backend était un choix compliqué et a demandé beaucoup d’analyse. En effet, il est important de choisir une technologie réactive, assez démocratisée et permettant de réaliser toutes les fonctionnalités déjà présente et future de l’application.

Après de nombreuses maquettes et tests, nous avons décidé de partir sur le langague Python et son framework Django. Pour ceux qui ne connaissent pas, il s’agit d’un module permettant de créer des applications web de manière structurée en respectant un modèle défini.

Couplé à Django, nous avons aussi utilisé DjangoRestFramework, un sous-module de Django permettant de modéliser une API REST directement depuis le modèle de données constitué dans Django.

Quel sont les éléments qui sont améliorés dans cette refonte pour le backend ?

1. Un de premier point que nous avons retravaillé est le système d’authentification et de permissions de l’application. Django permet nativement énormément d’interconnexion aux différents protocoles et méthodes d’authentification, Il était important pour nous de proposer un produit permettant de facilement s’interconnecter avec les différents systèmes d’annuaires et de gestionnaire d’identité.

   
   

2. Le second point est de faciliter l’interconnexion avec des outils tiers. C’est pour cela que nous avons choisi d’utiliser DjangoRestFramework. Ce module permet de communiquer avec l’application sur une base d’API RestFul. Tous les modèles et objets de l’application sont accessibles par le biais d’une route API dédiée proposant du GET, PUT, PATCH, POST et DELETE.

   
   

3. Un autre point est l’unification des données d’inventaire. Sur la version actuelle d’OCS Inventory, il y a une séparation entre les différentes typologies d’équipement. Dans la refonte du backend, nous avons opté de fusionner les différents types d’actifs dans un seul modèle de référence. Cela permet d’apporter des rapports plus complets et surtout de mieux entrevoir les évolutions futures.

   
   

4. Le dernier point et un est plus important est le modèle d’inventaire dynamique. La mise à jour des agents ainsi que le déploiement de script pour améliorer et modifier l’inventaire peut vite être contraignant. De plus, mettre à jour un agent sur un parc de plusieurs milliers de machine deviens très vite une tâche assez complexe en fonction de la typologie d’utilisateur ou de réseau. C’est pour cela que le backend propose un modèle d’inventaire dynamique, l’agent va désormais venir chercher une « routine d’inventaire » contenant toutes les informations à récupérer sur le système. Par ce biais, il ne sera plus nécessaire de mettre à jour l’agent pour modifier ou ajouter des données à inventorier.

Pour la communauté Open source, cela va-t-il changer quelques choses dans leur contribution ?

Nous allons faire en sorte de rendre la contribution la plus simple possible et surtout de mettre à disposition une documentation orientée développeur afin de faciliter la contribution. Sinon, tout sera comme avant, les contributeurs sont les bienvenues sur l’application !

Nous nous reverrons pour la prochaine étape qui arriveras dans combien de temps ?

La prochaine étape, qui portera sur l’article autour de l’agent, est prévue très prochainement. Cela permettra de présenter les avancées sur ce composant essentiel.

GitHub OCS Inventory 👉 https://github.com/OCSInventory-NG