IoT Hub : Scaleway pose les fondations de son PaaS IoT

IoT Hub, propulsé par un MQTT « natif »

Le plus gros travail effectué par l’hébergeur a été d’intégrer le protocole de communication MQTT, un standard généralisé dans l’IoT.

« Cela nous donne un avantage relativement important vis-à-vis de nos différents concurrents. Comme nous arrivons un peu plus tard sur le marché IoT, un standard s’est imposé : le MQTT. Notre système Pub/Sub supporte nativement l’ensemble des fonctionnalités MQTT alors que les autres fournisseurs proposaient déjà des services de messagerie avant sa disponibilité. Leur intégration du protocole n’offre qu’une passerelle vers ces anciens systèmes », affirme Grégoire de Turckheim.

Les fonctionnalités évoquées par le Product Manager, ce sont les messages retenus (retained messages), la prise en charge des testaments (last will) et les niveaux de services associés.

Pour retenir le dernier message d’un topic, le développeur en charge du publisher (l’objet ou sa représentation virtuelle quand il ne communique pas directement en MQTT) va indiquer une chaîne d’instruction pour le labéliser avec un drapeau (Flag) dans son script (généralement matérialisé par retain = True en Python). Sans cette option, l’utilisateur d’une application n’obtiendra pas l’état de l’équipement entre deux envois de messages.

Le principe de testament consiste à définir un dernier envoi de message après la déconnexion d’un appareil. Si un broker (courtier) ne reçoit pas les payloads (les données à envoyer) d’un émetteur, il envoie un message avec la fonction retained message activée, pour prévenir les abonnés (les applications associées) d’une interruption de connexion type ou un arrêt de fonctionnement.

À ces deux fonctionnalités est associée la notion de qualité de service (QoS) portée au sein du protocole. L’hébergeur propose les trois niveaux définis dans le protocole. Avec QoS 0 ou « fire and forget », le message est envoyé sans garantie qu’il soit reçu par l’abonné. Le deuxième QoS 1 ou « deliver at least once » assure que le récepteur intercepte les données au moins une fois. Enfin QoS 2 permet à un abonné de recevoir le message une seule et unique fois.

« Chez nos concurrents, ces options sont disponibles, mais cela demande d’écrire du code spécifique. Nous, nous appuyons totalement sur le standard MQTT » vante Grégoire de Turckheim.

À titre de comparaison, la documentation d’AWS IoT Core précise que la version 3.1.1 de MQTT proposée par le fournisseur américain n’assure que les niveaux QoS 0 et 1 tout comme Azure IoT Hub et GCP Publish/Suscribe.

« Le but du Hub, c’est d’être une véritable pieuvre ; plus nous ajoutons des tentacules, des technologies, mieux c’est ».

Scaleway ne supporte pas directement les protocoles industriels utilisés en usine. « Sur les sites industriels nous constatons qu’il y a des gateway IoT dédié. Ces gateway reçoivent les messages dans les protocoles de communications industrielles, dont OPC UA et ModBus TCP, avant de les renvoyer vers le cloud au moyen des API REST, et maintenant via MQTT », déclare Grégoire de Turckheim. « Nous avons déployé le protocole le plus courant, nous ne nous interdisons pas du tout d’en ajouter dans la partie IoT Networks. Le but du Hub, c’est d’être une véritable pieuvre ; plus nous ajoutons des tentacules, des technologies, mieux c’est ».

Scaleway mise également sur plusieurs niveaux de sécurité. Tout d’abord chaque équipement associé à un Hub possède un identifiant unique et les échanges avec les récepteurs peuvent être chiffrés via les certificats MTLS (authentification mutuelle) ou TLS (avec authentification serveur), au choix. Il est également possible de laisser le mode plain text, sans chiffrement, pour les données les moins importantes. « La règle d’or, c’est que nous nous interdisons de regarder le contenu du message », jure Grégoire de Turckheim.

Des infrastructures dédiées pour se différencier

Ce PaaS managé sur Kapsule, l’orchestrateur Kubernetes de Scaleway, est hébergé en France dans la région cloud de Paris. Pour Iot Hub, la filiale d’Iliad propose trois gammes : mutualisée, dédiée et haute disponibilité.

La version mutualisée donne accès à 50 000 messages gratuits par mois pour 10 objets connectés. Il faut ajouter 10 centimes d’euros par objet supplémentaire par mois. Dans la documentation, l’hébergeur précise qu’elle ne dispose pas des fonctionnalités de retained message, last will et les QoS associés.

Dans l’offre dédiée, le client dispose d’un message broker dédié, facturé 9,99 euros par mois pour 2 millions de messages. L’offre haute disponibilité fournit 10 millions de messages pour 24,99 euros par mois. Dans ce dernier cas, le courtier de message basé sur une infrastructure dédiée est répliqué dans le but affiché d’apporter de la tolérance aux pannes.

Pour les trois offres, chaque million de messages supplémentaires est facturé 70 centimes d’euros (la taille unitaire d’un message est de 4 kilooctets). La charge utile d’un message a été limitée à 4 mégaoctets, contre 128 Ko pour AWS IoT Core et 256 ko pour Azure IoT Hub (le payload maximum d’un message MQTT est de 256 Mo). Chaque instance du Hub peut supporter jusqu’à 10 000 objets connectés et 100 « routes » ou services/applications/objets abonnés, deux quotas qui peuvent évoluer à la hausse à la demande du client.

« Nous faisons le pari que les entreprises seront intéressées par ce type de produit qui ne souffre pas de l’utilisation du voisin et qui offre les fonctionnalités avancées de MQTT. »

« Aujourd’hui, les acteurs sur le marché ne proposent pratiquement que de l’infrastructure mutualisée. En nous appuyant sur de l’infrastructure dédiée, nous faisons le pari que les entreprises seront intéressées par ce type de produit qui ne souffre pas de l’utilisation du voisin et qui offre les fonctionnalités avancées de MQTT », assure Grégoire de Turckheim.

Trouver sa place sur un marché IoT peu mature

Pour autant, Scaleway ne propose qu’une des briques nécessaires à la mise en place d’une plateforme IoT. « [IoT Hub] est la brique essentielle, s’il n’y a pas de réseau, on ne fait rien tourner », rétorque le product manager. Cela n’empêche pas l’hébergeur de développer IoT Edge, une solution qui permettra, par exemple, de déployer des algorithmes au niveau des passerelles IoT.

« Nous considérons que le marché IoT est encore peu mature, à l’instar de celui de la machine virtuelle en 2010. Aujourd’hui, un client qui souhaite une solution IoT fait appel à un intégrateur qui saura lui offrir tous les maillons de la chaîne. Le marché est voué à se segmenter en reprenant le modèle IaaS, les objets, PaaS, la plateforme et SaaS, les applications. En attendant que le marché soit suffisamment mature, nous accompagnons les clients en co-conception avec les autres acteurs de la chaîne ».

D’autres acteurs, dont les géants du cloud, proposent leurs services IoT comme des briques pour composer des projets IoT. Ce mouvement vers la segmentation ne serait pas bien compris, selon notre interlocuteur.

« Aujourd’hui, les clients il faut aller les chercher avec les dents, avec une force commerciale pour les convaincre et les éduquer vers cette segmentation du marché. Scaleway doit maintenant faire preuve de fiabilité et de la pertinence de notre positionnement en qu’acteur du marché IoT », déclare Grégoire de Turckheim.

Pour se démarquer, Scaleway souhaite miser sur « la simplicité, des fonctionnalités qui n’existent pas chez les concurrents et des tarifs compétitifs ». « Nous avons une énorme corde à notre arc, c’est que chez nous les données sont hébergées en France et qu’elles ne sont pas soumises au CLOUD Act », ajoute-t-il.

Pour l’instant, Scaleway veut étendre les capacités d’ingestion et d’export de données d’IoT Hub, préparer la prise en charge de MQTT 5 et renforcer sa documentation. « Une fois que le Hub sera bien en place, nous offrirons des services d’analyse de contexte de diffusion de messages », conclut le product manager.