Les architectures orientées services (SOA) peuvent facilement migrer vers le cloud

L’avènement du Cloud Computing n’a pas seulement étendu géographiquement le périmètre des architectures orientées services (SOA), il les a aussi fait évoluer vers une relation applications-ressources reposant sur le cloud. En conséquence, les applications SOA sont celles que l’on peut faire migrer le plus facilement. Ce qui ne veut pas dire, aussi facile soit-elle, que cette migration soit  automatique.

En explorant les éléments de base des architectures logicielles, leurs composants et leurs classes de ressource, cet article a la vocation d’aider architectes, développeurs et administrateurs DevOps à faire migrer leurs architectures logicielles vers le cloud plus facilement.

Le concept de SOA émerge depuis plus de 10 ans. Il est né du désir des développeurs de créer des logiciels à partir de composants réutilisables, et du besoin des entreprises de personnaliser les comportements des applications afin d’optimiser la productivité des salariés.

L’infrastructure SOA se décompose en quatre éléments de base : des serveurs pour le traitement, un OS et un middleware de stockage, une mise en correspondance des utilisateurs et des applications et une répartition de charge. Il s’agit bien sûr des quatre éléments qui constituent le coeur de toute infrastructure IT, la SOA changeant néanmoins la manière dont les entreprises répartissent leurs capacités dans chacun de ces domaines pour optimiser disponibilité et performances. Et ce, tout en gardant le contrôle sur les coûts. Cet équilibre dépendra beaucoup du modèle architectural SOA retenu, et de la manière dont les applications sont subdivisées en différents composants puis déployées. 

l’Open Compute Project, fournit des conseils  sur le design matériel qui pourraient être utilisés pour comparer des éléments d'infrastructure vendus dans le commerce, mais ne permet pas forcément de créer la plateforme d’architecture logicielle optimale pour la SOA.

La différence fondamentale entre une architecture logicielle et des applications « atomiques » réside dans sa subdivision en composants. Les applications SOA qui font de bonnes candidates sont divisées et assemblées en composants fonctionnels pour former des applications, ce qui a des incidences majeures sur l’infrastructure :

• Chaque composant peut recourir à des ressources plus spécialisées que ne le feraient des applications entières. Les applications SOA qui effectuent des analyses sur une base de données peuvent séparer les fonctions analytiques et les fonctions base de données en deux composants séparés, l’un nécessitant d’importantes capacités de calcul, l’autre sollicitant les disques. Cette séparation peut permettre de choisir du matériel fabriqué sur mesure à plus faible coût.
• Les applications ainsi divisées en parties plus petites ajoutent un trafic « horizontal » entre composants au trafic « vertical » entre l’application et l’utilisateur. Cette modification dans les flux de trafic affecte la conception du réseau du datacenter et favorise notamment les « fabrics » aux dépens des hiérarchies entre commutateurs.
• Les composants peuvent être répliqués afin d’augmenter leur capacité de travail. Il faudra dans ce cas un ensemble d’outils spécifiques qui, en appliquant un ensemble de règles coût/performance, sera chargé d'attribuer des tâches à l’un des ensembles de composants SOA, ce qui permet une répartition des charges entre composants.
•  
• Les composants « proches de l’utilisateur », c’est-à-dire proches de l’interface utilisateur graphique (GUI), peuvent être déplacés pour être géographiquement plus proches et localisés à côté du point d’activité.

Le plus : les entreprises peuvent alors aborder l’infrastructure SOA en termes de « classes de ressources », soit un ensemble de configurations de stockage qui soutiennent efficacement la majorité de ses composants SOA. Le nombre de classes de ressource dépendra de la palette de composants SOA nécessaires, mais devra probablement comporter les éléments suivants :

• Des serveurs de base de données et d’interrogation, conçus pour servir de grandes bases de données en utilisant les principes du stockage hiérarchique. Ils devront généralement comporter de très grandes quantités de mémoire RAM complémentaires, de capacité de stockage flash, d’interfaces E/S rapides pour le stockage sur disque, de connections réseaux haute performance, ainsi que de modestes capacités de calcul. 
• Des serveurs de calcul et d’analytique, conçus pour effectuer des calculs complexes, qui comporteront généralement à la fois de la mémoire RAM et une grande quantité de cœurs de processeurs rapides, ou même, éventuellement, des processeurs graphiques (GPU) pour accélérer les fonctions de calcul.
• Des serveurs distribués, pour prendre en charge le traitement local - création d’interfaces utilisateur ou traitement d’évènements. Cela peut se faire à l’aide de microserveurs reposant sur une technologie ARM plutôt que sur des appareils X86 classiques.

La répartition des composants, et en particulier la réplication des composants SOA pour améliorer les performances, implique qu’il faudra prévoir une passerelle, quelle qu’elle soit, pour l’infrastructure SOA. Deux options se présentent : les appliances et les « passerelles virtuelles ». Une appliance, souvent appelée « répartiteur de charge » ou « commutateurs de niveau 3 », oriente le trafic vers un composant disponible, en s’appuyant sur une règle de planification. Les passerelles virtuelles utilisent les fonctions d’annuaire de l’architecture logicielle pour assigner les composants au fur et à mesure des besoins. La meilleure approche dépendra de la nature des relations inter-composants, et en particulier du fait que ces composants soient répliqués ou pas pour augmenter leurs capacités. Les appliances passerelles sont particulièrement appréciées pour créer un lien entre les utilisateurs d’application et les composants SOA ; on leur préférera néanmoins une gestion de flux inter-composants en aval pour les passerelles virtuelles, y compris les flux de messages du moteur de workflow ou de bus de service.

Côté base de données de l’infrastructure SOA, il faudra également réfléchir à la question : « virtuel » ou « physique » ? Les technologies de grilles de données permettent aujourd’hui aux applications d’accéder à des données réparties sur une zone géographique étendue, comme avec Hadoop, qui répartit souvent les applications entre de multiples nœuds fonctionnant en parallèle, puis collecte et recoupe les résultats, d’où un besoin de calcul hybride et de nœuds de stockage. À l’opposé, de nombreuses applications « big data » et analytiques reposent aujourd’hui sur des appliances ou des nœuds dédiés via un langage de requête. Cela permet aux composants des applications SOA d’être isolés de la fonction d’analyse de données, ce qui réduit d’autant le besoin d’interface de données spécifique ou de fonctionnalités analytiques pour CPU et GPU.

Ces exemples avec les passerelles et les bases de données montrent bien que les infrastructures SOA doivent d’abord être considérées au niveau virtuel et logique avant d’aborder les questions matérielles, logicielles et middleware. L’efficacité de la conception d’une application SOA dépendra avant tout de la manière dont les applications seront découpées en composants et de la rigueur de l’orchestration des flux. C’est ce processus qui permettra de créer les éléments logiciels qui devront être hébergés sur les ressources ; il définira également ce qui est nécessaire pour que le middleware relie les applications entre elles et permettra de déterminer le meilleur matériel pour héberger chaque composant ou classe de composants.

Face à ce constat, la plupart des gens comprendront que toutes les applications SOA évoluent vers une relation entre application et ressources reposant sur le modèle cloud, qu’il y ait un projet explicite d'hébergement d'applications dans un nuage public, privé ou hybride ou pas. La différence entre le « SOA cloud » et la forme moderne de SOA réside en fait principalement dans le présupposé de départ sur la répartition des ressources matérielles utilisées. La plupart des applications SOA fonctionnent aujourd’hui avec un datacenter ; les applications cloud partent, elles, de l’hypothèse que les ressources s’étendent sur de multiples datacenters, voire s’étendent dans le monde entier. Plus l’ensemble des ressources auquel le groupe d’applications SOA fait appel est large, plus il sera important de créer des connexions réseau efficaces pour permettre le trafic entre processus (et entre composants au sein de la SOA). Si le schéma des workflows est prévu et analysé avec soin, les contraintes réseau de la SOA pourront aisément être mises à niveau pour permettre la migration vers le cloud. La migration des applications SOA, bien planifiée, deviendra alors la plus facile de toutes les migrations d’applications.

Traduit et adapté d'un article de SearchSOA.com