Introduction

Pour un SI toujours plus évolutif, plus en adéquation avec les besoins, plus stable et pouvant supporter une charge d’activité colossale, prendre le virage du Cloud est devenu une priorité pour grand nombres d’entreprises.
Mais il est difficile pour une entreprise d’imaginer migrer d’un bloc tous ses services éligibles à la migration vers le Cloud.
Pourtant les grands acteurs du Cloud aujourd’hui ont plutôt des noms rassurants : Amazon, Oracle, Microsoft, etc…

Le principe des offres “as a Service” de ces fournisseurs est de payer à l’utilisation de ces services. Donc au début on n’est pas totalement sûrs que les coûts de fonctionnement de nos services seront forcément inférieurs à leurs coûts de fonctionnement en mode “On Premise”.
Pour cela, une idée peut être de lotir le processus de migration en déportant progressivement les services de l’entreprise.
Une architecture SOA, de part ses principes de modularité et d’agilité, est parfaitement adaptée à ce types de problématique.
Notamment, si l’on utilise un Enterprise Service Bus dont une des fonctions principales est le routage, il peut être très aisé de pratiquer le « Just in time binding » : principe de modification “à chaud” de l’assemblage des composants d’une architecture SOA.

Mise en oeuvre

Pour le mettre en pratique, prenons le cas d’une mise en place d’un tel routage dans le bus d’entreprise d’Oracle : Oracle Service Bus.
Pour cela, on peut utiliser les concepts de DVM (Domain Value Mapping).
Les DVMs sont une fonctionnalité standard de la SOA Suite et correspondent  fonctionnellement à une sorte de table de correspondances.
Dans la SOA Suite, ils sont implémentés sur la base d’une structure XML que vous verrez dans les captures d’écran ci-dessous.

1.

Par exemple, nous allons définir un DVM de routage de nos services en créant une correspondance entre le nom de mon service (ServiceName) et son url d’accès (ServiceEndpoint) :

 

2.

Ce chemin XPath me permettra ensuite de récupérer l’url d’appel à mon service :

$dvm/ns0:rows/ns0:row[ns0:cell[1]=$ServiceName]/ns0:cell[2]

3.

Ensuite, dans le noeud de routage du proxy de mon OSB :

On peut faire du routage dynamique en spécifiant l’url de mon service :

 
L’intérêt de tout cela est qu’un DVM offre les avantages suivants :

• modifiable à chaud
• indépendant de l’implémentation
• indépendant des déploiements
• intelligible, et donc modifiable par toute personne, qu’elle soit avisé ou non techniquement, et ayant les droits de le faire.

4.

Ainsi on offre une agilité maximum dans l’évolutivité de nos services en modifiant le DVM à sa guise :

Dans cet exemple, MonServiceA est passé dans le Cloud Oracle, et MonServiceB est passé dans le Cloud Amazon.
Remarque : cette mise en oeuvre peut aussi être faite dans un orchestrateur BPEL.

L’agilité au service de la maîtrise des coûts

Autre atout dans tout cela, c’est la possibilité de pouvoir réagir vite en cas de surprise au niveau des coûts liés au bon vouloir des fournisseurs d’offres IaaS et PaaS.
En effet, chaque fournisseur a ses propres tarifs basés sur des critères qui peuvent être différents (certains peuvent peut-être proposer un usage de bande passante à des prix intéressants, mais compensés par une facturation bien plus sévère sur l’usage des CPU par exemple, etc…).

Exemple de mise en situation

Pour rappel, le Cloud d’Amazon (choisi au hasard pour l’exemple) avait été initié pour rentabiliser les serveurs de leur plateforme d’eCommerce dans les périodes creuses (hors soldes, période de Noël, etc…). En effet, à l’époque, pendant ces périodes creuses les serveurs qu’ils avaient acquis étaient sous-exploités, d’où l’idée de vouloir rentabiliser ces ressources hardwares inoccupées.
La conséquence de tout cela pourrait être de penser qu’aujourd’hui les tarifs de leurs offres IaaS et PaaS  pourraient augmenter légèrement en périodes de haute activité, car eux-mêmes ont aussi grandement besoin de ces ressources. Le problème est que l’expression « augmenter légèrement » peut amener à de lourdes conséquences à grande échelle (lorsque l’on manipule des milliards de données quotidiennement).
Si tel est le cas, il serait peut être opportun de pratiquer le “Just in time binding” pour déporter (au mois temporairement) certains services vers un autre fournisseur de Cloud en fonction de :

• la fluctuation des prix des abonnements à l’usage
• l’évolution de nos services
  exemple : la nouvelle version déployée d’un service peut s’avérer d’un seul coup plus consommatrice en CPU/mémoire/réseau que la version précédente, et après quelques jours d’exécution en environnement réel on peut vouloir migrer ce service vers un fournisseur aux tarifs plus adaptés à ces derniers constats de performances d’exécution.

Remarque : cet exemple est totalement fictif et arbitraire, bien entendu qu’en aucun cas il y est stipulé d’enlever vos services du Cloud Amazon en période de Noël.

Conclusion

La vraie valeur ajoutée d’une architecture SOA dans le contexte d’agilité qui est celui du monde numérique d’aujourd’hui, est de pouvoir cloisonner l’environnement d’exécution de chaque brique métier de son SI.
Les offres de Cloud Privé/Public/Hybride, qui sont de plus en plus nombreuses et pertinentes aujourd’hui, sont bien trop intéressantes pour ne pas y passer.
Mais gardons la maîtrise de pouvoir ajuster le curseur à sa guise et de manière agile dans cette démarche d’envergure.