TagoIO vs. Microsoft Azure IoT

Vergleichen Sie TagoIO und Azure IoT (IoT Hub, IoT Central, IoT Operations) bei Anwendungsschicht, Dashboards, Preisen und Deployment-Optionen.

Aktualisiert am

Azure IoT ist Microsofts Portfolio aus Konnektivitäts- und Edge-Diensten für IoT-Lösungen auf Azure. TagoIO ist eine Full-Stack-IoT-Plattform, bei der die Anwendungsschicht, also Dashboards, Regeln, eigener Code und Portale für Endnutzer, bereits eingebaut ist. Der Vergleich hängt davon ab, welches Azure-IoT-Produkt gemeint ist, deshalb lohnt sich zuerst ein Blick auf das Portfolio.

Azure IoT Hub ist der Kerndienst: ein verwaltetes Geräte-Gateway mit Unterstützung für MQTT, AMQP und HTTPS, mit Device Twins für den Gerätezustand, Jobs für Flottenoperationen und dem Device Provisioning Service für Zero-Touch-Onboarding. Wie AWS IoT Core endet er bei Konnektivität und Nachrichten-Routing; Speicherung, Analytik, Dashboards und Anwendungen kommen aus anderen Azure-Diensten oder aus eigenem Code.

Azure IoT Central ist Microsofts gehostete Anwendungsplattform auf Basis von IoT Hub, mit Gerätevorlagen, integrierten Dashboards, einer Regel-Engine und Preisen pro Gerät. Im Februar 2024 kündigte eine Meldung im Azure-Portal die Einstellung von IoT Central für 2027 an; Microsoft zog sie innerhalb eines Tages zurück und erklärte, der Dienst stehe derzeit nicht vor der Abkündigung. Der Dienst bleibt verfügbar, und wer ihn evaluiert, kann Microsofts öffentliche Aussagen gegen die Frage abwägen, wohin die Investitionen sichtbar fließen.

Azure IoT Operations, seit Ende 2024 allgemein verfügbar, ist genau diese Investition: eine Kubernetes-basierte, über Azure Arc verwaltete Edge-Datenebene für industrielle Szenarien, aufgebaut um einen Edge-MQTT-Broker und OPC-UA-Konnektivität.

TagoIO ist eine einzige Plattform, die Gerätekonnektivität (MQTT, HTTPS und mehr als 500 Geräte-Connectors), Zeitreihen-Speicher, Dashboards, serverlose Analysis-Skripte in Node.js, Deno oder Python, Actions für Regeln und Alarme sowie TagoRUN White-Label-Portale für Endnutzer abdeckt. Dedizierte Deployments sind über TagoDeploy in mehr als 12 Regionen verfügbar.

Gerätekonnektivität und Provisionierung

IoT Hub ist starke Infrastruktur: Device Twins sind ein ausgereiftes Muster für die Zustandssynchronisation, DPS übernimmt die Provisionierung im Flottenmaßstab, und Device Update kümmert sich um OTA. LoRaWAN ist kein nativer Azure-Dienst, LoRaWAN-Projekte bringen also einen Partner-Network-Server mit und integrieren ihn selbst.

TagoIO verbindet Geräte über MQTT und HTTPS sowie über seine Connector-Bibliothek, die LoRaWAN-Network-Server (The Things Network, The Things Industries, Actility, Loriot, ChirpStack, Helium und weitere), Sigfox und Satellitenanbieter wie Myriota und Kinéis umfasst. Payload-Parser und ein Live Inspector zum Debuggen des Geräteverkehrs gehören zur Plattform. Die Netzwerknutzung ist kostenlos; die Pläne messen ein- und ausgehende Daten.

Wo die Anwendung entsteht

Bei IoT Hub bauen Sie die Anwendung selbst zusammen: Stream Analytics oder Fabric für die Verarbeitung, Power BI oder Grafana für die Visualisierung und Eigenentwicklung für alles, was Kunden zu sehen bekommen. Organisationen, die auf Microsoft-Tooling standardisiert sind, wollen oft genau das, weil die IoT-Daten im selben Fabric- und Power-BI-Stack landen, den der Rest des Unternehmens nutzt.

IoT Central bringt Operator-Dashboards und Regeln mit, und die REST-API erlaubt den Ausbau darüber hinaus; kundenorientierte Anwendungen bleiben aber Eigenentwicklung.

In TagoIO sind Dashboards, Regeln und Portale für Endnutzer Plattformfunktionen. Blueprint-Dashboards wenden ein Layout auf eine ganze Geräteflotte an. TagoRUN ergänzt gebrandete Portale mit Nutzerverwaltung, Zugriffsrichtlinien, eigenen Domains und einer optionalen Mobile-App unter Ihrer eigenen Marke, also genau den Teil, den Azure auf keiner Ebene als Produkt anbietet.

Eigene Logik

Azure leitet IoT-Hub-Nachrichten in Event Hubs, Functions und die breitere Datenplattform. Das Muster ist leistungsfähig und ohne Grenzen, bedeutet aber auch, Deployment und Betrieb für jede Function und jede Pipeline selbst zu verantworten.

Die Analysis-Engine von TagoIO führt eigene Skripte innerhalb der Plattform aus, ohne separate Infrastruktur, ausgelöst durch Datenbedingungen, Zeitpläne oder Dashboard-Interaktionen. Die Plattform-Analytik deckt auch Prognosen und Vorhersagen auf Sensordaten ab, nicht nur Dashboards. Teams, die an die eingebauten Grenzen stoßen, können External Analysis auf eigener Rechenleistung betreiben und dabei dieselben Plattform-APIs weiterverwenden.

Edge

Azure hat die tiefere industrielle Edge-Geschichte: IoT-Edge-Module und, seit kurzem, IoT Operations auf Arc-fähigem Kubernetes mit OPC-UA-Unterstützung, gedacht für Fabriken mit OT-Infrastruktur und Kubernetes-Know-how.

Die Edge-Komponente von TagoIO ist TagoCore, eine kostenlose Open-Source-IoT-Engine, die auf Hardware vom Raspberry Pi bis zur Cloud-VM läuft, ausgeliefert als Docker-Image mit Plugin-Architektur. Sie eignet sich für lokale Erfassung und Verarbeitung mit Synchronisation zur TagoIO-Cloud, nicht für industrielle Deployments im Kubernetes-Maßstab.

Preismodell

IoT Hub rechnet nach Kapazitätseinheiten und Stufen ab, mit einer kostenlosen Stufe; IoT Central rechnet pro Gerät ab; IoT Operations wird über Arc lizenziert. Speicher-, Verarbeitungs- und Visualisierungsdienste werden separat berechnet, die Lösungskosten sind also die Summe mehrerer Zähler.

TagoIO nutzt Planstufen plus Dienstnutzung: kostenlos für 5 Geräte und 5 Dashboards, Starter für 49 $/Monat, Scale für 199 $/Monat und dedizierte TagoDeploy-Instanzen ab 850 $/Monat. Gemessen werden Datentransaktionen, Speicher, Analysis-Minuten, Benachrichtigungen und Endnutzer, alles auf einer Rechnung.

Das Fazit

Azure IoT passt zu Organisationen, die fest auf den Microsoft-Stack setzen, zu Teams, die ihre IoT-Daten in Fabric und Power BI haben wollen, und zu industriellen Deployments, die am Edge in IoT Operations investieren können.

TagoIO passt, wenn das Ergebnis eine fertige IoT-Anwendung sein soll, besonders eine, in die sich Ihre Kunden unter Ihrer Marke einloggen, und wenn Sie lieber eine Plattform konfigurieren als eine Reihe von Diensten integrieren. Beide Ansätze betreiben produktive Flotten; der Unterschied liegt darin, wie viel der Lösung Sie als Code besitzen wollen.