© Natalia Vinokurova, 123RF

Mit Microservice-Architekturen haben inzwischen viele Entwickler zu tun. Das neue Paradigma bewirkt eine Abkehr von monolithischen Anwendungen und eine Hinwendung zu verteilten Anwendungssystemen. Das hat viele Vorteile, denen allerdings auch Nachteile gegenüberstehen.

Zu den Vorteilen der Microservice-Architekturen zählt, dass Entwickler einzelner Anwendungen nun sowohl die Programmiersprache als auch beispielsweise die Datenbank von Fall zu Fall frei und je nach Anwendungszweck auswählen können. Das schafft lokale Autonomie, führt zu besseren Designentscheidungen und fördert letztlich die Softwarequalität. Die Kehrseite: Dort, wo vorher eine einzelne Anwendung zu betreiben war, die von einer zentralen Datenbank abhing, gilt es nun unter Umständen, ein Dutzend Anwendungen, mehrere Datenbanken sowie Message-Queues und Analytics-Server zu betreuen. Diese stark erhöhte Systemkomplexität erfordert einen entsprechend erhöhten Betriebsaufwand.

Es ist kein Zufall, dass die Verbreitung des Microservice-Architekturansatzes zeitlich mit dem Aufkommen des Cloud Computing einhergeht: Diese Trends bedingen sich wechselseitig. Weiter begünstigt die Symbiose der beiden Technologien auch das Aufkommen von Service Meshes wie Istio [1] und Envoy [2], die eine starke Trennung von Zuständigkeiten ermöglichen. So lassen sich Funktionen wie etwa Lastverteilung, automatisches Failover, Verschlüsselung, Authentifizierung und intelligentes Routing bei Bedarf außerhalb der Anwendung regeln. Dabei erlauben Service-Mesh-Technologien eine zentrale Verwaltung von Regeln und Daten. Davon profitieren Anwendungsentwickler ebenso wie der Plattformbetreiber.

Cloud Foundry

Aus historischen Gründen wird der Begriff Cloud Foundry oft mit der Application Runtime gleichgesetzt. Der Begriff steht aber inzwischen nicht mehr nur für die Cloud Foundry Application Runtime mit ihrem berühmten Benutzererlebnis »cf push«. Mittlerweile haben sich viele weitere Projekte unter dem Dach der Cloud Foundry Foundation angesammelt. Damit müsste die ursprüngliche, oft mit dem Kurznamen Cloud Foundry bezeichnete Anwendungsplattform also genau genommen Cloud Foundry Application Runtime heißen.

Das grenzt sie unter anderem von der Cloud Foundry Container Runtime ab, einer BOSH-betriebenen Variante von Kubernetes. BOSH ist ein von Infrastruktur und Betriebssystem unabhängiges Orchestrierungswerkzeug, mit dem der Anwender zustandsbehaftete, verteilte Anwendungen über ihren Lebenszyklus hinweg automatisieren kann. Es eignet sich zur Bewältigung großer Anwendungslasten mithilfe der Cloud Foundry Application oder Container Runtime ebenso wie zum Beispiel zum automatisierten Betrieb von Datenbanksystemen.

Cloud Foundry (CF) ist, verglichen mit dem Newcomer Kubernetes (K8s), ein Urgestein unter den modernen Anwendungsplattformen. Von jeher stand bei CF der effiziente Betrieb einer Vielzahl an Anwendungen im Vordergrund. So waren in Cloud Foundry bereits Ansätze eines Service Mesh zu finden, bevor der Begriff populär wurde. Beispielsweise sendete CF schon immer eingehende Anfragen einer Anwendung über einen zentralen Router und verteilte sie von dort an die dem Request zugeordneten Anwendungsinstanzen. Ohne eine solche Routing-Funktion wäre eine Selbstheilung ausgefallener Anwendungsinstanzen in verteilten Container-Clustern (den sogenannten Diego Cells) unmöglich.

Anfragen den Anwendungsinstanzen zuzuordnen setzt einen regelmäßigen Austausch zwischen dem Router und den Container-Hosts voraus. Anwendungen in Cloud Foundry sind also von jeher über interne sowie externe URLs verfügbar, die die dahinterliegenden Anwendungsinstanzen abstrahieren und automatisch die Last eingehender Anfragen verteilen. Diese Anwendungs-URLs erlauben zudem eine saubere Kommunikation zwischen den Diensten einer Microservice-Architektur. Das ähnelt bereits der Idee eines Service Discovery. Das zentralisierte Speichern von Log-Ausgaben gehört ebenso zu den Cloud-Foundry-Bordmitteln. Weitere Werkzeuge braucht man nur, um die Informationen von Anwendungs- und Datendiensten zusammenzuführen.

Cloud Foundry Service Mesh

So gelungen und erprobt die Cloud Foundry Application Runtime auch ist, so progressiv verläuft die Entwicklung anderer Technologien. Als prominentester Vertreter darf hier sicherlich Kubernetes gelten, der das Service-Mesh-Konzept schnell und tiefgreifend adaptiert hat. Kubernetes macht die Verwendung von Istio und Envoy zum Kinderspiel – in Gestalt von Side-Car-Containern können sie Anwendungen einfach zur Seite gestellt werden. Dadurch steigt der Druck auf Cloud Foundry, ebenfalls eine entsprechende Service-Mesh-Funktionalität anzubieten. So verwundert an der Einführung von Istio und Envoy in Cloud Foundry höchstens, dass sie erst jetzt erfolgt; aktuell befindet sich das eingeführte Service-Mesh-Subsystem noch im Betazustand.

Das Service Mesh in CF ist als optionale Erweiterung ausgeführt und lässt sich bei Bedarf einer Cloud Foundry Application Runtime hinzufügen. Durch die Installation entsteht ein weiteres Routing-Subsystem neben den bestehenden Versionen für HTTP- und TCP-Traffic. Es kommen neue Systemdomains für Istio (*.istio) sowie das Mesh-Routing (*.mesh) hinzu. Wie bei allen CF-Routing-Systemen gilt es, einen Load-Balancer vorzuschalten, der eingehende Anfragen an die Router-Instanzen verteilt. Die Lastenverteilung erfolgt somit zweistufig über klassische, eher statische Load-Balancer sowie die dynamischen Router mit App-Awareness (Abbildung 1).

Abbildung 1: Cloud Foundry führt mit dem Service Mesh ein zweites Routing-Subsystem ein.

Die Integration in das Cloud-Foundry-CLI ist noch unvollständig, es stehen also nicht für alle Funktionen »cf«-Kommandos bereit. Stattdessen muss der Nutzer Curl-Kommandos gegen die APIs verwenden. Da sich das Cloud Foundry Service Mesh noch im Betastadium befindet, unterstützt es noch nicht jeder Cloud-Foundry-Anbieter. Wer allerdings über eine eigene CF-Umgebung verfügt, kann das System bereits jetzt erproben. Die Service-Mesh-Entwickler freuen sich über Rückmeldungen.

Gewichtetes Routing

Der Nutzen des Cloud Foundry Service Mesh ergibt sich derzeit besonders aus der Möglichkeit zum gewichteten Routen. Damit lassen sich Routen anders als bislang mehr als einer Anwendung zuordnen. Das wünschten sich seit mehreren Jahren viele Mitglieder der Cloud-Foundry-Gemeinschaft. Die steigende Popularität der Service-Mesh-Idee sorgte dabei für eine kritische Masse, die dazu führte, dass die Idee schließlich umgesetzt wurde. Mit der Funktion lässt sich eine Gewichtung vorgeben, anhand der die Last auf die beteiligten Anwendungen verteilt wird. Der Gewichtungsfaktor jeder Anwendung entscheidet also darüber, wie viele eingehende Anfragen im statistischen Mittel bei ihr eintreffen.

Gewichtete Routen eröffnen ein breites Spektrum neuer Anwendungsfälle für Entwickler. Dazu zählen unter anderem Blue-Green-Deployments, A/B-Testing und Canary-Releases. Im Rahmen von Blue-Green-Deployments kann man eine Anwendung zweimal ausbringen. Jeder Installation wird eine gesonderte Route zugewiesen, über die zugeordneten Gewichtungsfaktoren lässt sich der Traffic auf die Anwendungen verteilen. So kann man eine der beiden Installationen temporär aus der Lastverteilung entfernen, um sie beispielsweise zu aktualisieren. Während des Updates bedient die jeweils andere Anwendungsinstallation eingehende Anfragen. Nach der Aktualisierung erfolgt das Umschalten des Verkehrs auf die neue Installation. Im Falle eines unerwarteten Fehlers kann man jedoch sofort wieder auf die unveränderte, ältere Anwendungsversion zurückschalten. Verhält sich das System dagegen erwartungsgemäß, aktualisiert der Admin auch die zweite Anwendung.

Auf ähnliche Weise lässt sich das Verteilen von Traffic auf mehrere Anwendungsinstallationen auch für das multivariate Testing einsetzen. Im Fall zweier Varianten entsteht ein sogenannter A/B-Test, der unterschiedliche Benutzergruppen mit zwei verschiedenen Anwendungsversionen konfrontiert, um aus dem beobachteten Nutzerverhalten Rückschlüsse auf die Akzeptanz ziehen zu können. Bei einfachen Tests, wenn etwa zwei unterschiedliche Backend-Implementierungen gegeneinander antreten, helfen gewichtete Routen beim Testen. Sie decken die Anforderungen solcher A/B-Tests jedoch nur teilweise ab: Viele Fälle erfordern eine bewusste Zuordnung von Benutzern zu den einzelnen Varianten, wofür man andere Werkzeuge benötigt.

Im Falle von Canary-Releases wird eine neue Funktion nicht der gesamten Nutzerschaft auf einmal zugänglich gemacht. Ähnlich wie im A/B-Testing trennt man die Nutzergruppe auf. Nur ein Teil sammelt dann erste Erfahrungen, die der Testende auswerten kann, ehe alle in den Genuss der neuen Version kommen.

Wie wird das Service Mesh benutzt?

Sobald der Admin das Cloud Foundry Service Mesh erfolgreich installiert hat, kann er gewichtete Routen anlegen. Wie bereits erwähnt, stellt das Kommandozeilenwerkzeug »cf« noch nicht alle Befehle bereit, sodass der Admin die Befehle direkt gegen die Cloud-Controller-API absetzen muss. Das weitverbreitete Curl [3] hilft dabei.

Zunächst ist es erforderlich, eine Route zu erstellen. Eine Route benennt eine URL und macht sie so der Hauptkomponente im CF-Routing bekannt, dem Gorouter der Cloud Foundry Application Runtime:

# cf create-route development mesh.apps.anynines.com -n testapp

Hierbei gilt es zu beachten, dass die Route zu diesem Zeitpunkt zwar mit einem Space verbunden ist, aber noch nicht mit einer Anwendung. Die Assoziation einer Route zu einer Anwendung, das Route-Mapping, geschieht in einem gesonderten Schritt. Zunächst steht allerdings etwas Vorarbeit an, die der noch unvollständigen Integration geschuldet ist. Als Erstes gilt es, die GUID der Route zu ermitteln (Listing 1).In der Ausgabe kann die GUID der Route im Feld »resources[metadata]« entnommen werden.

$ cf curl /v2/routes?q=host:testapp
{
  "total_results": 2,
  "total_pages": 1,
  "prev_url": null,
  "next_url": null,
  "resources": [
    {
      "metadata": {
        "guid": "83d60b98-5864-45c6-94ad-4d02f5f4216a",
        "url": "/v2/routes/83d60b98-5864-45c6-94ad-4d02f5f4216a",
        "created_at": "2019-11-09T10:40:04Z",
        "updated_at": "2019-11-09T10:40:04Z"
      },
      "entity": {
        "host": "tired-duck-brash-civet",
        "path": "",
        "domain_guid": "fb6bd89f-2ed9-49d4-9ad1-97951a573135",
        "space_guid": "d6cddaa6-0886-44b3-9590-16717d5cd3c2",
        "service_instance_guid": null,
        "port": null,
        "domain_url": "/v2/shared_domains/fb6bd89f-2ed9-49d4-9ad1-97951a573135",
        "space_url": "/v2/spaces/d6cddaa6-0886-44b3-9590-16717d5cd3c2",
        "apps_url": "/v2/routes/83d60b98-5864-45c6-94ad-4d02f5f4216a/apps",
        "route_mappings_url": "/v2/routes/83d60b98-5864-45c6-94ad-4d02f5f4216a/route_mappings"
      }
    }
  ]
}

Das Erstellen einer gewichteten Route in Form eines Route-Mappings erfordert zudem die Angabe einer Anwendung, die man über ihre App-GUID referenziert. Die App-GUID lässt sich leicht ermitteln:

$ cf app testapp --guid a4238936-3f25-463b-4061-d3436e277be3

Nun kann der Admin das Route-Mapping erstellen, das auch die Gewichtung der zugehörigen Anwendung umfasst (Listing 2).

$ curl /v3/route_mappings -X POST -d \
'{
  "relationships": {
    "app": {
      "guid": "a4238936-3f25-463b-4061-d3436e277be3"
    },
    "route": {
      "guid": "83d60b98-5864-45c6-94ad-4d02f5f4216a"
    }
  },
  "weight": 2
}'

Der Gewichtungsfaktor beträgt in diesem Beispiel 2. Damit wäre diese Route doppelt so stark gewichtet wie eine Route mit dem Vorgabewert 1. Die statistische Verteilung der Anfragen auf die einzelnen Route-Mappings ergibt sich durch eine einfache Mittelwertbildung. Die einzelnen Gewichtungsfaktoren aller Mappings werden durch deren Summe dividiert. So ergeben sich die Verteilungsverhältnisse zueinander. Im Falle von zwei Routen mit den Gewichtungen 1 und 2 ergibt sich also 1/3 zu 2/3. Somit gehen rund 33 Prozent der Anfragen an die erste und 66 Prozent an die zweite Anwendung (Abbildung 2).

Abbildung 2: Die Gewichtung regelt die Verteilung der Last auf die Anwendungsinstanzen.

Um das obige Beispiel zu komplettieren, muss der Admin also mit den hier vorgestellten Schritten eine weitere Anwendung sowie ein weiteres Route-Mapping erstellen. Genauere Ausführungen zum Erstellen und Modifizieren von gewichteten Routen finden sich in der Cloud-Foundry-Dokumentation [4].

Fazit

Mit der Einführung des Service Mesh reagieren die Cloud-Foundry-Entwickler auf einen steigenden Bedarf. Entwickler von Anwendungen auf Microservice-Basis benötigen Werkzeuge wie das der gewichteten Routen, um modernen Anforderungen an Produkt- und Softwareentwicklung gerecht zu werden. Vergleicht man die Anwendungsfälle, die Service-Mesh-Technologien wie Istio und Envoy im Kontext von Kubernetes ermöglichen, dann liegt die Vermutung nahe, dass diese auch in Cloud Foundry nachgezogen werden.

Im Anschluss an das gewichtete Routing könnte also Unterstützung für das Circuit Breaker Pattern, Rate Limiting und Outlier Detection folgen. Wann und wie das geschieht bleibt abzuwarten; möglicherweise wird die Cloud Foundry Application Runtime schrittweise angepasst. Alternativ könnten Inkubationsprojekte der Cloud Foundry Foundation wie Eirini [5] der Adaption Vorschub leisten, sollte das bestehende Container-Subsystem der Cloud Foundry Application Runtime durch ein Kubernetes-Backend ersetzt werden. (jcb)