Les trois “P” d’une modernisation réussie des systèmes d’ancienne génération

mongodb - roman gruhn
Par Roman Gruhn, Directeur senior, Strategic Field Programmes, MongoDB

Alors qu’un vent de transformation digitale souffle sur tous les secteurs d’activité, les nouvelles technologies détiennent les clés de l’innovation en matière de services et d’expérience client. D’où l’importance capitale d’en exploiter le potentiel. Coûts, sécurité, rapidité, performances : les entreprises doivent aujourd’hui se montrer plus compétitives sur tous les fronts. Seulement voilà, les systèmes d’ancienne génération les empêchent souvent de tenir le rythme face à l’agilité des nouveaux entrants. Les infrastructures vieillissantes ralentissent les processus de développement, affectent la qualité des produits finaux, mais aussi et surtout limitent les possibilités de corriger le tir en cours de route. Heureusement, il existe de multiples moyens de moderniser vos systèmes existants. Dans cet article, je vous propose de découvrir comment faire du triptyque « personnes-processus-plateformes » le socle d’une transformation efficace des méthodes et systèmes de développement.

 

Personnes : un problème de productivité

Commençons par le plus important : les personnes. Alors que les développeurs sont aujourd’hui reconnus comme une force d’innovation, les entreprises peinent à capitaliser pleinement sur leurs compétences et leurs savoir-faire. Au moment d’établir votre projet de modernisation, prévoyez d’abord la mise en place de processus qui permettront à votre équipe de développement de travailler de manière productive et efficace.

Selon une récente étude Stripe et Harris Poll, les développeurs consacreraient en effet 42 % de leur temps en moyenne à la maintenance et à la correction de logiciels mal codés. Près de la moitié des développeurs interrogés reproche ainsi aux applications existantes de baisser leur productivité. Plus précisément, 9 % du temps de ces derniers serait consacré à réparer du code et 33 % à résoudre des problèmes liés à la dette technique, c’est-à-dire à effectuer des opérations de maintenance comme le débogage ou la refactorisation de code.

Mais le casse-tête des développeurs ne s’arrête pourtant pas là. Cette année, MongoDB s’est associé à Stack Overflow pour réaliser sa propre étude et a ainsi pu révéler de nombreux autres obstacles à la productivité des développeurs. Par exemple, nous avons constaté que 41 % de la journée d’un développeur est dédiée au maintien de l’infrastructure existante plutôt qu’à l’innovation ou au développement de nouveaux produits.

Or, quand on passe le plus clair de son temps à écrire du code backend et à maintenir une infrastructure bancale à flot, on consacre forcément beaucoup moins de temps à des projets porteurs de valeur. D’où l’importance de redéfinir les stratégies de développement et de migrer les applications existantes vers des plateformes data et logicielles modernes. À défaut, c’est votre capital le plus précieux, à savoir vos développeurs, qui sera totalement paralysé. Et vous vous retrouverez aussi dans l’incapacité d’exploiter les énormes flux de données qui déferlent actuellement sur votre entreprise.

Il existe pourtant une méthode beaucoup plus efficace qui se résume en trois mots : microservices, DevOps et Agile. Ensemble, ils agissent pour des logiciels plus performants, plus rapides à développer, plus simples à maintenir et plus faciles à faire évoluer dans le cloud. Revenons plus en détails sur ces trois concepts et sur les arguments en leur faveur.

 

Processus : vers des modèles de microservices

Les vastes codebases monolithiques sur lesquels reposent traditionnellement les applications d’entreprise sont à la fois source de ralentissements et de décalage avec les besoins des métiers, ce qui réduit l’agilité de l’entreprise. Alors que les applications ne cessent d’évoluer, le code devient de plus en plus complexe et difficile à gérer. Les applications monolithiques étant développées comme un seul et même bloc compact, le moindre changement nécessite une coordination de tout un ensemble, ce qui ralentit le processus.

Pour accélérer et améliorer le développement des applications, les entreprises adoptent de nouvelles méthodes, parmi lesquelles les processus DevOps et le développement agile. Le principe consiste à constituer des équipes pluridisciplinaires, formées de développeurs, d’opérationnels, d’experts en sécurité et de représentants des métiers. Ces cellules autonomes regroupent ainsi toutes les compétences nécessaires à la création, au développement et à l’évolution de services et applications de A à Z.

Leur mission : décomposer les applications monolithiques en « microservices », des composants autonomes de plus petites tailles servant un but précis. Pour une structure de grande taille, les microservices permettent de lancer de nouveaux produits et services plus rapidement et d’aligner les équipes de développement sur les objectifs métiers.

Tous ces services servent généralement une fonction ou un objectif spécifique, tout en restant dans un périmètre bien défini. Cette démarcation claire permet aux équipes de se concentrer sur les bons objectifs tout en garantissant l’autonomie des services. Les services sont développés, testés et déployés de façon autonome, puis sont généralement exécutés sous la forme de processus indépendants qui communiquent sur un réseau via des API standardisées.

Nous avons accompagné de nombreuses start-ups et entreprises plus établies dans l’adoption de microservices. Un bon exemple est celui de Breuninger, un distributeur allemand qui souhaitait mettre en place une nouvelle plateforme d’e-commerce pour améliorer l’expérience en ligne de ses clients.

L’ancienne plateforme de Breuninger reposait sur des technologies standard de gestion des informations produit (PCM, Product Content Management) que l’entreprise trouvait « rigides et difficiles à coder ». Outre les plantages de code à répétition, l’architecture sous-jacente suscitait de nombreuses crispations chez cet acteur en quête de processus plus agiles pour mieux servir ses clients. Breuninger a donc décidé de subdiviser son application en microservices reflétant les habitudes d’achat des clients en magasin, puis de structurer ses équipes de développement en fonction des différentes étapes du parcours client. Résultat : l’entreprise a pu déployer sa plateforme omnicanal en quelques mois au lieu de plusieurs années.

En général, les microservices se caractérisent par le mappage de chaque service autonome à son propre data store, plutôt qu’à une base de données partagée. D’où l’importance d’exploiter une plateforme suffisamment flexible pour les prendre en charge. Passons maintenant au pourquoi et au comment d’une migration d’un modèle relationnel tabulaire vers une plateforme data de nouvelle génération.

 

Plateformes : les avantages d’un modèle orienté documents

La criticité de certaines applications rend particulièrement délicate leur migration vers des plateformes data et logicielles modernes. C’est notamment le cas des applications mainframe des banques et des compagnies aériennes. Intégrer de nouvelles fonctionnalités à ces systèmes revient à effectuer une opération à cœur ouvert. Un seul faux-pas et c’est toute l’application qui se fige, entraînant l’entreprise entière dans sa paralysie.

Heureusement, il existe des moyens pratiques, éprouvés et efficaces de moderniser des applications d’ancienne génération. La première étape consiste à inventorier les applications existantes et à les classer en fonction de leurs spécifications techniques, leur niveau de criticité et leur capacité à porter le changement pour l’entreprise. Les applications en tête de liste font alors l’objet d’une analyse plus approfondie et d’une estimation globale des efforts de migration. Ces informations sont ensuite renvoyées aux responsables d’applications pour obtenir leur feu vert, ou pas.

unnamed.png

Il y a 20 ans, les bases de données tabulaires représentaient ce qui se faisait de mieux dans le monde de l’informatique. Le problème, c’est que ces bases n’ont pas été conçues pour répondre aux besoins de gestion des données de l’économie digitale actuelle. Leur principal inconvénient réside dans une trop grande rigidité, qui ne s’accommode guère au développement de nouvelles fonctionnalités sur les logiciels. Or, il est très difficile d’ajouter de nouveaux types de données à un schéma rigide de tableaux bidimensionnels liés entre eux.

Par contraste, les documents représentent un moyen plus naturel de décrire des données. Ils présentent une structure unique dont les données associées sont intégrées sous forme de tableaux et de sous-documents. Les documents peuvent ainsi être étroitement alignés à la structure des objets définie dans le langage de programmation. Quant aux développeurs, ils disposent d’une solution plus simple et plus rapide pour mapper les données de l’application aux données stockées dans la base de données. Une telle approche facilite aussi grandement l’intégration de nouveaux développeurs à un projet, par exemple pour l’ajout de microservices à une application existante.

Lors d’une migration vers un modèle orienté documents de type MongoDB, le principal changement réside dans la méthode de modélisation des données et le schéma représentatif de ces modèles. Bien que chaque cas d’utilisation soit unique, il existe des critères communs à la plupart des projets de migration des schémas. Cette migration nécessite aussi un changement de perspective chez les architectes, développeurs et DBA. Concrètement, elle consiste à passer d’un modèle bidimensionnel rigide et plat à un modèle orienté documents plus flexible, constitué de tableaux et sous-documents, qui mappe étroitement les objets dans le code et s’adapte aux nouveaux types de données générées par les applications web et mobiles.

Le tableau ci-dessous présente les différences (et les similitudes) terminologiques entre bases de données tabulaires et orientées documents.

Sans titre.jpg

Les bases de données de nouvelle génération réduisent les coûts, améliorent l’efficacité et offrent des performances nettement supérieures à leurs équivalents relationnels. Les principaux leviers d’économies se situent au niveau de l’extrême scalabilité de la base sur des matériels standards. Les montées en capacité des bases de données relationnelles coûtent en effet beaucoup plus cher dans la mesure où il faut investir dans un plus gros serveur.Autrefois, les applications étaient généralement conçues pour des équipes internes situées dans les mêmes locaux. Aujourd’hui, les utilisateurs exigent des applications disponibles à tout moment, accessibles sur n’importe quel appareil et offrant des temps de latence extrêmement bas où qu’ils se trouvent. De même, pas question d’accepter la moindre entorse aux nouvelles réglementations en matière de protection des données.

Par contraste, l’architecture des bases de données distribuées leur confère une scalabilité horizontale sur un matériel standard à bas coût, voire une infrastructure cloud, grâce à une technique appelée « sharding ». Elles répondent aux besoins des applications à très haut débit, adossées à de vastes ensembles de données. Le sharding partitionne et distribue automatiquement les données sur plusieurs instances physiques appelées « shards », ce qui permet aux développeurs d’adapter la base de données de manière transparente à mesure que leurs applications dépassent les limites matérielles d’un serveur unique, sans ajouter de complexité à l’application.

Conçue pour fonctionner sur un seul serveur, l’architecture des bases de données tabulaires se prête mal aux plateformes cloud modernes, construites sur un modèle de scalabilité horizontale autour de matériels standard et peu coûteux. Pour réduire les risques de verrouillage technologique dans le cloud, les équipes doivent donc créer leurs applications sur un modèle de bases de données distribuées offrant une expérience homogène dans tous les environnements.

Vieilles de plus de 30 ans, les bases de données tabulaires et les méthodologies de développement en cascade ont vécu. Place à de nouvelles architectures basées sur des modèles de microservices et des plateformes data modernes, porteurs d’agilité pour l’entreprise et de productivité pour les développeurs.

Au lieu de créer des ralentisseurs supplémentaires dans le processus de développement, les entreprises doivent redoubler d’efforts pour évoluer vers des plateformes et des processus intuitifs qui leur permettront d’optimiser les capacités d’innovation des développeurs.

Enfin, il est crucial de ne pas se laisser effrayer par la perspective d’abandonner une architecture monolithique inefficace. Inutile de tout chambouler d’un coup ou de s’engager dans une démarche du « tout ou rien ». En obéissant à la règle des trois “P” (personnes, processus, plateformes), les entreprises pourront non seulement rester compétitives, mais aussi se démarquer sur le terrain des performances, de la rapidité, des coûts et de la sécurité.

 

%d blogueurs aiment cette page :