IBM App Connect ist kein einzelnes Produkt mit einer einzigen Bereitstellungsoption. Es gibt einen verwalteten Cloud-Service, eine On-Premise-Engine, eine container-native Bereitstellung auf Red Hat OpenShift oder Kubernetes sowie verschiedene Hybrid-Kombinationen aus diesen drei Varianten. Unternehmen, die App Connect evaluieren, gehen oft davon aus, dass die Entscheidung binär ist: Cloud oder On-Premise. Das stimmt nicht, und die Wahl des falschen Modells schafft Probleme, die sich nur mit hohem Aufwand rückgängig machen lassen, sobald Integrationsflows darauf aufgebaut sind.
Dieser Leitfaden geht auf jede Bereitstellungsoption ein: wofür sie sich tatsächlich eignet, wo ihre Grenzen liegen und wie Sie ein Bereitstellungsmodell an die Infrastruktur und die Compliance-Anforderungen Ihres Unternehmens anpassen.
Vier Bereitstellungsmuster decken die meisten Unternehmensszenarien ab:
Alle drei technischen Bereitstellungsformen von App Connect Enterprise, On-Premise und als Container, laufen auf derselben zugrunde liegenden Integrations-Engine. Das ist für die Migration relevant, die dieser Leitfaden später behandelt.
App Connect as a Service ist das verwaltete Cloud-Angebot von IBM, konzipiert für Teams, die Integrationsflows aufbauen möchten, ohne eigene Infrastruktur zu betreiben.
Der Service bietet einen browserbasierten Low-Code-Flow-Designer mit vorgefertigten Connectors für gängige SaaS-Plattformen wie Salesforce, Workday und Slack. IBM übernimmt Provisioning, Skalierung, Patches und Verfügbarkeit. Flows lassen sich zeitgesteuert, durch ein Ereignis oder über einen API-Aufruf auslösen. Bei Bedarf lässt sich der Service zudem in das umfassendere Ökosystem von IBM Cloud Pak for Integration einbinden.
Der grösste Vorteil ist Geschwindigkeit. Teams kommen von einer Business-Anforderung zu einem funktionierenden Integrationsflow in Stunden statt Wochen, da keine Infrastruktur bereitgestellt oder gepatcht werden muss. Das eignet sich für Business-Technologen und kleinere Integrationsteams, die SaaS-Anwendungen verbinden müssen, ohne tief in die technische Umsetzung involviert zu sein.
Das SaaS-Modell tauscht Kontrolle gegen Komfort. Anpassungen beschränken sich auf die Connectors und Aktionen, die IBM in die Plattform integriert hat, Optionen für individuellen Code sind minimal, und Unternehmen mit strengen Anforderungen an die Datenresidenz stellen möglicherweise fest, dass die verwaltete Multi-Tenant-Infrastruktur nicht mit ihrer Compliance-Haltung vereinbar ist. Komplexe, mehrstufige Orchestrierung über viele Systeme hinweg lässt sich in diesem Modell schwerer aufbauen und pflegen als bei App Connect Enterprise.
App Connect Enterprise On-Premise ist die klassische Bereitstellungsform: die vollständige Integrations-Engine, installiert auf Infrastruktur, die das Unternehmen selbst besitzt und direkt betreibt.
Diese Bereitstellung bietet Zugriff auf das vollständige Toolset von App Connect Enterprise, einschliesslich individuellem Code in ESQL und Java, komplexer mehrstufiger Orchestrierung über mehr als zwei Systeme hinweg sowie der Integration von On-Premise-Legacy-Systemen ohne cloudfähige API. Sie geht auf IBM Integration Bus und WebSphere Message Broker zurück, und Unternehmen, die diese älteren Plattformen betreiben, migrieren ihre Flows in der Regel zuerst auf dieses Modell.
Die On-Premise-Bereitstellung bietet volle Kontrolle über Datenresidenz, Netzwerkisolation und Sicherheitskonfiguration, was für Unternehmen in regulierten Branchen wie Finanzwesen, Gesundheitswesen und öffentlicher Verwaltung besonders wichtig ist. Sie ermöglicht zudem eine tiefgehende Anpassung für Integrationsszenarien, die die Standard-SaaS-Connectors nicht abdecken.
Das Unternehmen trägt die gesamte operative Verantwortung: Hardware bereitstellen, die Runtime patchen, für Lastspitzen skalieren und Hochverfügbarkeit sicherstellen. Das erfordert eigenes Fachpersonal für Integrationstechnik, und das Hochskalieren bei einem plötzlichen Traffic-Anstieg dauert deutlich länger als in einer verwalteten Cloud-Umgebung.
Diese Bereitstellung nutzt dieselbe App-Connect-Enterprise-Engine wie das On-Premise-Modell, verpackt jedoch als Container auf Red Hat OpenShift oder Kubernetes, in der Regel über IBM Cloud Pak for Integration.
Integrationsflows werden als Container-Images verpackt und über Standard-Kubernetes-Tools bereitgestellt, einschliesslich Helm Charts und Operators. Das ermöglicht dieselben Funktionen für individuellen Code und Orchestrierung wie beim On-Premise-Modell von App Connect Enterprise, kombiniert mit container-nativer Skalierung, Rolling Updates und CI/CD-Integration.
Unternehmen, die bereits Kubernetes oder OpenShift betreiben, erhalten elastische Skalierung und DevOps-orientierte Bereitstellungspraktiken, ohne auf die Anpassbarkeit und Kontrolle der Enterprise-Engine zu verzichten. Integrationsflows lassen sich versionieren, testen und über dieselben Pipelines bereitstellen, die das übrige Plattformteam bereits verwendet.
Dieses Modell setzt operative Reife im Umgang mit Kubernetes oder OpenShift voraus. Teams ohne bestehende Erfahrung mit Container-Plattformen stehen vor einer steileren Lernkurve als beim SaaS- oder klassischen On-Premise-Modell, und der Betrieb des Clusters selbst, ob selbst verwaltet oder über einen verwalteten OpenShift-Service, bringt zusätzlichen operativen Aufwand mit sich.
Bei der hybriden Bereitstellung werden Cloud-gehostete App-Connect-Flows mit On-Premise-Systemen verbunden, in der Regel über eine sichere Verbindung, die es einer Cloud-Integration ermöglicht, auf interne Datenbanken und Anwendungen zuzugreifen, ohne sie direkt dem Internet auszusetzen. Dieses Muster eignet sich für Unternehmen, die die Geschwindigkeit Cloud-gehosteter Flows für SaaS-zu-SaaS-Integrationen nutzen möchten, während sie Flows, die sensible oder On-Premise-Legacy-Systeme betreffen, unter direkter Kontrolle behalten.
Der Kompromiss ist architektonische Komplexität. Eine hybride Umgebung bedeutet zwei zu pflegende Betriebsmodelle, zwei Sätze von Monitoring- und Zugriffskontrollen sowie einen Netzwerkpfad zwischen Cloud und On-Premise, der abgesichert und verfügbar gehalten werden muss. Hybride Bereitstellung ist eine bewusste Entscheidung für Unternehmen mit einer echten Trennung zwischen cloudfähigen und an On-Premise gebundenen Systemen, kein Standardausgangspunkt.
| Dimension | Cloud SaaS | On-Premise | Container (OpenShift/Kubernetes) |
|---|---|---|---|
| Infrastruktureigentum | IBM-verwaltet | Kundenverwaltet | Kundenverwaltet (Cluster), IBM-Engine |
| Anpassbarkeit | Beschränkt auf vorgefertigte Connectors | Vollständig, einschliesslich individuellem Code | Vollständig, einschliesslich individuellem Code |
| Skalierung | Automatisch, IBM-verwaltet | Manuell, kundenverwaltet | Elastisch, Kubernetes-verwaltet |
| Kontrolle über Datenresidenz | Eingeschränkt | Vollständig | Vollständig |
| Einrichtungsgeschwindigkeit | Am schnellsten | Am langsamsten | Moderat, abhängig von der Reife des Clusters |
| Am besten geeignet für | SaaS-zu-SaaS-Integration, kleinere Teams | Regulierte Branchen, Integration von Legacy-Systemen | Unternehmen, die bereits Kubernetes/OpenShift betreiben |
Unternehmen im Finanzwesen, Gesundheitswesen, Versicherungswesen oder in der öffentlichen Verwaltung benötigen in der Regel die Kontrolle über Datenresidenz und Netzwerk, die eine On-Premise- oder Container-Bereitstellung bietet. Die Wahl zwischen beiden hängt meist davon ab, ob das Unternehmen bereits eine Kubernetes- oder OpenShift-Plattform betreibt oder klassische Infrastruktur bevorzugt.
Unternehmen mit minimaler Legacy-Infrastruktur und einer auf SaaS-Anwendungen ausgerichteten Strategie sind mit App Connect as a Service oft gut bedient. Der Kompromiss, eingeschränkte Anpassbarkeit, ist selten ein Problem, wenn die Integrationsszenarien überwiegend SaaS-zu-SaaS sind.
Unternehmen mit einer echten Mischung aus modernen SaaS-Systemen und On-Premise-Legacy-Anwendungen, die sich nicht in die Cloud verlagern lassen, sind die klarsten Kandidaten für eine hybride Bereitstellung, sofern sie über die operative Kapazität verfügen, zwei verbundene Umgebungen zu betreiben.
Unternehmen, die für ihre Anwendungsplattform bereits auf Kubernetes oder OpenShift standardisiert haben, ziehen den grössten Nutzen aus App Connect Enterprise on containers, da die Integration so demselben Bereitstellungs- und Skalierungsmodell folgen kann wie der Rest ihrer Infrastruktur.
Da App Connect as a Service, das On-Premise-Enterprise-Modell und das containerisierte Enterprise-Modell für Flows der Enterprise-Stufe auf einer kompatiblen zugrunde liegenden Engine basieren, bedeutet der Wechsel zwischen dem On-Premise- und dem Container-Modell in der Regel, bestehende Integrationsflows als Container-Images neu zu verpacken, statt sie neu aufzubauen. Der Wechsel von App Connect as a Service zu Enterprise, ob On-Premise oder als Container, erfordert in der Regel den Neuaufbau der Flows im Enterprise-Toolset, da das SaaS-Angebot und die Enterprise-Engine unterschiedliche Umgebungen zur Flow-Erstellung verwenden.
Unternehmen, die noch IBM Integration Bus oder WebSphere Message Broker betreiben, können diese Flows in der Regel mit den Migrationswerkzeugen von IBM auf On-Premise- oder Container-Bereitstellungen von App Connect Enterprise migrieren, da App Connect Enterprise auf derselben Kern-Engine basiert wie diese älteren Produkte.
Der praktische Migrationsablauf für die meisten Unternehmen, die in Richtung Container gehen, besteht darin, Flows zunächst On-Premise zu validieren und sie erst dann als Container-Umgebung neu zu verpacken und bereitzustellen, sobald die Ziel-Plattform aus Kubernetes oder OpenShift betrieblich bereit ist, statt beide Schritte gleichzeitig zu unternehmen.
Mimacom hilft Unternehmen, auf Basis von Infrastruktur, Compliance-Anforderungen und Integrationsstrategie das richtige Bereitstellungsmodell für App Connect zu wählen. Unsere Engineering-Teams haben Kunden auf jedem dieser Wege begleitet, von den ersten Rollouts von App Connect as a Service bis zu vollständigen Enterprise-Migrationen auf OpenShift, und wir helfen dabei, den häufigen Fehler zu vermeiden, ein Bereitstellungsmodell nach lizenzrechtlicher Bequemlichkeit statt nach tatsächlicher operativer Eignung auszuwählen.
Es gibt kein universell richtiges Bereitstellungsmodell für App Connect. Die richtige Wahl hängt davon ab, was ein Unternehmen tatsächlich kontrollieren muss, von seinen Verpflichtungen zur Datenresidenz, seiner bestehenden Infrastruktur und davon, wie viel operativen Aufwand es tragen kann, nicht davon, welche Option in einem Verkaufsgespräch am einfachsten wirkt. Unternehmen, die ihre tatsächlichen Anforderungen vor der Entscheidung einem Bereitstellungsmodell zuordnen, vermeiden die kostspieligen Migrationen, die entstehen, wenn Bequemlichkeit statt Eignung den Ausschlag gibt.
Ja, rechnen Sie jedoch damit, Flows neu aufzubauen statt sie direkt zu migrieren, da das SaaS-Angebot und die Enterprise-Engine unterschiedliche Umgebungen zur Flow-Erstellung verwenden. Unternehmen, die eine spätere Einführung von Enterprise planen, beginnen manchmal mit einem kleineren SaaS-Anteil, um den Umfang des späteren Neuaufbaus zu begrenzen.
Das hängt von der vorhandenen Infrastruktur ab. Unternehmen, die bereits OpenShift oder Kubernetes betreiben, finden die Container-Bereitstellung in der Regel kosteneffizienter, da sie vorhandene Plattforminvestitionen weiterverwendet. Unternehmen ohne Container-Plattform müssen die Kosten für deren Aufbau einkalkulieren, was die Effizienzgewinne im Betrieb wieder aufheben kann.
Nicht zwingend. Eine Container-Bereitstellung auf einem selbst verwalteten oder privaten OpenShift-Cluster kann dieselben Anforderungen an Datenresidenz und Netzwerkisolation erfüllen wie eine klassische On-Premise-Bereitstellung, ergänzt um container-native Skalierungs- und Bereitstellungspraktiken. Entscheidend ist die Kontrolle über Infrastruktur und Datenstandort, nicht der Verzicht auf Container.
Lassen Sie Mimacom Ihre Architektur analysieren und den passenden Bereitstellungsweg empfehlen. Sprechen Sie mit unserem Team oder entdecken Sie unsere Integrations- und Data-Engineering-Services.