BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Comment Eviter Le Verrouillage Des Fournisseurs Sans Serveurs Avec Design Patterns ?

Comment Eviter Le Verrouillage Des Fournisseurs Sans Serveurs Avec Design Patterns ?

Favoris

Gregor Hohpe a récemment publié un article proposant un changement de paradigme pour résoudre les problèmes de verrouillage des fournisseurs sur les applications cloud sans serveur. La conception d'une solution à l'aide de modèle bien connu dissocie ses caractéristiques fonctionnelles de l'implémentation cloud sous-jacente et permet d'éviter plus facilement le verrouillage ou de passer au multi-cloud.

Même s'il est communément admis que les offres de services de plate-forme cloud sont fondamentalement équivalentes les unes aux autres, elles présentent suffisamment de différences pour rendre impossible le portage direct de cas d'utilisation non triviaux.

La portabilité est donc une préoccupation valable à garder à l'esprit lors de la conception de systèmes, en particulier s'ils sont destinés à des déploiements multi-cloud. Cependant, penser en termes de portabilité n'est pas toujours simple.

L'auteur soutient qu'un obstacle important est "l'enfermement mental". D'une part, les expériences antérieures peuvent limiter le schéma de pensée d'une personne, ce qui rend difficile l'adoption d'architectures différentes. D'autre part, les plates-formes cloud modernes proposent une manière attractive de décrire ses solutions en termes d'offres de services ce qui rend la transposition des solutions difficile sur une plateforme différente.

Ne penser uniquement qu’aux services des plateformes vous fait perdre toute volonté de concevoir des applications et vous enferme mentalement. 

Les mapping tables sont de niveau trop élevé pour décrire avec précision la portabilité car les capacités de services spécifiques ne correspondent pas à une base individuelle. De plus, l'ensemble des services cloud utilisés n'expriment pas nécessairement les besoins de la solution ou l'intention du concepteur.

Le parcours type dans le monde du génie logiciel consiste à créer une couche de portabilité au-dessus des implémentations de services spécifiques. L'auteur souligne qu'une telle approche peut vite conduire à un résultat de “plus petit dénominateur commun”. C’est un inconvénient car il empêche l’adoption d’innovations dans un domaine où les applications cloud évoluent très rapidement. 

Au lieu de penser en termes d'abstractions au niveau de la mise en œuvre, Hohpe suggère qu'il est préférable de penser en termes d'abstractions au moment de la conception. Étant un "vocabulaire de conception neutre sur le plan technologique", les design patterns constituent des abstractions utiles à appliquer au moment de la conception.

Exprimer votre solution sous forme de Design Pattern simplifie son portage vers une autre plate-forme

En exprimant une solution en termes de Design Patterns, l'intention de l'architecte et les besoins de la solution deviennent apparents.  

Image source: "Concerned about Serverless Lock-in? Consider Patterns!"

Tous les Design Patterns utilisés, par exemple les aggrégateurs, les canaux pub/sub, les orchestrateurs peuvent être réalisés en utilisant des offres de services propres à chaque fournisseur de cloud. Parfois, ces offres de service nécessitent d'être mélangé pour intégrer un Design Pattern spécifique ce qui n'est pas un inconvénient. 

Les combinaisons de services deviennent alors un détail d'implémentation et non plus un choix de conception.

L'auteur ajoute qu'une conception de système doit être exprimée à l'aide d'un "langage cohérent qui forme un vocabulaire unique". On peut utiliser plusieurs langages de motifs pour former ce vocabulaire, mais il est nécessaire d'avoir une vision claire de l'aspect du système auquel ils s'appliquent. Par exemple, les flux de données peuvent être conçus à l'aide de modèles d'intégration d'entreprise, mais les composants peuvent être mieux construits à l'aide de modèles orientés objet.

Un modèle de langage exprime l'intention du développeur dans un langage indépendant du service.

Les avancées de la plateforme signifient également que les compromis requis par les modèles changent. Cette évolution signifie que, par exemple, les plateformes cloud sans serveur ou les plateformes severless peuvent favoriser l'utilisation de modèles différents de ceux privilégiés sur les plateformes plus anciennes. De nouveaux modèles peuvent également apparaître, émergeant d'une utilisation généralisée.

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT