Phase 1 : Phase du gros système
Toutes les applications tournaient sur une seule grosse machine avec une seule base de données, c’était l’époque des mainframes
Cette phase a beaucoup souffert par les temps de mise en production très longue pouvant aller jusqu’à plusieurs mois voire année et par des risques de guerre et d’attentats dû au contexte géopolitique de l’époque des années 80 (la guerre froide)

Phase 2 : Les applications clients/serveur et 3 tiers
Ces applications ont apporté un premier niveau de décomposition où on a séparé les différents de l’application et notamment en 3 parties
La partie UI ou IHM pour le graphisme, les écrans et les rapports
La partie traitement business pour les règles de gestion spécifique à l’entreprise
La partie traitement et stockage des données avec l’émergence de nouvelle application dite de gestion de base de données exemples les plus connus SQL Server et Oracle

Phase 3 : Les applications accessibles par le Web
Cette 2éme phase a permis l’arrivée en masse des applications dites Web où la partie client tournait dans un navigateur (exemple les sites de vente en ligne, les applications CRM, ERP et RH qui tourne dans votre navigateur)
Toutes ces applications tournaient soit au sein de l’entreprise soit chez un hébergeur qui met en location le serveur d’hébergement et une partie de sa bande passante
Cette 3éme phase, bien qu’elle ait libéré une certaine vision de l’informatique elle a connu également des problèmes et de risques comme par exemple le risque de défaillance du fournisseur qui hébergeait l’application web et des problèmes d’évolutivité et de scalabilité car il fallait réserver les ressources à l’avance

Phase 4 : l’ère des infrastructures comme service
Au vu de ces risques majeurs, les gros éditeurs et opérateurs de l’informatique qui se sont constitués des systèmes très complexe pour leur besoin interne ont mis en location une partie de leur ressource disponible.
C’est l’arrivée du cloud de Microsoft Azure (1ér Février 2010) et de Amazon Web service (2006). Ces fournisseurs disposants de ressources pour leur plateforme (Microsoft avec MSN et Hotmail et Amazon avec leur site e-commerce) ont dans un premier temps proposé un hébergement classique telle que les autres fournisseurs proposaient mais avec leur renommé comme garantie. Cette phase a été nommée par le terme technique de IAAS ou « Infrastructure as a service en anglais »

Phase 5 : L’ère des plateformes comme service
Aujourd’hui nous sommes entrées dans l’ère du tout service, et notamment par dans un premier temps la virtualisation totale des plateformes techniques (à savoir les outils de gestion de bases de données, de suivi et de monitoring, les systèmes d’exploitation devant faire tourner l’application et même le système de stockage et de sauvegarde). Les opérateurs majeurs de la phase 4 se livrent une guerre et une course à celui qui sort le premier un composant as a service et on assiste donc à des offres de plus en plus complet et de plus en plus variés.
L’article que je vous propose profite de cette course, en effet c’est grâce au PAAS que nous voyons devenir réalité les architectures de type Serverless, FAAS et Microservices.

Phase 6 : L’ère des plateformes SAAS
En virtualisant les plateformes, les opérateurs des cloud publics et privés, permettent aux développeurs d’imaginer des solutions de plus en plus complexe. Rendant possible l’arrivée des solutions sans serveur (serverless), les solutions orientées fonctions (FAAS) et même les plateformes Microservices et CQRS

Flux de Données / FAAS

Qu’est-ce qu’un flux de données ?
Avant d’aller plus loin, dans notre voyage au tour des FAAS, voyant déjà une première question importante, Mais Qu’est-ce qu’un flux de données ?

Un flux de données est un programme qui permet d’interconnecter plusieurs composants applicatifs entre eux pour rendre un service métier. Par Exemple nous avons les flux d’import de catalogue produit qui permet à un site internet de vente en ligne d’importer son catalogue, nous avons également les flux de calcul de prix qui permet après validation du panier d’un client de calculer le prix de vente réelle, d’y appliquer les réductions et les frais de dossiers et de livraisons par exemple ou nous avons encore les flux d’export vers les tableaux de bord de suivi par exemple. 

Quels sont les catégories de flux de données ?
En règle générale, nous pouvons regrouper les flux en 3 catégories à savoir
• Les flux d’import qui permettent d’importer des données comme les catalogues produits, les prix, les promotions, etc..
• Les flux événementiels qui réagissent à des actions du système informatique comme le calcul de prix après ajout au panier ou le calcul de bon d’achat après achat
• Les flux d’export qui permettent de restituer les données du système à des systèmes tierces exemple l’export des données de vente vers les tableaux de bord ou les outils décisionnels
Quels sont les avantages attendue d’une architecture FAAS ?

Simple à déployer
Normalement et aussi bien dans le Cloud que en On-promise, les fonctions FAAS, sont très facilement déployable. En effet la partie technique étant standardisée, les équipes d’exploitations sont déjà formées sur ces outils et ne nécessitent aucune maitrise supplémentaire pour déployer une fonction additionnelle

Ouvert
Dans la plus part des cas, les fonctions FAAS sont ouvertes et s’intègrent facilement avec le SI déjà existant

Standard
Il est très rare de redévelopper tous les composants techniques pour faire fonctionner une fonction FAAS. Dans la matière, les développeurs seront plus tôt cadrées par les plateformes utilisées. Et par les mécanismes d’orchestration et d’exécutions fournies par la plateforme. Ainsi sur Azure Function, les développeurs vont en règle générale utiliser les connecteurs et services de Azure et implémenter uniquement leur code métier

Responsabilité unique
A l’instar des plateformes micro services, chaque fonction sera scalaire et sera responsable de fournir une fonction unique

Hébergement mature
Logiquement et en règles, les clusters et les plateforme d’hébergement seront déjà existant dans l’entreprise. Il n’est donc pas nécessaire de mettre en place des nouvelles plateformes et de les régler pour bien s’interfacer avec le système de l’Entreprise

Quels sont les domaines d’utilisation de FAAS ?
En règle les fonctions FAAS peuvent être utilisés dans tous les domaines de l’entreprise et plus spécifiquement là où la machine doit traiter des commandes unitaires automatisées.

Domaine de l’Informatique technique
Le domaine de l’informatique technique synchronisation de compte, gestion de self-service (DNS, SSL) ainsi que la gestion des ticketings Help desk pourraient grandement profiter des architectures FAAS pour automatiser leur traitement

Sécurité Informatique
Le domaine de la sécurité informatique utilisent beaucoup de batch pour auditer les plateformes à surveiller et détecter les risques d’intrusions. Microsoft sur Azure avec WIF par exemple se base beaucoup sur Azure batch. C’est pourquoi FAAS peut être une solution plus qu’envisageable

Domaine de l’informatique de gestion
Les progiciels de gestion de type ERP, Comptabilité, Sales Force, CRM utilisent énormément des batchs de nettoyage, d’intégration, de calcul ils gagneraient également à utiliser les FAAS

Domaine de l’e-Commerce
Les opérateurs Internet de l’e-commerce utilisent beaucoup les architectures de type microservices et les services d’intégration. Nous pouvons penser que les plateformes FAAS ont même été conçues initialement  pour ce type de besoins

Les réseaux sociaux et la syndication de contenu
Une domaine historique de l’intégration de contenu, qui se faisaient très manuellement et qui de plus en plus profitent de ces nouvelles plateformes FAAS pour orchestrer et partager le contenu entre les différents réseaux et le site CMS de l’entreprise. D’ailleurs nous pouvons bien résumé les offres de beaucoup de produits dans ce domaine y compris Google et Bing dans ce domaine à du FAAS

commerciale
Big Data et l’Analytics
Les système de Big Data et analytics ont toujours été les domaines phare de l’intégration des données, là aussi FAAS pourraient jouer un rôle

Quels sont les prérequis pour faire du FAAS ?
Pour faire du FAAS, un certain nombre d’éléments est nécessaire
Dans Azure

• 1 compte Saas Function App base sur App service
• Possibilité d‘accès aux sources et services Dans votre entreprise via le service Azure Relay

Sur Windows

• Windows 2016 avec le support de Container

Sur Amazon

• 1 compte Lambda Function

Integration

• 1 compte de stockage pour  la lecture et l’écriture fichiers plats
• 1 compte service bus pour les files d‘attente et les rubriques de notification
• 1 ou plusieurs sources de données de type SQL ou non SQL

Comment cela fonctionne ?

Les Déclencheurs
Le déclencheur est un composant souvent fournit par la plateforme d’hébergement de la fonction pour déclencher une action.

Les Déclencheurs sur AZURE Function
• Blob Storage
• Cosmos DB
• Event Grid
• Event Hubs
• HTTP
• Microsoft Graph
• Queue storage
• Service Bus
• Timer
• Webhooks

Les déclencheurs sur Amazon Lambda
• Amazon S3 Bucket
• Amazon DynamoDB
• Amazon Kinesis Data Streams
• Amazon Simple Notification Service
• Amazon Simple Email Service
• Amazon Cognito
• CloudFormation
• CloudWatch Logs / Events
• CodeCommit
• Scheduler
• Resource Configuration
• Alexa
• Lex
• HTTP
• IOT
• CloudFront
• Kinesis Data Firehose

Le code de fonctionnement

Le code de fonctionnement peut-être dans plusieurs langages pour notre part, nous privilégierons .NET CORE 2 mais il est possible d’utiliser de nombreux autres langages

Langages supportés avec Azure Function
• C#
• Javascript
• F#
• Java
• Python
• PHP
• TypeScript
• Batch
• Bash
• Powershell

Langages supportés avec Amazon Lambda
• Node.js
• Python
• Java
• C#
• Go

Les publieurs
Les publieurs permettent de récupérer le résultat d’une fonction et de la publier sur un autre pour par exemple être réutilisé par une autre fonction voir même une autre interface utilisateur
Il existe différentes catégories de publieur mais nous pouvons notamment lister
– Les publieur de sources de données qui permettent de mettre à jour des bases de données SQL ou non SQL
– Les publieur d’events qui mettent à jour des messages dans des files d’attente ou dans des rubriques de notification
– Les publieurs de fichiers qui permettent de publier des fichiers

Les publieurs sur Azure Function
– Blob Storage
– Cosmos DB
– Event Hubs
– External File
– External Table
– HTTP
– Microsoft Graph
– Microsoft Graph
– Microsoft Graph
– Microsoft Graph
– Mobile Apps
– Notification Hubs
– Queue storage
– SendGrid
– Service Bus
– Table storage
– Twilio
– Webhooks

Les publieurs sur Amazon Lambda
Amazon fournit des publieurs pour l’ensemble des ces services cloud.

Les différentes architectures de traitement

Il est possible d’utiliser différentes types d’architecture pour pouvoir définir une architecture cible pour une fonction ou une application sur FAAS. Tout dépend de ce qu’on veut faire

Une fonction de Traitement des données ou de fichiers

En règle générale et avant l’arrivée des FAAS, il pouvait être très compliqué de concevoir des applications de batch de traitement des données ou des fichiers. En effet il était courant de faire des applications très complexes avec plusieurs fonctions pour traiter les fichiers entrants d’un système informatique.
Cette complexité a conduit les entreprises à utiliser des outils d’extractions, de transformation et de rechargement appelé ETL. Nous allons voir qu’en faite les applications de type FAAS permettent de simplifier grandement le travail des développeurs

Composants techniques nécessaires
Que nous utilisons Amazon Cloud ou Azure ou on promise, nous allons avoir besoin
– D’un connecteur pour récupérer le contenu à extraire (type fichier plat, source sql, messagerie e-mail, service social, photothèque, etc…)
– D’une architecture applicative en microservice
– D’un publieur pour recharger les données traitées
Plusieurs fonctions ou une seule Fonction
Il est de règle générale, et à l’instar des microservices, les fonctions FAAS doivent être le plus singularisé possible. Une fonction par responsabilité ou Action.
Exemple : Il n’est pas question de faire une fonction qui va extraite les données, les consolider ou valider et les recharger dans la même fonction

L’architecture physique
En réalité les fonctions FAAS reposent en règle générale sur des architectures microservices basée sur des événements de domaine.
Chaque action constituera en rège générale un microservice avec un front de type fonction
Nous utiliserons un système de publication/souscription pour publier les actions souhaitées et leur état. Sur Azure, il est fortement recommandée d’utiliser Azure Service Bus et sur Amazon d’utiliser Amazon SNS, mais d’autre fournisseurs peuvent être utilisés
Chaque fonction s’abonne à un événement et déclenche un autre événement
L’architecture physique suivant résume souvent le protocole utilisé pour traiter des données ou des fichiers

La vue Logique d’une fonction
Comme nous l’avons déjà vue à plusieurs reprise, l’architecture applicative d’une fonction se base sur une architecture très proche d’une architecture micro-service de toute autre application. Ainsi le diagramme dit en oignon peut très bien faciliter la lecture

Comme nous le voyons bien, nous pouvons observer 4 strates
– La strate de présentation est ici remplacée par tout simplement le code déclaratif de la fonction qu’elle soit sous Azure Function ou sous Amazon Lambda
– La strate service comporte les services, les événements, les métriques et la journalisation nécessaire, les modèles et les règles de mapping entité/modèle
– La strate infrastructure comporte les entités, les composants d’accès aux données et les composants d’accès aux services REST externes

Le Diagramme d’état d’un traitement FAAS
Le diagramme suivant donne les éléments clés nécessaires pour bien comprendre comment un service de traitement peut être enchainé grâce à FAAS. Ici chaque fonction correspond à un micro-service qui s’abonne à des événements du domaine et un système de notification / publication est mis en place.
Cette architecture permet de décorréler le traitement ainsi il sera plus scalable et la reprise sur incident sera plus facile.

Les Composants partagés
Il est notable que les services vont partager des composants, on utilisera alors les packages repository de nuget pour pouvoir le réaliser. Ainsi nous partagerons souvent
– Les composants d’accès aux données SQL ou Non exemple Entity Framework Core
– Les composants de logging exemple NLog, Log4Net ou encore ceux des fournisseurs Cloud Azure et Amazon
– Les composants de métriques exemple Application Metrics ou ceux des fournisseurs Cloud Azure et Amazon

Le Traitement des flux en temps réel

Vous pouvez utiliser FAAS avec un service de notification en temps de type Kinesis sur Amazon ou Event Hub sur Azure pour traiter en temps réel des données diffusées en continu dans les cas suivants : suivi des activités d’une application, traitement d’ordres de transaction, analyse de parcours de navigation, nettoyage de données, génération de mesures, filtrage de journaux, indexation, analyse de réseaux sociaux, télémétrie et mesure des données d’appareils de l’Internet des objets (IoT).
Les Composants techniques nécessaires
Que nous utilisons Amazon Cloud ou Azure ou on promise, nous allons avoir besoin
– Service de stockage en temps réel des événements exemple Kinesis sur Amazon et Azure Event Hub sur Azure
– D’une architecture applicative microservice pour le traitement
– Un système de monitoring et de logging de type CloudWatch sur Amazon ou Application insights sur Azure
– Un système de stockage interne des événements de type DynamoDB sur Amazon ou CosmosDB sur Azure
– Un système de publieur qui va publier les données traitées

L’architecture Physique
L’architecture physique suivant montre clairement les interactions nécessaires entre les ressources utilisées

Le Traitement ETL par microservice

Il est tout à fait possible également de mettre en place une solution d’extraction, transformation et chargement des données au sein du cloud, comme le service qui sera fourni avec tout ETL
Composants techniques utilisés
– Une source de données temps réel, comme une base non sql qui permet de stocker très rapidement des données. Exemple : DynamoDB sur Amazon ou CosmosDB sur Azure
– Une fonction de transformation, qui se charge d’extraire les données depuis la base temps réel, de les standardiser ou transformer et de les publier dans une source plus structurée ou dans un fichier plat de type CSV
– La destination et un mécanisme de réplication si nécessaire exemple Amazon Redshift
L’architecture physique
Le schéma suivant montre les interactions des ressources entre elles pour rendre un service d’ETL moderne et sans serveur, Rien n’empêche d’aller chercher des données depuis différentes sources

Les architectures Back-ends

Il est tout à fait possible de créer des back-end sans serveur grâce à des FAAS et ainsi gérer des requêtes API Web, mobiles ou encore en provenance de l’Internet des objets IOT ou de tiers
Réaliser un back-end pour une plateforme IOT
Il est possible grâce à FAAS de réaliser un back-end pour un IOT moderne et de gérer des requêtes API Web
Composants techniques utilisés
Pour réaliser une telle architecture il faut
– Un système de notification temps réel de type Azure Event Hub ou Amazon Kinesis qui reçoit les événements des différents devices
– Une fonction d’ingestion qui va recupérer les événements et les stocker en local dans une base destructurée de type CosmosDB ou DynamoDB
– Une fonction de type Rest API pour recupérer les données depuis la base destructurée en mode synchrone
– Un service de monitoring
– Un service interne de notification pour permettre le suivi des événements interne
– Une fonction de publication qui permet de publier les données et les événements à des outils d’analyse plus complexe de type Azure HDInsight ou Amazon Elastic MapReduce
– Un système d’analyse des événements qui permet d’avoir des dashboards et de calculer des PKI sur les différents événements

Schéma physique
Le schéma d’architecture suivant montre comment les différentes ressources interagissent pour fournir le service nécessaire pour réaliser un back-end pour une plateforme de IOT

Réaliser un back-end pour une application mobile

Il est tout à fait possible de créer des back-ends à l’aide de FAAS et des fonctions en Rest HTTP pour authentifier et traiter des requêtes API. FAAS facilite la création d’expériences riches et personnalisées pour les applications mobiles.
Le client ayant choisi de faire un backend FAAS, exécute un backend sans serveur pour son application mobile et ses sites web à l’aide de la fonction Rest HTTP. Grâce aux architectures sans serveur, les clients se basant dessus, n’ont pas à se soucier de la gestion de l’infrastructure et chaque ingénieur peut donc se concentrer sur la création de nouvelles fonctionnalités et sur l’innovation à apporter

Composants technique
Pour réaliser une telle architecture il faut
– Un service d’authentification mobile basé sur Azure Mobile Apps ou sur Amazon Cognito
– Un service de stockage des fichiers
– Un CDN pour la réplication des fichiers
– Une gateway API de type API Gateway sur Amazon ou API Management sur Azure
– Une ou plusieurs fonctions pour le traitement applicatif
– Un système de notification mobile
– Un système de stockage destructuré pour le stockage temporaire de type CosmosDB ou DynamoDB
– Un service d’indexation de type Azure Search ou Amazon CloudSearch
– Une fonction d’extraction des modifications des données et de chargement dans le service d’indexation
Schéma physique
Le schéma physique montre les interactions possibles entre les ressources

Réaliser une application web complète

En combinant FAAS et d’autres services SAAS ou ServerLess de Azure ou Amazon, les développeurs peuvent créer de puissantes applications Web dont la taille s’adapte automatiquement aux besoins dans le cadre d’une configuration hautement disponible, sur plusieurs centres de données, sans aucune tâche administrative nécessaire en matière de dimensionnement, de sauvegarde et de redondance des centres de données
Composants techniques
Les composants suivants sont nécessaire pour une telle plateforme
– Un serveur web en ServerLess de type App service sur Azure ou amazon elastic beanstalk
– Un service d’accès mobile pour les utilisateurs de type mobile
– Un service d’authentification
– Un ou plusieurs fournisseurs externes OAuth2 (exemple Facebook, LinkedIn, Google, MS)
– Une API Gateway
– Une ou plusieurs fonctions
– Une base destructurée
– Un CDN et un service de partage de fichiers
– Un système de load balancing
– Un système de notification
– Un service de gestion des événements
– Un service d’indexation et recherche full text
Architecture physique