Wie DevOps die Entwicklung von IoT-Lösungen schneller und agiler macht

In den vergangenen Jahren sind das Interesse und die Investitionen im Bereich Internet of Things (IoT) stark gewachsen. Das Aufkommen neuer, leistungsfähiger Mikrocontroller, teilweise mit eingebauter WLAN- oder Bluetooth-Funktionalität, zusammen mit neuen Frameworks und Tools erleichtern die Entwicklung von vernetzten Geräten. Hierdurch haben auch kleine Teams die Möglichkeit, schnell eigene Geräte zu entwickeln.

Um den besten Nutzen aus diesen neuen Entwicklungen zu ziehen, reicht es aber nicht aus, nur die neueste Hardware zu verwenden. Auch die Teamstrukturen und die Teamzusammensetzung müssen den neuen Gegebenheiten angepasst werden.

Was ist bei IoT anders als bei einer normalen Webanwendung?

Auch wenn inzwischen viele bekannte Firmen eine IoT Platform anbieten, gibt es bisher noch sehr wenig Erfahrungswerte für die Entwicklung von vernetzen Geräten. Im Gegensatz zur Entwicklung von Webanwendungen oder Mobile Apps, gibt es nicht den Technologie-Stack, den man als “Standard” oder “erprobt” bezeichnen könnte.

Stattdessen müssen immer wieder Abwägungen zwischen, auf den ersten Blick, gleichwertigen Alternativen getroffen werden. Sollte MQTT, CoAP oder HTTP2 zur Kommunikation verwendet werden? Bluetooth oder WiFi? Protocol Buffers, MessagePack oder doch einfaches JSON?

Viele dieser Fragen lassen sich durch Erfahrungen aus anderen Projekten beantworten, andere durch eine sorgfältige Analyse der verschiedenen Optionen. Aber in einigen Fällen ist ein direktes Ausprobieren die einfachste und schnellste Lösung.

Wie kann DevOps hier helfen?

Bei diesen Entscheidungen ist ein nach dem DevOps-Prinzip organisiertes Team gut aufgestellt. Schon bevor es an das Ausprobieren möglicher Lösungen geht, ist es hilfreich, auch die Kompetenzen aus anderen Bereichen im Team zu haben. Wichtige Fragen zu Ausfallsicherheit, Wartbarkeit, Persistenz und anderen eher administrativen Bereichen könnten sonst übersehen werden und erst nach dem Start zu Problemen und höheren Kosten führen.

Aber insbesondere, wenn es an das tatsächliche Ausprobieren der Optionen geht, wird ein Team, das selbst in der Lage ist, seine Infrastruktur nach Belieben anzupassen, erheblich schneller sein als ein Team, welches sich für jeden Test mit einer anderen Abteilung koordinieren muss. Neben dem direkten Starten und Ausprobieren unterschiedlicher Software lassen sich mit modernen Tools und Cloud-Anbietern zum Beispiel auch leicht einige tausende Instanzen starten, um einen Lasttest gegen die verschiedenen Testkandidaten durchzuführen.

Der DevOps-Ansatz lässt sich auch auf das andere Ende des Software Stacks anwenden. Oft wird die tatsächliche Hardwarekomponente nicht vom gleichen Team entwickelt, das die Software schreibt. Idealerweise sollte es trotzdem eine sehr enge Zusammenarbeit zwischen den Hard- und Softwareentwicklern geben. Falls es getrennte Teams gibt, kann es auch hilfreich sein, Entwickler mit Hardwareerfahrung im Softwareteam zu haben.

IoT auf agile Art

Grundsätzlich ist es eher schwierig, ein IoT-Projekt auf eine agile Art zu entwickeln. Die Tatsache, dass die Hardware physisch produziert werden muss, macht einen iterativen Ansatz in kleinen Schritten sehr schwer. Die Realität der aufwendigen Zertifizierungsprozesse, Produktionsabläufe und die Kosten kleiner Prototypenfertigung verleiten schnell dazu, bei der Planung auf ein Wasserfallmodell zurückzuverfallen und nur sehr spät im Projektablauf die ersten Prototypen der Hardware zu produzieren.

Um trotzdem früh ein testbares Produkt zu erlangen und seine eigenen Annahmen in der Realität zu testen, sollte man möglichst schnell eigene, kleine Prototypen und Dummy-Geräte bauen. Um die Bedienungsoberfläche zu testen, reicht ein Dummy aus Holz oder Styropor. Um die endgültige Geschwindigkeit und den Energieverbrauch grob abschätzen zu können, kann man fertige Evaluation-Boards der verschiedenen Chip-Hersteller nutzen. Nach dem gleichen Prinzip gibt es auch Testboards für Sensoren, verschiedene Vernetzungsmöglichkeiten und Displayarten.

Um allerdings in der Lage zu sein, alle diese Möglichkeiten zu nutzen, braucht man ein Team mit vielschichtigen Fähigkeiten. Im idealen Fall ein Team, welches gleichermaßen in der Lage ist, einen Styropor-Dummy zu formen, ein Sortiment von Evaluations-Boards zu vernetzen und einen neuen Backend-Server zu programmieren und zu provisionieren.

IoT-Projekte brauchen andere Strukturen

Die DevOps-Bewegung ist daraus entstanden, dass sich in traditionellen Strukturen meistens unterschiedliche Abteilungen um die Entwicklung der Software und um das Betreiben der Server kümmern. In einigen traditionell gewachsenen Unternehmen gibt es oft auch mehrere Abteilungen, die im Bereich der Softwareentwicklung arbeiten. Oft sind diese Abteilungen als Teil eines anderen Fachbereichs entstanden. Zum Beispiel als Teil der Finanzabteilung, weil die Kostenabrechnung als erstes digitalisiert wurde. Oder als Teil des Marketings, weil die Website das erste große Projekt war.

Gerade in Unternehmen, die elektronische Geräte herstellen, gibt es oft Mitarbeiter mit IT-Kompetenzen in Elektronik oder Mechanik, die sich sehr gut mit der Entwicklung auf Mikrocontroller-Ebene auskennen. Es erscheint nur logisch, dass immer komplexer werdende elektronische Systeme zur Entstehung von IT-Abteilungen im Hardwarebereich führen.

Oft sind diese Abteilungen aber komplett abgetrennt von einem anderen Bereich, der sich um die Entwicklung von Webanwendungen kümmert (zum Beispiel in der Marketing- oder Finanzabteilung). Diese beiden Bereiche haben auf den ersten Blick nicht besonders viel gemeinsam und können friedlich koexistieren. Die Hardware-nahen Entwickler schütteln vielleicht immer mal wieder den Kopf über diese Webentwickler, die selbst für die kleinsten Anwendungen hunderte MByte an RAM brauchen, oder scheinbar alle zwei Monate ein neues Javascript Framework ausprobieren wollen.

Auf der anderen Seite können die Webentwickler nicht verstehen, wieso jemand im Jahr 2017 noch seinen eigenen JSON Parser oder HTTP-Server schreibt. Aber in ihrem normalen Tagesablauf gibt es zwischen den beiden Seiten wenig Berührungspunkte.

Bei einem IoT-Projekt jedoch müssen beide Seiten eingebunden werden. Oft muss eine relativ schwache Hardwarekomponente mit einer webbasierten Infrastruktur oder mobilen Apps verbunden werden. Wird das Projekt lediglich von einem der beiden Bereiche umgesetzt, ignoriert man wertvolle Erfahrungen und Fähigkeiten aus dem anderen Bereich.

Wenn beide Teams getrennt in ihren eigenen Strukturen weiterarbeiten, wird es unvermeidlich zu Missverständnissen und suboptimalen Lösungen kommen. Dadurch, dass jedes Team seine eigenen Prioritäten, Planung und Probleme hat, kommt es schnell dazu, dass gerade kleine Probleme zwischen beiden Teams hin- und hergeschoben werden, anstatt dass sie gemeinsam das Problem analysieren und eine Lösung dafür suchen.

Aus diesem Grund sollte – soweit möglich – immer ein gemeinsames Team die Verantwortung für alle relevanten Aspekte des Projektes haben, um selbständig alle notwendigen Entscheidungen treffen und umsetzen zu können. Egal ob es um das Datenaustauschformat zwischen Gerät und Backend geht, oder um das Provisionieren neuer Infrastruktur. Diese enge Zusammenarbeit ist ein wichtiger Erfolgsfaktor für IoT-Projekte.

Über den Autor

Philip Peter ist Senior Infrastructure & DevOps Consultant bei ThoughtWorks, einer weltweit tätigen IT-Beratung. Das Unternehmen hat seinen Hauptsitz in Chicago (USA) und beschäftigt über 4500 Mitarbeiter in 42 Büros in 15 Ländern. In Deutschland ist es mit Standorten in Hamburg, Köln, Berlin und München vertreten.