architecture

#3 Application Architecte Mach en eCommerce

#3 APPLICATION ARCHI MACH EN ECOMMERCE

11 juin 2024

Architecture

Erik Zanga

Manager Architecture

Dans les précédents volets, nous avons expliqué ce qu’est une architecture MACH et dans quels cas elle exploite tout son potentiel.

Dans cet article nous allons décrire les 5 points fondamentaux à la mise en place d’une architecture MACH dans un contexte legacy.

Définir le parcours utilisateur et les points de bascule

Le parcours utilisateur est naturellement le point de départ de la création d’une architecture web, mais dans quelle mesure il me permet de la définir et de la concevoir ? 

L’identification des différents points de bascule est primordiale pour identifier le découpage de l’architecture. Le “point de bascule” est une étape  dans le parcours client qui nous permet de passer d’un contexte fonctionnel à un autre.

Pour identifier les points de bascule, pensez données

Nous n’allons pas nous éterniser sur ce point, qui a déjà été traité dans d’autres articles (lien vers les articles micro-services).

Le point important à retenir, pour assurer un bon découpage de l’application, est que ma donnée peut passer de mon navigateur (micro front-end) à mon application back-end (micro-service) jusqu’à mon back-office (SAP, etc.) sans avoir des dépendances et des liens qui se croisent. En gros, un micro-service qui fait appel à un autre micro-service, n’est plus un micro-service.

Pour cela, nous devons bien identifier les données impliquées dans chaque étape.

architecture

Bien que nous ayons des données qui semblent similaires, le découplage est garanti : l’information du panier n’est pas forcément persistée, c’est un “brouillon” de ma commande que je vais abandonner une fois qu’elle est confirmée, il aura donc un cycle de vie différent avec une “fin de vie” au moment de la création de la commande.

Si nous voulons faire du micro-service, nous devons réfléchir au découpage des micro-services

Quand on parle de mise en place d’une architecture MACH, avec des back-office legacy, alors le découpage doit être adapté au contexte applicatif.

L’utilisation de la logique DDD (Domain Driven Design) ne doit pas s’abstraire de l’implémentation car quand on parle micro-service on parle bien de domaine métier mais également d’indépendance, etc. des principes qui découlent de choix d’implémentation.

Nous devons donc analyser les applications legacy et identifier les interactions qui seront nécessaires.

architecture

Ce découpage logique, simple, va créer le découplage entre mon application web, mon site eCommerce, et mes back office legacy, tout en exploitant leur potentiel et en créant des verticaux liés par le processus et indépendants dans leur conception et déploiement.

architecture

Penser déploiement et cloud-first

Bien que le Cloud ne soit pas une condition sinequanone, ces architectures se prêtent bien à un déploiement Cloud. 

Les services managés des cloudeurs s’adaptent bien à ce type d’architecture. Nous pouvons parler ici de serverless (ex. AWS Lambda, Google Cloud Functions, etc.), de la containerisation dynamique (ex. AWS Fargate, Azure Containers) ou, bien que moins intéressant, de la simple virtualisation.

architecture

Mais attention, les systèmes legacy ne sont pas forcément scalables autant que nous le souhaiterions. Penser à la chaîne complète des intéractions n’est pas un luxe. Dans certains cas l’échange avec ces outils peut réduire notre potentiel de montée en charge.

Dans ces cas, pensons découplage front-office / back-office.

Voici deux cas de figure et des solutions possibles :

architecture

L’architecture MACH s’avère être une solution hautement pertinente pour les entreprises souhaitant accroître leur agilité et améliorer leur réactivité technologique. Malgré les défis que son adoption peut poser, notamment dans des contextes dominés par des systèmes hérités, les bénéfices en matière de personnalisation, de performance et de gestion de l’infrastructure sont incontestables. Les organisations doivent soigneusement évaluer leur capacité à intégrer cette architecture, en considérant leur environnement technique actuel et leurs objectifs futurs.

architecture mach

#2 DÉFINIR POURQUOI L’ARCHITECTURE MACH S’ADAPTE BIEN À L’ECOMMERCE

#2 DÉFINIR POURQUOI L’ARCHITECTURE MACH S’ADAPTE BIEN À L'E COMMERCE

3 juin 2024

Architecture

Erik Zanga

Manager Architecture

L’architecture MACH convient-elle à tous les métiers et cas d’usages, ou existe-t-il des situations où elle est plus avantageuse et d’autres où elle est moins adaptée ?

Pour répondre à cette question nous allons à nouveau décomposer ce style d’architecture dans ses 4 briques essentielles : Microservices, API First, Cloud First et Headless.

La lettre M : Micro-services

C’est probablement ce premier point qui dirige notre choix de partir vers une architecture MACH vs aller chercher ailleurs. 

Nous pourrions presque dire que si l’architecture s’adapte à un découpage en Micro-services, le MACH est servi.

Pour aller un peu plus dans le détail, nous allons introduire le concept de “point de bascule” dans le parcours utilisateur. Nous définissons “point de bascule”, dans un processus, chaque étape qui permet de passer d’une donnée à une autre, ou d’un cycle de vie de la donnée à une autre. 

Une première analyse pour comprendre si notre architecture s’adapte ou pas à une architecture MACH, est d’établir si dans le parcours utilisateur nous pouvons introduire ces points de bascule, qui permettent de découper l’architecture des front-end et back-end en micro front-end et micro-services. 

Un processus eCommerce par exemple s’adapte bien à ce type de raisonnement. Les étapes sont souvent découpée en :

Ces 5 étapes traitent les données de façon séparée, et sont donc adaptées à un découpage en Micro-services.

Résultat : Le “M” de MACH et l’efficacité de cette architecture est fortement liée au cas d’usage et au domaine d’application.

La lettre A : API-First

Qui parle web a forcément dû penser aux APIs, dans le sens de Rest API, pour garantir la communication entre front-end et back-end.

Pas de surprise que cela s’adapte à pas mal de solutions, car la communication entre le front-end (navigateur) et le back-end (application) se base sur le protocole HTTP et donc très adapté à ce type d’interface. 

Nous ajoutons à tout ça le fait que la création d’un Micro-services et d’un Micro front-end, avec un découpage vertical sur les données traitées, implique naturellement la mise en place d’APIs et ressources spécifiques à chaque étape du parcours client. 

Le contexte eCommerce, encore une fois, est bien adapté à ce cas de figure. Les étapes de parcours dont nous avons parlé avant s’inscrivent dans une logique d’APIsation, avec pour chacune d’entre elles une API dédiée. 

Résultat : Le “A” de MACH impacte moins que le “M” dans le choix de l’architecture mais épouse bien les concepts définis dans le “M”. Il est donc également très approprié pour un contexte eCommerce. 

architecture mach
Pexels – ThisIsEngineering

La lettre “C” : Cloud-Native

Ce cas est probablement le plus simple : les seules raisons qui nous poussent à rester chez soi (infrastructure on premise), à ne pas s’ouvrir au cloud aujourd’hui sont de l’ordre de la sécurité, de l’accès et de la confidentialité de nos données (éviter le Cloud Act, etc.).

Au-delà de ces considérations, le passage au Cloud est une décision d’entreprise plus dans une optique d’optimisation de l’infrastructure que dans le cadre d’un cas d’usage, de processus spécifiques.

Résultat : Le “C” de MACH n’est pas d’un point de vue architectural pure une variante forte.

Néanmoins si nous regardons le cas d’usage cité auparavant, eCommerce, les restrictions sont levées car qui parle eCommerce parle naturellement d’ouverture, de mise à disposition sur le web, d’élasticité, concepts bien adaptés au contexte Cloud.

La lettre “H” : Headless

L’approche Headless convient particulièrement aux entreprises qui recherchent une personnalisation poussée de l’expérience utilisateur et qui ont la capacité de gérer plusieurs interfaces utilisateur en parallèle. 

C’est le cas pour du eCommerce, où l’évolution rapide, le time to market et la réactivité au changements du marché peuvent influencer l’appétence, le ciblage du besoin client et le taux de conversion.

Résultat : Le « H » de MACH souligne l’importance de l’expérience utilisateur et de la flexibilité dans la conception des interfaces. Il est particulièrement avantageux dans les contextes où la personnalisation et l’innovation de l’interface utilisateur sont prioritaires. Cependant, il nécessite une réflexion stratégique sur la gestion des ressources et des compétences au sein de l’équipe de développement.

En somme, l’architecture MACH offre une grande flexibilité, évolutivité, et permet une innovation rapide, ce qui la rend particulièrement adaptée aux entreprises qui évoluent dans des environnements dynamiques et qui ont besoin de s’adapter rapidement aux changements du marché. Les secteurs tels que l’e-commerce, les services financiers, et les médias, où les besoins en personnalisation et en évolutivité sont élevés, peuvent particulièrement bénéficier de cette approche.

Cependant, l’adoption de l’architecture MACH peut représenter un défi pour les organisations avec des contraintes fortes en termes de sécurité et de confidentialité des données, ou pour celles qui n’ont pas la structure ou la culture nécessaires pour gérer la complexité d’un écosystème distribué. De même, pour les projets plus petits ou moins complexes, l’approche traditionnelle monolithique pourrait s’avérer plus simple et plus économique à gérer.

En définitive, la décision d’adopter une architecture MACH doit être prise après une évaluation minutieuse des besoins spécifiques de l’entreprise, de ses capacités techniques, et de ses objectifs à long terme.

architecture mach

#1 DÉFINIR RAPIDEMENT L’ARCHITECTURE MACH ET POURQUOI ON EN PARLE

#1 DÉFINIR RAPIDEMENT L’ARCHITECTURE MACH ET POURQUOI ON EN PARLE

27 mai 2024

Erik Zanga

Manager Architecture

L’architecture MACH, de par son acronyme, regroupe quatre pratiques courantes et actuelles dans le développement d’applications web.

C’est quoi Architecture MACH ?

Dans ce premier volet, nous allons nous concentrer sur les concepts fondamentaux qui composent ce concept : Microservices, API First, Cloud First, Headless, afin d’adresser l’objectif de chacun.

Tout d’abord un avis personnel, le fait de mettre ces concepts ensemble découle du bon sens : ce type d’architecture est considéré comme simple, efficace, intuitive, bien structurée, modularisée, bref… un travail que les vrais architectes doivent forcément apprécier !

Les Microservices

Qu’est-ce qu’un Micro-service ? Une petite API ? 

Quid d’Amazon annonçant faire marche arrière pour Prime Video car la mise en application des micro-services implique un nombre d’orchestrations élevées ?

Les Micro-services, tels qu’expliqués dans d’autres articles (voir article micro-services), sont dans notre vision très fortement liés à un découpage DDD (Domain Driven Design).

Dans notre conception un micro-service définit un composant, dérivé d’un découpage métier et fonctionnel, agissant sur une donnée définie. 

Le micro-service ne se limite pas uniquement à la partie back-end. Dans un contexte d’architecture web, il peut s’appliquer également au front-end.

micro front end

Le Micro front-end et le Micro back-end se retrouvent intimement liés par une logique “composant d’affichage” et “composant qui traite applicativement la donnée affichée”.

Une architecture micro-services implique donc une certaine verticalité affichage, traitement et data.

micro front end

API-First

C’est presque logique, on fait communiquer les différents composants par APIs. 

micro service

Être API-first signifie d’intégrer la conception des APIs au cœur du processus de conception globale de l’application. Un peu comme si les APIs étaient le produit final. 

Attention par contre, autant nous allons retenir l’API entre micro front end et micro back end, autant ce principe n’est pas partagé avec la communication entre le micro-service et d’autres composants du SI. 

Une étude des différents patterns d’échange et un choix judicieux entre des méthodes synchrones et asynchrones est très importante pour éviter de mettre des contraintes fortes là où nous n’en avons pas besoin : pour partager une donnée avec les applications back office, tels qu’une confirmation de prise de commande avec un SAP, nous n’avons pas toujours besoin de désigner des flux synchrones ou API, nous pouvons par exemple découpler avec une logique de messaging, le cas d’usage nous le dira !

Cloud-First

Une vraie prédilection pour le Cloud, que du buzzword ?

En réalité, le fait de mettre en avant du Cloud dans cette démarche n’est que du bon sens. 

Nous pouvons mettre en place une architecture on premise, pourquoi pas, mais dans certains cas il s’agit d’un vrai challenge : mise en place des serveurs, déploiement de la couche OS, des services, de la partie VM ou Container, etc. 

Le Cloud First des architecture MACH vise la puissance des services managés, rapides de déploiement, scalables et élastiques, sur lesquels le déploiement en serverless ou en conteneur et la mise en place des chaînes CI/CD sont en pratique les seules choses à maîtriser, le reste étant fourni dans le package des fournisseurs de services cloud !

HEADLESS

Le Headless représente une tendance croissante dans le développement web et mobile. Cette approche met l’accent sur la séparation entre la couche de présentation, ou « front-end », et la logique métier, ou « back-end ». Cette séparation permet une plus grande flexibilité dans la manière dont le contenu est présenté et consommé. Elle offre ainsi une liberté de création sans précédent aux concepteurs d’expérience utilisateur et aux développeurs front-end.

Dans un contexte Headless, les front-ends peuvent être développés de manière indépendante. Les développeurs peuvent utiliser les meilleures technologies adaptées à chaque plateforme. Cela s’applique au web, aux applications mobiles, aux assistants vocaux, et à tout autre dispositif connecté. Cette approche favorise une innovation rapide. Cela permet aux entreprises de déployer ou de mettre à jour leurs interfaces utilisateur sans avoir à toucher à la logique métier sous-jacente.

La question qui nous vient à l’esprit maintenant est : 

Ce type d’architecture s’applique à tout cas d’usage ? Certains sont plus réceptifs que d’autres de par leur configuration, gestion du parcours utilisateur ?

Un exemple dans le prochain épisode !

Articles qui pourraient vous intéresser

as Prompt” va-t-il devenir la norme ?

“as Prompt” va-t-il devenir la norme ?

“as Prompt” va-t-il devenir la norme ?

15 avril 2024

Architecture d’entreprise

Clément Lefranc

Senior Manager Architecture

Impulsées par l’avènement du Cloud et du DevOps, les mouvances “as Code” et “Software Defined X” ont grandement amélioré la gestion du cycle de vie des assets informatiques (infrastructure, middleware, serveur d’application, …) avec principalement :

Nous détaillerons dans un futur article le positionnement de chacun et les grands paradigmes en présence (procédurale vs déclaratif), qui reposent sur une caractéristique commune: l’utilisation de template/playbook au format normalisé (HCL, YAML, …) décrivant l’état final à atteindre ou le moyen d’y aller.

Même si la syntaxe est Human Readable, il peut être fastidieux à l’échelle d’un SI en perpétuelle évolution d’écrire et de mettre à jour ces fichiers de description.

Bien qu’il existe de plus en plus de plateformes simplifiant la création de ceux-ci sur base de conception visuelle en LowCode/NoCode ou de schématisation…Que diriez-vous de troquer d’un point de vue utilisateur le ”as Code” par du ‘as Prompt” ?

#GenAI à la rescousse

Le terrain de jeux des Large Language Models (LLM) et de la GenAI ne cesse de croître, en n’oubliant pas au passage l’ingénierie logicielle.

Imaginez pouvoir simplement demander “Provisionne un cluster de VM EC2 avec NGINX en exposition publique ainsi qu’une base Elasticache” pour voir votre souhait exaucé instantanément.

D’ailleurs, n’imaginez plus, car l’Infrastructure as Prompt (IaP) est déjà proposée par Pulumi AI, et bien d’autres en cours (depX) ou à venir.

Ce positionnement et les avancées rapides et significatives dans ce domaine ne sont pas étonnantes car nous sommes en plein dans le domaine de prédilection des LLMs: les langages.

Qu’ils s’agissent de langages parlés (Français, Anglais, …), de langages de programmation (Python, JavaScript, Rust), de langage de description (HCL, YAML, …), ils ont tous deux concepts fondamentaux: 

Plus le dictionnaire et la grammaire d’un langage sont dépourvus d’ambiguïtés, plus le degré de maturité et la mise en application de la GenAI et des LLMs sur celui-ci peut-être rapide. 

L’Infrastructure as Prompt n’est pas une rupture totale avec le “as Code”, simplement une modernisation de l’interface “Homme-Clavier”.

A l’avenir elle pourra se révéler un parfait assistant pour faire des recommandations et propositions d’ajustement vis-a-vis de la demande initiale pour optimiser l’architecture à déployer:

#La confiance n’exclut pas le contrôle

Bien que la baguette magique qu’apporte cette surcouche soit alléchante, nous ne pouvons qu’abonder les paroles de Benjamin Bayard dans son interview Thinkerview Intelligence artificielle, bullsh*t, pipotron ? (25min) : “tous les systèmes de production de contenus si ce n’est pas à destination d’un spécialiste du domaine qui va relire le truc, c’est dangereux.”

Dans un avenir proche l’Infrastructure as Prompt // la Configuration as Prompt n’est pas à mettre dans les mains de Madame Michu (que nous respectons par ailleurs) qui ne saura pas vérifier et corriger le contenu de Provisioning, de Configuration ou de Change qui a été automatiquement généré. Nous vous laissons imaginer les effets de bords potentiels en cas de mauvaise configuration (impact production, impact financier, …) dont le responsable ne serait autre que la Personne ayant validé le déploiement. Impossible de se dédouaner avec un sinistre “c’est de la faute du as Prompt”.

Vous l’avez compris, la déferlante LLM et GenAI continue de gagner du terrain dans l’IT, le potentiel est énorme mais ne remplace en rien la nécessité d’avoir des experts du domaine.
Le “as Prompt” se révèle être un énorme accélérateur pour l’apprentissage du sujet, ou dans le quotidien de l’expert .. qui devra avoir une recrudescence de prudence quant aux configurations qui ont été automatiquement générées.

version 6 de SAFe pour l’architecte d’entreprise ?

Quoi de nouveau dans la version 6 de SAFe pour l’architecte d’entreprise ?

Quoi de nouveau dans la version 6 de SAFe pour l’architecte d’entreprise ?

Thomas Jardinet

Manager Architecture

Salomé Culis

Consultante Architecture

Le VRAI Enterprise Architect

Cet article est le troisième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version 6 du framework SAFe. 

Après avoir étudié le System Architect et le Solution Architect, rencontrons l’Enterprise Architect ! Avant de rentrer dans le vif du sujet, nous souhaitions vous faire part de nos impressions quant aux évolutions du rôle de l’Enterprise Architect. 

Dans les versions précédentes, le rôle de l’architecte d’entreprise n’était pas très détaillé. Il était clair que celui-ci intervenait dans la définition de la stratégie et aidait à mettre en adéquation les évolutions du système d’information avec celles du métier de l’entreprise, mais cela s’arrêtait là. 

Dans cette nouvelle version, le framework contient beaucoup plus de détails sur les responsabilités de l’architecte d’entreprise. Celui-ci gagne ses lettres de noblesse et récupère dans sa bannette des sujets qu’il aurait toujours dû avoir (par exemple la rationalisation du portefeuille technologique). Son rôle n’est plus dans la pure stratégie décorrélée du terrain, il devient plus concret. 

En revanche, il a aussi tout un lot d’activités nouvelles, que nous détaillerons dans la suite, et qui nous font dire qu’il faut avoir les épaules très larges pour occuper ce poste. L’architecte d’entreprise semble être partout à la fois, il est devenu une sorte de couteau-suisse ou d’architecte tout terrain si vous me passez l’expression. 

Serait-il devenu l’architecte de l’entreprise ? Celui qui cumule bon nombre de responsabilités et qui collabore très largement avec l’ensemble de l’entreprise ? C’est ce que nous allons découvrir dans la suite ! 

version 6 de SAFe pour l’architecte d’entreprise

De nouvelles responsabilités : De la définition de la stratégie, aux mains dans le code.

L’entreprise Architect s’est ainsi beaucoup musclé au passage de la version 5 vers la version 6 du framework Safe. Il est certes toujours responsable, au mot près, de la stratégie. Mais d’un rôle de facilitateur semi-passif (« Collaborating », « Assisting », « Helping », « Participating », etc…), il bascule vers un rôle de prescripteur. Un regard critique dirait qu’il retrouve ses prérogatives naturelles… Ainsi les différents (et nouveaux) rôles définis par le framework Safe sont : 

L’architecte d’entreprise reprend donc son rôle d’architecte d’entreprise, du métier aux développeurs, en passant par l’organisation des équipes. Par contre, son rôle est beaucoup plus étendu que dans la version 5, se retrouvant ainsi au milieu de nombreux acteurs.

version 6 de SAFe pour l’architecte d’entreprise

Un accent mis sur la collaboration : D’une tour d’ivoire à un lean-agile leader

En effet, dans la version précédente de Safe, l’architecte d’entreprise était vu comme gravitant surtout dans les hautes sphères et ne collaborait qu’avec les autres architectes et des acteurs de haut niveau ou très transverses (Lean Portfolio Management, Agile Program Management Office, et le Lean-Agile Center of Excellence par exemple). 

Il était supposé maintenir des relations avec les personnes de chaque Train mais ses activités quotidiennes ne s’y prêtaient guère. A présent que son périmètre s’étend considérablement, il sera amené à croiser des acteurs beaucoup plus nombreux. Il intervient comme proxy des acteurs business et doit être capable de porter la vision et la stratégie business auprès des différentes parties prenantes. 

Il participe également à tous les événements en lien avec les enablers epics et aura donc l’occasion d’interagir avec les acteurs opérationnels des différents Trains. 

Ses responsabilités étant également plus distinctes de celles des autres architectes, leur complémentarité est d’autant plus mise en évidence. Une collaboration efficace entre l’Entreprise Architect, le Solution Architect et le System Architect garantit l’alignement. 

Enfin, l’Entreprise Architect doit incarner le Lead Agile Leader par excellence. Il mentore les équipes agiles, contribue à la mise en place de nouveaux modes de fonctionnement, et montre l’exemple en continuant à apprendre et à évoluer. Une forme de super héros inspirant tout le monde sur son passage, facile non ? 

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 4 et 6 peuvent en particulier se révéler utiles : 

Parmi la littérature conseillée par le framework Safe, on ne peut que vous conseiller le fameux livre “Team Topologies” qui évoque le rapprochement des équipes technologies et business :

Google, le clouder de l’intégration

Google, le clouder de l’intégration ? Zoom sur leur nouvelle solution d’iPaaS

Google, le clouder de l’intégration? Zoom sur leur nouvelle solution d’iPaaS

7 novembre 2023

Srikanth Ramanoudjame

Consultant Architecture

“Application Integration” est un ajout récent au catalogue de services de la plateforme Cloud Google (GCP). Il s’agit d’une solution d’iPaaS (Integration Platform as a Service), composée par Google sur la base de ses Services Managés pour offrir des fonctionnalités que nous retrouvons traditionnellement dans les solutions  d’intégration pure players (#Boomi #MulesoftAnypoint #Snaplogic, …) (bibliothèque de connecteurs techniques/applicatifs, environnement de développement, mappings, …).

Quelles sont les caractéristiques du service “Application Integration” ? 

Sous quelle forme se présente le service et comment s’intègre-t-il avec les autres technologies de la plateforme GCP ?

Interface de la plateforme et modèle de déploiement

La plateforme permet de concevoir graphiquement les flux d’intégration entre applications à l’aide :

“Application Integration” est un service full managé de Google Cloud Platform. Pour l’heure un déploiement en mode hybride ou On-Prem n’est pas possible.

Modèle de facturation par typologies de connecteurs

Le service comprend une bibliothèque de connecteurs technologiques / applicatifs permettant de s’interfacer avec différentes applications, composants de l’écosystème Google ou tiers (progiciels du marché, bases de données open source, systèmes de messaging…). 

Ces « Integration Connectors » fonctionnent sur un modèle de paiement à l’usage, selon différentes modalités. Ainsi la facturation s’effectue en fonction des éléments suivants :

A titre d’exemple, on peut donc distinguer les connecteurs suivants :

Zendesk, Splunk ou encore ElasticSearch, etc. – pour des applications autres et en Preview

Google, le clouder de l’intégration

Intégration avec des outils/environnements de développement tiers 

Comme évoqué précédemment, la plateforme fournit une interface graphique pour construire des flux d’intégration en Drag & Drop, mais il est également possible d’intégrer des traitements spécifiques supplémentaires. 

Google Cloud Functions est un service de la plateforme GCP permettant de créer des fonctions déclenchées sur évènement.

La « Cloud Function Task » permet d’interagir avec des Cloud Functions crées sur GCP (seul l’environnement d’exécution Python est supporté par le service Application Integration pour l’implémentation des fonctions). 

L’exécution de la Cloud Function sera intégrée à la séquence d’exécution du flux d’intégration sur Application Integration.

Automatisation de parties de workflow de développement de flux 

Duet AI est un service Google proposant un assistant virtuel, intégré à l’interface d’”Application Integration”. L’assistant est ainsi intégré dans le workflow de développement du flux d’intégration, suggérant un mapping à l’aide d’inputs en langage naturel, sur l’intégration à implémenter :

En point notable, nous remarquons qu’”Application Integration” est avant toute chose une solution full GCP. Pas d’hybridation, cette modalité d’instanciation à date n’est dévolue qu’à APIGEE dans le catalogue de GCP sur les briques d’intégration. 

La solution Apigee est-elle pour autant le point d’entrée unique d’une architecture hybride ? C’est en tout cas l’impression que cela nous donne à date. 

Néanmoins, nous saluons l’effort de Google d’aller sur le marché de l’iPaaS, sans offre équivalente sur le marché des clouders Azure / AWS. Ces derniers proposent à ce stade, à couverture fonctionnelle comparable en matière d’intégration, des services / modules distincts plutôt qu’un applicatif packagé (logic apps, lambda, step functions…).   

“Application Integration” parviendra-t-il à détourner la clientèle des solutions iPaaS pure players ? Nul doute que les actuels clients GCP s’interrogeront.