AWS und IBM: ein Vergleich der IoT-Services – 4 Schritte

2024 Autor: John Day | [email protected]. Zuletzt bearbeitet: 2024-01-30 07:18

Heute vergleichen wir zwei Stacks, die es ermöglichen, IoT-Anwendungen unter dem Gesichtspunkt unterschiedlicher Serviceangebote zu entwickeln.

Schritt 1: Funktionen als Service

FaaS ist eine Kategorie von Cloud-Diensten, die zum Aufbau einer „serverlosen“Architektur verwendet werden. FaaS ermöglicht es den Kunden, Anwendungsfunktionen zu entwickeln, auszuführen und zu verwalten, ohne die Infrastruktur aufzubauen und zu warten.

Amazon bietet AWS Lambda an, IBM bietet IBM Cloud Functions an. Diese Dienste sind ziemlich ähnlich, jedoch war Lambda der erste dieser Art. Mit FaaS können Sie Codeteile in der Cloud ausführen und jeder Dienst unterstützt verschiedene Programmiersprachen.

IBM Cloud Functions: JavaScript, Swift, Java, Go, PHP, Python, Ruby,. NET (C# F# etc.), Any via Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Any über Runtime-API

IBM unterstützt mehr Sprachen und mit Docker sind in anderen Sprachen geschriebene Skripts einfach zu verwenden. Dies ist auch mit Lambda möglich, jedoch nicht sofort. Ein Beispiel können Sie hier lesen:

Beide Dienste haben Nutzungsbeschränkungen, wir melden sie in einer Tabelle und heben die besten hervor.

Der Preis basiert auf GigaBytes pro Sekunde (RAM) zuzüglich der Anzahl der Anfragen für AWS Lambda. Jeder Service hat einen kostenlosen Plan und sie sind fast gleichwertig. Wie Sie sehen, ist Lambda für die GB/s etwas billiger, aber es verursacht Kosten im Zusammenhang mit Anfragen, die Cloud Functions nicht hat, so dass die Kosten im Allgemeinen fast gleich sind. Wenn Sie Aufgaben ausführen müssen, die Speicher verbrauchen und nur wenige Anforderungen verwenden, sollten Sie natürlich Lambda verwenden. Der Hauptvorteil von IBM Cloud Function besteht unserer Meinung nach darin, dass der Stack Open Source ist. Es basiert vollständig auf Apache OpenWhisk und kann auch auf einer privaten Infrastruktur bereitgestellt werden.

Schritt 2: Maschinelles Lernen

Ein Feld, in dem die IBM- und AWS-Stacks ähnliche Dienste anbieten, ist das maschinelle Lernen: Amazon mit seinem SageMaker und IBM mit Watson Machine Learning. Die beiden Dienste sind in vielerlei Hinsicht sehr ähnlich: Beide präsentieren sich als Tools, die Datenwissenschaftlern und Entwicklern helfen, ihre Machine-Learning-Modelle zu erstellen, zu trainieren und dann in produktionsbereiten Umgebungen bereitzustellen, aber die Philosophien der beiden Unternehmen unterscheiden sich stark. Bei beiden Diensten können Sie zwischen verschiedenen Kontrollgraden für die von Ihnen verwendeten Modelle wählen. In Watson ML verfügen Sie über einige integrierte Modelle, die bereits für einige sehr spezifische Aufgaben trainiert wurden: Wenn Sie beispielsweise erkennen möchten, welche Objekte in einem Bild vorhanden sind, importieren Sie einfach das VisualRecognitionV3-Modell und übergeben ihm das Bild, das Sie analysieren wollen. Sie können auch ein „benutzerdefiniertes Modell“erstellen, aber in Watson ML bedeutet dies meistens, dass Sie ein bereits erstelltes Modell nehmen und unser Training damit durchführen, sodass die Anpassung ziemlich begrenzt ist. Es ist jedoch wichtig zu beachten, dass weder SageMaker noch Watson ML die einzigen Möglichkeiten sind, maschinelles Lernen auf den Stacks ihrer Entwickler durchzuführen, sondern nur Dienste, die das Leben der Entwickler erleichtern sollen. Die Watson ML-Plattform unterstützt auch viele der beliebtesten Machine-Learning-Bibliotheken, sodass Sie mit PyTorch, Tensorflow oder ähnlichen Bibliotheken sogar ein Modell von Grund auf neu erstellen können. Sie verwenden diese Bibliotheken entweder direkt oder verwenden die vorgefertigten Modelle, es gibt keinen Mittelweg. Watson ML unterstützt auch nicht Amazons Wahlbibliothek Apache MXNet, die stattdessen erstklassige Unterstützung in SageMaker bietet.

Der Ansatz von Amazon SageMaker ist selbst bei Verwendung integrierter Optionen etwas niedriger: Anstatt Sie aus vorgefertigten Modellen auswählen zu lassen, können Sie aus einer Vielzahl bereits implementierter Trainingsalgorithmen wählen, die Sie beim Erstellen Ihres Modell auf traditionellere Weise. Wenn diese nicht ausreichen, können Sie auch Ihren eigenen Algorithmus verwenden. Diese Vorgehensweise erfordert sicherlich mehr Wissen darüber, wie maschinelles Lernen durchgeführt wird, als nur ein trainiertes Modell in Watson ML zu verwenden.

Auf den ersten Blick mag es scheinen, dass Watson ML der „einfache und schnelle“Weg ist, wobei Amazon SageMaker der komplexer einzurichtende Weg ist. Dies mag unter einigen Gesichtspunkten nicht ganz zutreffen, da SageMaker so strukturiert ist, dass alles auf einem Jupyter-Notebook ausgeführt wird, während Sie für dieselben Funktionen in Watson ML viele verschiedene Unterdienste über die Web-Benutzeroberfläche einrichten müssen. Die Vorverarbeitung der Daten hat auch dedizierte Bereiche im IBM Service, während SageMaker darauf angewiesen ist, dass Sie alles über den Code in Ihrem Notebook erledigen. Dies und die Tatsache, dass Jupyter-Notebooks aus softwaretechnischer Sicht nicht gerade die beste Wahl sind, kann SageMaker daran hindern, in der Produktion sehr gut zu skalieren. Beide Dienste verfügen über ziemlich gute und einfache Mechanismen, um Ihr Modell bereitzustellen und APIs dafür in der Außenwelt verfügbar zu machen.

Zusammenfassend lässt sich sagen, dass Watson ML in großen Projekten besser abschneidet, bei denen die Jupyter-Notebooks an ihre Grenzen stoßen und bei denen Sie nicht viel Anpassungen beim Modell selbst benötigen. SageMaker ist viel besser, wenn Sie mehr Flexibilität bei der Definition der Algorithmen benötigen, aber bei der Verwendung müssen Sie berücksichtigen, dass Sie sich auf Jupyter-Notebooks verlassen müssen, die in der Produktion möglicherweise nicht gut skalieren. Eine Lösung könnte darin bestehen, den restlichen Code so weit wie möglich vom Modell zu entkoppeln, damit der Code in den eigentlichen Notebooks nicht zu groß wird und wir unsere Software in den anderen Modulen, die nur die API unseres Modells verwenden, besser organisieren können.

Schritt 3: Datenstreaming und -analyse

Daten-Streaming-Dienste sind entscheidend für die Verarbeitung und Analyse großer Datenströme in Echtzeit. Dieser Fluss kann von der Cloud zum Gerät der Benutzer erfolgen, wie ein Videostreaming, oder von den Benutzern in die Cloud, wie IoT-Telemetrie und Sensormesswerte. Insbesondere im zweiten Fall könnten wir eine Situation haben, in der einzelne Quellen kleine Datenmengen hochladen, aber wenn wir den Gesamtdurchsatz aller Geräte betrachten, wird eine beträchtliche Bandbreite verbraucht, daher ist es sinnvoll, einen darauf spezialisierten Dienst zu verwenden Datenströme ein. Ohne diesen kontinuierlichen Fluss direkt zu handhaben, müssten wir die eingehenden Informationen in einem temporären Speicher zwischenspeichern und sie ein zweites Mal mit einer Rechenmaschine verarbeiten. Das Problem dieses letzten Ansatzes besteht darin, dass wir mehr verschiedene Dienste koordinieren müssten, um das zu erreichen, was ein einzelner Datenstromdienst bereits allein leistet, was die Komplexität der Wartung und Konfiguration der Anwendung erhöht. Darüber hinaus kann die Pufferung unsere Anwendung grundsätzlich nicht mehr in Echtzeit ausführen, da es für eine Verarbeitung eines Elements erforderlich ist, dass alle anderen Elemente davor ebenfalls verarbeitet werden, und das Hinzufügen von Prioritätsrichtlinien zum Puffer kann dies wieder tun, die Komplexität drastisch erhöhen. Zusammenfassend lässt sich sagen, dass Daten-Streaming-Dienste eine Datenflussverarbeitung in Echtzeit mit einer einfachen Konfiguration ermöglichen und Analysen zu den eingehenden Daten bereitstellen können. Hier vergleichen wir die beiden wichtigsten Streaming-Dienste des IBM- und AWS-Stacks, nämlich IBM Streams und AWS Kinesis.

Zunächst stellen wir fest, dass alle grundlegenden Funktionen, die wir uns von einem Streaming-Dienst wünschen, sowohl von IBM als auch von AWS angeboten werden. Zu diesen Funktionen gehören eine praktisch unbegrenzte Verarbeitungsrate, geringe Latenz und Echtzeit-Datenanalyse. Da es sich um professionelle Dienstleistungen handelt, bieten beide Tools in Produktionsqualität für die Bereitstellung und Automatisierung.

Apropos Datenanalyse: Beide Dienste bieten diese optional an, sodass Sie nur bezahlen, ob Sie sie benötigen oder nicht. Im Fall von Kinesis, wenn Sie keine Analyse, sondern nur die Datenflussverarbeitung benötigen, werden die Preise pro verarbeitetem GB und nicht wie im Fall von IBM nach Verarbeitungszeit berechnet. Der Preis pro GB ist im Allgemeinen günstiger als der Preis pro Zeit, da Sie nur für den eingehenden Datenverkehr bezahlen. Für den Rest dieses Beitrags betrachten wir sowohl IBM Streams als auch AWS Kinesis mit aktivierter Datenanalysefunktion.

Streams und Kinesis bieten die Integration mit verschiedenen Diensten zur Vorverarbeitung und Filterung der eingehenden Daten, bevor sie an die Datenanalyse bzw. mit Apache Edgent und AWS Lambda übergeben werden. Obwohl sich diese Dienste radikal voneinander unterscheiden, werden wir sie nur aus der Sicht der beiden Streaming-Dienste diskutieren. Der grundlegende Unterschied zwischen den beiden besteht darin, dass Apache Edgent auf dem Gerät ausgeführt wird, während AWS Lambda in der Cloud ausgeführt wird. Dies bringt viele Vor- und Nachteile mit sich: Von Lambda-Seite haben wir einen flexiblen und einfach zu bedienenden Service mit einer nahtlosen Integration mit Kinesis, der jedoch erfordert, dass die Daten bereits in die Cloud hochgeladen werden, wodurch die Effizienz verloren geht und Kinesis auch bezahlt wird für die Daten, die schließlich verworfen werden. Von Edgent-Seite haben wir stattdessen, dass der größte Teil der Berechnung am Rand des Netzwerks (also auf den Geräten) erfolgt, bevor nutzlose Daten in die Cloud hochgeladen werden. Der Hauptnachteil besteht darin, dass Edgent ein großes Framework ist, dessen Einrichtung möglicherweise Zeit in Anspruch nimmt und dessen Wartung komplex sein kann. Ein weiterer Unterschied, der bei der Wahl einer Plattform relevant sein könnte, ist, dass Edgent vollständig Open Source ist, Lambda nicht. Dies kann sowohl als Vorteil angesehen werden, da der Zugriff auf den Code, den Sie oder Ihr Kunde ausführen werden, immer eine positive Sache ist, sowohl als Nachteil, da es Situationen geben kann, in denen Sie dringend Unterstützung benötigen, die nicht bereitgestellt werden kann alle Open-Source-Umgebungen.

Andere Funktionen, die wir erwähnen können, ist die automatische Skalierbarkeit der zugewiesenen Ressourcen durch Kinesis. Tatsächlich besteht die angebotene Hardware aus einer Reihe von sogenannten Kinesis Processing Units (KPUs), die parallel laufen, wobei eine KPU 1 vCore und 4 GB RAM bietet. Ihre Anzahl hängt von den Anforderungen der Anwendung ab und wird dynamisch und automatisch zugewiesen (was Sie tatsächlich zahlen, ist die CPU-Zeit mal die Anzahl der KPUs). Denken Sie jedoch daran, dass es eine Kinesis-Richtlinie ist, Ihnen eine KPU mehr zu berechnen, wenn Sie ein Java verwenden Anwendung. IBM Streams hingegen bietet diese Art von Flexibilität nicht und bietet Ihnen einen Container mit fester Hardware, mehr Details, wenn wir über die Preise sprechen. Auf der anderen Seite ist IBM Streams offener als Kinesis, da es über gängige Protokolle wie HTTP, MQTT usw. mit dem WAN verbunden ist, während Kinesis gegenüber dem AWS-Ökosystem geschlossen ist.

Lassen Sie uns zum abschließenden Vergleich über die Preisgestaltung sprechen, und lassen Sie mich sagen, dass IBM in diesem Punkt nicht großartig funktioniert. Wir haben verschiedene Lösungen für drei verschiedene Kategorien (Basic, High-End, Ultra-High-End) für IBM und AWS konfiguriert und werden deren Preis vergleichen. In der Grundkonfiguration haben wir eine bereits erwähnte AWS KPU gegen eine IBM-Lösung mit derselben Hardware. Für das High-End laufen 8 KPUs parallel für Kinesis und 2 Container immer parallel für IBM mit jeweils 4 vCores und 12 GB RAM. IBM bietet im Ultra-High-End immer einen einzigen Container mit 16 vCores und 128 GB RAM an, während wir eine gleichwertige Lösung für AWS weggelassen haben, da eine Anwendung, die so viel RAM benötigt, nicht auf verschiedenen KPUs ausgeführt werden kann. Die von uns angegebenen Preise sind in $/Monat unter Berücksichtigung einer 24/7-Nutzung angegeben. Für die Grundkonfiguration haben wir für IBM und AWS jeweils 164$ und 490$, für das High-End 1320$ und 3500$, für das Ultra-High-End kommt AWS nicht in Betracht und es gibt nur IBM mit 6300$. Aus diesen Ergebnissen können wir sehen, dass Kinesis für den alltäglichen Benutzer bis hin zum Enterprise-Level besser funktioniert, während es an Optionen zur direkten Handhabung von Datenanalysen fehlt, die eine enorme Rechenleistung erfordern. Kinesis bietet ein besseres Performance/$-Verhältnis als IBM Streams, unterstützt auch durch die dynamische Zuweisung kleiner Ressourcenblöcke nur bei Bedarf, während IBM Ihnen einen festen Container bietet. Auf diese Weise sind Sie, wenn Ihr Workload durch Spitzen gekennzeichnet ist, bei IBM gezwungen, Ihren Anwendungsbedarf zu überschätzen und im schlimmsten Fall eine Lösung zu konfigurieren. IBM bietet Stundengebühren an, anstatt den ganzen Monat zu bezahlen, aber es ist nicht wie Kinesis automatisiert.

Schritt 4: IoT-Architektur

Die Konfiguration von Geräten für aws iot ist im Vergleich zu ibm watson iot recht einfach. Weil in ibm watson iot die Authentifizierung pro Gerät mit Token erfolgt und sobald das Token angezeigt wird, wird es nie wieder angezeigt. Kommen wir wieder zum Preis von Teil ibm watson iot ist im Vergleich zu aws iot ziemlich kostspielig. Der Preis in ibm watson iot basiert also auf den Gebühren pro Gerät, Datenspeicher und Datenverkehr. Aber in aws iot können wir den Betrag einmal bezahlen und wir können weitere Geräte und Daten hinzufügen, die von Geräten veröffentlicht und an Geräte geliefert werden.

Beginnen Sie mit Ihrem Gerät – sei es ein Sensor, Gateway oder etwas anderes – und lassen Sie sich von uns helfen, sich mit der Cloud zu verbinden.

Ihre Gerätedaten sind immer sicher, wenn Sie sich über das offene, leichte MGTT-Messaging-Protokoll oder HTTP mit der Cloud verbinden. Mit Hilfe von Protokollen und Node-Red können wir unser Gerät mit der iot-Plattform verbinden und auf Live- und historische Daten zugreifen.

Verwenden Sie unsere sicheren APIs, um Ihre Apps mit Daten von Ihren Geräten zu verbinden.

Erstellen Sie Anwendungen innerhalb unseres angegebenen Cloud-Dienstes, um Daten zu interpretieren.