Ausgeschlossene Optionen

Bewertung der Lösungen aus dem Lösungsraum gegen die Anforderungen. Dieses Dokument begründet, welche Optionen ausscheiden und warum.

Verbleibende Kandidaten werden in comparison.md verglichen.

Harte Ausschlusskriterien

Argo Workflows (+ Argo Events)

Ausschlussgrund: Benötigt Custom Resource Definitions (CRDs) und ClusterRoles.

Argo Workflows installiert eigene CRDs (Workflow, CronWorkflow, WorkflowTemplate, etc.) und benötigt einen Cluster-weiten Controller mit ClusterRole-Berechtigungen. Dies verstößt direkt gegen die Anforderung, in einem Kubernetes-Namespace mit limitierten Rechten zu laufen (keine CRDs, keine ClusterRoles).

Apache Camel K

Ausschlussgrund: Benötigt Custom Resource Definitions (CRDs) und einen Cluster-Level Operator.

Camel K ist als Kubernetes Operator konzipiert und installiert eigene CRDs (Integration, IntegrationPlatform, Kamelet, etc.). Der Operator benötigt cluster-weite Berechtigungen. Ohne CRDs und ClusterRoles ist Camel K nicht einsetzbar.

Hinweis: Apache Camel als Library (ohne K) hat dieses Problem nicht, wäre dann aber eine Eigenentwicklung und kein eigenständiger Lösungskandidat im Sinne einer fertigen Pipeline Engine.

Vector

Ausschlussgrund: Deckt die funktionalen Kernanforderungen nicht ab.

Vector ist ein Observability-/Event-Forwarder, kein Integrations-Framework. Konkret fehlen:

• Kein SQL-Konnektor (weder als Input noch Output)
• Keine HTTP-Endpunkt-Bereitstellung (Request/Response)
• Kein Kontrollfluss (if/then/else, switch/case)
• Sehr eingeschränkte Transformationslogik (keine allgemeine JSON-Mapping-/Validierungslogik)
• Kein MQTT-Output

Vector eignet sich als Forwarder innerhalb einer Architektur, nicht aber als Pipeline Engine.

Node-RED

Ausschlussgrund: Nicht produktionstauglich im geforderten Umfang.

• Keine Isolation: Node-RED bietet keine Pipeline-Level-Isolation. Alle Flows laufen im selben Node.js-Prozess -- kein User-to-User- oder User-to-Platform-Schutz.
• Keine horizontale Skalierung: Kein natives Clustering oder Sharding. Skalierung nur durch manuelle Replikation ganzer Instanzen.
• Fehlende Produktionsreife: Konzipiert als Rapid-Prototyping- und Edge-Werkzeug, nicht als mandantenfähige Plattform-Komponente.

ksqlDB

Ausschlussgrund: Lizenzrechtliche und infrastrukturelle Einschränkungen.

• Confluent Community License: Nicht vollständig Open Source. Im Kontext souveräner Betrieb und Air-gapped-Deployment problematisch -- Lizenzbedingungen schränken Nutzung in konkurrierenden SaaS-Angeboten ein.
• Kafka-Abhängigkeit: Erfordert einen vollständigen Kafka/Redpanda-Cluster als Voraussetzung. Erheblicher infrastruktureller Overhead für das beschriebene Mengengerüst.
• Kein MQTT nativ: MQTT-Integration nur über zusätzliche Kafka-Connect-Komponenten.

Kafka Streams

Ausschlussgrund: Unverhältnismäßiger Infrastruktur-Overhead.

• Keine eigenständige Pipeline Engine: Kafka Streams bietet keine Konnektoren, kein Scheduling, keine HTTP-Endpunkte. Müsste mit weiteren Komponenten (Kafka Connect, REST Proxy) zu einer vollständigen Lösung zusammengebaut werden.

Apache Flink

Ausschlussgrund: Massiver Overhead für das Mengengerüst.

• Überdimensioniert: Flink ist für Streaming im Bereich von Millionen Events/Sekunde ausgelegt. Das beschriebene Szenario (500 aktive Datensätze, hochfrequent = 0.5-1s) erfordert diese Kapazität nicht.
• Hoher Ressourcenbedarf: JobManager + TaskManager(s) benötigen signifikante Ressourcen, auch bei geringer Last. Verstößt gegen die Anforderung effizienter Ressourcennutzung bei ungenutzten Sandboxes.
• Komplexer Betrieb: Flink in Kubernetes erfordert entweder den Flink Kubernetes Operator (CRDs!) oder ein manuelles Session-/Application-Mode-Setup mit hohem operativem Aufwand.
• Kein HTTP-Endpunkt-Serving: Flink verarbeitet Streams, stellt aber keine Request/Response-APIs bereit.

Weiche Ausschlussgründe (erhebliche Bedenken)

Die folgenden Optionen sind nicht durch ein einzelnes hartes Kriterium ausgeschlossen, weisen aber in der Summe so viele Lücken auf, dass sie als Kernkomponente der Pipeline Engine nicht in Frage kommen.

EMQX (Rules + Data Integration Bridges)

• BSL-Lizenz: Business Source License ist im Souveränitätsrahmen problematisch, da sie Nutzungseinschränkungen mit sich bringt.
• Kein Pipeline Engine: EMQX ist ein MQTT-Broker mit angehängter Rules Engine. Die Transformationslogik ist auf einfache Regeln beschränkt -- kein vollwertiges Mapping, keine komplexe Kontrollflusslogik, kein Scheduling.
• Mögliche Rolle: Als MQTT-Broker in der Architektur denkbar, aber nicht als Pipeline Engine.

Apache Airflow

• Kein Streaming: Airflow ist ein reiner Batch-Scheduler (DAG-basiert). Ereignisgetriebene oder Stream-Verarbeitung ist nicht vorgesehen.
• Kein nativer MQTT-Support: MQTT-Integration nur über Custom Operators.
• Hoher Ressourcenbedarf: Scheduler + Webserver + Executor + Metadaten-DB. Im Leerlauf mehrere hundert MB RAM.
• Keine HTTP-Endpunkt-Bereitstellung: Airflow stellt APIs für die eigene Verwaltung bereit, nicht für Pipeline-Daten.

Prefect

• Cloud-first-Architektur: Prefect ist stark auf die eigene Cloud-Plattform ausgerichtet. Self-Hosted (Prefect Server) ist möglich, aber Air-gapped-/souveräner Betrieb ist aufwändig.
• Kein MQTT: Keine native MQTT-Integration.
• Python-Abhängigkeit: Pipelines sind Python-Code. Für eine konfigurierbare Plattform (Pipelines per YAML/Config) ist dies ungeeignet.
• Kein Streaming: Batch/Scheduling-fokussiert.

Dagster

• Data-Asset-Fokus: Dagster modelliert Daten-Assets, keine Integrationsflüsse. Für ETL/Analytics konzipiert, nicht für MQTT-basierte IoT-Integration oder HTTP-API-Bereitstellung.
• Kein MQTT: Keine native MQTT-Integration.
• Kein HTTP-Endpunkt-Serving: Kein Request/Response-Modus.
• Python-Abhängigkeit: Wie Prefect rein Python-basiert.

Bento

• Entwicklungsstagnation: Bento entstand als Fork nach der Lizenzänderung von Redpanda Connect (vormals Benthos). Die Entwicklung ist deutlich geringer als beim Original. Langfristige Wartung und Community-Support sind unsicher.
• Funktional identisch zu Redpanda Connect: Wenn Bento gewählt wird, dann kann direkt Redpanda Connect evaluiert werden, das aktiv weiterentwickelt wird.

Apache StreamPipes

• Eingeschränkte Reife: Relativ junges Apache-Projekt mit kleiner Community.
• Fokus auf IIoT-Low-Code: Die UI-gesteuerten Pipelines sind für Fachbereiche gedacht, nicht für eine programmatisch konfigurierbare Plattform.
• Eingeschränkte Konnektoren: Weniger breit als Camel oder Redpanda Connect.
• Mögliche Rolle: Als ergänzende Komponente für Fachbereichs-Szenarien denkbar, aber nicht als Kern-Engine.

SuperMQ + Propeller

• Sehr frühe Phase: Kleine Community, wenig produktive Referenzen.
• Nischenfokus: Edge/WASM-orientiert. Nicht als zentrale Pipeline Engine für eine Plattform ausgelegt.
• Hoher Integrationsaufwand: Müsste mit weiteren Komponenten ergänzt werden, um die volle Anforderungsbreite abzudecken.

Kestra

• Open-Core-Lizenzmodell: Kestra ist nur in der Basisversion Open Source (Apache 2.0). Zentrale Features für die Civitas-Anforderungen liegen bereits in der kostenpflichtigen Enterprise Edition:
  • SSO / OIDC-Integration: Nicht in der OSS-Version.
  • RBAC / Access Control: Nicht in der OSS-Version.
  • Ohne diese Features ist die geforderte Security (User-to-User-Isolation, rollenbasierte DataSet-Berechtigungen) nicht umsetzbar.
• Vendor-Lock-in-Risiko: Als VC-funded Open-Core-Projekt besteht das Risiko, dass weitere Features (z.B. K8s Task Runner, Namespace-Isolation, Audit Logging) in die Enterprise Edition verschoben werden.
• Fazit: Die für Civitas zwingend notwendigen Security-Features sind nicht in der freien Version enthalten. Kestra scheidet damit als Kandidat aus.

Verbleibende Kandidaten

Nach dieser Analyse verbleiben als ernstzunehmende Kandidaten:

Kandidat	Kategorie	Stärke
Redpanda Connect	Integrationsplattform	Breite Konnektoren, YAML+Bloblang, leichtgewichtig, kein CRD, Helm-fähig
Apache NiFi	Integrationsplattform	Flow-UI, Backpressure, MQTT/HTTP-Prozessoren, Registry-Versionierung

Diese beiden Kandidaten erfüllen die harten Anforderungen. Detaillierte Architekturskizzen: Redpanda Connect | Apache NiFi