Container und Serverless mit Azure

Microsoft Azure bietet ein breites Angebot im Bereich von Container Services und Serverless Computing.

Autor: Yu Li

Microsoft Azure und sein Ökosystem bieten eine sehr breite Palette an Services in Bezug auf Container Services und Serverless Computing. Die Vielfalt des Public Cloud Angebots bringt nicht nur Flexibilität, Effizienz und Innovation, sondern stellt auch viele Cloud-Architekten und Public-Cloud-Verantwortliche vor Herausforderungen, wenn es um Architekturentscheide geht. Hippe Technologien wie Kubernetes und Serverless sind nicht unbedingt die Lösung für alle Probleme. In welchen Szenarien sollte welcher Service zur Anwendung kommen? In diesem Blog finden Sie die Gedanken und Erfahrungen der ipt.

Welcher Service für welches Szenario?

Um Ihnen einen klaren Überblick über die Thematik zu geben, zeigt die Abbildung unten fünf relevante Microsoft Azure Services im Kontext Container und Serverless, sowie ihre Kernfunktionen und die möglichen Einsatzszenarien.

Container_and_Serverless_with_Azure_YLI.PNG
Abbildung 1: 5 relevante Microsoft Azure Services, ihre Kernfunktionen und Einsatzszenarien.

Die ausgewählten Azure-Services decken eine oder mehrere der folgenden Kernaufgaben ab:

  • Container Service umfasst die Funktionen zum Betreiben eines Containers, von Networking, Sicherheit und Skalierung bis zum Deployment.
  • Orchestration beinhaltet die Management-Funktionen von mehreren Containern, z.B. Deployment und Rollback von Containern, Scale-out und individuelle Skalierung, Zuweisung von Host-Ressourcen an Container, Load Balancing und Monitoring.
  • Serverless ist eine Cloud-native Fähigkeit, die es Entwicklern ermöglicht, Anwendungen zu erstellen und auszuführen, ohne Server verwalten zu müssen.
  • Bei der Hybrid Cloud werden die Public Cloud und die Private Cloud einheitlich verwaltet.

Die Abbildung zeigt auch die entsprechenden Einsatzszenarien der folgenden fünf Produkte:

  • Azure App Service for Container betreibt containerisierte Applikationen auf einer vollständig verwalteten Art und Weise und bietet Features wie AuthN/AuthZ und CI/CD an. Azure App Service for Container ermöglicht ausserdem die Integration mit Azure Active Directory, oder auch Facebook sowie Google zur Authentisierung und Autorisierung out-of-box. Ein sogenannter “Easy-Auth”-Side-Car-Container [1] wird neben dem Applikations-Container deployed, um die AuthN/AuthZ Logikabfragen zu verarbeiten. Azure App Service for Container bietet beim Deployment auch out-of-box Integration zu Azure Container Registry und verschiedenen Code Repo Providern wie bspw. Github. Deshalb werden entweder Container Images oder Source Codes mit einem Dockerfile als Input für das Deployment entgegengenommen. Trotz vielen Vorteilen stösst diese Plattform an ihre Grenzen, wenn es zum Betrieb und Management von Applikationen, die aus mehreren Microservices bestehen, kommt.

Empfehlung 1

Setzen Sie Azure App Service for Container für eine einfache Applikation mit wenigen Microservices ein.

Empfehlung 2

Setzen Sie Azure App Service for Container zum Starten des Projektes ein, wenn die fachlichen Anforderungen und technische Komplexität noch unklar sind.

 

  • Azure Kubernetes Service ist der managed Kubernetes-Service von Microsoft und eignet sich für komplexe Applikationen auf Basis einer Microservice-Architektur. Die Kernfunktion von AKS (Azure Kubernetes Service) ist die Container-Orchestrierung, die viele Aspekte vom Deployment über die Skalierung bis hin zum Monitoring umfasst. Beim Deployment sorgt Kubernetes dafür, dass alle Container-Services der Anwendung gleichzeitig mit einer neuen Version deployed werden. In einem Fehlerfall können diese synchronisiert und auf die letzte Version zurückgerollt werden. AKS sorgt ausserdem auch dafür, dass nur einzelne Microservices, statt die gesamte Anwendung (alle Microservices), bei Lastspitzen auf Basis von Metriken wie CPU, Speicher oder Queue-Füllstand skaliert werden.

Empfehlung 3 

Setzen Sie Azure Kubernetes Service für komplexe Applikationen ein. Komplex heisst in diesem Fall, dass die Applikation aus mehreren Microservices besteht und oft durch verschiedene Teams entwickelt wird.

 

  • Azure Red Hat Openshift ist eine der beliebtesten Kubernetes-Varianten und wird von vielen Unternehmen für ihre Private Cloud verwendet. Seit einiger Zeit ist Openshift auch auf Azure in einer verwalteten Version verfügbar. Openshift bietet out-of-the-box zahlreiche Enterprise-freundliche Funktionen wie Monitoring, Logging und CI/CD an. Im Gegensatz zu Azure Kubernetes Service, wo diese mit . Services wie Azure DevOps (CI/CD) oder Azure Monitor abgedeckt werden müssen. Dafür verlangt Openshift aber auch einen entsprechenden Preis. Neben den Infrastrukturkosten (VMs) müssen zusätzlich Lizenzkosten (rund 124 US-Dollar für eine D4s v3 VM) bezahlt werden. Im Vergleich dazu fallen bei AKS neben den Infrastrukturkosten keine Lizenzkosten an [2][3]. Außerdem ist AKS bereits vollständig in das Azure-Ökosystem integriert, zum Beispiel durch Azure DevOps oder Azure Monitor Security Center. In dieser Hinsicht ist eine fundierte Abwägung  durchaus sinnvoll.

Empfehlung 4

Ziehen Sie Azure Red Hat Openshift in Betracht, wenn Sie Openshift bereits für Private Cloud und On-prem einsetzen und eine Hybrid-Cloud-Strategie verfolgen.

  • Azure Functions ist das Serverless Offering von Microsoft Azure. Bei der Verwendung von Azure Functions übernimmt Microsoft Azure den Betrieb und die Skalierung der Code-Logik, sodass sich das DevOps-Team auf die funktionalen Anforderungen konzentrieren kann. Für Logging und Monitoring bietet Azure Function eine built-in Integration mit Application Insights. Für CI/CD werden viele Optionen unterstützt, wie  zum Beispiel Azure Pipelines oder GitHub Actions. Mit zahlreichen Triggern und Bindings können Sie mit wenig Aufwand andere Services wie etwa Azure Storage Account integrieren. Zur Skalierung werden Azure Functions automatisch je nach Bedarf skaliert; die Skalierung wird komplett von den Cloud-Anbietern übernommen. Es gibt aber auch Nachteile bei der Verwendung von Serverless, wie Vendor Lock-in und Latenz. Weitere Details zu Vor- und Nachteilen von Serverless finden Sie in meinem Blogbeitrag Cloud-Native! Aber wie? Container vs. Serverless.

Empfehlung 5

Serverless ist nicht für jede Situation geeignet. Den grössten Nutzen von Azure Functions erzielen Sie, wenn Sie eine Event-driven Architektur verfolgen.

  • Azure Container Instance + Virtual Nodes ist eine Kombination welche die sekundenschnelle und einfache Skalierung des Azure Kubernetes Services  ermöglicht. Azure Container Instances (ACI) sind gemanagte Services für den Betrieb von kurzlebigen Container-Instanzen. ACI cacht unter anderem das Basis-Betriebssystemimage, um das Deployment der kurzlebigen Container-Workloads zu beschleunigen. ACI ermöglicht eine viel schnellere Skalierung im Vergleich zu Azure App Service für Container oder VMs. Weiter agiert Azure Virtual Nodes als eine gute Ergänzung zu Azure Container Instance. Azure Kubernetes Services werden mit Azure Container Instance auf Netzwerkebene integriert und erweitern auf diesem Weg die Kubernetes API, wodurch Azure Container Instance unterstützt werden kann. Die Kombination von Azure Container Instance und Virtual Nodes erlaubt eine schnellere Reaktion auf Lastspitzen, weil keine VMs zur Hochskalierung erstellt werden muss. Diese Kombination ist auch der Ansatz von Microsoft um Azure Kubernetes Services zu Serverless Kubernetes weiterzuentwickeln.

Empfehlung 6

Überlegen Sie sich, die Kombination Azure Container Service und Virtual Nodes für Applikationen mit vielen Lastspitzen oder vereinzelten Aufrufen einzusetzen.

Alle Empfehlungen auf einen Blick

  1. Setzen Sie Azure App Service for Container für eine einfache Applikation mit wenigen Microservices ein.
  2. Setzen Sie Azure App Service for Container zum Starten des Projektes ein, wenn die fachlichen Anforderungen und technische Komplexität unklar sind.
  3. Setzen Sie Azure Kubernetes Service für komplexe Applikationen ein. Komplex heisst in diesem Fall, dass die Applikation aus mehreren Microservices besteht und oft durch mehrere Teams entwickelt wird.
  4. Ziehen Sie Azure Red Hat Openshift in Betracht, wenn Sie Openshift bereits für Private Cloud und On-prem einsetzen.
  5. Serverless ist nicht für jede Situations Szenario geeignet. Den grössten Nutzen von Azure Functions erzielen Sie, wenn Sie eine Event-driven Architektur verfolgen.
  6. Überlegen Sie sich, die Kombination Azure Container Service und Virtual Nodes für Applikationen mit vielen Lastspitzen oder vereinzelten Aufrufen einzusetzen.

Fazit

Die optimale Auswahl von Services in der Cloud-native Entwicklung ist für den Projekterfolg entscheidend. Die Wahl eines "Flugzeugträger"-Services für ein "Gummiboot"-Problem erhöht Kosten und Komplexität, diese Metapher gilt auch bei Cloud-native Entwicklung. Ein klarer Überblick über die Azure-native-Services und ein ausgeprägtes Verständnis bezüglich deren Vor- und Nachteile hilft, die richtige Architekturentscheidung zu fällen.

Ihr ipt-Experte

Ich freue mich auf Ihre Kontaktaufnahme