Einsatz von DevOps zur Bewältigung von Herausforderungen mit eingebetteter Software

DevOps gilt als der beste Weg, um die Anforderungen des Marktes für eingebettete Software nach mehr Anwendungen und neuen Funktionen zu erfüllen, die alle in kürzerer Zeit verfügbar sind.

Ein perfekter Sturm braut sich für die Entwicklung von Software für eingebettete Geräte zusammen. Eingebettete Geräte nehmen zu, insbesondere da neue Konnektivitätsoptionen wie 5G innovative Anwendungen für vernetzte Geräte ermöglichen und ihre Verwendung zunimmt, indem neue Analyse- und künstliche Intelligenzfunktionen genutzt werden. Gleichzeitig machen es die Anforderungen des Gerätelebenszyklus, wie z. B. die Reaktion auf sich entwickelnde Cyberangriffe, erforderlich, Softwareänderungen schnell zu erstellen und bereitzustellen.

Diese Bedingungen stellen neue Anforderungen an das Entwicklungs- und Betriebspersonal. DevOps gilt zunehmend als der beste Weg, um die Marktnachfrage nach mehr Anwendungen und neuen Funktionen zu erfüllen, die alle in kürzerer Zeit verfügbar sind. RTInsights hat sich kürzlich mit Graham Morphew, Senior Director of Product Management bei Wind River, zusammengesetzt. Wir haben die Herausforderungen der Softwareentwicklung für eingebettete Geräte, die Unterschiede zwischen DevOps für traditionelle Umgebungen und eingebettete Geräte und mehr diskutiert.

Hier ist eine Zusammenfassung unseres Gesprächs.

RTInsights:Wie unterscheidet sich DevOps für eingebettete Geräte von herkömmlichen DevOps-Ansätzen zur Softwareentwicklung?

Morphew: Wenn Sie sich traditionelle DevOps in einer unternehmensbasierten IT-Umgebung ansehen, haben Sie eine allgegenwärtige Ausführungsumgebung. Sie laufen entweder auf Intel-Servern in der Cloud oder Sie haben etwas, das auf einem Intel-PC läuft. Eingebettet ist ganz anders. Ihre Endausführungsumgebung hat normalerweise eine andere Architektur als die, die Sie für die Entwicklung verwenden. Aufgrund der Vielfalt der Endhardware und der Art und Weise, wie Sie sie bereitstellen, gibt es weitere Herausforderungen. Wenn Sie beispielsweise Software für eine Cloud-basierte Umgebung entwickeln, wissen Sie, dass sie in einer Google Cloud-, Azure- oder AWS-Umgebung läuft. Wenn Sie eingebettete Software erstellen, ist die Vielfalt der Wahlmöglichkeiten für die Bereitstellungsumgebung nahezu unbegrenzt, und Sie könnten auch Geräte an entfernten Standorten haben.

Es gibt also viele Unterschiede in Bezug darauf, wie Sie über die Software denken und wie sich diese Unterschiede in Herausforderungen bei der DevOps-Implementierung niederschlagen.

Sie müssen sich mit spezialisierter Hardware, Cross-Compiling, Cross-Debugging, Speicherbedarf und Sicherheitsproblemen auseinandersetzen. Sie haben nicht die nahezu unbegrenzten Ressourcen zur Hand, wie Sie es in einer Cloud-Umgebung tun würden. Es gibt eine Ausführungsinsel, die Sie beim Entwerfen dieser Systeme im Auge behalten müssen. Sie müssen sich auch um die Sicherheit kümmern. Sie haben nicht unbedingt die physische Kontrolle über die Sicherheit der Geräte. Möglicherweise müssen Sie sich mit physischer Manipulation des Geräts auseinandersetzen.

Eine weitere Herausforderung besteht darin, dass die Daten dieser Geräte schwieriger zu erfassen sind. In einer DevOps-Umgebung möchten Sie eine kontinuierliche Feedback-Schleife. Das ist einfach, wenn die Entwicklung auf Servern stattfindet, die unter Ihrer Kontrolle stehen. Wenn Sie über Geräte sprechen, werden diese wahrscheinlich remote verteilt und sind möglicherweise nicht immer online. Beim Vergleich Ihrer traditionellen DevOps und DevOps für eingebettete Software kommen also viele verschiedene Probleme ins Spiel.

RTInsights:Warum wird sich die Embedded-Device-Community in Richtung DevOps bewegen? Warum wird es überzeugend und was passiert auf den Märkten, um dies voranzutreiben?

Morphew: Bei eingebetteter Software besteht ein wachsender Bedarf an häufigeren Updates und höherer Qualität. Um dorthin zu gelangen, benötigen Sie Automatisierung, die Sie auf Ihrem Weg unterstützt. Automatisierung wird in der Zukunft von DevOps und eingebetteter Software eine große Rolle spielen. Wenn Sie ein oder zwei Jahrzehnte zurückgehen, wurde viel Wert auf die Hardware gelegt, die die Fähigkeiten des Geräts antreibt. Heute ist viel, viel mehr der differenzierenden Technologie unter den Geräteanbietern Software.

Ein weiterer Faktor, der Unternehmen zu DevOps für eingebettete Systeme drängt, ist etwas, das wir bei Wind River ziemlich oft sehen:die sich ändernde demografische Entwicklung der Softwareentwicklung.

Es gibt zwei sehr unterschiedliche Lager. Sie haben Ihre traditionellen eingebetteten Softwareentwickler und neue Absolventen oder Entwickler, die in die Domäne intelligenter Geräte aus anderen Softwaredomänen eintreten. Die traditionellen Entwickler sind in der Regel älter, und viele gehen in den Ruhestand. Wie ich gibt es Leute, die nach dem College zu einer Zeit auf den Markt kamen, als man sich Hardware-Handbücher, Programmregister und ähnliches ansah. Das ist einfach nicht etwas, womit College-Programme jetzt viel Zeit verbringen.

Ich habe einen Sohn, der jetzt im College-Alter ist. Er programmiert in Python. Er hat gerade zum ersten Mal C gelernt, und das war ein großer Augenöffner. Python bietet viel höhere Abstraktionsebenen.

DevOps kann dabei helfen, dieses Hindernis zwischen der Anwendungsumgebung und dem Wunsch zu überwinden, diese für Entwickler von Gerätesoftware wie eine vertraute Umgebung aussehen zu lassen. Dies ist erforderlich, da Unternehmen, die Geräte herstellen, Schwierigkeiten haben, neue Talente für die Softwareentwicklung zu finden.

Ich sprach mit jemandem, den wir kürzlich als Praktikanten eingestellt hatten, und er erzählte uns, dass viele seiner Klassenkameraden ins Silicon Valley gehen und für Unternehmen wie Facebook, Google, Apple und Tesla arbeiten wollen. Für Unternehmen in den Bereichen Industrie, Luft- und Raumfahrt und Verteidigung kann es eher eine Herausforderung sein, die erforderlichen Softwaretalente anzuziehen, die in eine rudimentäre C-Umgebung eingebettete Geräte programmieren würden.

Um dies zu überwinden, glauben einige Unternehmen, dass es hilfreich sein wird, dieser neuen Generation von Softwareentwicklern eine Umgebung zu bieten, mit der sie vertraut sind. Und das ist einer der Gründe, warum Wind River eine Visual Studio Code-Umgebung einführt. Visual Studio Code ist eine Umgebung, die seit ihrer Markteinführung schnell an Popularität gewonnen hat. Jeder, mit dem wir gesprochen haben, ist mit VS Code sehr vertraut, und wir sehen weniger Erfahrung des neuen Entwicklers mit älteren Umgebungen wie Eclipse. Manchmal müssen Sie also dort sein, wo Ihr Publikum bereits ist.

RTInsights:Welche Probleme haben Unternehmen, wenn sie versuchen, DevOps-Lösungen einzuführen? Und was sind die größten Herausforderungen für den Bereich der eingebetteten Geräte im Vergleich zu anderen Domänen?

Morphew: Die größte Herausforderung ist der kulturelle Wandel, der innerhalb der Unternehmen stattfinden muss. Und das ist nicht unbedingt eine Embedded-spezifische Herausforderung. Es ist in einigen Softwareentwicklungspraktiken tiefer verwurzelt.

Sie haben kleine Teams, und in vielen Fällen haben Sie Einzelpersonen, die sehr spezifische Aufgaben erledigen. Sie brauchen ein Maß an Zusammenarbeit und Zusammenarbeit mit DevOps, das Menschen manchmal aus dem Bereich herausholt, in dem sie sich seit einigen Jahren wohlfühlen. Sie müssen sagen:„Alle arbeiten zusammen.“

Der Ops-Teil von DevOps für Embedded ist eine Herausforderung, da Opsis in einer traditionellen DevOps-Umgebung für die Cloud ziemlich Standard ist. Sie betreiben eine Website oder entwickeln eine Anwendung, die etwas über eine Cloud-basierte Schnittstelle tut. Wenn Sie von Embedded sprechen, sprechen Sie von einem Gerät im Feld, und was dieses Gerät tut, ist spezifisch für Ihr Unternehmen. In vielen Fällen sind die Gerätehersteller nicht die Unternehmen, die die Geräte betreiben. Ein Gerätehersteller kann sein Gerät an ein großes Elektrounternehmen oder einen großen Hersteller verkaufen. Diese Unternehmen betreiben die Geräte. Manchmal gibt es Unterstützung vom Gerätehersteller, aber es ist kein vollständig geschlossener Kreislauf, wie Sie ihn vielleicht bei einer Cloud-basierten Lösung sehen.

Es gibt Kompatibilitätsprobleme mit Toolsets. Eine gemeinsame Entwicklungsumgebung zu haben, stößt manchmal auf Widerstand. Damit kommen wir auf die kulturelle und verwaltungstechnische Unterstützung zurück, die Sie benötigen, um diese Systeme zu implementieren.

Und dann ist da noch einmal das Hardware-Problem. Es ist ein allgemeines Thema auf dem Embedded-Markt. Wie erhalten Sie genügend Hardware, um die Automatisierungsumgebungen aufzubauen, die für die Realisierung von DevOps erforderlich sind? Das ist eine ständige Herausforderung. Typischerweise verfügen erfolgreiche Kunden über eine Mischung aus Hardware und Simulation, um ihre Testprozesse zu skalieren.

RTInsights:Gibt es Tools, die den Übergang zu DevOps erleichtern würden?

Morphew: Eine Sache, die Unternehmen dabei hilft, diese Revolution zu überstehen, ist die Verfügbarkeit von Tools. Viele dieser Tools sind Open Source oder haben kostenlose Versionen. Was Sie oft sehen würden, war eine Konsolidierung rund um eine Art Source Code Management, oft eine Art Git. Inzwischen sind Organisationen von einer sehr stark auf Source Code Management ausgerichteten Lösung dazu übergegangen, immer mehr DevOps-Tools in ihre Lösungen aufzunehmen. Das hilft Unternehmen bei der Umstellung.

Es gibt viel Auswahl. Sie könnten argumentieren, dass es manchmal zu viel Auswahl gibt. Die Herausforderung, vor der unsere Kunden jetzt stehen, ist, ja, es gibt viele Tools. Wie bringe ich sie zu einer Lösung zusammen, die für mich funktioniert?

Heutzutage starten viele Unternehmen Projekte, in denen sie intern Teams bilden, um den Übergang zu einer stärker digital ausgerichteten Entwicklungsumgebung zu bewältigen. Wir sehen jetzt einen Übergang im Embedded-Bereich, wie wir ihn bei anderen technologischen Übergängen gesehen haben. In vielen Fällen ist es sehr viel eine Do-it-yourself-Mentalität von:„Lasst uns das perfekte System für uns bauen, lasst es uns an unsere Bedürfnisse anpassen.“ Solche Bemühungen entziehen dem Unternehmen immer mehr Ressourcen, nur um diese Dinge in Zukunft aufrechtzuerhalten. Dort wollen sie nicht unbedingt investieren. Dieser Ansatz wird sich wahrscheinlich dahin entwickeln, dass Menschen im Laufe der Zeit mehr von ihrer Umgebung durch ein anderes Unternehmen pflegen lassen möchten.

Ein weiterer Bereich, in dem sich Unternehmen letztendlich das Leben erleichtern können, ist eine klare Trennung zwischen der Anwendungsentwicklung und der Wartung der Softwareplattformen, auf denen sie laufen. Früher hatten Sie ein kleines Team, das beides erledigte, und die Anwendung und die Plattform verschmolzen miteinander. Aber jetzt brauchen Sie diese klare Trennung, um Ihre Software zu modularisieren und Leute an dem arbeiten zu lassen, wofür sie die besten Fähigkeiten haben.

RTInsights:Was sind die Branchentreiber für Lösungen, die das Entwickeln und Testen von Software für eingebettete Geräte vereinfachen?

Morphew :Es gibt die Konvergenz der IT- und OT-Welt. Sie haben Geräte mit dem Internet verbunden. Dies war ein großer Antrieb für Unternehmen, die Art und Weise, wie sie Software bereitstellen, zu überprüfen. Außerdem gibt es mehrere Branchen, in denen Sie Compliance-bezogene Anforderungen haben, um die Software in Geräten zu aktualisieren. Das sieht man im medizinischen Bereich, wo man jetzt nachweisen muss, dass man sein Gerät updaten kann, wenn eine Sicherheitslücke bekannt wird. Dies kann ein Szenario auf Leben und Tod sein. Sie müssen nachweisen können, dass Sie ein solches Problem lösen können, wenn eines auftritt.

Solche Treiber drängen Unternehmen dazu, sich die Prozesse anzusehen, die sie im Hinblick auf ihre Fähigkeit zur Durchführung von Remote-Updates verwenden. Was wir sehen, ist, dass viele größere Unternehmen die Bedrohung durch diese digital-nativen neuen und aufstrebenden Unternehmen spüren. Es gibt sogar Begriffe, die sie verwenden, um es zu beschreiben. Sie hören den Begriff Teslafizierung. Sie sagen, dass sie mehr wie Tesla sein und ein sehr, sehr softwareorientiertes Unternehmen sein müssen, im Gegensatz zu Backstein- und Mörtel-, Stahl- und Eisen-Denken, die mehr mit Hardware in Verbindung gebracht werden. Sie müssen ihr Produkt immer mehr durch die Software differenzieren, die auf den Dingen läuft, die sie bauen.

Die Pandemie hat diesen Trend zusätzlich beschleunigt. Die meisten softwareorientierten Mitarbeiter arbeiten von zu Hause aus. Und in vielen Fällen wird eine beträchtliche Anzahl von Mitarbeitern danach nicht mehr ins Büro zurückkehren. Das ist eine große Umstellung. Sie müssen also die Art und Weise ändern, wie Jugendliche über die Arbeit denken, um diese Situation für Entwickler produktiv zu machen. Das ist eine Herausforderung. Es schreit bis zu einem gewissen Grad nach mehr Collaboration-Tools und mehr Standardisierung in Bezug darauf, wie Dinge erledigt werden, weil es nicht viele Leute gibt, die von Angesicht zu Angesicht arbeiten und auf traditionellere Weise zusammenarbeiten.

RTInsights:Kommen wir zu einem anderen Thema:Warum sind schnelle Software-Iterationen in jeder Branche zu einem entscheidenden Wettbewerbsvorteil geworden? Und wie hängt das mit der Notwendigkeit automatisierter Tests zusammen?

Morphew: Ich habe mehrere Projekte durchlaufen, die von einem Wasserfallmodell zu einem agileren Modell übergegangen sind. Diese Fähigkeit, kontinuierliche Tests und automatisierte Tests durchzuführen, ist oft der limitierende Faktor in Bezug auf die Steigerung Ihrer Produktivität. Wenn Sie schnell laufen und trotzdem Ihre Qualität beibehalten möchten, ist dies eine Notwendigkeit. Dies ist ein besonderer Bereich, in dem Sie mit einem digitalen Zwilling Ihres Endgeräts viele Tests darauf durchführen können, und Sie können dies in großem Maßstab tun.

Eine der großen Neuerungen, die wir in Bezug auf die Anwendbarkeit von DevOps auf Embedded sehen, ist die Möglichkeit, eine Simulation des Embedded-Geräts zu nehmen und es dann in großem Maßstab in einer Cloud-basierten Umgebung zu verwenden. Auf diese Weise können Sie hundert Tests gleichzeitig ausführen. Sie sind nur durch Cloud-Ressourcen begrenzt. Das ist eine der Transformationen, die wir bei einer Reihe von Unternehmen erleben, und etwas, das sie letztendlich sehr schätzen.

Wir betreiben seit vielen Jahren ein Simulationsgeschäft bei WindRiver. Einige der Early Adopters haben viel davon auf ihren Servern durchgeführt und eine große Anzahl von Simulationen hochskaliert. Aber wenn Sie es in die Cloud verschieben, müssen Sie nicht alle sechs Monate neue Server kaufen.

Sie haben die Kontrolle über die Art der von Ihnen verwendeten Hardware und deren Menge. Sie können es hoch- und runterwählen, je nachdem, was Sie gerade benötigen, anstatt die Kapitalausgaben großer Hardware- und IT-Teams für die Wartung aufwenden zu müssen. Im Moment sehen wir eine ausgewogene oder eine Art hybride Cloud-Umgebung, in der ein Teil der Tests lokal vor Ort und ein Teil in einer öffentlichen Cloud durchgeführt wird.

RTInsights:Gibt es noch andere Punkte, die Sie ansprechen möchten, die wir ausgelassen haben?

Morphew: Wenn Sie über DevOps und die Verlagerung der Entwicklung eingebetteter Software in eine Cloud-nativere, Cloud-fokussierte Umgebung sprechen, gibt es mehrere Dinge, die ich persönlich als Produktmanager gesehen habe und die große Veränderungen darstellen.

Einer davon ist die Zusammenarbeit. Ich habe versucht, einen Linux-Build fertigzustellen. Ich bin kein bewährter Linux-Ingenieur. Ich hatte einige Probleme damit, einen Build richtig zum Laufen zu bringen. Und während ich das tat, konnte einer unserer Linux-Softwarearchitekten sehen, dass ich mehrere fehlgeschlagene Builds hatte. Und er kontaktierte mich über eine Instant-Messaging-App und sagte:„Hey, ich habe gesehen, dass Sie Probleme haben, ich habe nachgesehen, und Sie müssen nur die Einstellung ändern, und Sie werden gut sein. Und ich habe einfach weitergemacht und es für Sie repariert.“

Wenn ich in einer anderen Umgebung entwickeln würde, in der ich Software auf meinem PC installiert hätte, würde niemand jemals wissen, dass ich Probleme habe. Ich müsste rausgehen und fragen. Außerdem wäre ich höchstwahrscheinlich nicht in der Lage, dasselbe Szenario nachzubilden. Höchstwahrscheinlich wäre ich den ganzen Tag daran hängengeblieben. Und vielleicht habe ich nach einer Weile einfach aufgegeben. Die Möglichkeit, schnell auf Software zuzugreifen, die Sie nicht lokal installieren müssen, und in einer gemeinsamen Sandbox spielen zu können, war für mich ein großer Augenöffner dafür, wie diese Änderung zeigt, wie Sie arbeiten, nur weil Sie im Wesentlichen diese Art von Software haben von gemeinsam genutzten Vermögenswerten in Ihrem Team.

RTInsights:Sonst noch etwas?

Morphew: Die eine Sache, auf die wir uns in nicht allzu ferner Zukunft freuen, sind digitale Feedback-Schleifen, bei denen Sie Daten vom Gerät nehmen, Daten aus Ihrer Entwicklungsumgebung entnehmen und diese zurückgeben, um Ihre Software zu verbessern. KI und maschinelles Lernen spielen ebenfalls eine Rolle. Welche Art von Informationen kann ich von diesen Geräten erhalten? Wie kann ich es potenziell mit einem großen Cloud-Scale-Big-Data-Typ eines Modells oder einer Engine analysieren und das dann in die zukünftige Softwareentwicklung einspeisen? Das könnte mir helfen, ein System als Ganzes zu optimieren.