Azure-Technologien für den Erstellungsprozess

Abgeschlossen

In dieser Lerneinheit erfahren Sie mehr über die Beziehung zwischen dem Innovationsprozess und einigen Technologien in der Branche, die Ihnen helfen können, neue Funktionen zu entwickeln und in Anwendungen zu integrieren.

DevOps

Nachdem Sie mit der Erstellungsphase begonnen haben, um Ihre Innovationshypothesen zu validieren, sollten die erforderlichen Entwicklungs-, Integrations- und Bereitstellungszyklen so optimiert wie möglich sein. In dieser Phase kommt DevOps ins Spiel. Sie können DevOps als „Prozesse und Tools zur schnellen und zuverlässigen Bereitstellung von Softwarefeatures“ definieren. Hier finden Sie weitere Informationen zu dieser Definition:

• Prozesse und Tools: DevOps basiert als Innovationsprozess als Ganzes auf Kulturmustern, die Veränderungen fördern. Azure und GitHub bieten hervorragende Tools für DevOps, aber der Erwerb einer Lizenz reicht nicht aus. Ihre Prozesse und Ihre Unternehmenskultur müssen sich weiterentwickeln, um Veränderungen und Innovationen anzunehmen.

• Schnelle Bereitstellung von Softwarefeatures: DevOps-Prozesse und -Tools nutzen das „Fail Fast“-Konzept. Der zentrale Aspekt des DevOps-Konzepts besteht darin, dass MVPs oder Prototypen erstellt werden, um schnell überprüfen zu können, ob das Feature, an dem Sie arbeiten, in die richtige Richtung geht.

• Zuverlässige Bereitstellung von Softwarefunktionen: Änderungsscheue Unternehmen assoziieren schnelle Änderungen häufig mit Ausfallzeiten. DevOps verspricht jedoch genau das Gegenteil: eine schnelle Änderungsrate und ein hohes Maß an Zuverlässigkeit. Diese Zuverlässigkeit wird erreicht, indem Tests in frühe Phasen des Entwicklungszyklus integriert werden. Der entsprechende Prozess wird als „shift to the left“ (Verschiebung nach links) bezeichnet.

  Wenn Sie sich die Entwicklung eines Features im Zeitverlauf als Linie von links nach rechts vorstellen, erfolgen Benutzervalidierung und Qualitätskontrolle beim alten Entwicklungsprozess am Ende des Entwicklungszyklus (also ganz rechts auf der Linie). DevOps empfiehlt Ihnen, so früh wie möglich, also möglichst weit „links“ auf dieser Zeitlinie zu testen und zu überprüfen.

DevOps verkörpert die gleichen Kernkonzepte einer gesunden Innovationskultur. Die Übernahme dieser Methodik ist der Schlüssel, um zu einem agilen Innovationszyklus zu gelangen.

Microservices-Architekturen

Modularität ist eine bekannte Technik zur Reduzierung der Komplexität in der Architektur komplexer Systeme. Wenn ein System ein komplexes Zusammenspiel vieler Teile ist, die nicht getrennt werden können (oft als „Monolith“ bezeichnet), erschweren enge Abhängigkeiten der Komponenten untereinander Systemverbesserungen. Jede Änderung muss mit dem Rest des Systems überprüft werden, sodass der Testprozess komplex ist.

Wenn das System modular ist, können Sie es in kleinere Subsysteme aufteilen, die über wohldefinierte Schnittstellen miteinander interagieren. Die Einführung von Änderungen in einem dieser Subsysteme ist einfacher, da das Gesamtsystem weiterhin funktioniert, solange die Schnittstelle mit den anderen Modulen konstant bleibt.

Microservicesarchitekturen sind Anwendungsmuster, die Modularität ausnutzen. Anwendungen werden in separate, kleine Komponenten unterteilt, die unabhängig voneinander entwickelt werden können, möglicherweise sogar mit unterschiedlichen Programmiersprachen. Jede Komponente oder jeder Microservice kann eigenständig ausgeführt werden. Sie können DevOps nach Bedarf skalieren, zur Fehlerbehebung als einzelne Einheit behandeln und unabhängig von den anderen Microservices ändern.

Eine Frage, die Unternehmen oft stellen: Was ist zu tun, wenn eine Anwendung monolithisch ist? Sollte die Organisation die Anwendung in eine Microservicesarchitektur umgestalten, bevor sie die Innovation einführt, oder können der Innovations- und der Umgestaltungsprozess parallel stattfinden? Auf diese Frage gibt es keine einheitliche Antwort. Dies hängt von der Komplexität und geschäftlichen Relevanz der jeweiligen Anwendung ab.

Mit dieser Frage sah sich Tailwind Traders konfrontiert, als es um die Einführung von Innovationen in der E-Commerce-Plattform des Unternehmens ging. Das Unternehmen hat sich entschieden, ein Projekt zur Umgestaltung der E-Commerce-Anwendung in eine Microservicesarchitektur zu starten, da die geschäftliche Bedeutung der Anwendung diesen Aufwand rechtfertigt. Würde keine modulare Anwendung zur Verfügung gestellt, würde dies die Fähigkeit von Tailwind Traders, auf sich ändernde Trends im Onlinemarkt zu reagieren, erheblich beeinträchtigen.

Tailwind Traders hat sich jedoch entschlossen, gleichzeitig einige der größten Lücken in der Plattform des Unternehmens zu beseitigen. Zu warten, bis das Projekt zur Neugestaltung der Anwendung abgeschlossen ist, würde bedeuten, einen erheblichen Marktanteil an neue Startups zu verlieren, die den E-Commerce-Markt gerade aufmischen.

Die Projekte sollen miteinander interagieren und sich am Geschäftswert der Innovationen orientieren. Die Umgestaltungsbemühungen sollen sich auf die kritischsten Anwendungsbereiche konzentrieren, in denen der Änderungsbedarf zur Verbesserung der Kundenerfahrung am höchsten ist.

Container

Die Technologie der Containerisierung wird zwar nicht nur in Microservicesarchitekturen eingesetzt, aber die Konzepte funktionieren gut zusammen. Container sind eine Möglichkeit, Anwendungscode und die zugehörigen Abhängigkeiten zu kapseln, sodass der Code und die Abhängigkeiten mühelos auf jeder Plattform bereitgestellt werden können.

Bei herkömmlichen Anwendungsbereitstellungen muss das Unternehmen zunächst Software installieren, z. B. die Anwendungslaufzeit, Programmierbibliotheken oder externe Komponenten. Diese Herangehensweise führt häufig zu dem Problem „auf meinem Rechner funktioniert es“: Es ist schwierig, die gleiche Umgebung in Entwicklung, Tests, Staging und Produktion zu replizieren. Kleine Unterschiede in der Art und Weise, wie die Anwendungsabhängigkeiten installiert werden, können dazu führen, dass die Anwendung beim Testen einwandfrei funktioniert, bei der Bereitstellung in der Produktion jedoch fehlschlägt.

Container ändern die Spielregeln. Die Anwendungsabhängigkeiten werden zusammen mit dem Anwendungscode in einer autonomen Bereitstellungseinheit gepackt, die als „Containerimage“ bezeichnet wird. Unabhängig davon, ob der Anwendungscontainer auf dem Laptop eines Entwicklers oder in einem Produktionscluster mit Hunderten von Knoten bereitgestellt wird – die Abhängigkeitsbehandlung ist gleich. Der Container funktioniert auf exakt die gleiche Weise, was Anwendungstests zuverlässiger und verlässlicher macht.

Container haben einen langen Weg hinter sich, seit Docker seinen Code 2013 als Open Source veröffentlicht hat. Container unterstützen jetzt sowohl Linux als auch Windows sowie verschiedene CPU-Architekturen. Es gibt viele Angebote in Azure, die die Ausführung containerbasierter Workloads ermöglichen. In dieser Lerneinheit lernen Sie einige von ihnen kennen.

Kubernetes und Red Hat OpenShift

Eine Containerlaufzeit ist die Technologie, die Container auf einem Computer startet, aber in einer Produktionsumgebung ist mehr Logik erforderlich. Wer stellt weitere Container bereit, wenn mehr Leistung erforderlich ist? Wer startet die Container neu, wenn ein Problem besteht? Wer entscheidet, auf welchem Computer ein bestimmter Container gestartet werden soll, wenn mehrere Computer verfügbar sind? Diese und andere Aufgaben liegen in der Verantwortung einer Containerorchestrierungsplattform.

Die erste Version von Kubernetes wurde 2015 veröffentlicht und bald zum De-facto-Standard für Containerorchestrierung. Kubernetes-Cluster bestehen aus mehreren Workerknoten. Jeder Workerknoten verfügt über eine Containerruntime, sodass er Container ausführen kann, wobei die Kubernetes-Steuerungsebene die Bereitstellung von containerisierten Anwendungen plant. Diese Steuerungsebene wird in der Regel auf einer Reihe von Kernknoten ausgeführt. Sie ist dafür verantwortlich, dass die Anwendung ordnungsgemäß ausgeführt wird, die Anwendung hoch- oder herunterskaliert wird und alle erforderlichen Updates ausgeführt werden.

Einer der Hauptgründe für die Beliebtheit von Kubernetes ist die Hardwareunabhängigkeit, die Container bieten. Da containerbasierte Anwendungen zuverlässig in jeder Containerlaufzeit bereitgestellt werden können, können Sie Kubernetes in Clouds ausführen, die verschiedene Hypervisoren verwenden. Die bereitgestellten Anwendungen sollten sich ähnlich verhalten (vorausgesetzt, die zugrunde liegenden Hardwareressourcen sind ebenfalls ähnlich). Viele Organisationen haben Kubernetes als Abstraktionsschicht übernommen, die konsistente Anwendungsbereitstellungsprozesse sowohl lokal als auch in öffentlichen Clouds ermöglicht.

Die Ausführung von Kubernetes in Azure ist einfach. Azure Kubernetes Service ist einfach bereitzustellen und kostengünstig, da den Kund*innen nur die Kosten der Workerknoten in Rechnung gestellt werden. Microsoft übernimmt die Kosten und den Betrieb der Steuerungsebene, die die Kernkomponenten enthält. Microsoft übernimmt das Patchen und Aktualisieren des Betriebssystems auf den Workerknoten, was die operative Komplexität der Verwaltung eines Kubernetes-Clusters für die Ausführung von Linux- und Windows-Containern weiter reduziert.

OpenShift ist eine Anwendungsbereitstellungsplattform, die auf Kubernetes basiert und von Red Hat entwickelt und unterstützt wird. Sie enthält zahlreiche weitere Funktionen. Einige Organisationen, die ihre Anwendungen unter OpenShift ausführen, tun dies aufgrund dieser zusätzlichen Features und des von Red Hat bereitgestellten Supports. Die Ausführung von OpenShift in Azure ist ebenfalls einfach. Azure Red Hat OpenShift besteht aus einem OpenShift-Cluster, in dem Microsoft zahlreiche Aspekte verwaltet – unter anderem den gesamten Lebenszyklus des Clusters.

Azure App Service

Azure App Service ist eine Plattform, auf der Organisationen ihre webbasierten Workloads ausführen können, ohne einen Orchestrator oder ein zugrunde liegendes Betriebssystem verwalten zu müssen. Die einzige Anforderung besteht darin, den Anwendungscode über eine von zahlreichen verfügbaren Bereitstellungsmethoden in den Dienst hochzuladen. Azure übernimmt den Rest: Skalierung der Anwendung, Patching und Wartung der zugrunde liegenden virtuellen Computer und vieles mehr, ohne die Lernkurve von Kubernetes zu benötigen.

Azure App Service unterstützt containerbasierte Workloads, sodass Sie Ihr Containerimage anstelle des Anwendungscodes hochladen können. Außerdem werden Linux- und Windows-Workloads sowie viele verschiedene Anwendungsruntimes unterstützt.

Azure App Service unterstützt verschiedene Preismodelle, einschließlich einer serverlosen Option namens Azure Functions. In Azure Functions wird nur die Anwendungsnutzung in Rechnung gestellt. Es entstehen keine Fixkosten.

Das serverlose Modell ist für Innovationen interessant, da es Ihnen die Bereitstellung neuer Microservices ermöglicht, ohne dass hohe monatliche Kosten entstehen, falls diese vom Markt nicht akzeptiert werden. Dieses Modell ist ein weiteres Beispiel für die Fail-Fast-Strategie, bei der Innovation nicht unbedingt hohe Ausgaben bedeutet.

Azure App Service bietet auch Features, die DevOps-orientierte Bereitstellungen unterstützen, z. B. Web-App-Slots. Slots sind Stagingbereiche, in denen Sie neue Features bereitstellen können, ohne die Produktionsumgebung zu beeinträchtigen. Slots sind aus Innovationssicht hervorragend, da Sie eine kleine Gruppe Ihrer Kund*innen zu dieser neuen Version der Anwendung umleiten können. Anschließend können Sie überprüfen, ob Ihre Innovationshypothese richtig ist. Wenn Sie den neuen Code schließlich in die Produktion höherstufen möchten, können Sie Slots „austauschen“, sodass die Stagingumgebung zur Produktionsversion wird.

Zusammenfassung

In dieser Einheit haben Sie erfahren, wie Technologie Innovationen unterstützen kann:

• Mit DevOps-Prozessen und -Tools können Ihre Entwicklungs- und Betriebsteams schnell und zuverlässig neue Features bereitstellen.
• Sie können Anwendungen in Microservices umgestalten, um Innovationen für einzelne Komponenten zu ermöglichen, ohne dass sich dies auf den Rest auswirkt.
• Container ermöglichen eine zuverlässige Anwendungsbereitstellung über mehrere Plattformen und Umgebungen hinweg.
• Kubernetes ist eine cloudunabhängige Orchestrierungsplattform zum Ausführen von Containeranwendungen.
• Azure App Service kann webbasierte Workloads mit minimalem Verwaltungsmehraufwand ausführen. Die Anwendung bietet viele Features wie serverlose Slots oder Anwendungsslots, um den Innovationszyklus zu beschleunigen.

Tailwind Traders hat sich entschieden, mit der Umgestaltung der E-Commerce-Anwendung in eine Microservicesarchitektur zu beginnen. Das erste Anwendungssubsystem, das das Unternehmen aus dem monolithischen Subsystem herauslöst, ist der Zahlungsdienst, da Sie diesen als kritischen Bereich identifiziert haben, in dem Mitbewerberunternehmen den Kund*innen einen Mehrwert bieten.

Nach dem Zahlungssubsystem werden weitere Anwendungskomponenten in unabhängige Microservices konvertiert. Die Microservices können über REST-APIs kommunizieren. Der Anwendungscode für jeden Microservice soll containerisiert werden, und die Entwicklungs- und Betriebsorganisationen sollen bewährte DevOps-Methoden einführen.

Da Tailwind Traders nicht von einer bestimmten öffentlichen Cloud abhängig sein möchte, hat sich das Unternehmen entschieden, intern Kubernetes-Fachwissen aufzubauen und die Anwendung in Azure Kubernetes Service-Clustern bereitzustellen. Wenn neue Microservices entwickelt werden müssen, zieht das Unternehmen Azure Functions als Plattform für die MVP-Bereitstellung in Betracht, um die Entwicklungskosten zu senken.

Wo als nächstes gesucht werden sollte

Viele der Konzepte in dieser Einheit werden in den Cloud Adoption Framework-Artikeln Unterstützen der Einführung mit digitalen Erfindungen und Kubernetes im Cloud Adoption Framework detaillierter behandelt.