In wenigen Schritten zum self-managed Kafka Cluster in der Public Cloud

Seit ich vor rund 3 Jahren meinen Blogpost Apache Kafka und was es mit dem Hype auf sich hat geschrieben habe, ist vieles passiert in der Welt des Stream Processings. Apache Kafka ist definitiv kein Hype mehr, dies belegen eindrückliche Zahlen: Gemäss Confluent haben 

• 6 von 10 Unternehmen aus der Reisebranche
• 7 von 10 der Grossbanken
• 8 von 10 Versicherungsunternehmen
• sowie 9 von 10 Telekommunikationsunternehmen Kafka produktiv im Einsatz. 

Nicht zuletzt dürfte einer der Hauptgründe die breite Einsatzmöglichkeit für unterschiedlichste Use Cases sein. Mario Maric beschreibt einige davon in seinem Blogpost zu drei unterschiedlichen Architektursmustern.
Die grosse Popularität hat auch eine stark wachsende Community gebildet, welche intensiv an der Entwicklung von Apache Kafka sowie an Tools und Produkten im Kafka-Ökosystem arbeitet. 
Doch das Aufsetzen und Betreiben eines Kafka Clusters sowie dem Ökosystem (Kafka Connect, Schema Registry, KSQL, ...) stellt IT-Abteilungen vor Herausforderungen. Es bedingt sehr viel technisches Know-How und ein entsprechend aufgestelltes Team.

Es gibt unterschiedliche Ansätze, wie Kafka Cluster betrieben werden können:

• Fully-managed (oder auf Kafka-as-a-Service): Wird beispielsweise von Confluent angeboten und bedeutet, dass sie sich um den kompletten Cluster Aufbau und Betrieb in der gewünschten Public Cloud kümmert. Dies beinhaltet auch automatische Skalierung bei zunehmender Auslastung. Abgerechnet wird verbrauchsbedingt direkt über den entsprechenden Public-Cloud Provider.
• Self-managed: Der self-managed Ansatz bedeutet nichts anderes, als dass man selber für den Aufbau und Betrieb des Clusters zuständig ist. Dies kann in der Public Cloud, private Cloud oder on-Premise sein. Im Unterschied zum fully-managed Angebot hat man die volle Kontrolle über das Setup, was aber nicht zwingend nur Vorteile hat. Monitoring und Skalierung beispielsweise müssen selber umgesetzt werden. Trotzdem ist es heute dank Operatoren einfacher denn je, einen Cluster selbst zu betreiben.

In diesem Blog möchte ich aufzeigen, was man braucht, um in wenigen Schritten einen self-managed Kafka Cluster mit Hilfe eines Operators in der Public Cloud zu deployen. 

Einführung

Kafka in Container

Container sind in der heutigen cloud-nativen Welt nicht mehr wegzudenken. Dies gilt auch für Kafka. Obwohl Kafka auch auf Bare-metal und VMs deployed werden kann, ist der de-facto Standard heute container-basiert mit einem Orchestrator wie Kubernetes. Nebst der einfachen Skalierung, die Kubernetes mitsichbringt, gibt es viele weitere Vorteile. Einer davon sind die Kubernetes Operatoren.

Der Kubernetes Operator Pattern

Ein Kubernetes Operator ist nichts anderes als eine Erweiterung für Kubernetes, welche einen gewünschten Zustand auf einem Cluster herstellt. Vereinfacht gesagt wird ein Zustand definiert, also was auf dem Cluster deployed werden soll (z.B. ein Kafka Deployment mit 3 Brokern). Der Operator interpretiert diesen Zustand und führt entsprechende Operationen aus, um diesen zu erreichen, und prüft permanent, dass dieser Zustand so bleibt. Gerade bei einem komplexen Deployment wie Kafka, wo viele Konfigurationen zusammenspielen müssen, welche üblicherweise “von Hand” gepflegt werden, ist ein Operator eine enorme Unterstützung.

Diesen Operator-Pattern haben sich unterschiedliche kommerzielle und opensourced Projekte zunutze gemacht, indem sie Kafka Cluster Operatoren entwickelt haben. Es haben sich unterschiedliche Ansätze bewährt, wobei einer von Confluent, der treibenden Kraft hinter dem Open Source Projekt Apache Kafka konstruiert wurde, sowie ein Opensource Projekt namens Strimzi.

Infrastruktur in der Cloud

Immer mehr Unternehmen wagen den Schritt in die Cloud - und dies zurecht, denn die Vorteile liegen auf der Hand: Time-to-Market, Optimierung der Kosten, mehr Agilität, etc.
Gerade in Bezug auf Agilität kann die Cloud Punkten: Managed Kubernetes Cluster lassen sich mit wenigen Klicks oder CLI-Befehlen in der Cloud deployen und skalieren. Vorbei sind die Zeiten, wo man nach Erstellen eines Order-Tickets mehrere Tage auf die Bereitstellung eines Dienstes oder Systems wartet.
Während man für einen PoC ohne weiteres die Infrastruktur zusammenklicken kann, will man jedoch für ein produktives Setup diesen Prozess vorhersagbar und wiederholbar ausführen. Diese Aufgabe kann mit Hilfe von Infrastructure-as-code (IaC) Tools bewerkstelligt werden. Eines der bekanntesten Tools in diesem Bereich ist Terraform von Hashicorp. Mit Terraform lässt sich Cloud Infrastruktur deklarativ (also anhand eines gewünschten Zielzustandes) beschreiben und entsprechend provisionieren, und dies über sämtliche grosse Hyperscaler wie Google, Amazon, Microsoft oder auch Alibaba Cloud hinweg. Dies kann dann attraktiv werden, wenn man eine Hybrid-Cloud Strategie verfolgen will und somit mehrere Cloud-Provider gleichzeitig bedient.

Durch die Infrastrukturbeschreibung anhand von Zustandsdateien lässt sich das Ganze auch sehr gut in einen GitOps-Prozess integrieren. Das heisst, Änderungen an der Infrastruktur sind versioniert und können nur mit einem Approval durchgeführt werden.

Mögliches Vorgehen beim Erstellen eines self-managed Clusters in der Public Cloud

Folgende Schritte sollten berücksichtigt werden, wenn man Kafka self-managed in der Public Cloud betreiben will:

• Auswahl des Cloud Providers
  Managed Kubernetes Angebote gibt es mittlerweile bei allen Hyperscaler, sprich Google Cloud, Amazon und Microsoft. Je nachdem, wie weit ihr Unternehmen bereits mit der Cloud Journey ist, ist der Provider möglicherweise schon vorgegeben. Hier sollten auch zwingend Governance-Aspekte berücksichtigt werden. Das beinhaltet Fragen wie: 
  
  Wo sind die Daten? 
  
  Wie müssen die Daten verschlüsselt sein? 
  
  Wer hat Zugriff auf die Daten?
   
• Kafka Operator evaluieren
  Es gibt sowohl kommerzielle wie auch open sourced Kafka Operatoren. Hier sollten die Anforderungen genau geprüft werden. Nicht alle Features sind in beiden Varianten zu finden.
  Es bietet sich an, die Operatoren mit einem PoC zu testen, am besten gleich auf dem Cloud Provider, für den man sich im ersten Schritt entschieden hat.
   
• Provisionierungstool bestimmen
  Wie bereits angesprochen, kann man über das Web-Interface der Cloud Provider relativ einfach und schnell Infrastruktur provisionieren. Dies mag für den Start ausreichend sein, aber für produktive Setups sollte dies idealerweise mittels IaC Tool erfolgen. Terraform ist ein mögliches Tool, es gibt aber einige Alternativen.

Fazit

Kombiniert man die Fähigkeiten eines Kafka Operators zusammen mit den Vorteilen der Public Cloud, hat man das Beste aus zwei Welten. Folgende Punkte sprechen für deren Einsatz:

• Die Public Cloud überzeugt gegenüber klassischen on-Premise Landschaften unter anderem mit Agilität und reduzierten Kosten, und das alles unter Einhaltung sehr hoher Sicherheitsstandards
• Kubernetes Operatoren vereinfachen Deployments auf Kubernetes massiv, indem sie einen gewünschten Zustand auf einem Kubernetes Cluster automatisiert abbilden
• Es gibt kommerzielle wie auch Open Source Kafka Operatoren
• Die Kafka Operatoren beinhalten auch Komponenten des Kafka-Ökosystems wie Kafka Connect, Schema Registry, etc.
• Infrastruktur in der Cloud kann mit Hilfe von IaC Tools vorhersagbar und wiederholbar provisioniert werden
• Sowohl für die Infrastruktur wie auch den Kafka Cluster Zustand kann der GitOps-Ansatz genutzt werden, in dem die entsprechenden Artefakte versioniert in einem Repository abgelegt werden. Änderungen sind nur über Approvals möglich.
• Die Skalierung des Clusters ist sehr einfach und kann jeweils der Auslastung angepasst werden