Developer and DevOps Experience is key with Ambassador!

Was ist Ambassador?

Ambassador selbst beschreibt sich als ‘Developer-First Kubernetes’. Hierbei steht das Builden von Cloud Native Applications / Microservices aus der Entwicklersicht klar im Vordergrund.

Das Wort Ambassador bedeutet ‘Botschafter’.

Die Firma Ambassador Labs (vorher Datawire) wurde 2014 gegründet und ist stark auf das Thema DevOps für Kubernetes fokussiert. Die global agierende Firma mit dem Hauptsitz in Boston führt sowohl Open Source als auch kommerzielle Produkte.

Aus welchen Komponenten besteht Ambassador?

DCP - Developer Control Plane

Die Idee hinter diesem Developer-focused Control Plane ist, dass Entwickler heutzutage für viel mehr als nur ihren eigenen Code verantwortlich sind. Bisher hatte man seine lokale Anwendung, welche man mit einigen wenigen Sprachen entwickelt und getestet hat. Der ganze Build & Deployment Prozess funktioniert irgendwie und man muss sich weiter um nichts kümmern.

Sobald dann das Wort DevOps ins Spiel kommt, ändert sich schlagartig alles. Man ist als Entwickler plötzlich technisch für die gesamte Applikation inkl. CI/CD, Zertifikatsmanagement, Betrieb, Provisioning und so weiter verantwortlich, muss sich mit weit mehr Tools und Sprachen auseinandersetzen als zuvor.

Der Full-Stack Developer wird zu einem Full-Lifecycle Developer, da er neben der eigentlichen Entwicklung auch für Testing, Q/A, Building & Deploying, Running, Monitoring etc. verantwortlich ist. Diese Terminologie des Full Lifecycle oder Full Cycle Developer kommt ursprünglich von Netflix und identifiziert eine neue Spezies von Entwicklern.

Ambassador will mit der DCP ein Dashboard bieten, welches den Full Lifecycle Developer bei diesen neuartigen Aufgaben unterstützt und speziell auf diesen Einsatz zugeschnitten ist.

Figure: Quelle: 31.08.2021: https://blog.getambassador.io/introducing-the-ambassador-developer-control-plane-339c97fa4716

Grundlegend gibt es hier drei grosse Bausteine:

DCP - Code

Hierbei geht es um die eigentliche Entwicklungsarbeit und die unterschiedlichen Umgebungen. Der Entwickler kann über die DCP unterschiedliche Umgebungen konfigurieren sowie APIs, welche für die Entwicklung zur Verfügung stehen, einsehen und erkunden.

Klassische Tools in diesem Sektor sind die IDE, Source Control and Continuous Integration Systems (CI). Ambassadors Produkt in diesem Sektor heisst Telepresence.

DCP - Ship

Hierbei geht es um das Veröffentlichen von Updates inkl. Zero Downtime Deployments und Canary Releasing. Ein Canary Release beschreibt das Konzept von einem ’langsamen’ Rollout einer neuen Version. Gleich wie bei einem Blue / Green Deployment wird die neue Version komplett deployed, bei einem Canary Release werden aber nur wenige User auf den neuen Release geleitet. Populäre Auswahlkriterien der Benutzer neben dem Zufallsprinzip sind z. B. bestimmte Benutzergruppen. Oft werden auch erst interne Mitarbeiter auf eine neue Releaseversion gelassen, bevor diese nach aussen freigegeben wird. Dies hat den grossen Vorteil, dass ein Release erst ausgiebig getestet und Schritt für Schritt freigegeben werden kann.

So kann es schnell passieren, dass mehrere Versionen einer Anwendung veröffentlicht und im Einsatz sind. Wichtig hier ist, dass diese Praxis meist nicht nur auf den Applikations- oder Webserver beschränkt ist und es oft auch eine parallele oder dedizierte Datenbank für einen neuen Release gibt.

Ausserdem ermöglicht die DCP ein ständiges Monitoring der aktuell veröffentlichten Versionen sowie deren Verteilung im Canary Release.

Klassische Tools in diesem Sektor sind die Container Management Tools, Kubernetes Manifest Templates und Continuous Deployment Systems (CD).

Ambassador erfindet hier das Rad nicht neu, sondern greift zu bewährten Tools wie zum Beispiel ArgoCD.

DCP - Run

Hierbei geht es um das Monitoring und die Sicherstellung eines 24x7 Betriebs der Applikation. Durch diese Teile der Control Plane sollen Fehler oder Anomalien identifiziert und analysiert werden können.

Klassische Tools in diesem Sektor sind die API Gateways und Observability / Monitoring Systems.

Auch hier kommt eine bereits bekannte Technologie zum Einsatz. Der Enovy Proxy fungiert auch in diesem Setup als Sidecar Container.

Telepresence

Telepresence erlaubt es, Teile einer komplexen Kubernetes Applikation lokal laufen zu lassen.

Cloud Native Applikationen können schnell zu gross und zu komplex werden, um sie mit allen beweglichen Teilen und Abhängigkeiten lokal zu starten. Mit Telepresence wird ein smarter Proxy genutzt, um den Traffic eines bestimmten Services (Microservice) an die lokale Entwicklungsumgebung weiterzuleiten. So wird quasi der eigene Rechner oder Laptop in das Kubernetes Cluster eingebunden.

Aufgerufen wird die gesamte Applikation dann über eine gewisse Preview URL, welche das Routing des Zielservices an die lokale Maschine aktiviert. Technisch gesehen wird beim Aufruf dieser Preview URL ein Header an den Request gehängt. Anhand dieses Headers entscheidet dann der Telepresence Proxy, ob der Traffic zum echten Service oder zum lokal laufenden Service gerouted werden soll.

Telepresence wurde vor Kurzem in der Version 2.0 veröffentlicht, welche nun nicht mehr in Python, sondern in Go Lang geschrieben ist. Ausserdem wurde die Version 2 speziell auf den Einsatz in Corporate Netzwerken, beispielsweise in Kombination mit VPNs entwickelt.

Konkret gibt es zwei Modi welche entscheiden, wie der Traffic weitergeleitet wird. Im Default Modus wird sämtlicher Traffic direkt an die lokale Maschine geleitet; die laufende Applikation wird somit vollständig beeinflusst. Im Collaboration Modus ist es möglich nur bestimmte Benutzer, über eine preview URL, auf die lokale laufende Instanz eines Microservices zu leiten. So bleibt die Applikation an sich unberührt und kann weiterhin normal genutzt werden.

Der grosse Vorteil dieses Konzeptes ist die Zeitersparnis. Bei kurzen Tests im Cluster muss nicht immer der komplette CI / CD Prozess durchlaufen werden, sondern es ist möglich nur bestimmte User auf die lokale Instanz lotsen. So erhält man ein wesentlich schnelleres Feedback und kann sich beim Pair Programming viel einfacher austauschen. In einem heterogenen System ist es oft umständlich ein Bug lokal nachzustellen. Auch hier schafft Telepresence Abhilfe, indem man die lokale Instanz einfach debuggen und anschliessend den erforderlichen Fix direkt im CLuster vornehmen kann.

In folgendem Bild ist die Architektur von Telepresence beschrieben. Über einen sogenannten Traffic Manager wird gesteuert, wohin bestimmter Traffic geleitet wird. Der Traffic Agent sorgt als Sidecar Proxy Container dafür, dass alle Container angesprochen werden können.

Figure: Quelle: 31.08.2021: https://www.getambassador.io/docs/telepresence/latest/reference/architecture/

Telepresence muss lokal und im Cluster installiert und konfiguriert werden. Das Forwarding kann dann vom lokalen Rechner, mit gültiger kubeconfig, gestartet werden. Wir werden dieses Thema in einem weiteren TechUp noch genauer unter die Lupe nehmen.

Edge Stack

Ambassador Edge Stack beschreibt den kompletten Prozess eines Requests vom Kunden bis zur Applikation.

Dieser Prozess besteht aus unterschiedlichen Komponenten wie z. B. dem Ambassador Kubernetes API Gateway.

Hierbei werden die folgenden API Gateway Funktionalitäten unterstützt:

• Authentication
• Rate Limiting
• Access Control

Der Edge Stack besteht aber noch aus weit mehr Komponenten wie beispielsweise einem Kubernetes Ingress Controller, welcher für das Traffic-Management zuständig ist.

Out-of-the-box liefert Ambassador auch eine Service Mesh Provider Integration für Service Discovery, End to End TLS und Observability. Diese können mit bekannten Service Mesh Providern wie Istio oder LinkerD verwendet werden.

‘Under the hood’ läuft bei Edge Stack der bereits aus anderen TechUps (Istio) bekannte Envoy Proxy.

Ein weiterer Bestandteil des Edge Stacks sind die Delivery Accelerator. Dies ist eine Zusammenfassung von unterschiedlichen CI/CD Features um Microservices schnell und einfach direkt aus GitHub deployen zu können. Hierbei wird das Open-Source-Projekt Kaniko von Google genutzt, um in sogenannten Micro CD Pipelines schnell GitHub Code bauen und deployen zu können.

So bietet der Edge Stack, zumindest auf den ersten Blick, sehr viele Komponenten, welche in einem produktiven Real World Case nützlich oder notwendig sind.

Emissary-Ingress

Emissary-Ingress ist ein Open Source Kubernetes-native API Gateway, Layer 7 Load Balancer und Kubernetes Ingress (aufbauend auf Envoy Proxy). Dieses Produkt war früher bekannt als Ambassador API Gateway und ist heute in der CNCF Landscape als Incubating Tool zu finden. Der eigentliche Edge Stack baut hier als Enterprise Produkt komplett auf dem Open Source Emissary Ingress auf.

Pricing

Ambassador hat ein sehr ausgeklügeltes Preismodell, grundlegend gibt es drei Pakete:

• Open Source

  • Teile der Ambassador Palette sind Open Source wie z. B. das Traffic-Management mit Edge Stack
  • Das Developer Portal ist in der Open Source Version nicht vorhanden
  • Telepresence bietet nur die Möglichkeit, den Service ganz auszutauschen und nicht nur bestimmte User auf die lokale Instanz lotsen
  • Diese Produkte sind zu 100 % Open Source und können einzeln oder gemeinsam genutzt werden

• Free

  • Beinhaltet alle Funktionalitäten für bis zu 5 Services
  • Die Security Features im Edge Stack sind hierbei auf bis zu 5 Requests pro Sekunde beschränkt

• Standard bzw. Enterprise

  • Mehr als 5 Services bzw. 5 Requests pro Sekunde
  • Umfangreicher Support

Fazit

Abschliessend kann man sagen, dass das ganze Ambassador Konstrukt in der Theorie sehr vielversprechend klingt, grundsätzlich aber sehr undurchsichtig ist. Es ist schwer einzusehen, was Open Source und was kostenpflichtig ist. Nichtsdestotrotz wollen wir Ambassador Hands On ausprobieren und sehen, was es kann, was es gut oder eher passabel macht.

Stay tuned!