Bonjour,

Bienvenue dans un monde fascinant des WEB API en ASP.NET Core 2. Microsoft a beaucoup facilité la création de Web API et aujourd'hui beaucoup d'architecture moderne les implémentent mais savez-vous réellement créer une Web API qui sera RestFUL, documentée et testée ?

L'approche de cet article se veut didacticiel. Ainsi nous partirons de la création d'une simple API de type Rest, nous lui ajouterons les verbes HTTP pour devenir compatible RestFul. Une fois notre API RestFul, nous utiliserons Swagger pour la documenter et NSwag pour générer le client et en fin nous utiliserons XUnit pour créer des projets de test unitaire et d'intégration.

Qu'est-ce qu'une API ?

Une API (Application Programming Interface ou interface de programmation) est un ensemble de services offert par un logiciel à d'autres logiciels. Grâce aux API, les programmes informatiques peuvent interagir entre eux selon des conditions déterminées.

Aujourd'hui pour créer une API, il existe différentes styles d'API Web.

Les différentes démarches de développement

Il existe aujourd'hui deux méthodes pour créer une API Web RestFul en ASP.NET Core 2.1

La méthode proposée par cet article, est la méthode appelée code first où l'écriture du code se fait en premier, puis la documentation est générée automatiquement pour en fin permettre de générer le client SDK.

Il est cependant possible de générer la documentation au préalable permettant de donner un cadre à notre API et ainsi permettre une collaboration plus rapide entre les développeurs qui développent l'API et les développeurs qui consomment l'API. Cette démarche est appelée Spec-first

Les styles d'API Web

Comme je l'ai indiqué dans mon livre Learning ASP.NET Core 2.0 édité par Packt,, les API Web ont différentes styles et nous pouvons cités les styles suivantes

L'API Rest 

REST est un style d'architecture défini dans la thèse de Roy Fielding dans les années 2000, ce n'est donc ni un protocole ni un format. Les implémentations sont donc multiples et différentes. Cependant, on retrouve souvent le principe dans les API HTTP, comme c'est le cas de GitHub et Twitter par exemple.

L'API RestFul

L'API Restful est une API rest qui comporte l'ensemble des verbes HTTP

Les différents verbes

L'API Hateoas

pour Hypermedia As The Engine Of Application State, est la contrainte (4.4) qui est la plus présente sur le web mais malheureusement pas souvent dans les APIs. Arrivé à ce niveau, on reconnaît évidemment que le web est bien ancré sur le principe de REST, à quelques exceptions près. Lorsque l'on obtient une ressource, ou une page sur le web, il est très important de la lier à d'autres ressources via des liens. C'est aussi bête que ça.

Cet article ne traite pas des API, si vous souhaitez savoir comment créer une API Hateoas, je vous invite à lire mon livre sur Learning ASP.NET Core 2

Créer une API Web Rest Simple

Architecture de l'API

Premier Exemple - Api Simple

Voir le fichier SimpleAPIController.cs 
https://github.com/mbt-versusmind/APIRest/blob/master/SimpleAPI1.cs

Dans ce premier exemple, nous jouons uniquement avec les premiers verbes HTTP

Nous avons décorer décoré notre classe API avec les décorateurs suivants

Ajouter une action de validation généralisée

Bien qu'il soit possible d'appeler directement le mécanisme de Validation fournit par .NET Core 2, il est recommandé d'utiliser une Action filtre permettant d'abstraire le code et d'éviter d'avoir plusieurs responsabilités dans chaque action. Ce filtre peut être appelé directement depuis la classe API et donc être appliqué à l'ensemble des actions ou alors être appelé depuis une seule action

public class ValidateModelAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext context)
    {
        if (!context.ModelState.IsValid)
        {
            context.Result = new BadRequestObjectResult(context.ModelState);
        }
    }
}

Ajouter un contrat à notre API

Ici au lieu de retourner un POCO fortement typé, nous avons préféré utiliser un retour Standard pour l'ensemble de nos actions

IActionResult

et d'utiliser des code HTTP différents pour le type de résultat

Quelque limites à ce code

- Le client SDK va devoir gérer le code Retour pour savoir si le traitement s'est bien passé et lire le contenu

- Nous confondons là, les erreurs HTTP techniques et les erreurs fonctionnelles

En régle générale

Il est fortement recommendé de ne pas jouer avec les codes HTTP lorsque ce sont des erreurs fonctionnelles mais d'utiliser un POCO indiquant clairement si l'opération s'est bien passé fonctionnellement ou non et de retourner un message descriptif. Les code HTTP doivent être uniquement servir pour les status techniques

Transformons notre API Simple en API Fortement typée

Créons une Interface

Voir le fichier https://github.com/mbt-versusmind/APIRest/blob/master/ICategoryApiController.cs

Modifions maintenant notre API pour utiliser l'interface

Voir le fichier https://github.com/mbt-versusmind/APIRest/blob/master/SimpleAPI2.cs

Cool maintenant nous avons une API fortement typée.

Transformons notre API Fortement typée en API RestFull

Voyons maintenant un peu plus loin et essayons d'être compatible avec RestFUL.

Tout d'abord qu'est-ce que RestFUL.

RestFUL est un standard basé sur REST et prenant en compte les régles suivantes

1°) Les Verbes HTTP doivent être utilisés

2°) Gérer Les resultats des opérations de retour correctement

3°) Notre API doit être décrite et documentée

Transformons notre API pour utiliser les verbes HTTP

Ici, avec notre exemple d'API simple nous avons déjà implémenté les verbes GET, GET("{id}") et POST. Nous allons ajouter les méthodes de modification et mise à jour partielle et de suppression

Commençons par modifier notre Interface

Voir le fichier https://github.com/mbt-versusmind/APIRest/blob/master/ICategoryApiControllerRestFull.cs

Modifions maintenant notre API pour implémenter les méthodes manquantes

Voir le fichier https://github.com/mbt-versusmind/APIRest/blob/master/CategoryApiControllerFullRest.cs

Cool nous avons maintenant une API qui fait appel à tous les verbes HTTP existants, voyons maintenant la deuxième régle

Gérer Les resultats des opérations de retour correctement

2.1 - Opération de création

Une Opération de création doit avoir pour resultat un statut 201 et disposer dans le header un attribut Location possédant l'URL. Pour ce faire nous pouvons ajouter une classe CreatedActionResultFilterAttribute

public class CreatedActionResultFilterAttribute : ActionFilterAttribute
{
    public override void OnActionExecuted(ActionExecutedContext context)
    {
        if (context.Result is ObjectResult)
        {
            var objRes = context.Result as ObjectResult;

            if (objRes.Value is RequestResultWithData)
            {
                RequestResultWithData requestResultWithData = objRes.Value as RequestResultWithData;

                context.HttpContext.Response.Headers["Location"] = requestResultWithData.Location;

                if (requestResultWithData.IsSuccess)
                    context.HttpContext.Response.StatusCode = (int)HttpStatusCode.Created;
                else
                    context.HttpContext.Response.StatusCode = (int)HttpStatusCode.BadGateway;
            }
        }

        base.OnActionExecuted(context);
    }
}

et de décorer nos actions d'insertion

/// <inheritdoc />
[HttpPost(""), CreatedActionResultFilter]
public async Task<RequestResultWithData<Category>> AddAsync(Category Category)
{

2.2 - Opération de Mise à jour 

Une Opération de mise à jour doit avoir pour resultat un statut 200. Pour ce faire, nous créons une classe UpdateActionResultFilterAttribute

public class UpdateActionResultFilterAttribute : ActionFilterAttribute
{
    public override void OnActionExecuted(ActionExecutedContext context)
    {
        if (context.Result is ObjectResult)
        {
            var objRes = context.Result as ObjectResult;

            if (objRes.Value is RequestResultWithData)
            {
                RequestResultWithData requestResultWithData = objRes.Value as RequestResultWithData;

                context.HttpContext.Response.Headers["Location"] = requestResultWithData.Location;

                context.HttpContext.Response.StatusCode = requestResultWithData.IsSuccess ? (int)HttpStatusCode.OK : (int)HttpStatusCode.BadGateway;
            }
        }

        base.OnActionExecuted(context);
    }

}

et nous pouvons utiliser comme pour les méthodes d'Ajout le décorateur

[HttpPut("{categoryId}/translation/{translationId}"), UpdateActionResultFilter]
        public async Task<RequestResult> UpdateTranslationAsync([FromRoute]Guid categoryId, [FromRoute]Guid translationId, CategoryTranslation translation)
        {

....

}

2.3 Les opérations de suppression

Les opérations de suppression doivent avoir pour retour 202.

Pour cela nous ajoutons une action DeleteActionResultFilter

public class DeleteActionResultFilterAttribute : ActionFilterAttribute
{
    public override void OnActionExecuted(ActionExecutedContext context)
    {
        if (context.Result is ObjectResult)
        {
            var objRes = context.Result as ObjectResult;

            if (objRes.Value is RequestResultWithData)
            {
                RequestResultWithData requestResultWithData = objRes.Value as RequestResultWithData;

                context.HttpContext.Response.Headers["Location"] = requestResultWithData.Location;

                context.HttpContext.Response.StatusCode = requestResultWithData.IsSuccess ? (int)HttpStatusCode.Accepted : (int)HttpStatusCode.BadGateway;
            }
        }

        base.OnActionExecuted(context);
    }

}

et nous pouvons ajouter un décorateur à nos méthodes de suppression

/// <inheritdoc />
[HttpDelete("{id}"), DeleteActionResultFilter]
public async Task<RequestResult> RemoveAsync([FromRoute]Guid id)
{

Décrivons notre API 

Pour permettre une meilleur intégration de notre API dans un système existant ou pour permettre facilement la création de nouveau SDK client, il est nécessaire que notre API soit documenté

Il existe deux standards pour décrire une API

Open API

Contrairement à une API privée, une API décrite au format OpenAPI (maintenant on est à la version 3 https://en.wikipedia.org/wiki/Open_API) est accessible au public pour tous les développeurs. Ils permettent aux développeurs, en dehors d'une organisation, d'accéder aux données backend qui peuvent ensuite être utilisées pour améliorer leurs propres applications. Les API ouvertes peuvent augmenter considérablement les revenus sans que l'entreprise n'ait à investir dans l'embauche de nouveaux développeurs, ce qui en fait une application logicielle très rentable.

Cependant, il est important de se rappeler que l'ouverture de l'information au public peut créer toute une gamme de problèmes de sécurité et de gestion. Par exemple, la publication d'API ouvertes peut rendre plus difficile aux organisations de contrôler l'expérience que les utilisateurs finaux ont avec leurs ressources d'informations. Les éditeurs d'API ouverts ne peuvent pas supposer que les applications client construites sur leurs API offriront une bonne expérience utilisateur. De plus, ils ne peuvent pas garantir que les applications client conservent l'apparence de leur image de marque.

Swagger

Swagger est une spécification indépendante du langage pour décrire les API REST. Le projet Swagger a été donné au projet OpenAPI Initiative et s’appelle maintenant Open API. Les deux noms sont utilisés indifféremment, mais Open API est préféré. Il permet aux ordinateurs et aux utilisateurs de comprendre les fonctionnalités d’un service sans aucun accès direct à l’implémentation (code source, accès réseau, documentation). L’un des objectifs est de limiter la quantité de travail nécessaire pour connecter des services dissociés. Un autre objectif est de réduire le temps nécessaire pour documenter un service avec précision

La spécification de Swagger

Pour que Swagger fonctionne et encore plus l'interface de documentation graphique appelée Swagger UI, un fichier swagger.json doit exister (du moins au minimum virtuellement).

Ce fichier, est en général en ASP.NET générée par un composant tierce qui recupére la documentation du code au format XML et en extrait une documentation Json.

Elle décrit les fonctionnalités de votre API et comment y accéder avec HTTP. Elle gère l’IU Swagger et est utilisée par la chaîne d’outils pour activer la découverte et la génération de code client

en ASP.NET Le composant à utiliser était le composant Swashbuckle

Swashbuckle compte trois composants principaux :

• Swashbuckle.AspNetCore.Swagger : modèle objet Swagger et intergiciel (middleware) pour exposer des objets SwaggerDocument sous forme de points de terminaison JSON.
• Swashbuckle.AspNetCore.SwaggerGen : générateur Swagger qui crée des objets SwaggerDocument directement à partir de vos routes, contrôleurs et modèles. Il est généralement associé à l’intergiciel de point de terminaison Swagger pour exposer automatiquement Swagger JSON.
• Swashbuckle.AspNetCore.SwaggerUI: version incorporée de l’outil IU Swagger. Elle interprète Swagger JSON afin de générer une expérience complète et personnalisable pour décrire la fonctionnalité de l’API web. Il inclut des ateliers de test intégrés pour les méthodes publiques

Pour plus d'information https://docs.microsoft.com/fr-FR/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-2.1&tabs=visual-studio%2Cvisual-studio-xml

en ASP.NET core 2 il est plus recommandé d'utiliser le composant NSwag

L’utilisation de NSwag avec un intergiciel (middleware) ASP.NET Core nécessite le package NuGet NSwag.AspNetCore. Le package se compose d’un générateur Swagger, de l’IU Swagger (v2 et v3) et de l’IU ReDoc

Pour utiliser le package

1. Référencez le package NSwag.AspNetCore
2. Dans Startup Appelez le middle Swagger

app.UseSwagger(typeof(Startup).Assembly, settings =>
{
    settings.PostProcess = document =>
    {
        document.Info.Version = "v1";
        document.Info.Title = "Manage product's familly API";
        document.Info.Description = "This API allows to create a familly of product, set the translation and SEO values and manage product's category in the same maner";
        document.Info.TermsOfService = "See Startpoint web site";
        document.Info.Contact = new NSwag.SwaggerContact
        {
            Name = "Michel Bruchet",
            Email = "admin@startpoint-inc.com",
            Url = "https://www.startpoint-inc.com"
        };
        document.Info.License = new NSwag.SwaggerLicense
        {
            Name = "Startpoint inc",
            Url = "https://startpoint.io/license"
        };
    };
});

app.UseMvc();
}

Pour installer le client Swagger-ui

Appelez le middleware SwaggerUi3

app.UseSwaggerUi3(typeof(Startup).GetTypeInfo().Assembly, settings =>
{
    settings.GeneratorSettings.DefaultPropertyNameHandling = NJsonSchema.PropertyNameHandling.CamelCase;
});

Pour tester l'application appelez l'URL http://monserver/swagger

Vous pouvez utiliser ReDoc pour générer l'interface de documentation. Celle-ci fournit une meilleur interface graphique

Pour cela il suffit juste de remplacer app.UseSwagger par app.UseSwaggerReDoc 

Créons un client C# pour notre API

Pour permettre aux applications clients d'accéder à notre API, nous avons besoin de générer un client c# 

pour ce faire, NSwag nous fournit une application Windows capable de lire le fichier swagger.json et de générer un client en c#

1. Installer le composant

- Téléchargez depuis le repository Github le MSI https://github.com/RSuter/NSwag/wiki/NSwagStudio

- Installez le MSI

2. Générer le client c#

- Lancez le programme

Sélectionnez l'onglet Swagger specification

Cliquez sur Create local copy

Cochez l'option Csharp Client

Cliquez sur Generate Outputs

Vous pouvez générer les fichiers cs nécessaire ou copier le code

3. Utilisez le code c#

- Créez un projet NetStandard

- Créez un dossier Generated

- Ajoutez une classe ApiClient

- Copiez/collez le code depuis l'interface de génération client

4. Préparez le code c# client pour être testé

2. Ajoutez une classe partial qui ajoute un constructeur et charge la méthode PrepareRequest

public partial class CategoryRootApiClient
{
    private HttpClient _httpClient;

    public CategoryRootApiClient(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public CategoryRootApiClient(HttpClient httpClient, string baseUrl)
    {
        _httpClient = httpClient;
        _baseUrl = baseUrl;
    }

    partial void PrepareRequest(HttpClient client, HttpRequestMessage request, StringBuilder urlBuilder)
    {
        client = _httpClient ?? client ?? new HttpClient();
    }
}

Créeons un projet de test unitaire

Il est possible d'utiliser différentes technologies pour réaliser les tests unitaires et d'intégration de notre API RestFull

Ici nous allons utiliser XUNIT et Moq pour le mocking des repositories

1. Commençons par créer un projet de type Test

2. Ajoutons les packages Moq et FluentAssertions

- Le package Moq permettra d'éviter d'implémenter le code pour le repository et de pouvoir utiliser le Moqing (qui permet de contrôller le retour d'une méthode)

- Le package FluentAssertions permet d'écrire des assertions plus lisibles

3. Ajouter une interface ICategoryRootApiControllerTest qui posséde les méthode que l'interface ICategoryRootApiController mais Permettant de tester les fonctions souhaitées ce qui nous garantira que nous avons bien testé toutes les méthode de l'interface

4 - Implémentons chaque méthode de test en respectant les 3 A

• Arrange : Permet de paramétrer les objects et le contexte du test
• Act : Permet d'implémenter la logique même du test
• Assert : Permet de contrôller que le test s'est bien passé

N'oublions pas d'ajouter également la méthode qui permettra d'appeler le test

Exemple de code pour un test unitaire

[Fact]
public void CheckAddFact()
{
    var categoryRoot = new CategoryRoot { Id = Guid.NewGuid(), Name = "Test" };
    CheckAdd(categoryRoot).ConfigureAwait(false);
}

public async Task CheckAdd(CategoryRoot categoryRoot)
{
    //Arrange
    _moqRepositoryCategory.Setup(m => m.AddAsync(categoryRoot)).Returns(Task.FromResult((true, categoryRoot)));
    var controller = new CategoryRootApiController(_moqRepositoryCategory.Object, _moqRepositoryCategoryTranslation.Object);

    //Act
    var createResult = await controller.AddAsync(categoryRoot).ConfigureAwait(false);

    //Assert
    createResult.Should().NotBeNull();
    createResult.IsSuccess.Should().BeTrue();
    createResult.Data.Should().NotBeNull();
    createResult.Data.Id.Should().Equals(categoryRoot.Id);
}

Créons maintenant un projet de test d'intégration

Contrairement à un test unitaire, le test d'intégration va consister à charger l'API dans un serveur virtuel (car lorsque vous mettez en place un test d'intégration automatique via un CI comme avec VSTS ou Jenkins il ne s'agit pas de charger IIS ou Kestrel pour accéder à l'API). Le processus pour réaliser un test d'intégration va consister

1. Créer un projet de test en règle général le nom du projet se termine souvent par TestIntegration mais ce n'est pas une obligation
2. Créer une classe qui hébergera l'API et utiliser le package Microsoft.AspNetCore.Mvc.Testing

public class CustomWebApplicationFactory<TStartup>:WebApplicationFactory<Startup>
{
    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureServices(services =>
        {
            Mock<IRepository<CategoryRoot>> moqRepositoryCategory;
            Mock<IRepository<CategoryRootTranslation>> moqRepositoryCategoryTranslation;

            moqRepositoryCategory = new Moq.Mock<IRepository<CategoryRoot>>();
            moqRepositoryCategoryTranslation = new Moq.Mock<IRepository<CategoryRootTranslation>>();

            services.AddTransient<IRepository<CategoryRoot>>(provider=>moqRepositoryCategory.Object);
            services.AddTransient<IRepository<CategoryRootTranslation>>(provider=>moqRepositoryCategoryTranslation.Object);

        });

        base.ConfigureWebHost(builder);
    }
}

1. Créer une classe de test similaire à la classe unitaire et appeler la classe Factory pour générer un client HTTP

public class CategoryRootApiControllerTest:IClassFixture<CustomWebApplicationFactory<Startup>>
{
    private readonly CustomWebApplicationFactory<Startup> _factory;
    private readonly HttpClient _client;

    public CategoryRootApiControllerTest(CustomWebApplicationFactory<Startup> factory)
    {
        _factory = factory;

        _client = _factory.CreateClient(new WebApplicationFactoryClientOptions
        {
            AllowAutoRedirect = false,
            HandleCookies = true
        });

    }

    [Fact]
    public async Task Get_ListAllCategories()
    {
        var content = await _client.GetAsync("/api/root").ConfigureAwait(false);

        content.Should().NotBeNull();
        content.EnsureSuccessStatusCode();
    }
}

Conclusion

Dans cet article, nous avons abordé comment créer une API Web en ASP.NET core 2. Documenté via Swagger et Nswag. réaliser automatiquement le client SDK en C# (Swagger permet de réaliser des clients dans beaucoup d'autre languages). Et en fin nous avons mis en place les tests unitaires et d'intégration pour permettre de tester le bon fonctionnement de l'API.

Quoi faire ?

Nous avons vu dans notre article que le document de spécification Swagger a été généré automatiquement après le développement hors si plusieurs développeurs ont besoin de travailler ensemble sur l'API cela devient très difficile car le développeur qui a besoin de consommer son api a besoin d'attendre la réalisation de l'API avant de pouvoir l'utiliser. Pour simplifier la bonne collaboration il est tout à fait possible de réaliser la spécification de l'API avant de l'écrire, pour cela nous utiliserons une méthode appelée Spec first. MAis cela est un autre sujet que nous verrons dans un article prochain

Bienvenue dans cette article qui complète la présentation de Christophe Gigax sur Azure Serverless - Cette article s'intitule Démarrer avec Azure Serverless – Intégrer votre SI

Cet article présente l'intégration des SI diversifié des entreprises. Il vous donnera les informations nécessaires pour bien intégrer vos données. cet article, faisant partie d'une série de plusieurs articles vous présente le domaine et l'architecture FAAS. Au cours de cette série d'article couvrant les FAAS sur Azure et AMAZON, vous apprendrez comment utiliser Azure Service bus pour mettre en place un CQRS, Azure Function pour le calcul unitaire et Azure App logic pour un traitement de vos processus orchestrés
Pour plus d'information sur chaque composant, vous pouvez vous référer sur les articles d'approfondissement concernant le sujet souhaité.
Voici le sommaire de ce premier article
• Introduction
• Architecture d’un projet d’intégration
• Développement
• Déploiement automatique avec VSTS
• Supervision des flux
Contexte et historique
Bonjour, commençant notre article par une petite introduction pour bien dresser le contexte d’utilisation, l’architecture technique, un petit glossaire et les différents outils que nous allons utiliser pour réaliser une telle architecture
Nous pouvons simplifier l’évolution de l’informatique en 5 phases

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

 

Etudes de cas

Etude de cas sur Amazon Lambda

THOMSON
Thomson Reuters utilise une architecture sans serveur pour traiter jusqu'à 4 000 événements par seconde pour son service d'analyse d'utilisation. Ce service gère de façon fiable des pics correspondant à deux fois son trafic normal et dispose d'une durabilité élevée. L'entreprise a déployé le service en production en seulement cinq mois grâce à AWS.

iRobot
iRobot, une entreprise de robotique pour les consommateurs de premier plan au niveau mondial et le créateur du robot aspirateur Roomba connecté à Internet, est en train de concevoir la prochaine génération des appareils connectés pour la maison intelligente en utilisant une architecture sans serveur. La plateforme iRobot, basée sur AWS Lambda et AWS IoT, est gérée par moins de 10 personnes

Autodesk
Autodesk crée des logiciels pour les secteurs de l'architecture, de la construction, de l'ingénierie, de l'industrie, ainsi que des médias et des loisirs. Pour gérer un nombre croissant de comptes AWS, Autodesk a créé Tailor. En utilisant une architecture sans serveur, Tailor a été conçu et fonctionnel en un mois.

Financial Engines
Financial Engines est le plus grand conseiller en investissement indépendant aux États-Unis par rapport à ses actifs sous gestion. En déplaçant sa plateforme cœur sur une architecture sans serveur alimentée par AWS Lambda, Financial Engines a pu profiter d'une réduction de ses coûts, d'une absence d'administration et de temps d'arrêt, ainsi que d'un dimensionnement transparent qui a pris en charge des taux de requêtes jusqu'à 60 000 par minute.

NETFlix
Netflix est l'un des plus grands fournisseurs de streaming multimédia en ligne au monde. L'entreprise compte utiliser AWS Lambda pour créer une infrastructure auto-gérée basée sur des règles et remplacer les processus inefficaces en vue de réduire le taux d'erreurs et gagner un temps précieux.

Etude de cas sur Azure Function

Zeiss
ZEISS est une société de technologie opérant dans les domaines de l'optique et de l'optoélectronique. Pour numériser sa vaste gamme de solutions avec rapidité, ZEISS a utilisé Microsoft Azure et travaillé avec son partenaire Microsoft PlanB. GmbH pour créer une plate-forme basée sur les microservices et un système d'identité flexible et hautement sécurisé pour faciliter le partage des données, en interne et avec les clients.

Fujifilm
FUJIFILM Software a franchi une étape majeure dans son parcours vers le cloud en transformant son service de gestion et de partage de fichiers d'images IMAGE WORKS, très apprécié, en plate-forme Microsoft Azure en tant que service. 

Conclusion

Nous avons vu dans les sections précédentes un historique des différentes évolutions des systèmes informatiques, jusqu’aujourd’hui pour avoir des solutions en fin évolutif sans se soucier de leur déploiement et de leur exploitation.
Nous avons vu par la suite les différentes architectures réalisables avec FAAS
En fin, nous vous avons présenter quelques études de cas de réalisation au tour de ces technologies sur Azure et Amazon. Bien entendu il peut exister de nombreux autres cas d’utilisations chez des clients tout aussi prestigieux que ceux qui ont été cités ici.
Pour aller plus loin avec FAAS, nous verrons dans le prochain article, les différentes architectures applicatives et SI et nous étudierons un vrai cas pratique pour un processus de traitement