Der Tod von Googles IoT-Cloud – eine Chance für offene Standards
Googles Abschied von IoT Core ist ein Warnschuss für alle, nicht in die Lock-in-Falle zu stapfen, meint Dominik Obermaier.
- Dominik Obermaier
Am 16.08.2022 ließ Google die Bombe platzen: Das Unternehmen schaltet das Cloud-Angebot IoT Core komplett ab. Kunden, die darüber Tausende von Geräten an die Google Cloud angebunden haben, müssen sich nun nach einer Alternative umsehen. Sie fragen sich zurecht, wie sie vermeiden können, vom Regen in die Traufe zu kommen.
Das maßgebliche Problem an Cloud-Angeboten wie IoT Core, aber auch AWS IoT Core und Azure IoT ist, dass sie meist physische Geräte der Kunden anbinden und dabei proprietäre SDKs im Gerät verwenden. Im Fall der Google Cloud Platform (GCP) können sich die Geräte ab August 2023 nicht mehr mit der Cloud verbinden, wenn die Kunden nichts unternehmen. Damit findet keine Datenübertragung mehr statt. Ein Desaster für alle Google-Cloud-Kunden, die an ihre eigenen Kunden Geräte verkauft haben, die nicht mehr funktionieren werden.
Der einzige Weg, aus der Misere herauszukommen und sich für die Zukunft aufzustellen, ist auf offene Standards zu setzen. Der Erfolg des Internets basiert auf solchen Standards wie Ethernet, TCP/IP, TLS, DNS sowie diversen Applikationsprotokollen wie HTTP, FTP und Websockets. Es ist daher verwunderlich und verantwortungslos, dass Firmen ausgerechnet für IoT-Anwendungen proprietäre Kommunikationssoftware in ihren Geräten verbauen.
Konkret bieten Hersteller wie AWS und Microsoft ihre Edge-Laufzeitumgebungen wie IoT Edge und AWS Greengrass an, damit die Kunden sie in die Hardware und damit direkt in die Wertschöpfungskette einbauen. Unter dem Deckmantel offener Standards wie MQTT suggerieren die Anbieter, dass es dabei keinen Lock-in-Effekt gäbe. Die Realität könnte jedoch nicht weiter davon entfernt sein: AWS, Microsoft und Google verwenden eine proprietäre, nicht kompatible MQTT-Version auf Basis des alten und angestaubten Standards MQTT 3, die ausschließlich mit ihren eigenen Clouds kompatibel ist und nicht das Standard-Feature-Set und die Protokollgarantien bietet. Wohlgemerkt: MQTT 5 existiert bereits seit Januar 2018. Natürlich sind die Clouds beim Datentransport untereinander nicht kompatibel, und die Device-Management-Funktionen der IoT-Produkte sind zu 100 % proprietär.
Mit dem Tod von GCP IoT Core werden nun einige Stimmen laut, die behaupten: "Mit AWS und Azure wäre das nicht passiert!". Eine ähnliche Aussage hätte man vermutlich vor einiger Zeit über Google hören können, da sich niemand vorstellen konnte, dass einer der großen drei Cloud-Spieler das Handtuch wirft. Leider halten sich Cloud-Anbieter in der Regel bedeckt, wenn es um Deprecations geht. Microsoft Azure schickt regelmäßig Dienste, APIs und SDKs in den Ruhestand und hat dafür einen eigenen Twitter-Account. Zu den beerdigten Angeboten gehört Device SDKs, also genau die Software die in der Wertschöpfungskette ihrer Kunden verbaut ist. AWS hält sich bezüglich Deprecations bedeckt. Der Branchenkenner Corey Quinn berichtet jedoch regelmäßig darüber in seinem Blog "Last Week on AWS". Unter anderem versorgt Amazon das in vielen IoT-Geräten eingebaute AWS Greengrass in Version 1 nur noch offiziell bis 2023 mit Softwareupdates.
Software auf Geräten muss auf offenen Standards und Open-Source-Software basieren. Wenn ein Anbieter dann einen Dienst wie IoT Core abschaltet, würde man den Cloud-Endpoint ändern und sich als Gerätehersteller nicht von den Entscheidungen einzelner Cloud-Produktteams abhängig machen. Für MQTT gibt es Open-Source-Broker wie Eclipse Mosquitto, HiveMQ oder das aus China finanzierte und dort hergestellte EMQX. Für Geräte bietet Eclipse Paho die Standardimplementierungen für MQTT an. Diese lassen sich – mit einigen Verrenkungen – kompatibel zu den IoT-Angeboten von AWS und Azure (und noch GCP) gestalten, auch wenn sich dabei nicht alle Features verwenden lassen. Eine große Lücke im Markt gibt es bei offenen Standards für das Device-Management. Protokolle wie LWM2M haben sich leider nicht durchgesetzt, und die Open-Source-Anwendungen sind stark fragmentiert.
Raus aus der Abhängigkeit
Getrieben von den Nachrichten vom Tod von GCP IoT Core werden zahlreiche Entwicklungsabteilungen die Themen Vendor Lock-in und proprietäre SDKs äußerst kritisch diskutieren. Wichtig ist nun, nicht vom Regen in die Traufe zu kommen. Die Abhängigkeit von Cloud-Diensten, die in die Wertschöpfungskette von Geräten hineingeht, wird zum Business Risk. Jede Entscheidung gegen offene Standards wie MQTT wird langfristige Auswirkungen auf die Wettbewerbsfähigkeit von Unternehmen haben.
Kommerzielle Garantien jenseits von Lippenbekenntnissen, dass sie bestimmte proprietäre Connectivity-Produkte für lange Zeiträume unterstützen, gibt es von offizieller Seite bei Cloud-Anbietern üblicherweise nicht. Das bedeutet nicht, dass man Cloud-Produkte verteufeln sollte – ganz im Gegenteil! Elementare Bauteile wie Compute, Network oder Storage, aber auch Techniken wie Hosted Kubernetes bringen einen klaren Wettbewerbsvorteil.
Sobald es um Connectivity der Geräte geht, zeigt der Tod von GCP IoT Core, wie riskant proprietäre Angebote sind. Wenn Google jetzt das Handtuch wirft, welche Hersteller werden in den nächsten Jahren noch folgen? Und welche Kunden wollen ihr eigenes Geschäft davon abhängig machen? Nur offene Standards sind der Weg nach vorn.
(rme)
