Microsoft IoT Strategie 2023

Auch dieses Jahr durften wir Martin Grossen von AVNET Silica am Microsoft Embedded / IoT Seminar bei uns willkommen heissen. Martin Grossen ist Spezialist für Microsoft Windows IoT und weiss als Microsoft MVP über die neusten Entwicklungen aus Redmond bestens Bescheid. Seine Präsentation war äusserst informativ und bot den Teilnehmern wertvolle Einblicke in die neuesten Trends und Strategien von Microsoft.

Microsoft Strategie

Der Fokus liegt bei Microsoft ganz klar im Bereich der künstlichen Intelligenz (AI). Für alle möglichen Tätigkeiten werden AI-getriebene Tools entwickelt, sogenannte Copilots. Nebst dem Copilot for Code (Github Copilot) sind unter anderem auch Copilots für Security, Produktivität, Sales, Analysis und viele mehr in Entwicklung. Durch diesen Fokus auf das momentan sehr lukrative Geschäft mit den AI-Assistenten wurden auch Ressourcen aus wenig profitablen Sparten abgezogen, dies hatte auch eine Verschlankung des IoT-Teams bei Microsoft nach sich gezogen.

Azure IoT Operations

Die aktuelle IoT Infrastruktur bestehend aus IoTHub und IoTCentral ist nicht für grosse Datenströme gedacht und nur schwer in die neuen AI Lösungen integrierbar. Die Vision von Microsoft nennt sich Azure IoT Operations. Das Edge-Gerät wird zu einem Azure Arc-enabled Kubernetes Cluster. Die Applikationen und Dienste können so verwaltet werden, wie man es sich aus Cloud-Anwendungen gewohnt ist. Dabei können die Daten einfach in Microsoft Fabric mit Unterstützung des Fabrics Copilot analysiert werden.

Natürlich hat dieser Ansatz auch einen Nachteil: Im Vergleich zu der bisherigen Lösung muss eine signifikant leistungsstärkere CPU und bedeutend mehr RAM im Edge-Gerät verbaut sein.

Windows IoT Lizenzierungsmodelle

Die von Microsoft angebotenen Windows 10 IoT Enterprise und Windows 11 IoT Enterprise Systeme bieten unterschiedliche Update- und Support-Modelle. Es gibt grob zwei Modelle: den Semi Annual Channel (SAC) bzw. Current Branch for Business (CBB) und den Long Term Servicing Channel (LTSC).

Beim SAC/CBB-Modell erhalten Kunden halbjährlich ein Updatepaket von Microsoft, das innerhalb von 12 Monaten installiert werden muss. Bis jetzt gibt es keine technischen Hürden das Update weiter herauszuzögern, jedoch ist man vertraglich zur Installation verpflichtet. Diese Pflicht besteht auch beim General Availability Channel (GAC), jedoch werden da nur einmal pro Jahr grosse Updates veröffentlicht.

Im Gegensatz dazu wird beim LTSC-Modell nur alle 2 bis 3 Jahre eine Version mit aktuellem Systemkern veröffentlicht. Diese Releases werden jedoch für 10 Jahre mit Sicherheits- und Stabilitätsupdates versorgt. Es ist wichtig zu beachten, dass in der LTSC-Version einige Microsoft-Tools nicht verfügbar sind, wie z.B. der Store, Cortana und OneDrive. Obwohl es technisch möglich ist, Anwendungen aus dem Store auch ohne die Store-Oberfläche zu installieren, wird davon abgeraten. Die Anwendungen können Abhängigkeiten zu neuen Features aufweisen, welche im LTS-Kanal entweder gar nicht verfügbar sind oder nur in einer inkompatiblen Version.

Es ist wichtig, die Unterschiede zwischen den beiden Modellen zu berücksichtigen und die richtige Wahl entsprechend den Anforderungen und Bedürfnissen des jeweiligen Einsatzbereichs zu treffen.

Wie der Roadmap zu entnehmen ist gibt es für Windows 11 IoT ist derzeit noch kein LTSC Release. Die erste Version sollte im kommenden Sommer veröffentlicht werden. Gleichzeitig wird auch eine normales non-IoT Windows 11 LTSC erwartet. Die IoT-Version wird zwar teurer sein als die normale Version, jedoch mit 10 Jahren auch doppelt so lange Support erhalten. Auch ist vorgesehen, dass Windows 11 IoT ohne Trusted Platform Module (TPM) auskommt und lediglich DirectX 10 Grafiksupport erfordert. So sollte es auch auf Industrie PCs lauffähig sein, die nicht die aller neuste Hardware verbaut haben.

Windows for ARM

Die ARM-Architektur gewinnt zunehmend an Bedeutung und dringt in Bereiche vor, die traditionell von der x86/x64-Architektur dominiert wurden. Microsoft hat diese Entwicklung erkannt und setzt sich zunehmend mit ARM auseinander. Auf der diesjährigen Ignite wurden zwei Chips vorgestellt: der Microsoft Azure Maia AI Accelerator, welcher perfekt in die AI-orientierte Strategie passt, und Azure Cobalt, ein ARM-64-basierter CPU, der für AI-Rechenzentren konzipiert wurde, um die General Purpose Compute Workloads zu verarbeiten.

Im Gegensatz zu den Hardware-Updates im Microsoft-Rechenzentrum, die nur indirekt spürbar sein werden, sind die Fortschritte bei Windows 10 IoT Enterprise LTSC für ARM sehr direkt spürbar. Im Gegensatz zu früheren Windows for ARM Lösungen wurde erreicht, dass der Benutzer den Übergang von der x86-Welt zur ARM-Welt kaum bemerkt. Ähnlich wie bei macOS lassen sich auf der ARM-CPU Applikationen ausführen die eigentlich für x86 gebaut wurden. Natürlich geht das nur für normale Anwendungen, bei Treibern muss die CPU-Architektur stimmen.

In der Pause konnten sich die Seminarteilnehmer selbst ein Bild davon machen, wie gut Windows for ARM funktioniert. Martin Grossen hat zu diesem Zweck ein Anschauungsobjekt mitgebracht. Basierend auf dem NXP i.MX 8M Plus ist Windows 10 IoT for ARM flüssig bedienbar. Auch simultanes abspielen eines Videos und zeichnen auf dem Touchscreen funktionierte problemlos.

Es ist zu erwarten, dass Windows for ARM in naher Zukunft eine grössere Verbreitung finden wird, unter anderem weil die Exklusivvereinbarung zwischen Microsoft und Qualcomm zu Windows on ARM ausläuft. Zudem haben AMD und Nvidia haben bereits Pläne für neue ARM-basierte Chips angekündigt.

Praxisbeispiel: Bereitstellen von Infrastruktur in der Pipeline

Zum Abschluss des Seminars demonstrierten Linus Riedi, Architekt und Software-Ingenieur, und Lukas Brun, Software-Ingenieur, beide von Cudos, anhand eines kleinen Beispiels, wie Infrastructure as Code mit Bicep-Dateien und Azure Pipelines umgesetzt werden kann. Sie erklärten, wie sie in der Bicep-Datei die Azure-Ressourcen definieren, die sie für ihre Webanwendung benötigten.

Diese Methode ermöglicht es, die Infrastruktur nach Bedarf einfach zu replizieren. Darüber hinaus kann das Bicep-File als Dokumentation dienen, was den Vorteil hat, dass im Gegensatz zu extern geführten Dokumentationen keine Änderungen vergessen werden können.

Durch den gezielten Einsatz von Parametern kann das gleiche Bicep-File verwendet werden, um beispielsweise mehrere Instanzen der Infrastruktur zu erzeugen. Dies ermöglicht es, für mehrere Kunden eine jeweils unabhängige Instanz aller Ressourcen bereitzustellen, wobei nur die Parameter für das Bicep-File angepasst werden müssen.

Das Deployment der Azure-Ressourcen mittels Bicep lässt sich ebenfalls in CI/CD Pipelines in Azure DevOps integrieren. Damit kann erreicht werden, dass in der selben Pipeline der Code der Applikation kompiliert wird, die benötigten Ressourcen auf Azure deployed werden, und die kompilierte Applikation schliesslich auf diesen neu erstellten Ressourcen bereitgestellt wird.

Mithilfe der beiden oben genannten Techniken kann eine neue Instanz der Applikation für einen Neukunden inklusive aller Abhängigkeiten per One-Click Deployment erstellt werden.

Auch das Reparieren einer Instanz ist mit Bicep meist kein Problem. Hat jemand an der Infrastruktur rum gepfuscht, reicht ein einfaches inkrementelles Deployment. Dieses erzeugt alle fehlenden Ressourcen und setzt bei den bestehenden Ressourcen die Einstellungen zurück auf den Wert, der im Bicep-File festgelegt wurde.