Pour faire rapide, pour faire de l’architecture orienté service, il ne suffit pas de dessiner de jolis crobards dans un coin du tableau

blanc et annoncer « bin yaka faire de l’ORM truc much Linq-Hibernate-machin chouette, et les exposer avec du REST/SOAP ! ça va régler pas mal de problèmes, non ? ». 

Non. Ce type d’architecture nécessite de lever un peu les yeux du guidon et de voir chaque projet comme faisant partie d’un tout. Le tout pouvant être traduit comme l’entreprise, la communauté, (dans le cas d’Amazon, l’humanité). L’idée étant de prendre un peu de hauteur, et de se demander comment s’organiser (pas organiser son code, s’organiser, nous, les gens) pour séparer toutes les fonctions d’une application sous forme de services (web principalement, mais on pourrait imaginer d’autres protocoles plus rigolos) et comment en faire bénéficier la communauté : les développeurs, les clients, et tous si affinité. La finalité d’une telle architecture peut être dans un petit cadre restreint  partager des données entre les acteurs et lorsque la communauté est énorme, on peut aussi se servir de cette architecture pour en monayer l’accès. Bienvenue dans l’ère du ouèb 2.0. Tadam…

Un exemple typique : l’authentification / identification et la gestion de l’utilisateur de ces droits. Cette fonction se retrouve dans quasiment tous les projets. Et bien si vous n’avez pas envie de développer votre couche d’authentification, vous pouvez, en utilisant le service commun, utiliser celle qui a déjà été développée, hébergée, et éprouvée par d’autres, et bénéficier ainsi de ce que la communauté a fait pour vous. Et on généralise ça  non seulement aux utilisateurs humains (utilisateurs d’applications), mais aussi pour authentifier des applications (dans le cas de OAuth, cet usage est même central : c’est exactement ce qu’il se passe lorsque vous autorisez l’accès à certaines de vos données à une application dans le Play Store de Google, en utilisant le service d’authentification de Google.).

L’architecture orientée service, c’est généraliser ce principe à toute fonctionnalité que l’on pourrait exposer au monde extérieur, d’une façon ou d’une autre.

On pense alors à tout un tas de services différents :

Ces services peuvent s’utiliser les uns les autres. Par exemple, pour générer tel rapport, le service de génération de rapport peut très bien demander au service d’authenfitication / identification s’il a le droit de le faire pour tel compte, et au passage, il envoie des données au service de monitoring pour lui faire part de cette demande et la faire apparaître dans les statistiques du système global.

Pour faire beau, ce genre d’architecture se trouve en général sous la forme d’une offre PAAS (Plateforme As A Service). Octave Klaba, CTO d’OVH en a fait d’ailleurs une longue promotion lors de son dernier Summit.

La façon d’utiliser ces APIs est souvent du REST, mais peut aussi être en SOAP. Les formats sont divers et variés en fonctions des usages et des préférences de chacun : JSON, XML, CSV, YAML, que sais-je… Conséquence : les différentes applications ne sont pas développées uniquement pour le ou les clients du projet cible. Elles sont au départ développés par et pour les développeurs qui en ont besoin, puis l’offre est « ouverte » vers l’extérieur. C’est le principe de « eat your own dog food ». Les développeurs se servent de leur logiciel avant même de le vendre.

 Structurellement, chaque service clé serait donc en mesure d’offrir ses fonctions non pas à une seule application ni à un seul client mais à toute demande identifiée et authentifiée, voire à toute demande publique dans le cadre de l’OpenData. Les conséquences d’un tel choix d’architecture sont les suivantes :

• grande simplification potentielle des applicatifs pour se concentrer sur le spécifique.
• chaque service central devient alors critique car plusieurs applications vont en dépendre.
• le couplage entre les différents services pose aussi la question de la gestion du versionning et de leur cohabitation.

Autant de sujets qui ne sont pour la plupart du temps pas abordés ni résolus lors du développement d’applications monolithiques classiques. Dans le cadre d’une telle démarche, le métier se transforme. Lorsqu’un service est mis en place, au lieu de le voir par le trou de la serrure dans un contexte restreint et spécifique, il faut partir du principe que la demande extérieure peut-être très importante, soumis à des demandes émanant de contextes et d’usages différents, et ce en permanence. Le monitoring fait donc lui aussi partie des concepts clés pour mener à bien une telle architecture.

---

Structurellement faite pour grandir et renforcer les liens

 Lorsque l’on code une appli, pour un nouveau projet, la question du dimensionnement est structurante. Si votre projet est fait pour gérer 10 utilisateurs, et écrire 100 enregistrements par jour en base de données, la question du volume est anecdotique. Par contre, si votre service est utilisé par des milliers de bons hommes qui effectuent 100 appels par seconde, on sent bien que la question de la scalabilité (capacité à gérer une grande quantité d’utilisateurs)va être centrale.

De part le découpage en services web dont la fonction est très restreinte, une autre caractéristique structurelle d’une architecture oriéntée service est que l’infrastructure a « envie » de grandir par nature, car cette dernière est utilisée par tous. La scalabilité fait donc partie des gènes d’une plateforme orientée service.

La mise en commun de services implique chacun dans la bonne santé du système au global. On transforme un cercle vicieux (1), en un cercle vertueux (2) dans lequel chaque nouveau développeur se transforme en « devops »  et contribuera par le simple usage à l’enrichissement et à l’amélioration des services communs, ne serait-ce que par la remontée de bugs des services des copains. Ajouter de nouveaux services, les rendre utilisables par tous, les inclure dans une démarche de gagnant/gagnant et de capitalisation des développements _et_ de l’opérationnel (le fameux concept « devops »)

Le défi lancé par la mise en place d’une telle architecture est donc passionnant. Il sort du cadre d’un seul projet, en se posant des questions touchant au fonctionnement global de l’infrastructure logicielle et de l’interaction technique et humaine entre les projets de la communauté.