Qui n’a jamais tremblé lorsque le post-it “Définir le Target Operating Model (TOM)”, alias Gouvernance, lui a été attribué ?

Il s’agit là d’une activité complexe mais pourtant au combien nécessaire pour l’efficacité et la pérennité d’une offre ou d’un service.

La Gouvernance IoT n’échappe pas à ce constat général, la difficulté en est même démultipliée : 

• l’IoT s’applique à une diversité de Métiers ayant chacun leurs particularités,
• la chaîne IoT nécessaire à un cas d’usage métier est constituée de nombreux maillons technologiques (cf. notre article IoT Un Marché en pleine ébullition) répartis sur un large spectre de compétences.

Quelle part de responsabilité attribuer aux Métiers / à l’IT ? Comment définir une structure commune transverse à l’échelle de l’Entreprise ? Comment fédérer les initiatives locales pour les encadrer et démultiplier les bénéfices ? Quel RACI peut être mis en place ?

IoT, flagrant délit de franchissement de ligne, de l’Information Technology (IT) vers les Operational Technology (Métier)

Comme nous l’avons évoqué dans notre précédent article, les technologies IoT s’immiscent sur des cas d’usages purement métier assurés jusque là par des Operational Technology.

Les Métiers étaient et sont toujours les sachants sur :

• Le contexte et les finalités du cas d’application,
• Les contraintes environnementales applicables (vibration, climatique, form factor, interférence, …),
• Les données pertinentes à récolter, et leurs fréquences,
• Les traitements métiers à appliquer sur les données pour obtenir les informations nécessaires au cas d’usage ciblé.

L’IT apporte son expertise sur les différentes couches technologiques :

• Les infrastructures à mettre en oeuvre,
• Les objets connectés (ou composant) à utiliser,
• Les plateformes qu’elles soient on-premise ou en mode PaaS / SaaS,
• La connectivité (les protocoles réseaux adéquats…),
• Les best practices et pattern d’intégration pour véhiculer, stocker et partager l’information,
• La sécurité sur l’ensemble de la chaîne.

De facto, nous identifions rapidement les risques à adopter une Gouvernance portée de façon unilatérale par :

• Le Métier : solution non pérenne technologiquement ou ne répondant pas aux standards de l’entreprise, solution propriétaire “vendor lock-in”, solution sous-dimensionnée, …
• L’IT : une couverture fonctionnelle non adaptée aux besoins réels (trou dans la raquette VS Rolls-Royce), une solution trop rigide et peu évolutive au regard des transformations du métier, …

Il y a donc une vraie dualité Métier / IT à mettre en oeuvre au niveau de la Gouvernance.

Une Gouvernance mixte, N approches

Personne aujourd’hui ne saura en mesure de vous conseiller de procéder comme-ceci ou comme celà sans avoir sondé votre existant :

• Quelle est le degré d’autonomie des entités opérationnelles ?
• Les métiers disposent-ils de ressources IT propres ?
• Est-ce que les directives IT sont centralisées ?
• Les cas d’usages IoT sont-ils déjà bien ancrés en transverse dans l’entreprise ou bien largement isolés ? Est-ce qu’une équipe dispose d’une vision globale sur toutes les initiatives / tous les projets ?
• Est-ce qu’il y a déjà des affinités à positionner telle entité sur le BUILD ou le RUN de tel ou tels maillons d’une chaîne IoT ?
• Est-ce que quelqu’un dispose de la vision bout en bout entre le cas d’usage et les moyens IT à mettre en oeuvre pour le traiter ?

Comment renseigneriez-vous les quelques éléments ci-dessous ?

Néanmoins quelques modèles de gouvernance  IoT émergent. Ci-dessous une illustration non-exhaustive :

• Filière 1 : Miser sur un socle IoT transverse à l’entreprise
  • Le Groupe est un enabler pour les métiers :
    • Le Digital est en charge de la définition de la stratégie IoT Groupe,
    • Le département IT, est responsable de la mise en oeuvre des socles / plateformes IoT (horizontales), d’accompagner et de supporter les métiers dans leurs projets.
  • Les Métiers sont responsables de leurs projets IoT positionnés en verticaux.

• Filière 2 : Miser sur l’agilité d’une Feature Team pour délivrer des solutions sur mesure
  • Les Métiers sont à l’origine des projets IoT,
  • Le département IT dédie des ressources à l’IoT dans ses différentes équipes (infrastructure, plateforme, réseaux, développement…). Ces ressources s’organisent généralement en Features Teams pour accompagner les projets métiers IoT avec le maximum de réactivité.

Et vous, vers quel modèle vous projetez-vous ?

Les victoires collectives sont les plus belles

La définition d’une Gouvernance est toujours complexe.

L’instruction d’un sujet IoT de bout en bout n’est pas une mince affaire. Cela requiert énormément de compétences technologiques (électronique, hardware, software, en passant par les télécoms…), tout en devant constamment s’assurer de l’adéquation avec la réalité terrain (contraintes mécaniques, etc.). 

De là à dire que définir une Gouvernance IoT est impossible, il n’y a qu’un pas.

Métier et IT doivent travailler main dans la main, le fossé les séparant devant être définitivement comblé.

Adopter une démarche d’Open Innovation (ateliers d’idéation, fablabs, pizza teams…) permettra de casser les silos, de cadrer et d’affiner le “Qui fait Quoi ?” dans cet écosystème en constante évolution.

#Teasing : dans un prochain article nous vous parlerons des différentes stratégies, des positionnements possibles pour mettre sur le marché une Offre IoT.

L’adoption du Cloud Public par les entreprises est une réalité et plusieurs d’entre elles ont fait le choix d’adopter cette stratégie dans le cadre de leur transformation digitale. Avoir une stratégie Cloud First pour une entreprise consiste à utiliser des services ou infrastructures Cloud par défaut pour répondre à toute nouvelle application, processus ou fonction. Mais l’adoption d’une stratégie Cloud First est-elle une bonne idée? Répond-elle aux promesses de réduction des coûts ou de gain en agilité? Faut-il foncer tête baissée avec une approche jusqu’au-boutiste? Cloud First, mythe ou réalité ?

Nous allons essayer de répondre à ses différentes questions en vous présentant les 5 mythes les plus répandus lors du cadrage d’une stratégie Cloud First !

Mythe #1 : Le cloud vous permettra de réduire vos coûts liés à l’infrastructure

Faux ! Ne pensez surtout pas que par défaut vous réaliserez des économies en migrant votre application sur le Cloud. Établissez très vite une grille de critères et un arbre de décision pour opter pour la meilleure stratégie de migration pour chaque socle applicatif et n’hésitez pas à décommissionner lorsque vous le pouvez.

Mythe #2 : Toute application est éligible au cloud public

Faux ! Il ne convient pas également de supposer que toutes vos applications ou processus métiers devraient s’exécuter sur le Cloud Public. Ce sera adapté dans certains cas et pour d’autres il faudra convenir du bon scénario (Cloud Privé, Serveurs physiques) en prenant le temps d’évaluer les bénéfices et les risques.

Mythe #3 : Il vous faut choisir un fournisseur cloud privilégié qui deviendra l’option par défaut

Faux ! Une stratégie Cloud First ne signifie pas pour autant se lier à un seul ou deux fournisseurs avec un catalogue de services le plus important possible. Il ne faut pas oublier qu’il n’y a pas que AWS, Azure et GCP sur le marché. D’ailleurs en terme de sourcing, il sera préférable d’éviter d’être complètement dépendant d’un fournisseur unique. Il existe pléthore de fournisseurs cloud, notamment SaaS, qui sont souvent plus adaptés pour certaines catégories d’applications pour des fonctions support ou de back-office (messagerie, outils de collaboration, crm, erp, etc.). Dans ce cas précis, une stratégie “Best-of-breed” où vous retenez la solution répondant au mieux dans l’état de l’art en service SaaS puis dans un deuxième temps la meilleure architecture solution via le catalogue de service de votre fournisseur Cloud Public privilégié peut être une meilleur stratégie. Si vous choisissez cette option, nous vous conseillons de déployer une Hybrid Integration Platform (HIP) pour gérer vos échanges de données.

Mythe #4 : Migrer votre application vers le cloud la rendra automatiquement plus résiliente

Faux ! Le SLA ou engagement de service pour un service Cloud sur Azure par exemple est de 99,95%. Bien que ce chiffre puisse paraître important et suffisant, cela signifie tout de même qu’il sera toléré par le fournisseur que le service soit arrêté ou en panne pendant 4 heures par mois, soit 2 jours par an en cumulés ! Or, plusieurs fonctions ou applications métier ou techniques nécessitent des engagements de service plus élevés. Afin de bénéficier d’une meilleure résilience de vos services sur le Cloud public, il sera nécessaire de revoir la conception de votre application et de choisir des principes d’architecture haute disponibilité distribuée adaptés à cet environnement pour rendre vos applications « Cloud Native » : «event-driven », fonctions isolées et indépendantes, « data centric », « stateless », etc.

Mythe #5 : une fois dans le cloud, la fonction d’architecture technique ne sera plus nécessaire

Faux ! Il vous sera toujours nécessaire d’avoir des architectes techniques pour supporter les besoins suivants :

• Gouverner, surveiller et sécuriser le Cloud,
• Estimer les coûts d’infrastructure pour vos prévisions budgétaires,
• Faire des recommandations d’optimisation d’architecture solution et technique,
• Automatiser des processus liés à la gestion et au déploiement de     solution/infrastructure,
• Maintenir et mettre à jour votre catalogue de services et les patterns d’architectures Cloud associés,
• Réaliser de la veille techno et évaluer de nouveaux produits et fonctionnalités offerts par vos fournisseurs,
• Implémenter des outils annexes pour compléter ceux disponibles dans le Cloud en tenant compte des résultats de votre veille techno.

Il sera donc primordial de nommer un Lead Cloud Architect et d’avoir votre centre d’expertise d’architecture technique Cloud pour assurer ces tâches. Evitez le piège d’énoncer uniquement des principes théoriques à suivre par les projets et prenez le temps d’expérimenter les modèles ou tester vos hypothèses.

Conclusion et recommandations

Capteur de température intelligent , smart watch, smart light … les smart things c’est IN, c’est HYPE, la majorité des publications en font l’éloge.

Est-ce que ces objets sont si smart qu’ils le prétendent ? Uniquement du point de vue technologique ? Qu’en est-il du point de vue utilisateur ?

Prenons le cas de Mr Dupont qui acquiert il y a quelques années son premier Smart Bracelet : le Jawbone UP 3.

Sur le papier : cet objet est vendu comme très intelligent car disposant de plein de capteurs (accéléromètre, gyroscope, température, …).

Dans la vraie vie :

1. Mr Dupont est agacé car certaines fonctionnalités n’ont jamais été implémentées bien que les capteurs nécessaires soient présents,
2. Étant très fragile, le bracelet (caoutchouc) s’est rompu à de multiple reprises. Par ailleurs, cette partie disposant d’un certain nombre de capteurs et étant indissociable de la véritable partie électronique, Mr Dupont a dû faire remplacer la totalité de son objet bon nombres de fois.
3. La société Jawbone a arrêté son activité Wearable grand public, les serveurs ont été débranchés.

Bilan :

• L’objet en lui même fonctionne bien, mais ne dispose pas d’écran pour afficher les données basiques (nombres de pas, …),
• La synchronisation des données entre l’objet et le smartphone n’est plus fonctionnelle,
• Quoi qu’il arrive le service étant décommissionné chez le fournisseur, les indicateurs et recommandations pour l’utilisateur ne sont plus calculés,
• Les centaines de millions d’unités vendues peuvent être jetées à la poubelle.

Ce simple exemple peut être décliné sur un grand catalogue de produit « smart ».

En conclusion

Il est effectivement facile d’écrire Smart sur un package marketing mais ce n’est pas une mince affaire à implémenter.

L’intelligence de l’objet doit être pensée sur chacune des phases du projet : de la conception de l’objet, en passant par l’architecture IoT (la localisation des traitements, …), jusqu’à l’ouverture à d’autres écosystèmes.

Nous tenterons très prochainement via un nouvel article (#RhapsodiesConseil #TeamIoT) de vous éclairer sur les différentes stratégies concernant la localisation des traitements (Cloud Computing VS Edge Computing).

Et si le client n’était que la partie visible de l’iceberg ? Pour tous les “transformers” digitaux des entreprises, l’objectif est de mieux connaître les clients. Imaginez cependant que vos clients vous écartent de votre véritable objectif : maîtriser la totalité de votre patrimoine de données.

Priorité client ne signifie pas priorité SI client

Les métiers expriment le besoin de mieux connaître les clients. Le premier réflexe est donc de lancer des projets sur les outils permettant de travailler étroitement avec les clients. Par SI orienté Client, nous entendons ainsi parler par exemple de CRM, Data lake client, DMP. La priorité est ainsi souvent donnée aux outils centrés sur la relation client et centrés sur les métiers en contact quotidien avec les clients.

Vous faites cependant face à des changements rapides du marché et à la transformation des habitudes des clients, liés aux opportunités du digital. L’évolution du seul SI client ne répondra pas à ces changements. L’approche client ne doit donc pas être uniquement synonyme d’évolution du SI client : elle doit piloter l’analyse de l’évolution du SI au travers de l’évolution des attentes des clients.

Connaître les attentes des clients avant tout

Prenons quelques exemples pour démontrer que bien connaître les attentes des clients permettra d’avoir le socle de votre transformation.

Le premier exemple concerne la confidentialité des données. Garantir la confidentialité et être transparent avec les clients, sont des sujets qui vont révolutionner la relation avec les clients. “Aujourd’hui 54% ¹ de la “GenTech” (génération Z) s’inquiètent quant à l’accès qu’ont les organisations à leurs données”. Les entreprises devront garantir et prouver à cette génération (les futurs clients) qu’ils répondent à la réglementation qui se développe sur le sujet.

Le deuxième exemple concerne le parcours d’un client qui cherche une assurance habitation. Suite à un ciblage et à une campagne par e-mail il est informé d’une toute nouvelle assurance habitation. Il ne donnera pas suite cependant car il n’a pas trouvé les informations détaillées sur la nouvelle assurance. Le parcours client ne comprend plus uniquement le fait de communiquer et de fournir un prix : il s’agit aussi de mettre à disposition les caractéristiques détaillées des produits pour faciliter l’acte d’achat.

Le dernier exemple concerne la disponibilité produit. Selon une étude PwC, “85% ² des enseignes françaises déclarent générer des revenus sur plusieurs canaux”.  Cependant les clients souhaitent connaître la disponibilité d’un produit peu importe le canal. Intégrer tous les points de vente dans vos stocks est la réponse qu’attendent dorénavant les clients.

Ces quelques exemples montrent qu’il est primordial d’avoir une vision à 360° des attentes des clients pour capter l’exhaustivité des besoins. Cette exhaustivité est le socle pour opérer votre transformation. Comment alors ensuite construire ce socle? Le plus sûr chemin pour y parvenir est de travailler à l’échelle de vos données.

La capillarité des données, base de la Transformation

La donnée est présente dans tous les processus, en contact ou non avec le client. C’est la capillarité des données. Pour répondre à l’ensemble des attentes des clients, il faut donc préférer travailler les données au travers de leurs utilisations.

Ainsi par ricochet, de nombreux sujets SI transverses seront adressés grâce à la capillarité des données. Collecter les données, créer des référentiels, mettre en place une gouvernance pour garantir la mise en qualité des données, garantir des informations en temps réel, connaître l’état d’avancement de processus, sont des sujets transverses à adresser dont tous les clients bénéficieront. 

La capillarité des données oblige en effet à se concentrer la maîtrise du patrimoine de données. L’analyse des attentes des clients au travers des données, va donc petit à petit faire émerger le SI permettant de maîtriser ces données : un SI Data Centric.

Être data centric est pérenne

Les bénéfices d’un SI Data Centric sont de construire un SI agile, évolutif et pérenne.

Définir au travers d’une approche “données” des principes de gouvernance et de mise en qualité, oblige à avoir des architectures SI orientées données, basées sur des “piliers SI” tels que les référentiels, les échanges, les outils de qualité de données et les workflows. 

Cette transformation sera durable tout en étant évolutive. Peu importe le besoin, le référentiel client alimente les systèmes liés à ce besoin. De même, les outils de qualité sauront s’adapter à tous les sujets business. Pour finir, l’approche API, conçue à partir de vos données, des besoins, et s’appuyant sur une conception fonctionnelle transverse à votre entreprise, sera aussi un outil robuste face aux changements des habitudes de vos clients.

A chaque nouveau besoin, vous enrichirez un de ces “piliers SI”. Chacun vous sollicite et profite de l’approche et de la capillarité des données. L’effet en est ainsi démultiplié avec l’accumulation des projets. 

Il reste cependant à savoir si vous avez la capacité à définir votre approche par les données et à mettre en place ces “piliers SI”. 

L’expert en vaut la chandelle

De la collecte à la mise à disposition des données, les “piliers SI” doivent garantir la bonne gestion des données et permettre de mieux satisfaire les clients. L’enjeu business est donc important.

Pour cela, des experts sur les SI Data Centric sont indispensables. L’expertise garantit d’optimiser les coûts et les plannings de construction du SI Data Centric autour des “piliers SI”. D’ailleurs, maintenant qu’il est établit qu’un SI répondant aux besoins clients est un SI Data Centric, quels sont les “piliers SI” à construire ?

¹ Source : theconversation.com
² Source : ecommerce.mag

Le phénomène d’API GraphQL est en progression, aujourd’hui sommes-nous prêts à abandonner à nouveau tout ce qui a été fait sur les API ces 15 dernières années et passer à un nouveau concept d’intégration ? Le GraphQL est-il une option viable pour remplacer l’API telle que nous l’avons définie jusqu’à aujourd’hui ?

Qu’est ce que le graphql ?

Le GraphQL se résume par la mise à disposition d’une interface de requêtage qui s’appuie sur les mêmes technologies d’intégration utilisées par les API REST. Nous allons toujours passer par le protocole HTTP et par un payload de retour, préférablement au format JSON, mais la différence pour le client repose sur le contrat d’interface.

Si nous essayons de vulgariser, les réponses apportées par le REST et le GraphQL à la même question sont fondamentalement différentes.

Analysons la question suivante : qui es-tu ? 

Voici comment elle serait abordée par Rest et par le GraphQL

Le REST :

• QUESTION : qui es-tu ?
• REPONSE : voici ma pièce d’identité (ni plus, ni moins)

Le GraphQL

• QUESTION : quels sont ton nom, prénom, date de naissance, adresse de résidence, lieu de travail et tes coordonnées personnelles ?
• RÉPONSE : voici toutes ces informations ciblés (et tu peux avoir encore plus de détails si tu veux, en une seule fois)

On a affaire ici à un changement radical dans la manière d’aborder les requêtes.

Ce qui reste central : la data

La DATA reste l’élément central de la réflexion autour du GraphQL. Sur ce point, nous pouvons voir l’héritage venant des paradigmes du REST, avec une focalisation sur la ressource. Alors que les pratiques précédentes, comme le SOAP, étaient plus axées “action”, le GraphQL est très axé sur la DATA, l’objectif primaire étant la manipulation de la donnée et pas l’exécution d’une opération.

Le concept de DATA est cependant présenté différemment. Elle n’est pas contrainte par une structure strictement définie à l’avance mais il est désormais possible de la naviguer par l’API GraphQL, ce qui change complètement le concept du contrat d’interface.

Il n’y a donc plus de contrat d’interface ? 

Nous pourrions en déduire que le contrat d’interface, très cher aux démarches SOAP et REST, n’est plus d’actualité pour le GraphQL…

Notre vision se résume en une simple phrase : ”Le contrat d’interface change de forme. Il n’est plus centré sur la structure de l’information retournée par l’API mais s’intéresse au modèle de données lui-même”

Le contrat d’interface s’appuie sur le modèle de données qui devient encore plus crucial puisqu’il est maintenant directement exposé / connu par les clients de l’API. Pour rappel, nous avons défini le GraphQL comme un langage de requêtage qui s’appuie sur la structure de la donnée définie dans notre schéma de modélisation. Bien qu’une couche d’abstraction ne soit pas totalement à exclure, le modèle de données, défini dans nos bases de données et exposé aux clients (par introspection ou connaissance directe), devient le point de départ de toute requête.

Voici un exemple de lecture issu de l’API GraphQL Spotify : 

Des avantages…

Cela saute aux yeux, la flexibilité est le grand avantage apporté par le GraphQL. Nous ne sommes plus contraints par le retour de données défini par le fournisseur de l’API mais uniquement par la donnée qui nous est mise à disposition. Cela permet de réduire le phénomène de l’underfetching (obligation d’utiliser plusieurs appels car un seul ne permet pas de remonter la totalité des informations nécessaires) et de l’overfetching (récupération de plus de données par rapport au besoin réel), vrais casse-têtes lors de la conception des APIs. 

L’autre vrai avantage est la rapidité de mise en œuvre. Sans vouloir rentrer dans la réalisation, la mise à disposition d’une API classique a toujours comporté des longues périodes de réflexion sur le périmètre, le découpage, la profondeur des données retournées. Ces phases de réflexion qui, sans un besoin clair en face, avaient tendance à se prolonger et à réduire le Time-To-Market des APIs. GraphQL permet de pallier ces problèmes :

• En libérant le fournisseur de l’API de cette lourde tâche de conception,
• En évitant la multiplication des APIs sur le même périmètre,
• En facilitant le choix du périmètre de la part du consommateur, sans qu’il soit forcément obligé d’orchestrer plusieurs requêtes afin obtenir ce dont il a besoin, sans limites théoriques.

…mais aussi des contraintes

La liberté donnée au client de l’API est certainement un avantage pour les deux parties mais apporte également des contraintes de sécurisation et de gestion de la charge serveur.

La charge

Une API, REST ou SOAP, est globalement maîtrisée. Elle a un périmètre bien défini et donc la seule question à se poser porte sur la volumétrie et/ou la fréquence d’appel. Le GraphQL, par le fait que les requêtes sont variables, réduit la prévisibilité de la charge associée :

• La non-prédictibilité des requêtes expose au risque de retours complexes et volumineux, sans pagination, ce qui pourrait mettre en difficulté une infrastructure mal dimensionnée ;
• L’utilisation du cache est complètement révolutionnée / complexifiée, car la probabilité d’avoir la même requête de deux différents consommateurs est très faible et ne permet donc pas de s’appuyer complètement sur le cache pour décharger les machines.

La sécurité

Dans l’ancienne conception nous pouvions avoir des niveaux de sécurité induits par le périmètre restreint de l’API. 

Le GraphQL, de par la liberté d’exploration des données, oblige à une réflexion plus profonde sur la question des habilitations et de l’accès aux informations. Cette sécurisation doit être garantie par une sorte de “douane” qui se définie comme la couche par laquelle nous devons transiter pour accéder aux données, et qui gère directement les droits d’accès par utilisateur.

Cette pratique n’est pas nouvelle, elle devrait accompagner toute démarche API, toutes technologies confondues. La couche de sécurisation et d’habilitations devrait toujours être indépendante de l’exposition de l’API. Parfois, un défaut de conception non identifié de cette couche de sécurité était pallié, tant bien que mal, par la limitation de périmètre imposé par l’API or cette limitation n’existe plus avec le GraphQL.

Conclusion

GraphQL représente la tentative la plus intéressante de “flexibiliser” la gestion des APIs et apporte une nouvelle dynamique à celle-ci, tout en respectant les contraintes induites par ce mode d’intégration. 

Si l’objectif n’est pas forcément de “tout casser”, pour recommencer tout en GraphQL, cette approche devient une alternative concrète aux démarches API dites “classiques”.Exemple en est la mise en application de cette méthode d’intégration sur une plateforme de paiement, Braintree, filiale de Paypal.

Une architecture Serverless, c’est quoi ?

Le marché du Serverless ou FaaS a bondi de manière importante en 2018, porté entre autres par la popularité grandissante de AWS Lambda, Azure Functions ou de Google Cloud Functions. Mais en quoi consiste une architecture Serverless ? Cela consiste à exécuter des fonctions sur le cloud sans se soucier de la conception de l’architecture technique et du provisionnement de serveurs. La facturation de ce type de service étant basée sur le temps que le traitement aura mis pour s’exécuter. Il y a donc toujours besoin de serveurs mais la conception et la gestion de ceux-ci sera réalisée à 100% par le fournisseur Cloud.

La différence avec une architecture basée sur des containers ?

La containérisation reprend les concepts de la virtualisation mais ajoute de la souplesse.

Un container est un sous-système pré-configuré par le biais d’une image. Celle-ci définit ce que le conteneur embarque à sa création (serveur d’application, application, etc.), normalement le minimum indispensable pour votre application (fonction ou micro-service).

Le Serverless est une architecture qui repose sur un concept simple : l’abstraction complète des ressources machine. 

Il vous suffira par exemple d’avoir un compte AWS, cliquer “Create function” depuis la console, configurer quelques paramètres techniques comme la taille de la mémoire allouée et le temps de timeout maximum toléré, copier votre code et voilà !

Avantages et inconvénients

Le principal avantage de ce type d’architecture est le coût. Vous ne paierez que ce vous utiliserez basé sur des métriques à la seconde. Plus besoin de louer des ressources comme des machines virtuelles que vous n’utilisiez jamais à 100% ou de payer un nombre d’utilisateurs qui n’étaient pas connectés en permanence dans l’outil. Par exemple pour une fonction AWS Lambda à laquelle vous aurez attribué 128 Mo de mémoire et que vous prévoyez d’exécuter 30 millions de fois en un mois (pour une durée de 200 ms par exécution), vos frais ne seront que 10€/mois environ ! Si cela correspond à un pic saisonnier atteint en période de solde et que la moyenne d’exécution correspondra à la moitié de cette charge vous ne paierez que ce que vous aurez consommé. À titre de comparaison, un serveur virtuel de 1 coeur et 2 Go de RAM facturé au mois sera facturé 12€/mois, peu importe la charge. Et si un serveur de ce type ne suffisait pas, il faudra prévoir le coût d’une plus grosse instance ou d’une deuxième. Il est donc évident que le FaaS permet d’optimiser vos coûts par rapport à du IaaS ou du PaaS.

Le second avantage est qu’il n’y a pas besoin de gérer et maintenir l’infrastructure. Vous n’arrivez pas sur vos projets Agiles à anticiper vos besoins d’infrastructure ? Vous pensez qu’attendre 1 jour pour avoir une machine virtuelle c’est encore trop long ? Vous trouvez bien le principe des microservices mais vous trouvez compliqué de gérer une architecture technique distribuée ? Une architecture Serverless ou FaaS vous simplifiera la vie de ce point de vue.

Il y a cependant des désavantages. Les AWS Lambda et Azure Functions sont des technologies propriétaires qui vous rendront complètement dépendant de votre fournisseur. Si un jour vous désirez migrer sur une autre plateforme, il vous faudra revoir le code de votre application notamment si celui-ci fait appel à des services ou infrastructure propre à ce fournisseur (lire un fichier dans un container S3 par exemple ne sera pas de la même façon que de le lire sur un Azure Blob). L’autre point important aussi à surveiller est que ces services sont bridés en termes de ressources et ne conviendront donc pas pour des applications nécessitant des performances élevées.

Pour quels cas d’usage ?

Une architecture Serverless peut convenir lorsque les critères suivants sont réunis :

Cela peut être par exemple :

•  Le lancement d’une requête comme l’appel d’une API pour récupérer les données de météo et les déposer dans la base de données utilisée par une application mobile.
•  L’envoi de notification par messagerie pour prévenir un groupe d’utilisateurs d’un événement.
•  Le transfert et la vérification du format de fichiers multimédias pour un site permettant à des photographes de partager leur travail.

En résumé, il s’agit d’une nouvelle façon de concevoir votre architecture solution, pouvant vous permettre de réaliser des économies importantes mais qui vous rendra plus dépendant du fournisseur Cloud que vous aurez retenu.