3 Dinge, die das Netzwerk für IoT bereitstellen muss

Das Internet der Dinge (IoT) ist weiterhin ein interessantes Thema. Und während es in der Regel um verbraucherorientierte Gadgets und Gizmos geht, die Schlagzeilen machen, sind es die Vorbereitungen hinter den Kulissen in den Rechenzentren, die von den Early Adopters durchgeführt werden, die für mich noch faszinierender sind.

Wahrscheinlich, weil die Unterstützung eines groß angelegten IoT-Projekts eine Menge Arbeit erfordert. Und so etwas wie eine IoT-Einführung im kleinen Maßstab gibt es eigentlich nicht, wenn das „Ding“ auf Verbraucher ausgerichtet ist. Denn falls Sie es noch nicht bemerkt haben: Es gibt da draußen eine Menge Verbraucher. Und sie stehen auf das Glänzende.

Vor diesem Hintergrund tut sich derzeit in der gesamten Technologiebranche eine Menge, um diejenigen zu unterstützen, die das IoT in bestehende Angebote (Autos, Haushaltsgeräte, Spielzeuge) integrieren, sowie diejenigen, die hoffen, mit brandneuen Dingen, von denen Sie nicht wussten, dass Sie sie brauchen, der nächste große Star zu werden, bis Sie sie hatten.

Wirklich. Während der Staat die Branchen, die IoT-Produkte einkaufen (laut unserem State of Application Delivery 2016), dominiert, sind die Anbieter von Telekommunikation, Technologie und Cloud-Diensten nicht weit dahinter. Tatsächlich war in allen Branchen in den vergangenen zwölf Monaten die Kaufquote recht gut, was darauf schließen lässt, dass im Bereich IoT viel mehr gearbeitet wird, als es den Anschein macht, wenn man nur den Verbraucherbereich betrachtet. 

Vieles von dem, was passiert, findet in der Infrastruktur statt; im Netzwerk, das Konnektivität und sofortige Reaktion der Anwendungen im Backend bereitstellt, die die süßen kleinen Chips, die in den Lieblingsteddybär Ihres Kindes eingebettet sind, verwalten, messen, überwachen, sichern und mit ihnen interagieren.

Wie bei jeder App oder jedem Client (denn genau das sind diese Remote-Dinge: Clients) gibt es einen grundlegenden Satz von Diensten, die sie benötigen, um konsistent, vorhersehbar und zuverlässig zu funktionieren. Sie benötigen nämlich Dienste, die Sicherheit, Bereitstellung und Transparenz ermöglichen.

Sicherheit

Bei neuen Technologien konzentrieren wir uns meist zuletzt auf die Sicherheit. Deshalb werde ich damit beginnen, denn selbst bei so jungen Technologien wie dem IoT erregen Sicherheitslücken heutzutage meist die meiste Aufmerksamkeit.

Dinge müssen mit Back-End-Apps kommunizieren. Egal, ob es darum geht, Daten zu speichern, Updates oder Patches abzurufen oder Konfigurationen zu ändern, die Dinge müssen – sicher – mit Back-End-Apps kommunizieren. Das bedeutet sichere Tunnelunterstützung über SSL oder TLS. Dies bedeutet, dass Sie sicheres HTTP und keinen Klartext verwenden und dass Sie keine Schlüssel in Ihren Dingen fest codieren. Das meine ich ernst. Tu es nicht.  

Sicherheit bedeutet auch Identitätsüberprüfung. Ja, ich weiß, dass das Ding ein Auto ist, aber *wessen* Auto ist es? Wir benötigen Dienste, die Dinge schnell und präzise identifizieren und sie ihren autorisierten Benutzern und Eigentümern zuordnen können, um die Möglichkeit zu verringern, dass mein Nachbar beschließt, mein Radio auf etwas anderes als einen Heavy-Metal-Sender einzustellen. Der Horror!

Sicherheit bedeutet schließlich auch Protokollanalyse. Dies ist insbesondere im Hinblick auf die neuen Protokolle wichtig, deren Standardisierung im gesamten IoT-Universum in Erwägung gezogen wird. Protokollunsicherheiten können ein erhebliches Risiko darstellen (Sie erinnern sich vielleicht an Heartbleed) und sind in der Regel schwierig zeitnah zu beheben. Durch die Fähigkeit, einen potenziellen Missbrauch von Protokollen zu erkennen, können Risiken bereits im Vorfeld eingedämmt werden.

Lieferung

Transaktionale und andere Daten müssen an Dinge und Back-End-Apps übermittelt werden. Dabei handelt es sich nicht immer nur darum, ein paar JSON-codierte Bits irgendwo in eine REST-API zu schieben. Viele Dinge sprechen die neuen Sprachen des IoT: MQTT, CoAP und AQMP. Aber ihre jeweiligen Back-End-Apps? Sie Sprechen Sie REST, da sie auch Web- und mobilen App-Zugriff auf dieselben Funktionen und Informationen ermöglichen. Das bedeutet letztendlich, dass sich irgendwo im Übermittlungspfad ein Gateway befindet; ein Übersetzer; ein Vermittler, der für die Protokollinteroperabilität sorgt.

Dadurch kann das Ding in Ihrem Auto Daten oder Nachrichten über MQTT senden, die von der Back-End-App verstanden werden können, die REST spricht. Der Vermittler fängt die Daten ab und übersetzt (sicher), um eine nahtlose Konversation zwischen Ihrem Ding und seinen Apps zu ermöglichen. Stellen Sie sich den Vermittler wie C3PO vor und Ihr Auto (oder ein anderes Objekt) ist R2D2. Dies bedeutet native Protokollunterstützung sowie einen softwaredefinierten Ansatz, der eine Skriptplattform bietet, über die schnell Unterstützung für andere Protokolle entwickelt werden kann. Datenpfad-Skripting ist eine der drei Hauptkomponenten der Netzwerkprogrammierbarkeit, wird jedoch am wenigsten erwähnt. Wenn es um IoT und die Unterstützung einer wahrscheinlich großen Vielfalt an Protokollen und Sprachen geht, wird die Flexibilität, die diese oft unbesungene Fähigkeit bietet, von unschätzbarem Wert sein.

Ich habe bereits zuvor den Maßstab als zu berücksichtigenden Aspekt erwähnt und wir sehen, dass diese Anforderung hier bei der Lieferung unterstützt wird. Um beispielsweise die Unterstützung für eine Million Dinge zu skalieren, werden Sie wahrscheinlich eine auf Zerlegung basierende App-Architektur verwenden. Vielleicht keine vollwertigen Microservices, aber Sie werden wahrscheinlich zumindest Funktionsbereiche trennen, um die Skalierung verschiedener Funktionen mit einer effizienteren (und kostengünstigeren) Methodik zu ermöglichen.

Hier kommt so etwas wie ein nachrichtenbasierter Lastenausgleich ins Spiel. Sie erinnern sich vielleicht an dieses Konzept, das im Dienstanbieterbereich im Zusammenhang mit Protokollen wie Diameter und SIP erwähnt wurde, bei denen die Wirksamkeit und Kosteneffizienz der Skalierung von entscheidender Bedeutung ist.

Nachrichtenbasierter Lastausgleich ist wichtig, da Protokolle wie MQTT auf Nachrichten basieren. Es handelt sich dabei um ein Pub-Sub-Modell (Publish-Subscribe), das der nachrichtenbasierten Middleware, von der man vielleicht schon gehört hat, dass sie tief in Unternehmen existiert, nicht unähnlich ist. Wie dem auch sei, sie basieren auf Nachrichten, und diese Nachrichten müssen analysiert und an den entsprechenden Dienst oder das entsprechende Gerät gesendet werden. Um dies zu erreichen und zu skalieren, muss der Lastausgleichsdienst in der Lage sein, die Nachricht zu analysieren und zu bestimmen, wohin sie gesendet werden soll, und anschließend eine geeignete Ressource für die Verarbeitung auszuwählen.

Das ist bei weitem nicht so einfach, wie es klingt, da einfache Load Balancer nur über begrenzte Möglichkeiten zur Anwendungsanalyse verfügen.  Es wird jedoch eine Voraussetzung sein, die Skalierung der von IoT-Geräten bevorzugten Protokolle zu unterstützen.

Sichtweite

Schließlich muss die Infrastruktur die Sichtbarkeit unterstützen. Das bedeutet, dass man erkennen kann, was vor sich geht. Erst durch die Transparenz sicherer Transaktionen (SSL-Prüfung) kann die Sicherheitsabteilung Maßnahmen ergreifen und böswillige Akteure identifizieren. Die Transparenz der Nutzungsmuster kann eine automatische Skalierung der entsprechenden Dienste ermöglichen.

Bei der Sichtbarkeit geht es nicht nur um „Big Data“, die eine robuste Betriebsanalyse liefern, sondern auch um Berichterstellung und Protokollierung. Die Fehlerbehebung wird in diesen komplexen Architekturen wirklich knifflig und die Protokollierung wird für Tools und Personen gleichermaßen von entscheidender Bedeutung sein, um das Problem aufzuspüren. 

Bei der Skalierung und Unterstützung des IoT geht es nicht nur um die Geräte. Es gibt viel zu tun im Netzwerk, in der Infrastruktur und in den betrieblichen Rahmenbedingungen, die zur Unterstützung erforderlich sind. Die gute Nachricht: Wenn Sie zu den Leuten gehören, die an den (sehr wichtigen) Back-End-Architekturen arbeiten, die für die Unterstützung einiger cooler Gadgets sorgen, können Sie immer argumentieren, dass Sie eins (oder drei) zum Testen benötigen.