Blog
Azure Container Apps: Die Zukunft der Microservices in Azure?
Wenn wir uns den aktuellen Stand der Softwareentwicklung ansehen, können wir ein paar Dinge feststellen:
- Container sind auf dem Vormarsch. Im Laufe der Jahre sind containerisierte Workloads immer beliebter geworden, und wir sehen, dass die meisten reifen Softwareunternehmen von der Cloud bis zum Edge von Containern profitieren.
- Die DevOps-Bewegung wächst und wächst. Das Mantra "You build it, you run it" funktioniert wirklich für die Entwicklung besserer Software. DevOps-Teams müssen das gesamte Bild der Anwendungsentwicklung berücksichtigen, von den Funktionen bis zu den Kosten, von der Anwendungsüberwachung bis zur zugrundeliegenden Infrastruktur, anstatt nur für die Erstellung von Funktionen für ihre Anwendungen verantwortlich zu sein.
Die Kombination dieser beiden Trends auf dem Markt erklärt, warum Technologien wie Serverless so beliebt wurden. Entwicklungsteams müssen sich auf alles konzentrieren, was mit der Erstellung funktionaler, widerstandsfähiger und robuster Anwendungen zu tun hat, und dabei die Kosten im Auge behalten. Serverless hilft dabei, die Anzahl der beweglichen Teile zu reduzieren, die Sie als Entwicklungsteam verwalten müssen.
Kubernetes ist eine weitere Technologie, die in den letzten Jahren die Welt im Sturm erobert hat. Containerisierte Arbeitslasten sind beliebt, und Kubernetes bietet Ihnen eine Vielzahl von Optionen für die Bereitstellung und Ausführung dieser Arbeitslasten, entweder in der Cloud oder am Rande, mit Flexibilität zwischen allen Clouds und selbstgehosteten Optionen.
Kubernetes bietet auch großartige Tools für die automatische Skalierung, die Wiederherstellung von ausgefallenen Containern, die Bereitstellung ohne Ausfallzeiten und die Kontrolle des Netzwerks innerhalb der Anwendungen mit Service-Meshes. Aus diesem Grund haben alle Cloud-Anbieter kräftig investiert, um Möglichkeiten für den Betrieb von Kubernetes in ihren Clouds zu schaffen. Deshalb entwickelt sich Kubernetes zur Standardinfrastruktur für moderne native Cloud-Anwendungen.
Es gibt auch einige Nachteile von Kubernetes. Die Verwaltung von Kubernetes selbst ist recht komplex, und obwohl alle Public Cloud-Anbieter in die immer einfachere Ausführung von Anwendungen investieren, ist Kubernetes selbst noch weit von einem PaaS oder serverlosen Dienst entfernt, der für Produktions-Workloads wenig bis gar keine Konfiguration benötigt. In einer Welt, in der wir T-förmige Entwicklungsteams haben wollen, die ihre Anwendungen erstellen und ausführen können, kann es eine ziemliche Belastung sein, wenn diese Teams auch noch alles über Kubernetes wissen müssen.
Microsoft hat dies erkannt und erkannt, dass die meisten Unternehmen nicht alle Funktionen benötigen, die Kubernetes zu bieten hat. Ihr Ziel bei der Entwicklung von Azure Container Apps war es, eine eigenständige Methode zur Bereitstellung von containerisierten Arbeitslasten auf Azure zu schaffen, die mehrere Funktionen von Kubernetes bietet, ohne dass ein Cluster verwaltet werden muss: automatische Skalierung, Bereitstellungen ohne Ausfallzeiten und Traffic Shaping mit Kontrolle über den Ingress.
Einführung in Azure Container Apps (ACA)
Wie bereits erwähnt, hatte Microsoft das Ziel, eine optimierte Methode zur Bereitstellung und Ausführung von containerisierten Arbeitslasten bei der Erstellung von Azure Container Apps. Ihr Ziel war es, eine Lösung zu entwickeln, die es Entwicklungsteams erleichtert, auf Microservice-Architekturen basierende Anwendungen zu erstellen und diese in Azure bereitzustellen. Die Idee ist, Entwicklungsteams die Funktionen zu bieten, die sie von Kubernetes erwarten, ohne sich mit Kubernetes selbst beschäftigen zu müssen.
Azure Container Apps basiert hinter den Kulissen immer noch auf Kubernetes, aber als Entwickler sollten Sie sich nicht darum kümmern. Es wurde für Sie so eingerichtet, dass es sich anfühlt (und kostet) wie eine serverlose Art der Bereitstellung von containerisierten Arbeitslasten auf Azure, mit Schwerpunkt auf Cloud-nativen Anwendungen und Microservice-Architekturen.
Welche Funktionen hat Azure Container Apps zu bieten?
Welche Funktionen wünschen sich Entwicklungsteams beim Aufbau und Hosting von Microservices? ACA bietet eine Möglichkeit, eine Reihe von Containern bereitzustellen und zu skalieren, aus denen eine Anwendung besteht. Dabei wird sichergestellt, dass alle Komponenten miteinander kommunizieren können, je nach Auslastung skalieren, von außen zugänglich sind und ohne Ausfallzeiten bereitgestellt werden können.
Wenn Sie die Komponenten betrachten, die eine Azure Container Apps-Lösung definieren, beginnen Sie immer mit einer "Azure Container Apps-Umgebung". Die Umgebung ist eine sichere Grenze um mehrere "Container Apps" und ermöglicht die Kommunikation zwischen diesen verschiedenen Container Apps, ähnlich wie eine App Service Umgebung bei der Verwendung von Azure App Services. Innerhalb der Azure Container App Umgebung können Sie Azure Container Apps erstellen. Jede App stellt eine einzelne einsatzfähige Einheit dar, die einen oder mehrere zusammenhängende Container enthalten kann. Sie können eine Azure Container App mit einer Bereitstellung in Kubernetes vergleichen. Für jede App können Sie mehrere "Revisionen" erstellen. Revisionen sind eine Möglichkeit, mehrere Versionen einer App bereitzustellen, wobei Sie die Option haben, den Datenverkehr an bestimmte Versionen zu senden. Zwischen den Revisionen kann die ACA anders zusammengesetzt sein: Denken Sie an die Verwendung verschiedener Images, zusätzliche Container usw.
Diese Funktionen sind die grundlegenden Konzepte für die Ausführung von APIs und Frontends, aber ACA verfügt auch über Funktionen zum Hosten von Workern oder Hintergrundprozessen, die Teil der Microservice-Anwendung sind. ACA hat Kubernetes Event-driven Autoscaling (KEDA) integriert. KEDA kann Hintergrund-Worker auf der Grundlage von Skalierungsregeln skalieren, z. B. anhand der Anzahl der Anfragen oder der Anzahl der Nachrichten in einer Warteschlange. Diese Regeln können für jede Container-App einzeln festgelegt werden, so dass sie nach ihren eigenen Bedürfnissen skaliert werden können.
Bereitstellen einer Anwendung in Azure Container Apps
Azure Container Apps basieren auf Kubernetes-Technologien, Technologien, die bei der Bereitstellung einer neuen Container App unter der Oberfläche verborgen sind. Um ein besseres Verständnis für die beteiligten Technologien und die schwere Arbeit zu bekommen, die dabei geleistet wird, sehen Sie hier, was bei der Bereitstellung einer Container App passiert.
Container können in Kubernetes auf verschiedene Arten bereitgestellt werden. Eine Möglichkeit, Container auszurollen, ist die Verwendung von Deployments. Eine Kubernetes-Bereitstellung kann als yaml-Deklaration definiert werden, in der beschrieben wird, welche Container, Speichervolumes und Ports erstellt werden sollen, sowie die Anzahl der Replikate. Ein Beispiel für ein Kubernetes-Deployment, das drei Instanzen des Nginx-Webservers bereitstellt, sehen Sie unten:
apiVersion: apps/v1 Art: Einsatz Metadaten: Name: nginx-Bereitstellung Etiketten: Anwendung: nginx spec: Replikate: 3 Selektor: matchLabels: Anwendung: nginx Vorlage: Metadaten: Etiketten: Anwendung: nginx spec: Container: - Name: nginx Bild: nginx:1.14.2 Häfen: - containerPort: 80
Jedes Mal, wenn sich die Definition der yaml ändert und erneut auf den Cluster angewendet wird, wird eine neue Revision erstellt und die laufende Bereitstellung wird schrittweise auf die neue Revision aktualisiert. Einer der Vorteile ist, dass die Revisionshistorie in Kubernetes gespeichert wird, so dass der Administrator die Bereitstellung auf eine frühere Revision zurücksetzen kann.
Wenn eine Azure Containerized App in Azure bereitgestellt wird, wird die App als Kubernetes-Bereitstellung verpackt und nutzt so die Vorteile einer Kubernetes-Bereitstellung. Jede Aktualisierung der ACA führt zu einer neuen Revision, die bei Bedarf zurückgenommen werden kann.
Damit der ACA den Ingress zulässt, werden im zugrunde liegenden Kubernetes-Cluster ebenfalls ein Service und eine Ingress-Ressource erstellt.
Die Service-Ressource ist ein statischer Endpunkt innerhalb des Clusters und ein Mapping für Kubernetes, um Container mit bestimmten Ports zu verbinden. Dies geschieht über das Schlüssel/Wert-Paar im Selektor. In unserem Beispiel ist dies " app: nginx".
Art: Dienstleistung
apiVersion: v1
Metadaten:
Name: nginx-service
spec:
Selektor:
Anwendung: nginx
Häfen:
- Hafen: 80
Die Ingress-Ressource beschreibt dann, wie der eingehende Datenverkehr zum Cluster an die richtigen Container weitergeleitet wird. Wenn in diesem Beispiel eingehender http-Verkehr auf Port 80 erkannt wird, wird der Verkehr an den Dienst mit dem Namen "nginx-service" weitergeleitet. Der nginx-Service leitet dann den Datenverkehr an alle Pods oder Bereitstellungen mit dem Selektor "ap: nginx" weiter.
apiVersion: extensions/v1beta1 Art: Ingress Metadaten: Name: nginx-ingress Anmerkungen: ingress.kubernetes.io/rewrite-target: / spec: Regeln: - https: Wege: - Pfad: / Backend: serviceName: nginx-service servicePort: 80
Das Äquivalent all dieser schweren Arbeit wird hinter den Bildschirmen erledigt, wenn die folgende Bicep containerApp Ressource in Azure bereitgestellt wird.
resource containerApp 'Microsoft.Web/containerapps@2021-03-01' = {
Name: nginx-Beispiel
Art: 'containerapps'
Standort: 'West-Europa'
Eigenschaften: {
kubeEnvironmentId: 'xxxxxxxx'
Konfiguration: {
Geheimnisse: Geheimnisse
Registrierungen: []
Ingress: {
'extern':true
targetPort':80
}
}
Vorlage: {
Container: [
{
Name':'nginx'
image':'nginx:1.14.2'
'Befehl':[]
'Ressourcen':{
'cpu':'.25'
Speicher':'.5Gi'
}
}
]
}
}
Der Vorlagenabschnitt im Bicep-Beispiel beschreibt die bereitzustellenden Container (Name: nginx). Der Abschnitt Konfiguration beschreibt das Äquivalent des Kubernetes-Dienstes (targetport: 80) und den Kubernetes-Ingress (extern: true).
Verkehrsteilung zwischen Revisionen
Überarbeitungen in Container Apps ermöglichen es uns, den Datenverkehr zwischen den Überarbeitungen aufzuteilen, um neue Funktionen schrittweise für unsere Benutzer einzuführen.
Die Aufteilung des Verkehrs erfolgt durch das Hinzufügen von Verkehrsregeln, in denen die verschiedenen Revisionen der Container App unterschiedlich gewichtet werden (beachten Sie: die Summe der Gewichte muss 100 ergeben).
{
...
"Konfiguration": {
"activeRevisionsMode": "mehrfach"
"Ingress": {
"Verkehr": [
{
"revisionName": <NAME_DER_REVISION_1>,
"Gewicht": 95
},
{
"revisionName": <NAME_DER_REVISION_2>,
"Gewicht": 5
}
]
}
}
}
Um die Verkehrsaufteilung zu verwenden, sollteder activeRevisionsMode der ContainerApp auf "multiple" eingestellt sein. Wenn dieser Modus auf "single" eingestellt ist, würde eine neue Revision dazu führen, dass andere Revisionen automatisch deaktiviert werden.
Hintergrundarbeiter in Azure Container Apps
Azure Container Apps bieten die Möglichkeit, "Hintergrund"-Anwendungen auf Azure bereitzustellen. Dabei handelt es sich um Anwendungen, die keine öffentlichen Endpunkte bereitstellen und die ewig laufen können.
Durch die Verwendung von standardmäßigen Kubernetes Event-driven Autoscaling (KEDA)-Technologien können Azure Container Apps je nach Anzahl der zu verarbeitenden Ereignisse hoch- und herunterskaliert werden. Die maximale Anzahl der Replikate ist auf 25 Replikate festgelegt. In den meisten Fällen können Azure Container Apps auf 0 Replikate zurückskaliert werden, wenn sie im Leerlauf sind.
Viele KEDA-Skalierer sind für eine Vielzahl von Technologien verfügbar (z.B. AWS, GCP, Azure, Redis, usw.). Pro Container App können die Skalierungsmetriken auf der Grundlage mehrerer Regeln festgelegt werden, die für jede Technologie unterschiedlich sind...
Im folgenden Beispiel wird die Container-App allmählich auf maximal 5 Replikate skaliert, wenn die Anzahl der gleichzeitigen Http-Anfragen 100 beträgt.
{
...
"Ressourcen": {
...
"Eigenschaften": {
...
"Vorlage": {
...
"Skala": {
"minReplikate": 0,
"maxReplikate": 5,
"Regeln": [{
"Name": "http-rule",
"http": {
"Metadaten": {
"concurrentRequests": "100"
}
}
}]
}
}
}
}
}
Wenn Sie anfangen, mit Container Apps und KEDA-Triggern zu arbeiten, finden Sie die Dokumentation zur Trigger-Spezifikation auf der KEDA-Website(Kubernetes Event-driven Autoscaling).
Die KEDA-Dokumentation zeigt Codebeispiele in YAML, während die Container Apps ARM-Vorlage in JSON vorliegt. Wenn Sie die KEDA-Beispiele für Ihre Bedürfnisse umwandeln, stellen Sie sicher, dass Sie die Eigenschaftsnamen von Kebab Casing (alles in Kleinbuchstaben, mit Bindestrichen zwischen den Wörtern) auf Camel Casing (alles in Kleinbuchstaben, alle Wörter nach dem ersten Wort beginnen mit Großbuchstaben) umstellen.
Microservices mit Dapr in Azure Container Apps
Damit verschiedene Komponenten in der Microservice-Landschaft zusammenarbeiten können, bietet ACA Dapr-Unterstützung, indem ein Konfigurationswert auf true gesetzt wird. Von dort aus kann jede Anwendung alle Funktionen von Dapr nutzen, wie z.B. Service Location, Pub/Sub Messaging oder Distributed Tracing.
Dapr ist ein Open-Source-Projekt, das vor einigen Jahren im CTO-Büro von Azure begonnen wurde und 2021 an die CNCF Foundation gespendet wurde und nun ein CNCF-Inkubationsprojekt ist [1]. Dapr steht für"Distributed Application Runtime" und hilft Entwicklern, sich mehr auf ihre Anwendungen zu konzentrieren, anstatt alles über das Netzwerk, den Speicher, die Überwachungstools usw. zu wissen.
Dapr schafft eine Abstraktion für Entwickler, so dass sie nur einen Satz von APIs benötigen, um andere Dienste aufzurufen, Zustände zu speichern oder Nachrichten zu senden. Wir haben einen Artikel über Dapr im XPRT Magazine #10 [2] geschrieben und auf der Website Dapr.io finden Sie zahlreiche Informationen.
Dapr arbeitet mit einer Sidecar-Architektur. Azure Container-Apps machen es möglich, indem Sie einfach ein Kontrollkästchen aktivieren, um diese Sidecar-Container für Ihre Azure Container-App zu aktivieren, ohne dass Sie selbst etwas einrichten müssen. Wenn Sie diese Funktion für Ihre App aktivieren, können Sie sofort alle Funktionen nutzen, die Dapr bietet.
Die Hinzufügung dieser Funktion beweist einmal mehr, dass Azure Container Apps einen Weg gewählt hat, um containerisierte Microservice-Anwendungen zu erstellen, obwohl die Verwendung von Dapr völlig optional ist.
Azure Container Apps im Vergleich zu anderen Container-Hosting-Optionen in Azure
Bei all den Computing-Lösungen, die Microsoft Azure anbietet, kann es schwierig sein, die richtige zu wählen. Wann sollten Sie sich für Funktionen, Web Apps, Container-Instanzen, Kubernetes oder Container Apps entscheiden? In diesem Abschnitt helfen wir Ihnen, die richtige Wahl zu treffen.
Azure Container-Instanzen
Azure Container-Instanzen sind die einfachste Möglichkeit, einen Container in Azure auszuführen. Dies eignet sich hervorragend für die Ausführung bestimmter Prozesse, bei denen es sich nicht um eine Webanwendung oder einen Hintergrundworker handelt, da Azure Web Apps und Azure Functions in diesen Szenarien mehr Funktionalität bieten. Für andere Anwendungen, die nur aus einem einzigen Container bestehen, ist Azure Container Instances eine hervorragende Lösung. Ein weiterer Nachteil von Azure Container Instances ist, dass sie nicht auf 0 Instanzen herunter skaliert werden können, so dass Sie immer gewisse Kosten haben.
Azure Funktions-Apps Funktions-Apps sind serverlose Anwendungen, die auf der Grundlage von Auslösern wie http-Anfragen, Timern oder Nachrichten in einer Warteschlange ausgeführt werden. Azure Functions erfordern den geringsten Aufwand bei der Konfiguration der Infrastruktur, so dass Sie sich auf die Geschäftslogik konzentrieren können. Für kleinere Anwendungen oder Verarbeitungsaufträge ist dies die perfekte Lösung. Der größte Nachteil von Funktionen können die "Kaltstarts" sein, bei denen die Verarbeitung einer ersten Anfrage nach einer Leerlaufphase eine Weile dauern kann. Aus diesem Grund würden wir sie nicht für APIs oder das Hosting von benutzerorientierten Webanwendungen empfehlen.
Azure Web Apps Azure Web Apps sind die beste Lösung für einfache Webanwendungen oder APIs. Als PaaS-Lösung ist die Konfiguration recht einfach. Es gibt keine integrierte Unterstützung für mehrere Regionen, so dass Sie dies außerhalb von Azure Web Apps verwalten müssen. Azure Web Apps unterstützt auch die Ausführung von Containern und kann eine großartige Kombination für Frontends in Verbindung mit Workern als Funktionsanwendungen oder Container-Instanzen sein.
Azure Container Apps ACA kann als eine "Kubernetes To Go"-Lösung betrachtet werden, bei der der Entwickler einen Großteil der Leistungsfähigkeit von Kubernetes nutzen kann, ohne sich um die Wartung eines Clusters kümmern zu müssen. Allerdings stehen dem Benutzer nicht alle Kubernetes-Funktionen zur Verfügung. Ein ideales Szenario wäre die Containerisierung von Microservices oder beliebigen Hintergrundprozessen mit schwankenden Lastspitzen unter Verwendung von KEDA-Autoskalierern. Eine vollständige Anwendung in Azure Container Apps könnte in Zukunft das Beste aus beiden Welten vereinen, wenn man die Funktionen von Kubernetes mit der Einfachheit der Kombination von Azure Web Apps & Azure Functions vergleicht.
Azure Kubernetes Dienst AKS ist das Kubernetes PAAS-Angebot von Microsoft, bei dem Microsoft die zugrunde liegenden Cluster-Technologien und virtuellen Maschinen verwaltet. Das bedeutet nicht, dass es keine Wartung braucht. Benutzerverwaltung, Ingress- und Egress-Routing, Netzwerke, Sicherheit und Ressourcenzuweisungen sind alles Dinge, die Sie bei der Verwendung von AKS berücksichtigen müssen. Die Lernkurve kann steil sein, wenn man mit Kubernetes zu arbeiten beginnt, aber es bietet einen Stack, der fast jede Anwendung in jedem Technologie-Stack ausführen kann. In Kombination mit den Skalierungs- und Selbstheilungs-/Autorecovery-Diensten, die Kubernetes bietet, ist dies eine hervorragende Option für Unternehmen, die geschäftskritische Anwendungen hosten möchten.
Sind Azure Container Apps die Zukunft der Microservices auf Azure?
Azure Container Apps (ACA) befindet sich derzeit in der öffentlichen Vorschau. Sie wurde auf der Ignite Ende 2021 angekündigt und es wird noch einige Zeit dauern, bis sie allgemein verfügbar (GA) sein wird.
Da wir nach dem Mantra "Sie bauen es, Sie betreiben es" leben und gerne Microservice-Architekturen aufbauen, haben wir oft eine Hassliebe zu Kubernetes. Kubernetes hat so viele gute Funktionen, aber sie haben ihren Preis in Form von zusätzlicher Komplexität, die die Entwicklungsteams oft nicht begreifen können. Deshalb lieben wir das Konzept von Azure Container Apps, das viele dieser Funktionen ohne die Komplexität bietet. Allerdings haben Azure Container Apps in ihrem derzeitigen Zustand einige Schwachstellen. Wir hoffen, dass diese bald behoben werden und einige davon stehen bereits auf der Roadmap von Microsoft.
Einige wichtige Verbesserungen, die wir gerne sehen würden?
Verwaltete Identitäten
Mit Managed Identities können Sie laufende Dienste mit anderen Azure-Ressourcen wie Datenbanken oder Warteschlangen verbinden. Im Moment werden Managed Identities noch nicht unterstützt, aber Microsoft hat angekündigt, dass dies noch vor der GA verfügbar sein wird.
Untersuchen von laufenden Containern
Im Moment ist die einzige Möglichkeit, laufende Container in ACA zu überprüfen, die Protokollierung in Log Analytics. Microsoft hat bereits angekündigt, dass sie an einer Möglichkeit arbeiten, dies zu verbessern. Wir haben die Hoffnung, dass dies die Untersuchung von Problemen während der Entwicklung sehr viel einfacher machen wird, wenn das möglich ist.
Erweiterte Verkehrsgestaltung
Die aktuellen Revisionen im ACA ermöglichen es Ihnen, den Traffic auf die einzelnen Revisionen zu lenken. Die einzige Möglichkeit, dies zu tun, besteht darin, einen bestimmten Prozentsatz des Datenverkehrs auf diese Revision zu lenken. Wir halten das für eine nette Idee, aber in der Praxis nutzt fast niemand diese Möglichkeit. Es wäre viel besser, wenn wir den Datenverkehr auf fortschrittlichere Weise gestalten könnten, z.B. indem wir den Datenverkehr mit bestimmten http-Anfrage-Headern an die eine oder andere Revision senden oder andere Optionen, die alle in der SMI-Spec [3] definiert sind.
Regionale Ausfallsicherung
Azure Container-Apps haben derzeit keine Optionen für regionale Failover, wenn es zu einem Ausfall kommt. Einer der Vorteile von Kubernetes ist, dass Sie einen Cluster über mehrere Regionen hinweg ausdehnen können und dass er den Ausfall der Rechenleistung in einer Zone oder Region bewältigen kann. Sie könnten denselben ACA in 2 Regionen einsetzen und ihnen eine Azure Frontdoor vorschalten, um den Datenverkehr zu leiten, aber es wäre schön, wenn dies in den Dienst integriert wäre, insbesondere in Ländern, die sich auf 1 Region konzentrieren. ACA stellt automatisch mehrere Verfügbarkeitszonen bereit, um eine hohe Verfügbarkeit zu gewährleisten, was ein guter Anfang ist.
Begrenzte Hardware-Konfigurationsmöglichkeiten
Wenn Sie Container-Apps erstellen, können Sie ihnen CPU- und Speicherressourcen zuweisen. Derzeit gibt es nur Optionen von 0,25 CPU-Kernen und 0,5Gi Speicher bis zu 2 CPU und 4Gi Speicher. Wir denken, dass dies flexibler sein sollte für Apps, die die CPU nicht stark beanspruchen, aber mehr Speicher benötigen oder umgekehrt.
Die Zukunft des Hostings von Microservices in Azure?
Azure Container Apps befindet sich noch in der Vorschau. Es sind bereits viele Verbesserungen in Arbeit. Die Zeit wird es zeigen. Wir sind begeistert von der Entwicklung hin zu einer serverlosen, Kubernetes-ähnlichen Umgebung für unsere Microservices. Azure Container Apps ist ein großer Schritt in die richtige Richtung. Zum jetzigen Zeitpunkt fehlen noch einige Funktionen, die uns davon abhalten würden, sie in der Produktion einzusetzen, wie z.B. das Fehlen einer verwalteten Identität. Wir glauben, dass sich Azure Container Apps zu einer dominierenden Plattform für das Hosting von Container-Workloads entwickeln könnte, insbesondere für Microservice-basierte Anwendungen, wenn diese Funktionen hinzugefügt würden.
Referenzen:
[1] https://landscape.cncf.io/serverless?selected=dapr Website
[2] Xebia Website
[3] Service Mesh Interface Traffic Split v1alpha4 Spezifikation auf GitHub
Strategien zur Anwendungsmodernisierung für IT-Führung und Innovation
eBook herunterladenVerfasst von
Geert van der Cruijsen
Unsere Ideen
Weitere Blogs
Contact