Informatique orientée services : principes et mise en œuvre

L’informatique orientée services, ou « services computing », étudie la manière de transformer des capacités métier en services que des systèmes logiciels peuvent découvrir, utiliser et combiner. Elle relie une question comme « Comment traiter une commande ? » aux choix d’interfaces, de données, de déploiement et d’exploitation.

Un processus dont le résultat est clairement défini constitue un bon point de départ. Une commande peut mobiliser des services de gestion des stocks, de paiement et de livraison. L’informatique orientée services examine leur coopération, leurs responsables et les conséquences de l’échec d’une étape. La location d’un serveur cloud ne répond qu’à une partie de ces besoins.

Que couvre l’informatique orientée services ?

Le périmètre défini par l’IEEE Computer Society réunit les processus métier, les services logiciels et leur exploitation. Il comprend la modélisation, la découverte, la composition, la supervision et la gestion des services. La recherche porte aussi sur les méthodes formelles, la qualité de service et les applications métier ou scientifiques.

Pour un service de livraison, le résultat attendu peut être la confirmation d’un créneau de collecte. Sa description doit préciser les informations requises sur l’adresse et le colis, les réponses possibles et les conditions d’acceptation d’une réservation. Une interface qui renvoie « succès » sans expliquer ce qui a été réservé laisse un problème d’intégration non résolu.

Le modèle de référence SOA d’OASIS distingue l’accès à une capacité de sa mise en œuvre interne. Le consommateur doit comprendre l’interface, les règles applicables et l’effet attendu. Il n’a pas besoin de connaître chaque opération interne du fournisseur.

Informatique orientée services, SOA, microservices et cloud

Ces termes correspondent à des décisions différentes :

• Informatique orientée services : discipline qui traite de la conception, de l’intégration, de la fourniture et de la gestion des services.
• Architecture orientée services, ou SOA : organisation de capacités derrière des interfaces permettant leur utilisation entre systèmes ou entre organisations. La SOA n’impose ni produit particulier ni bus de services d’entreprise.
• Microservices : approche architecturale reposant sur des services déployables indépendamment, organisés autour de capacités métier définies. Elle implique des choix sur leurs limites, leurs communications et la responsabilité des données.
• Cloud computing : modèle d’accès à la demande à des ressources informatiques mutualisées. Il peut fournir l’infrastructure ou les capacités managées utilisées par une application orientée services.

Le guide Microsoft sur les microservices décrit le déploiement indépendant et la complexité supplémentaire de l’exploitation distribuée. Découper une application ne la rend pas automatiquement plus rapide, moins coûteuse ou plus facile à maintenir. Pour une petite équipe dont les besoins sont étroitement liés, une application modulaire avec moins d’unités de déploiement peut être préférable.

Notre guide des modèles de services cloud explique la distinction entre infrastructure louée, plateformes managées et logiciels prêts à l’emploi. Ces choix d’achat ne déterminent pas à eux seuls la conception des processus métier de l’application.

Un exemple concret : traiter une commande

Prenons l’exemple fictif d’un commerçant disposant de capacités distinctes pour les stocks, le paiement et la livraison. Avant de choisir un système de messagerie, précisez le sens de « commande acceptée ». Faut-il que le stock soit réservé, le paiement autorisé et l’expédition acceptée par un transporteur ? Qu’affiche-t-on au client lorsqu’une étape est encore en attente ?

Un enchaînement possible consiste à réserver le stock, autoriser le paiement, puis demander la livraison. Si celle-ci est impossible, l’application doit suivre une réponse définie : proposer une autre option, libérer la réservation ou transmettre la commande à une personne. Cette décision relève de la conception du processus, pas d’une boucle de nouvelle tentative improvisée.

Désignez un responsable pour chaque capacité et un responsable du résultat complet pour le client. Le service de paiement peut fonctionner alors que des commandes restent bloquées ailleurs. L’équipe chargée du processus complet doit disposer des informations nécessaires pour repérer et résoudre ce problème.

De la modélisation au déploiement des services

Définir les limites et les contrats

La modélisation des processus métier doit identifier le résultat, les participants, les données et les exceptions avant la création des services. Choisissez des limites correspondant à des responsabilités que votre équipe peut maintenir. Évitez de créer un service réseau distinct pour chaque petite fonction.

Documentez les entrées, les sorties, le sens des erreurs, les exigences d’authentification, les règles de versionnement et les responsables. La spécification OpenAPI fournit un format de description des API HTTP lisible par machine. Cette description peut alimenter la documentation et les outils ; elle ne prouve pas que l’implémentation fonctionne correctement. Testez les requêtes valides, mais aussi les demandes incorrectes ou non autorisées.

Les technologies de services web et d’API doivent également être nommées avec précision. SOAP définit un cadre de messagerie fondé sur XML, REST est un style architectural et GraphQL définit un langage de requête et un modèle d’exécution. Ce ne sont pas trois protocoles interchangeables. Choisissez selon les clients, les contraintes de compatibilité et les opérations concernées.

Distinguer découverte des services et catalogue

Un catalogue aide les développeurs à trouver une capacité, son responsable et sa documentation. La découverte à l’exécution permet au logiciel de localiser une instance joignable. Les deux besoins sont liés, mais distincts : une fiche de catalogue peut être exacte alors que le point d’accès est indisponible.

Par exemple, un Service Kubernetes fournit une abstraction réseau permettant d’atteindre un ensemble de points de terminaison lorsque les Pods changent. Il ne définit pas le sens métier d’une opération et ne compose pas automatiquement un processus de commande. Kubernetes est une option d’implémentation, pas une obligation de l’informatique orientée services.

Préparer l’exploitation avant le déploiement

Avant le déploiement, définissez la gestion de la configuration, des secrets, des accès, des données persistantes et du retour à une version précédente. Testez les défaillances des dépendances. Une version fonctionnant avec une dépendance locale rapide peut se comporter autrement lorsque le service distant ralentit ou devient indisponible.

Prévoyez le retrait des versions autant que leur lancement. Identifiez les consommateurs avant de supprimer une opération ou de modifier sa réponse. Accordez-leur un délai de migration adapté, sans supposer que tous les clients sont mis à jour au même moment que le serveur.

Composition des services : orchestration et chorégraphie

La composition combine plusieurs capacités dans un processus plus large. La note du W3C sur l’architecture des services web distingue l’orchestration, qui précise comment un service en appelle d’autres, de la chorégraphie, qui décrit les interactions entre participants.

Dans un traitement de commande orchestré, un coordinateur suit l’étape suivante et son résultat. Dans un traitement chorégraphié fondé sur les événements, les services réagissent à des événements convenus, par exemple une réservation de stock. Le premier rend le processus explicite dans un coordinateur ; le second répartit sa logique entre les participants.

Choisissez selon la complexité du processus et la capacité de l’équipe à en suivre l’exécution. Les deux approches exigent une gestion des échecs. Le coordinateur doit pouvoir reprendre son travail après une panne ; une architecture par messages doit gérer les événements dupliqués, retardés ou reçus dans le désordre. La décentralisation ne supprime pas les dépendances opérationnelles.

Gérer les échecs partiels et les requêtes répétées

Un dépassement de délai ne prouve pas qu’une opération a échoué. Une autorisation de paiement peut réussir avant que sa réponse soit perdue. Une nouvelle tentative sans vérification peut répéter un effet que le client n’attendait qu’une seule fois.

Le guide Microsoft sur la chorégraphie traite des doublons, de l’ordre des événements et des risques liés à la séparation entre mise à jour des données et publication d’un événement. Utilisez des identifiants stables de requête ou de message et définissez les opérations répétables sans effet supplémentaire. Fixez des délais et un nombre limité de tentatives.

Pour un processus réparti entre plusieurs bases, le modèle saga coordonne des transactions locales et des actions de compensation. Une compensation est une opération applicative, comme la libération d’une réservation ; elle ne peut pas annuler universellement tous les effets. Elle peut aussi échouer : prévoyez une reprise et une intervention humaine.

Supervision, sécurité et gestion des services

Les signaux d’OpenTelemetry comprennent les traces, les métriques et les journaux. Leur utilisation conjointe peut aider l’équipe à relier l’échec d’une demande client aux services concernés. Elle nécessite une instrumentation, une collecte et une analyse adaptées.

Dans notre exemple, suivez le taux de commandes terminées, l’ancienneté des commandes en attente et les signalements d’effets répétés, en plus de la latence, du taux d’erreur et de l’utilisation des ressources. Définissez des objectifs reflétant le résultat pour le client. Ajouter de la capacité CPU ne débloquera pas un processus arrêté sur une exception métier non traitée.

Intégrez les vérifications d’autorisation à chaque opération, y compris l’accès à l’enregistrement demandé. Examinez les données personnelles ou confidentielles qui traversent chaque interface et celles qui apparaissent dans les journaux. Désignez les responsables des identifiants, des mises à jour, des incidents et des tests de reprise. Le nom d’une architecture ne garantit ni la sécurité ni la conformité réglementaire.

La gestion des services comprend aussi leur retrait, leur documentation et leur coût. Mesurez le coût du travail terminé en incluant l’infrastructure, les dépendances, l’observabilité et l’effort d’exploitation. Comparez-le à une situation de référence mesurée avant d’annoncer des économies liées à l’optimisation.

La place de l’infrastructure cloud

Compute with Hivenet fournit de la capacité de calcul GPU et CPU. Évaluez les instances disponibles selon les besoins logiciels, la mémoire, le stockage et la connectivité de votre charge de travail. La fourniture de capacité de calcul ne signifie pas que le prestataire assure la découverte des services, l’orchestration des processus ou la reprise automatique des applications.

La répartition des responsabilités compte aussi pour l’achat de support. Notre guide des services informatiques cloud distingue la location de ressources de leur gestion par un tiers. Documentez les tâches qui restent à votre équipe.

Comment lancer un projet d’informatique orientée services

Testez la conception sur un processus délimité avant de l’étendre. Une revue pratique devrait produire cinq éléments :

1. Un résultat défini : expliquez le succès, les états en attente et l’échec de manière reconnaissable pour un utilisateur ou un opérateur.
2. Des contrats avec des responsables : précisez les interfaces, les responsabilités sur les données, les règles d’accès et les attentes de compatibilité.
3. Un plan de gestion des échecs : testez les délais dépassés, les requêtes répétées, les dépendances indisponibles et les exécutions partielles.
4. Des éléments de preuve opérationnels : recueillez les traces de bout en bout, les mesures du processus, les résultats de reprise et le coût par opération terminée.
5. Une décision de mise en service : comparez le résultat au processus actuel et déterminez si les nouvelles séparations entre services justifient leur coût de maintenance.

Gardez la première implémentation assez petite pour pouvoir la comprendre. Ajoutez des services lorsqu’une responsabilité mieux définie, un besoin de déploiement ou une exigence de la charge de travail le justifie.