Lorsque l’on souhaite créer un backend IOT, deux types de services principaux sont nécessaires:

  • Ingress - service d’Ingestion : sert à recevoir les messages des différents appareis
  • Throughput - service(s) de débit ou de traitement : sert à traiter les messages reçus et à rediriger les messages ou déclencher des actions associées si nécessaires

Il existe un service Azure d’ingestion scalable permettant d’ingérer une très forte volumétrie de messages: Azure IOT Hub.
Il existe également de nombreuses solutions permettant le déploiement de services scalables de traitement de ces messages ou évènements, telles que Service Fabric.
Maintenant, avouez qu’il serait dommage que la communication entre ces deux services ne soit pas scalable et qu’on ait un vilain bottleneck au milieu.

Dans cet article nous ferons une présentation très rapide d’Azure IOT Hub qui sert à ingérer les messages et nous essaierons d’éclaircir l’intérêt des endpoints Event Hub et des partitions.
Par la suite, nous aborderons les partitions Event Hub, leur intérêt et la façon de les consommer.
Nous verrons également comment utiliser Service Fabric et les partitions pour créer un service scalable, capable d’absorber la charge provenant des différentes partitions d’un Event Hub.


Azure IOT Hub

Une solution pour l’ingestion des messages provenant des appareils est de fournir une passerelle principale vers laquelle les appareils envoient leurs messages.
Comme indiqué précédemment, dans cet article nous utiliserons Azure IOT Hub, un service très complet pour les scénarios IoT, utilisé notamment comme point d’entrée de la communication des devices vers le cloud.
Il s’agit d’une passerelle bidirectionnelle de messages apportant également une gestion du parc d’appareils mais son avantage le plus important est bien sûr de savoir accueillir une très forte volumétrie de messages.

Azure IOT Hub

Pour en savoir un peu plus sur Azure IOT Hub je vous invite à aller sur la documentation produit de Microsoft ou sur un de mes précédents articles expliquant comment provisionner un Hub dans le portail Azure et enregistrer vos premiers appareils. (en espérant que la doc n’est pas trop changée :P ).


API REST et SDK

L’objectif premier d’un BackEnd IOT est de pouvoir ingérer des messages mais également de les restituer, et de manière ordonnée si nécessaire. Le rôle du service dont nous avons besoin est donc de se connecter en lecture à la passerelle Azure IOT Hub pour en « digérer » les messages.
Pour restituer les messages entrants dans le Hub, plusieurs solutions s’offrent à nous et notamment les API REST proposées par le service.

Comme la plupart des services Azure, chacune des API REST se voit enrichie de SDK opensource pour de nombreux langages tels que .NET, Java, Node.js, Pyhton ou C.

Pour découvrir ces SDK, consultez: la documentation officielle


Event-Hub Endpoints

Dans le cadre d’un projet backend scalable nous n’utiliserons pas les points de terminaison REST classiques en direct ou via un SDK pour digérer les messages dans un souci d'optimisation des performances.

Event Hub est un autre service Azure qui propose des fonctionnalités très intéressantes de gestion d'évènements efficace des messages vers un tableau de bord ou un service de notification cliente par exemple.
Pour récupérer nos messages nous allons donc utiliser la fonctionnalité de points de terminaison « Event-Hub-endpoint » proposée par Azure IOT Hub. Azure IOT Hub Provisioning


Dans la plupart des cas nous n’utiliserons que le endpoint ou « point de terminaison » par défaut (messages/events) mais il faut savoir que le Hub IOT permet de rediriger automatiquement les messages vers des endpoints à définir, en fonction de critères de contenu du message.

Partitionnement

Un autre aspect important de l’IOT Hub est sa fonctionnalité native de partitionnement.

Pourquoi utiliser les partitions device-to-cloud dans un IOT Hub unique?
Lorsque l’on provisionne un Azure IOT Hub il nous est possible de définir la propriété correspondant au nombre de partitions (entre 2 et 32). Les partitions sont liées au degré de parallélisme en aval requis lors de la consommation des applications, c’est-à-dire notre capacité à paralléliser les traitements de débit ou de consommation des messages. Azure IOT Hub

S’il est déconseillé d’essayer de définir dans quelle partition envoyer les messages, on peut se servir de cette fonctionnalité dont le concept est emprunté aux concentrateurs d’évènements ou Event Hubs. Cette fonctionnalité est utilisée justement pour définir des points de terminaison compatibles Event Hub (messages/events) intégrés nativement dans un Azure IoT Hub.

Un autre aspect très pertinent des partitions dans Azure IOT Hub est la répartition des appareils par partition. En effet, si on laisse le Hub déterminer lui-même la partition la plus pertinente pour y envoyer les messages d’un appareil, il faut noter que tous les messages du même appareil transiteront par une seule et même partition. Cela est bien utile, voire indispensable pour la parallélisation de la lecture des messages.

Il faut cependant noter un inconvénient non négligeable à ce système de partitions au niveau IOT Hub. Si l’on peut choisir le nombre de partitions au provisionnement du Hub, il n’est plus possible de le modifier par la suite. La recommandation en cas d'augmentation d'appareils et donc de charge est de toute façon de provisionner de nouvelles unités IOT Hub.


Je vous donne rendez-vous tout bientôt pour prochain article dans lequel je vous ferai un petit bilan sur les partitions Event Hub, ce qu’elles apportent et la façon de les consommer.

Dans cet article nous verrons comment provisionner un Hub, le configurer et enregistrer nos premiers devices. Cela servira de préparatifs à la mise en place d’une suite logicielle IOT.

00Hub

Présentation

Tout d’abord, qu’est-ce-que ce hub ? Il s’agit de l’arme pas très secrète de Microsoft pour s’imposer sur le marché de l’IOT.

Le Hub est une ressource Azure qui a pour vocation de devenir votre plateforme centrale d’échange de messages entre vos devices, votre back-office, vos apps, etc.

Sa force serait donc de pouvoir recevoir et distribuer des milliards de messages sans se soucier de la charge associée. Oui, mais pas seulement. En effet, Azure IOT Hub se charge également de l’administration des devices, de l’enregistrement à la supervision en passant par les transports bidirectionnels de messages.

Step 1: Provisioning du IoT Hub depuis Azure et Pricing

Rien de plus simple que provisionner un Hub Azure IOT.

Accessible depuis le nouveau portail Azure, il vous suffit de sélectionner “Nouveau” et de rechercher “Azure IoT Hub”.

02NewHub

Suivez alors la procédure en cliquant sur le bouton “Créer”.

Vous serez alors invité à choisir le nom de votre hub ainsi que le tier associé.

03Pricing

Pour info, un Hub configuré en gratuit ne pourra pas être upgradé. Si vous voulez augmenter les capacités d’un tel Hub, il vous faudra donc en provisionner un autre et le configurer de nouveau. La simplicité de provisioning ne rendra pas la tâche trop difficile donc n’hésitez pas à vous faire la main sur du gratuit afin de déterminer vos besoins. Autre information importante, il n’est possible de provisionner qu’un seul Hub Free. Destiné à vos tests cela ne devrait donc pas être gênant.

Step 2: Configuration

Maintenant que votre Hub est provisionné, il va falloir le configurer pour pouvoir y accéder depuis vos devices et interfaces d’administration.

Par défaut, des clés et des groupes de droits ont été créés. Dans un premier temps nous n’aurons besoin que de récupérer les informations suivantes :

04Hub

05HubSharedAccessKeys

Step 3: Enregistrement des devices

Pour faire communiquer les devices avec notre hub, de nombreuses API sont disponibles ainsi que des SDK pour presque tous les langages de programmation.

Ici nous utiliserons le SDK C# disponible en package NuGet.

Commençons par créer une application console qui nous servira de provisioning pour les devices. C’est à dire qu’elle servira à associer les devices dans le service et à nous fournir les identités créées pour configurer les devices.

Pour nous aider dans cette démarche nous pouvons utiliser les APIs REST fournies par Azure mais le plus simple reste tout de même d’utiliser les SDK fournis. Nous utiliserons le SDK C# mais sachez qu’il existe pour les plateformes/langages suivants :

  • .NET
  • C
  • Node.js
  • Java

Comme à son habitude Microsoft joue le jeu de l’opensource et pour récupérer les SDKs vous pouvez vous rendre sur https://github.com/Azure/azure-iot-sdks/blob/master/readme.md

Dans notre exemple nous utiliserons donc NuGet et le package à récupérer porte le nom Microsoft.Azure.Devices (le Devices.Client nous servira plus tard).

06NugetAzureDevices

Dans notre application nous allons d’abord commencer par nous connecter au Hub. Pour cela nous aurons besoin de la chaine de connexion récupérée sur Azure dans l’étape 2 et d’un objet RegistryManager :

    static RegistryManager registryManager;
    static string connectionString = "HostName=iotdeviceshub.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=azureIotHubKey";
    

Nous allons ensuite demander au hub d’enregistrer notre device. Cela se fait en utilisant la méthode AddDeviceAsync du RegistryManager qui prend en paramètre l’identifiant du device. La méthode permet de récupérer l’id généré et d’en créer. Encapsulons ça dans une méthode à nous :

    private async static Task AddDeviceAsync(string deviceId)
    {
    Device device;
    try
    {
    device = await registryManager.AddDeviceAsync(new Device(deviceId));
    }
    catch (DeviceAlreadyExistsException)
    {
    device = await registryManager.GetDeviceAsync(deviceId);
    }
    Console.WriteLine($"Generated device key: {device.Authentication.SymmetricKey.PrimaryKey}");
    }
    

Sous Windows 10 vous pourrez utiliser l’id unique du device et intégrer ce code dans le device, mais pour l’exemple nous utiliserons un nom choisi au hasard par l’utilisateur :

Voici le code à ajouter dans le corps de la méthode Main :

    registryManager = RegistryManager.CreateFromConnectionString(connectionString);
    while (true) // Loop indefinitely
    {
    Console.WriteLine("Enter a device id to generate/get the hub key or 'q' to quit");
    var message = Console.ReadLine();

    if (message == "q")
    {
    break;
    }
    AddDeviceAsync(message).Wait();
    }
    

Lançons l’application et nous devrions obtenir le résultat suivant :

07GeneratedDeviceKeys

Notons la clé générée. Il s’agit de la clé unique du device que nous venons d’enregistrer et qui nous servira à faire communiquer celui-ci avec notre hub.

Nous verrons dans le prochain article comment envoyer des messages depuis ledit device, comment lui envoyer un message spécifiquement destiné et comment superviser les messages transitant sur le Hub.

D’ici là, bon dev.