BLOG

Replateforme pour le Cloud

Byron McNaught Miniature
Byron McNaught
Publié le 13 avril 2023

Les architectes aident à définir les garde-fous de processus et les capacités techniques nécessaires à l'exécution de la stratégie numérique de l'entreprise, qui comprend souvent l'évolution des applications Web et de l'infrastructure API (passerelles API, maillages de services et portails de développeurs) vers des plates-formes basées sur le cloud.

Dans la pratique, il existe des approches de « lift and shift », de « refactorisation » (ou de « réarchitecture ») et de « replateforme », et la décision sur le parcours architectural à entreprendre dépend de plusieurs facteurs. Par exemple, dans quelle mesure le couplage et la cohésion peuvent être mis en œuvre en toute sécurité. L’objectif doit être une API hautement cohérente et faiblement couplée, car elle fournit une interface stable et un niveau d’abstraction, protégeant ainsi le système d’un effet en cascade de modifications d’implémentation qui seraient autrement nécessaires lorsqu’une seule modification de conception est effectuée. Cela permet aux différentes parties de l’architecture d’évoluer indépendamment.

Décomposer une application monolithique existante en microservices et la migrer vers le cloud est un choix prudent pour la modernisation, car cette approche permet aux fournisseurs et aux consommateurs d'API de faire évoluer leurs systèmes plus efficacement.

Nous allons ici explorer une étude de cas hypothétique dans laquelle une organisation modernise un système hérité en le refactorisant dans une architecture basée sur une API et en le replateformant pour le cloud.

Évolution vers un système basé sur API

Que signifie moderniser un système existant ? Une étape courante dans tout parcours de transformation numérique consiste à fournir les bons points de contact pour que les clients puissent effectuer des transactions, ce qui implique au minimum la création d'une application mobile. Mais il y a plus à faire. Dans la nouvelle économie numérique, la pression sur les délais de mise sur le marché a rapidement augmenté le nombre d'intégrations tierces, les organisations « construisant, empruntant ou achetant » pour développer leur notoriété numérique et leur clientèle.

Si nous examinons sous le capot la manière dont la modernisation est réalisée dans la pratique, nous constatons qu'elle implique à la fois le processus et la technologie , à savoir l'automatisation du déploiement et de l'amélioration des systèmes pour une livraison et une vérification continues ( processus ) et l'évolution des applications Web héritées vers des architectures orientées services basées sur des API ( technologie ). De plus, une infrastructure API telle qu’une passerelle API contribue à garantir un déploiement efficace dans un environnement cloud grâce à des capacités robustes de gestion du trafic et de sécurité.

Nous analysons ici une étude de cas hypothétique pour un tel embarquement numérique impliquant deux phases :

  1. Repenser un système hérité et une application monolithique dans une architecture pilotée par API
  2. Utiliser l'infrastructure API pour faire évoluer le système vers une plateforme cloud

Dans notre exemple hypothétique, un système de conférence prend en charge des fonctions telles que la création d'un compte de participant ( créer un compte ), l'examen des sessions disponibles ( examiner les sessions ) et la réservation de participation ( réserver des sessions ). Le client interagit avec le système de conférence via un navigateur Web. Par exemple, pour réserver une séance de conférence :

Sous le capot, le client interagit avec une application Web, qui envoie des appels API à l' application de conférence. L' application de conférence utilise SQL pour interroger le datastore backend :

Plusieurs exigences rendent nécessaire la modernisation du système de conférence existant :

  1. Prise en charge d'une application mobile
  2. Expansion du service sur les marchés mondiaux
  3. Réduction des coûts opérationnels dans le centre de données privé hébergeant actuellement le système

Un plan de haut niveau est élaboré :

  1. Exposez le service Attendee aux consommateurs à l'aide d'une passerelle API
  2. Refactoriser la fonctionnalité Sessions (afficher/réserver) à l'aide d'un service mesh
  3. Déplacez le service Attendee vers le cloud

Des mesures sont prises pour refactoriser le composant Attendee en un service indépendant. Le système de conférence dispose désormais de deux interfaces de trafic :

  1. Le client et le système de conférence ( Nord-Sud )
  2. Le système de conférence et le système des participants ( Est-Ouest )

Ensuite, une passerelle API est déployée pour faciliter la gestion évolutive, maintenable et sécurisée du trafic, y compris la terminaison SSL/TLS, l'authentification et la limitation du débit :

Ensuite, un service mesh est provisionné pour réutiliser la fonctionnalité Sessions du système de conférence hérité dans un nouveau service Session. Un service mesh fournit un contrôle précis du routage, garantit la fiabilité et gère efficacement le trafic pour la communication API de service à service afin de faciliter la visualisation et la réservation des sessions d'un participant :

Enfin, il est temps de migrer le service Attendee et la passerelle API vers le cloud. Cette approche évite des modifications majeures tout en tirant parti des services cloud natifs à mesure que l'organisation migre loin de son infrastructure sur site existante :

Pour mettre en pratique ce guide et moderniser vos applications existantes, consultez l’ eBook Mastering API Architecture pour découvrir les meilleures pratiques pour évoluer vers des systèmes basés sur des API.