Suchen

Expertenbeitrag

 Rostislav Markov

Rostislav Markov

Senior Consultant , Amazon Web Services

Serie: Konzeption & Aufbau einer IIoT-Lösung Hohes Bereitstellungstempo schon im Lösungsdesign verankern

Autor / Redakteur: Rostislav Markov und Kathleen deValk* / Sebastian Human

Diese wöchentliche Serie beschäftigt sich mit der Entwicklung einer erfolgreichen IIoT-Plattform. Der fünfte Teil widmet sich wichtigen strategischen Fragen, die sich rund um das Thema stellen.

Firmen zum Thema

Ein hohes Bereitstellungstempo bei der Entwicklung einer IIoT-Plattform hat viele Vorteile, bedingt aber auch einige taktische Überlegungen im Vorfeld.
Ein hohes Bereitstellungstempo bei der Entwicklung einer IIoT-Plattform hat viele Vorteile, bedingt aber auch einige taktische Überlegungen im Vorfeld.
(Bild: gemeinfrei / Unsplash)

Flexible Entwicklungs- und Bereitstellungszyklen sind der Schlüssel zum Erfolg für jedes IIoT-Projekt. Dabei empfiehlt es sich, kleinere Teams für die einzelnen Mikroservices zu bilden. Starke Abhängigkeiten zwischen den verschiedenen Mikroservices sollten vermieden werden.

Unabhängig agierende Entwicklerteams

Die inhaltliche Ausrichtung der Entwickler- und Bereitstellungsteams entlang der geplanten Mikroservices schafft ideale Voraussetzungen auch für die funktionale Entkopplung der Mikroservices. DevOps sollte als eine Strategie für alle Teams etabliert werden und es muss sichergestellt sein, dass jedes Team über die notwendigen Prozesse und Werkzeuge verfügt, um häufig, schnell und unabhängig Dienste bereitstellen zu können. Im Kleinen fällt es Teams meist leicht, unabhängig zu agieren. Mit zunehmender Plattformgröße wächst jedoch die Komplexität: Je mehr Dienstleistungen und Produkte eine Plattform anbietet, desto wichtiger wird es, die Unabhängigkeit der zugehörigen APIs sicherzustellen.

Monolithisch versus vollständig verteilt

Sofern zwei oder mehrere Teams am selben Themenbereich arbeiten, sollte ein möglichst direkter Austausch untereinander sichergestellt sein. Auf globaler Ebene stellen unterschiedliche Zeitzonen dabei oftmals eine große Herausforderung dar, weil für die Zusammenarbeit im Team dann häufig nur ein schmales Zeitfenster zur Verfügung steht. In solchen Situationen ist eine ausgewogene Balance zwischen dem gleichsam monolithischen und einem vollständig verteilten Team- und Kooperationsmodell von entscheidender Bedeutung. Ohne die richtige Balance droht entweder Mehrfachaufwand, oder der starre Monolith bremst die Entwicklung und Servicebereitstellung aus.

Erfolgskritisch ist demnach eine gut durchdachte Servicestruktur. Nutzt man die AWS-Lösung, kann deren Well-Architected-Framework dabei hilfreich sein: Hier bieten sich mehrere Möglichkeiten, um die Microservices verschiedener Teams gemeinsam nutzen zu können oder gezielt voneinander zu trennen. So lässt sich beispielsweise festlegen, wann Teams auf demselben Cluster, mit derselben Virtual Private Cloud oder demselben Konto agieren können. Generell begünstigt eine getrennte Arbeitsweise die Serviceunabhängigkeit und sorgt für eine höhere Fehlertoleranz.

Teamübergreifende Mindeststandards etablieren

Ein gemeinsamer Werkzeugkasten für die Entwicklung, die Kommunikation und die Zusammenarbeit befähigt Teams, effizient zu arbeiten. So helfen zum Beispiel gemeinsame Entwurfsmuster dabei, Best Practices auch in global agierenden Teams auf einfache Weise durchzusetzen. Hilfreich ist die verbindliche Festlegung von Mindeststandards für Entwicklungszyklen sowie die verwendeten Werkzeuge, Design-Frameworks und Architekturmuster.

Wichtig sind außerdem plattformweite Zertifizierungsprozesse für Betriebssystem-Images sowie für Patches und andere Wartungsaufgaben. Ein Mechanismus dafür wäre ein sogenanntes Artefakt mit gepatchten Images: Das Artefakt stellt hierbei eine zentralisierte Open-Source-Bibliothek zur Verfügung, sodass sich die einzelnen Teams nicht mehr mit der Pflege und Weiterentwicklung eigener Bibliotheken aufhalten müssen.

Bereitstellungszustand überwachen und optimieren

Schon vor der Veröffentlichung der ersten Version des Dienstes sollte eine detaillierte Bereitstellungsmetrik vorliegen. Wichtig ist dabei die manuelle Überwachung solcher Metriken am Anfang: Je häufiger eine neue Version bereitgestellt wird, desto tiefer wird das Verständnis für den Bereitstellungszustand im Team. Mit zunehmender Erfahrung lassen sich dann etliche Aktionen automatisieren – wie etwa das Zurückspielen auf eine Vorversion unter Beachtung bestimmter Parameter. Sehr zu empfehlen ist dabei die Verwendung von synthetischem Datenverkehr, um den Zustand aller Mikroservices über den kompletten Release-Zyklus hinweg zu überwachen.

Neben standardisierten Prozessen für Test- und Bereitstellungsroutinen brauchen erfolgreiche Teams auch ausreichend Freiraum für Experimente und die Fähigkeit zu spontaner Reaktion. Eine Möglichkeit, Neues auszuprobieren, bieten beispielsweise Accounts, bei denen die Ressourcen nach Verwendung automatisiert gelöscht werden sowie zeitbasierte Sandboxes.

Wie der Zufall Testfähigkeiten stärkt

Gerade wenn es um Standardverfahren geht, sind Testroutinen hilfreich. Ein solcher Schritt trainiert allerdings nicht den Umgang mit Unbekanntem. Um beispielsweise herauszufinden, wo sich Fehlerursachen und Engpässe eines Systems verbergen, kann es sinnvoll sein, unterschiedliche Workloads mit verschiedener Frequenz einzuspeisen und Instanzen zufällig abzuschalten. Im Rahmen von Chaostagen kann eine Gruppe von Entwicklern außerdem versuchen, das System an die Belastungsgrenzen zu treiben, während ein anderes Team genau das zu verhindern versucht. Im Gegensatz zu einem weitverbreiteten Missverständnis stellen solche Testformate die traditionellen Verfahren der Qualitätssicherung keineswegs in Frage: Ein gewisses Maß an Zufälligkeit in den Prozessen fördert vielmehr das Verständnis für das Verhalten komplexer Systeme. Außerdem trainiert es die Fähigkeit, Störungsursachen auch unter ungewöhnlichen Umständen schnell zu erkennen und zielgerichtet zu beheben.

Im nächsten Teil der Serie geht es um die Aspekte Multi-Regionen- und Mehrmandanten-Fähigkeit. Beide Punkte sind wichtig, um eine IIoT-Plattform global und für viele verschiedene Kunden erfolgreich anzubieten.

* Kathleen deValk arbeitet als Chief Architect Siemens MindSphere.

(ID:46395339)

Über den Autor

 Rostislav Markov

Rostislav Markov

Senior Consultant , Amazon Web Services