Prädiktives maschinelles Lernen entwickeln, mit Flink | Workshop am 18. Dezember | Jetzt registrieren

Apache Kafka: selbst gehostet oder als Managed Service? Ein Vergleich verschiedener Cloud-Services

Confluent Cloud ist der branchenweit einzige Cloud-native Service auf Basis von Apache Kafka für umfangreiches Daten-Streaming. Confluent wurde für die Cloud konzipiert, im Gegensatz zur einfachen Installation von Kafka in einer Cloud-Infrastruktur. Confluent bietet ein umfassendes, vollständig verwaltetes Daten-Streaming, -Verarbeitungs und -Analyse-Erlebnis über Public und Private Clouds hinweg.

Arten von verwalteten Services für Apache Kafka

Cloud-nativ

  • Entwickelt für die Cloud mit einer Architektur, die elastische Rechenleistung und unbegrenzten Speicherplatz bietet
  • Integrierte Automatisierung während des gesamten Kafka-Prozesses zur Reduzierung des operativen Aufwands
  • Flexibilität bei der Bereitstellung mit konsistenten Erfahrungen über verschiedene Clouds hinweg und der Möglichkeit zur Selbstverwaltung On-prem

Cloud-gehostet

  • Installierte Software auf selbst bereitgestellter Cloud-Infrastruktur mit traditioneller Broker-Architektur
  • Manueller Betrieb mit Provider- oder Open-Source-Tools für Aktivitäten, die über die Bereitstellung hinausgehen
  • Auf einen einzigen Cloud-Anbieter beschränkte Bereitstellung und/oder fehlende Option zur Selbstverwaltung On-prem

Cloud-natives vs. Cloud-gehostetes Kafka

Die Cloud-native Transformation mit Kafka geht über die Bereitstellung hinaus und erstreckt sich von der Dimensionierung bis zur Skalierung. Während ein in der Cloud gehosteter Service zwar die Bereitstellung von Kafka vereinfachen kann, bleibt anschließend aber immer noch der manuelle Betrieb und das Infrastruktur-Monitoring.

Die Wahl eines verwalteten Kafka-Services kann Unternehmen entweder dabei helfen, alle Vorteile von Kafka zu nutzen oder zu einer Verringerung der Entwicklerproduktivität führen und Markteinführungen aufgrund ungeplanter manueller Vorgänge verzögern.

Cloud-natives Erlebnis mit Confluent Cloud-gehostetes Erlebnis mit anderen Services
Dimensionierung Durchsatzbasiert
Durch eine Cluster-Dimensionierung, die auf Streaming-Anforderungen wie dem Durchsatz basiert, entfallen mühsame Performance-Tests und Kapazitätsplanung. Mit unbegrenztem Speicherplatz auf Cluster-Ebene und elastisch skalierbaren Clustern mit Scale-to-Zero-Pricing bei denen nur für die Nutzung und nicht für die bereitgestellte Infrastruktur bezahlt wird, können gleichzeitig Infrastrukturkosten gesenkt werden.
Broker-basiert
Zur Auswahl der Broker- oder Instanz-Typen und der Anzahl müssen Zeit und technische Ressourcen für mehrere Performance-Tests eingeplant werden. Das Pricing basiert auf Infrastrukturkomponenten, die sowohl für Rechen- als auch für Speicherkapazitäten bereitgestellt werden, und zwar für alle Cluster, auch für solche, die während der Entwicklung einen geringen Durchsatz haben.
Infra-Monitoring Proaktives Monitoring mit Confluent
Proaktive Cluster-Überwachung und Wartung durch die Kafka-Experten ermöglicht eine Fokussierung auf die App-Entwicklung. Ferner ermöglicht Infinite Storage unbegrenzte Anwendungsfälle auf Cluster-Ebene, vereinfacht die Kapazitätsplanung und verringert das Risiko von Ausfällen im Zusammenhang mit Festplattenspeicher.
Manuelles Monitoring
Ressourcen zur Überwachung von Broker-Metrics wie der CPU-Auslastung müssen zugewiesen werden, um die Cluster-Performance proaktiv zu managen und gleichzeitig Festplattenspeicher-Alerts zu überwachen und zu managen, um Ausfälle aufgrund der Speicherkapazität zu verhindern.
Topic-Monitoring Vorab-aggregierte und kostenlose Metrics
Wichtige Metriken, die mit Data Flow auf Topic- und Cluster-Ebene aggregiert werden, liefern wertvollste Erkenntnisse über alle Anwendungen — ohne zusätzliche Kosten. Aggregierte Metriken können über die Metrics-API vom bevorzugten Drittanbieter-Monitoring-Service genutzt werden.
Metriken pro Broker und Topic kosten extra
Für die Nutzung und manuelle Aggregation von Metriken auf Pro-Broker- und Pro-Topic-pro-Broker-Ebene, um den Verbrauch auf Topic- und Cluster-Ebene zu überwachen, entstehen weitere Kosten. Nutzer müssen außerdem eine Verarbeitungs- und Aggregationslogik der Metriken pflegen, um Daten nach Event-Skalierungen und wenn Partitionen über verschiedene Broker hinweg neu ausbalanciert werden, genau darzustellen.
Upgrades Immer auf der neuesten Version
Kein Aufwand für laufende Upgrades auf die neueste stabile Kafka-Version, die strategische Patches vor geplanten Apache-Releases enthält. Upgrades sind unterbrechungsfrei, um die per SLA garantierte Verfügbarkeit zu gewährleisten.
Eingeschränkte Versionen-Unterstützung
Upgrades müssen manuell ausgeführt werden, sobald Haupt-Versionen nach einem geplanten Apache-Release unterstützt werden. Während des Upgrade-Prozesses liegt zudem die Cluster-Verfügbarkeit in der Verantwortung des Nutzers.
Patching von Sicherheitslücken Proaktive Fixes
Sicher und zuverlässig streamen mithilfe von Kafka-Experten, die proaktiv bekannte Bugs und Schwachstellen beseitigen und selbst die kompliziertesten Kafka-Probleme beheben.
Nicht verfügbar
Ausfälle aufgrund von Software sind von den Verfügbarkeits-SLAs ausgeschlossen.
Cluster-Erweiterungen Elastische Skalierbarkeit
Automatische Ressourcenzuweisung für die Cluster, um Consumer-Lag zu vermeiden, wenn der Durchsatz mit selbst ausgleichenden Clustern zu- oder abnimmt. Infinite Storage vermeidet eine übermäßige Bereitstellung von Cluster-Rechenleistung und erhöht gleichzeitig die Topic-Retention.
Broker ohne Data Balancing hinzufügen
Nachdem Broker zu einem beliebigen Cluster hinzugefügt wurden, ist ein manueller Data-Rebalancing-Prozess mit Service-Provider- oder Drittanbieter-Tools wie Cruise Control erforderlich. Speicherplatzbeschränkungen pro Broker/Instanz zwingen Nutzer dazu, entweder mehr für Rechenleistung auszugeben oder Daten aus Kafka zu exportieren, wenn die Daten lange vorgehalten werden sollen.
Connectors Vorgefertigt und vollständig verwaltet
Beschleunigte Integration von modernen und Legacy-Services in On-Premises und Public Clouds mit einem ständig wachsenden Portfolio von über 120 Source- und Sink-Connectors. Vollständig verwaltete Connectors reduzieren den operativen Aufwand für die Bereitstellung, Verwaltung und Unterstützung zusätzlicher Infrastruktur für Integrationen.
Eigenständige Entwicklung und Verwaltung
Verlangsamte Abläufe aufgrund nicht wiederholbarer Integrationen in Daten-Services. Der operative Aufwand erhöht sich auch bei der Verwendung von Community-Connectors, da die Nutzer zusätzliche Connect-Cluster ohne Unterstützung selbst verwalten müssen.
Non-Java-Clients Confluent-unterstützt
Entwicklungsgeschwindigkeit erhöhen und Kafka für Anwendungen und Services mit einer Vielzahl von praxiserprobten Clients für C, Java, .Net, Go, Python und mehr zugänglich machen.
Selbstverwaltet
Nutzung selbst- oder von der Community erstellter Clients ohne technischen Support des Service-Anbieters.
Support Committer-getriebene Expertise
Erfahrene 24x7-Support-Engineers haben Zehntausende Probleme im Zusammenhang mit Kafka gelöst, die als Commits ins Open-Source-Projekt eingeflossen sind. Markteinführungen können durch das Know-how und die Unterstützung des Professional Services Teams weiter beschleunigt werden.
Begrenzte Expertise
Begrenzte Erfahrung mit der Unterstützung und Wartung von Kafka und seinem Ökosystem.
Umgebungen Die freie Wahl
Einheitliche Cloud-native Erfahrung in AWS, Azure und Google Cloud mit Subscribe-Option direkt über die jeweiligen Marketplaces, um die Abrechnung zu vereinfachen. Erweiterung der Event-getriebenen Architektur auf lokale oder private Cloud-Umgebungen mit Confluent Platform, unserer selbstverwalteten Software.
Eingeschränkt
Der Service ist auf einen einzigen Cloud-Anbieter beschränkt und/oder es fehlt eine selbstverwaltete Softwareversion für den vereinfachten On-Prem-Kafka-Betrieb.
Ökosystem Umfassend
Mit einem umfassenden Ökosystem einschließlich Schema-Management und Stream-Verarbeitung bietet Confluent weit mehr als nur einen Kafka-Service. Entwickler können die Anwendungskompatibilität mithilfe der vollständig verwalteten Schema Registry gewährleisten und mit vollständig verwaltetem Flink Echtzeit-ETL-Pipelines entwickeln.
Begrenzt
Nur Apache Kafka-Cluster.

Cloud-nativ unterwegs – noch heute mit Confluent