AWS et IBM : une comparaison des services IoT : 4 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:07

Nous comparons aujourd'hui deux stacks qui permettent de développer des applications IoT sous l'angle de différentes offres de services.

Étape 1: Fonctionne en tant que service

FaaS est une catégorie de services cloud utilisés pour créer une architecture « sans serveur ». FaaS permet aux clients de développer, d'exécuter et de gérer les fonctionnalités des applications sans créer ni maintenir l'infrastructure.

Amazon propose AWS Lambda, IBM propose IBM Cloud Functions. Ces services sont assez similaires, mais Lambda a été le premier de ce type. En utilisant FaaS, vous pouvez exécuter des morceaux de code dans le cloud et chaque service prend en charge différents langages de programmation.

Fonctions IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# etc.), Tout via Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Tout via l'API d'exécution

IBM prend en charge plus de langues et avec docker, il est facile d'utiliser des scripts écrits dans d'autres langues. Cela peut être fait aussi avec Lambda mais ce n'est pas immédiat. Vous pouvez lire un exemple ici:

Les deux services ont des limites d'utilisation, nous les rapportons dans un tableau et mettons en évidence les meilleurs.

Le prix est basé sur les gigaoctets par seconde (RAM) avec l'ajout du nombre de requêtes pour AWS Lambda. Chaque service a un forfait gratuit et ils sont presque équivalents. Comme vous pouvez le voir, Lambda est un peu moins cher pour le Go/s, mais il a un coût lié aux requêtes que Cloud Functions n'a pas, donc le coût est presque le même en général. Bien sûr, si vous devez exécuter des tâches qui consomment de la mémoire et utilisent peu de requêtes, vous devez utiliser Lambda. Le principal avantage d'IBM Cloud Function, à notre avis, est que sa pile est open source. Il est entièrement basé sur Apache OpenWhisk et peut également être déployé sur une infrastructure privée.

Étape 2: apprentissage automatique

Un domaine où les stacks IBM et AWS proposent des services similaires est celui du machine learning: Amazon avec son SageMaker et IBM avec Watson Machine Learning. Les deux services sont très similaires à bien des égards: ils se présentent tous deux comme des outils pour aider les scientifiques des données et les développeurs à créer, former puis déployer dans des environnements prêts pour la production leurs modèles d'apprentissage automatique, mais les philosophies adoptées par les deux sociétés varient considérablement. Les deux services vous permettent de choisir entre différents degrés de contrôle sur les modèles que vous utilisez. Dans Watson ML, vous avez des modèles intégrés qui sont déjà formés pour effectuer des tâches très spécifiques: par exemple, si vous voulez reconnaître quels objets sont présents dans une image, il vous suffit d'importer le modèle VisualRecognitionV3 et de lui transmettre l'image que vous vouloir analyser. Vous pouvez également créer un « modèle personnalisé », mais dans Watson ML, cela signifie principalement prendre un modèle déjà construit et suivre notre formation dessus, la personnalisation est donc assez limitée. Il est important de noter cependant que ni SageMaker ni Watson ML ne sont les seuls moyens de faire de l'apprentissage automatique sur les piles de leurs développeurs, ce ne sont que des services visant à faciliter la vie des développeurs. La plate-forme Watson ML prend également en charge la plupart des bibliothèques d'apprentissage automatique les plus populaires, vous pouvez donc même créer un modèle à partir de zéro avec PyTorch, Tensorflow ou des bibliothèques similaires. Vous utilisez soit ces bibliothèques directement, soit les modèles prédéfinis, il n'y a pas de terrain d'entente. De plus, Watson ML ne prend pas en charge la bibliothèque de choix d'Amazon, Apache MXNet, qui a à la place une prise en charge de première classe dans SageMaker.

L'approche d'Amazon SageMaker, même en utilisant des options intégrées, est un peu plus basse: plutôt que de vous faire choisir parmi des modèles prédéfinis, elle vous permet de choisir parmi une pléthore d'algorithmes de formation déjà implémentés, que vous pouvez utiliser lors de la création de votre modèle d'une manière plus traditionnelle. Si cela ne suffit pas, vous pouvez également utiliser votre propre algorithme. Cette façon de faire les choses nécessite certainement plus de connaissances sur la façon dont l'apprentissage automatique est effectué par rapport à la simple utilisation d'un modèle entraîné dans Watson ML.

À première vue, il peut sembler que Watson ML est le moyen « simple et rapide », Amazon SageMaker étant le plus complexe à configurer. Cela peut ne pas être tout à fait vrai de certains points de vue, car SageMaker est structuré pour que tout s'exécute sur un bloc-notes Jupyter, tandis que pour les mêmes fonctionnalités dans Watson ML, vous devez configurer de nombreux sous-services différents à partir de l'interface utilisateur Web. Le prétraitement des données dispose également d'espaces dédiés sur le service IBM tandis que SageMaker compte sur vous pour tout faire à partir du code de votre notebook. Ceci, ajouté au fait que les notebooks Jupyter ne sont pas exactement le meilleur choix du point de vue de l'ingénierie logicielle, peut empêcher SageMaker de très bien évoluer en production. Les deux services ont des mécanismes assez bons et simples pour déployer votre modèle et rendre les API disponibles dans le monde extérieur.

En conclusion, Watson ML fonctionne mieux dans les grands projets où les notebooks Jupyter commencent à montrer leurs limites et où vous n'avez pas besoin de beaucoup de personnalisation dans ce que fait le modèle lui-même. SageMaker est bien meilleur lorsque vous avez besoin de plus de flexibilité dans la définition des algorithmes, mais lorsque vous l'utilisez, vous devez prendre en compte le fait que vous devez vous fier à Jupyter Notebooks, qui peut ne pas bien évoluer en production. Une solution pourrait être de découpler autant que possible le reste du code du modèle, afin que le code dans les cahiers réels ne devienne pas trop volumineux et que nous puissions mieux organiser notre logiciel dans les autres modules qui utilisent simplement l'API de notre modèle.

Étape 3: Diffusion de données et analyse

Les services de streaming de données sont essentiels pour gérer et analyser en temps réel de grands flux de données. Ce flux peut être du cloud vers l'appareil des utilisateurs, comme un streaming vidéo, ou des utilisateurs vers le cloud, comme la télémétrie IoT et les lectures de capteurs. Surtout dans le second cas, nous pourrions avoir une situation où des sources uniques téléchargent de petites quantités de données, mais lorsque l'on considère le débit global, provenant de tous les appareils, cela consomme une bande passante considérable, il est donc logique d'utiliser un service spécialisé pour gérer de tels flux de données. Sans gérer directement ce flux continu, nous serions obligés de mettre en mémoire tampon les informations entrantes dans un stockage temporaire et dans un second temps de les traiter avec un moteur de calcul. Le problème de cette dernière approche est qu'il faudrait coordonner plus de services différents pour réaliser ce qu'un service de flux de données unique fait déjà seul, augmentant la complexité de la maintenance et de la configuration de l'application. De plus, la mise en mémoire tampon peut en principe faire en sorte que notre application ne soit plus en temps réel, car pour qu'un élément soit traité, il est nécessaire que tous les autres éléments avant lui soient également traités, et l'ajout de politiques de priorité au tampon peut, encore une fois, augmenter considérablement la complexité. En résumé, les services de streaming de données offrent une gestion des flux de données en temps réel, avec une configuration simple, et peuvent fournir des analyses sur les données entrantes. Nous comparons ici les deux principaux services de streaming de la pile IBM et AWS, à savoir IBM Streams et AWS Kinesis.

Nous commençons par noter que toutes les fonctionnalités de base que nous pouvons souhaiter d'un service de streaming sont proposées à la fois par IBM et AWS. Ces fonctionnalités incluent un taux de traitement pratiquement infini, une faible latence et des analyses de données en temps réel. Puisque nous parlons de services professionnels, ils offrent tous deux des outils de production pour le déploiement et l'automatisation.

En ce qui concerne l'analyse de données, les deux services l'offrent en option, vous faisant payer uniquement si vous en avez besoin ou non. Dans le cas de Kinesis, lorsque vous n'avez pas besoin d'analyses mais simplement de gestion des flux de données, les prix sont facturés par Go traité au lieu du temps de traitement, comme dans le cas d'IBM. La tarification au Go sera généralement moins chère que la tarification à l'heure, puisque vous ne payez que pour le trafic entrant. Pour le reste de cet article, nous considérerons à la fois IBM Streams et AWS Kinesis avec la fonction d'analyse de données activée.

Streams et Kinesis offrent une intégration avec différents services pour le pré-traitement et le filtrage des données entrantes avant de les transmettre à l'analyse de données, respectivement avec Apache Edgent et AWS Lambda. Bien que ces services soient radicalement différents l'un de l'autre, nous ne les aborderons que du point de vue des deux services de streaming. La différence fondamentale entre les deux est qu'Apache Edgent s'exécute sur l'appareil, tandis qu'AWS Lambda s'exécute sur le cloud. Cela apporte de nombreux avantages et inconvénients: du côté de Lambda, nous avons un service flexible et facile à utiliser avec une intégration transparente avec Kinesis, mais cela nécessite que les données soient déjà téléchargées sur le cloud, perdant ainsi en efficacité et payant également Kinesis pour les données qui seront finalement rejetées. Du côté Edgent à la place, nous avons que la plupart des calculs sont effectués, eh bien, à la périphérie du réseau (donc sur les appareils) avant de télécharger des données inutiles sur le cloud. Le principal inconvénient est qu'Edgent est un framework volumineux, ce qui peut prendre du temps à mettre en place et peut être complexe à maintenir. Une autre différence qui pourrait être pertinente dans le choix d'une plate-forme est qu'Edgent est entièrement open source, Lambda ne l'est pas. Cela peut être considéré à la fois comme un avantage, car avoir accès au code que vous ou votre client exécuterez est toujours une chose positive, à la fois comme un inconvénient, car il peut y avoir des situations où vous avez besoin d'une assistance urgente qui ne peut pas être fournie dans tous les environnements open source.

D'autres fonctionnalités que nous pouvons mentionner sont l'évolutivité automatique de Kinesis des ressources allouées. En effet, le matériel qu'il propose est composé d'un certain nombre d'unités de traitement Kinesis (KPU) fonctionnant en parallèle, où une KPU offre 1 vCore et 4 Go de RAM. Leur nombre dépend des besoins de l'application et est alloué dynamiquement et automatiquement (ce que vous payez est en effet le temps cpu multiplié par le nombre de KPU), rappelez-vous simplement que c'est une politique de Kinesis de vous facturer un KPU de plus si vous utilisez un Java application. IBM Streams, au contraire, n'offre pas ce type de flexibilité, vous proposant un conteneur avec du matériel fixe, plus de détails lorsque nous parlons de tarification. D'autre part, IBM Streams est plus ouvert que Kinesis, car il s'interface avec le WAN via des protocoles couramment utilisés, comme HTTP, MQTT, etc., tandis que Kinesis est fermé à l'écosystème AWS.

En guise de comparaison finale, parlons des prix, et laissez-moi vous dire qu'IBM ne fonctionne pas très bien sur ce point. Nous avons configuré différentes solutions pour trois catégories différentes (basique, haut de gamme, ultra-haut de gamme) pour IBM et AWS, et nous allons comparer leur prix. Dans la configuration de base, nous avons un AWS KPU, mentionné précédemment, contre une solution IBM avec le même matériel. Pour le haut de gamme, nous avons 8 KPU fonctionnant en parallèle pour Kinesis et 2 conteneurs toujours en parallèle pour IBM, chacun avec 4 vCores et 12 Go de RAM. Toujours IBM propose dans l'ultra haut de gamme un seul conteneur avec 16 vCores et 128 Go de RAM, alors que nous avons omis une solution équivalente pour AWS, car si certaines applications nécessitent cette grande quantité de RAM, il ne pourrait pas être possible de l'exécuter sur différents KPU.. Les prix que nous rapportons sont exprimés en $/mois en considérant une utilisation 24/7. Pour la configuration de base nous avons pour IBM et AWS respectivement 164$ et 490$, pour le haut de gamme 1320$ et 3500$, pour l'ultra-haut de gamme AWS n'est pas pris en compte et il n'y a qu'IBM avec 6300$. À partir de ces résultats, nous pouvons voir que Kinesis fonctionne mieux pour l'utilisateur quotidien jusqu'au niveau de l'entreprise, alors qu'il manque d'options pour gérer directement les analyses de données qui nécessitent une énorme quantité de puissance de calcul. Kinesis offre un meilleur rapport performances/$ qu'IBM Streams, aidé également par l'allocation dynamique de petits blocs de ressources uniquement en cas de besoin, tandis qu'IBM vous propose un conteneur fixe. Ainsi, si votre charge de travail est caractérisée par des pics, avec IBM vous êtes obligé de surestimer vos besoins applicatifs et de configurer une solution dans le pire des cas. IBM propose des frais d'heures au lieu de payer le mois complet, mais ce n'est pas automatisé comme Kinesis.

Étape 4: Architecture IoT

La configuration des périphériques pour aws iot est assez simple par rapport à ibm watson iot. Parce que dans ibm watson iot, l'authentification est par périphérique avec jeton et une fois qu'il affiche le jeton, il ne s'affichera plus jamais. Pour en revenir à la tarification, ibm watson iot est assez coûteux par rapport à aws iot. Ainsi, le prix en frais ibm watson iot est basé sur par appareil, stockage de données, trafic de données. Mais dans aws iot, nous pouvons payer le montant une fois et nous pouvons ajouter plus d'appareils et de données publiés à partir d'appareils et livrés aux appareils.

Commencez par votre appareil, qu'il s'agisse d'un capteur, d'une passerelle ou autre, et laissez-nous vous aider à vous connecter au cloud.

Les données de votre appareil sont toujours sécurisées lorsque vous vous connectez au cloud à l'aide du protocole de messagerie MGTT ou HTTP ouvert et léger. À l'aide de protocoles et de node-red, nous pouvons connecter notre appareil à la plate-forme iot et accéder aux données en direct et historiques.

Utilisez nos API sécurisées pour connecter vos applications aux données de vos appareils.

Créez des applications au sein de notre service cloud donné pour interpréter les données.