Letzte Woche haben wir einen sehr beliebten Webcast mit Dr. Stefan Ried, Principal Analyst und Vice President von Forrester für CIOs, veranstaltet. Stefan Ried gab einen detaillierten Überblick über die Forschungsergebnisse von Forrester zur Cloud-basierten Integration, die Trends auf dem Markt und erläuterte, warum Hybrid heute und in absehbarer Zukunft die IT-Realität ist. Der Webcast enthielt auch einen Überblick über die
SnapLogic Integration Cloud und eine interaktive Fragerunde zu einer Vielzahl von Themen. In der Frage- und Antwortrunde wurde erörtert, warum der Legacy Enterprise Service Bus (ESB) für Cloud-Integrationsszenarien nicht geeignet ist, welche Vorteile Multi-Tenancy bietet und vor welchen Herausforderungen Legacy-Integrationstechnologien stehen, wenn sie mit modernen Integrationsanforderungen zu tun haben.
Vor der Diskussion fasste Stefan die Position von SnapLogic auf dem Markt mit den Worten zusammen:
"Wie Sie gesehen haben, kann SnapLogic wirklich sowohl die Integration in die Cloud als auch die Integration mit der Cloud sein. Wenn Sie Snaplex vor Ort einsetzen möchten, haben Sie eine Datenverwaltung vor Ort und können auf die SaaS-Anwendungen verweisen, mit denen Sie sich verbinden möchten. Wenn Sie jedoch die meisten Anwendungen in der Cloud haben, möchten Sie Snaplex in der Cloud haben. Eine solche Architektur ist sehr flexibel und hält beide Optionen offen."
Hier ist die Abschrift der Fragen und Antworten:
Frage: Sie erwähnten, dass ESBs in der Regel nicht mandantenfähig sind und sich nicht gut für die Cloud eignen. Gibt es spezifische Gründe warum ein ESB nicht die richtige Wahl für die Cloud-Integration ist?
Antwort: Es gibt mehrere Gründe.
- Die Skalierbarkeit eines ESB. ESBs können sehr groß werden, wie Sie vielleicht schon in Ihrer eigenen Infrastruktur gesehen haben, wenn Sie einen großen ESB betreiben, aber ESBs haben Schwierigkeiten, sehr klein zu werden. Das klingt komisch, ist es aber nicht. Zum Beispiel, wenn Sie Ihr Cloud-basiertes Integrationsszenario für die B2B-Integration nutzen. So können Sie nicht nur Ihr Salesforce.com-System in Ihr ERP-System integrieren, sondern auch alle Ihre Vertriebspartner Ihres Salesforce.com-Mieters in Ihr ERP-System. Auf diese Weise können Sie eine sehr elegante Kanalintegration vornehmen. Wenn Sie für jeden dieser Partner einen ESB aufsetzen würden, der nur für ein paar Nachrichten pro Tag verwendet wird, würden Sie eine Menge Infrastruktur (und übrigens auch Lizenzen) verschwenden. Dies sind Beispiele, die an die Grenzen der traditionellen ESB-Architekturen stoßen.
- Das Paradigma der Entwicklung komplexer Integrationsszenarien. Diese sind hilfreich, wenn Sie sehr komplexe Anforderungen haben, aber wenn Sie Ihre NetSuite-Kundendaten mit Ihren SAP-Kundendaten synchronisieren wollen, oder was auch immer Sie für ein ERP-System vor Ort haben, ist das ein Overkill an Tools. Ich habe gesehen, dass Kunden, die versuchen, einen traditionellen ESB für diese Cloud-Szenarien zu verwenden, am Ende viel höhere Kosten haben und daher Fähigkeiten benötigen, die sie sogar extern kaufen müssen, und die cloudbasierte Integration als Alternative wirklich genießen.
Frage: Warum kann ich dies nicht einfach mit meiner vorhandenen Middleware tun, und was ist meine Empfehlung für die Verwendung meiner vorhandenen Middleware für einige dieser neuen Szenarien?
Antwort: Zunächst einmal möchte ich alle motivieren und ermutigen, die neuen Lösungen auszuprobieren. Nicht nur, weil dies ein Gespräch ist, das von SnapLogic gesponsert wird, sondern wirklich, weil sowohl die traditionelle Anwendungsintegration als auch die traditionelle Datenintegration in vielen Fällen einfach zu schwergewichtig für die Anforderungen der Synchronisierung von Daten mit der Cloud sind. Das heißt, ich möchte Sie ermutigen, es auszuprobieren, herauszufinden, welche Anwendungsfälle in Ihrem Unternehmen dazu passen, und dann die Abwägung zu treffen, ob Sie Ihre alte Middleware verwenden und auf diese Anwendungsfälle ausweiten oder ob Sie etwas Neues lernen und lizenzieren wollen. Viele mittlere und große Unternehmen nutzen am Ende beides. Cloud-basierte Integration ist also kein Ersatz, sondern eine Ergänzung. Sie bietet eine Lösung für die Fälle, in denen herkömmliche ESB- oder Datenintegrationstools einfach überflüssig sind.
Frage: Können Sie Ihr Konzept der Metadaten-Zusammenarbeit näher erläutern und erklären, warum Cloud-Integrationsplattformen dafür besser geeignet sind als On-Premise-Plattformen?
Antwort: Wenn Sie die Metadaten in der Cloud betreiben, können Sie natürlich einfach die Cloud-Zusammenarbeit nutzen. So können Sie zum Beispiel einen Marktplatz einrichten. Oder Sie können Crowdsourcing-Szenarien einrichten, in denen Sie einfach die Metadaten freigeben können, unabhängig davon, ob sie von einem professionellen Integrator oder Anbieter erstellt wurden oder von einem Ihrer Kollegen, vielleicht von jemandem in einem völlig anderen Unternehmen mit der gleichen Art von Konfiguration oder den gleichen beiden Endpunkten. Das bedeutet, dass Sie sich den Umgang mit Metadaten eher so vorstellen können wie den Umgang mit einer Google-Tabelle, zum Beispiel. Sie können sie problemlos in Echtzeit mit anderen Personen teilen. Die alte Art des Umgangs mit Metadaten in traditioneller Middleware war eher die Art von traditionellem Microsoft Office, wo man eine Excel-Tabelle verschickt. Wenn es ankommt, ist es bereits veraltet.
Das ist der Unterschied in der Cloud. Sie ist mehr auf Zusammenarbeit ausgerichtet. Es wird mehr geteilt. Sie können sich einen Marktplatz und Crowdsourcing vorstellen, die gemeinsame Nutzung von Metadaten auf eine ganz andere Art und Weise. Und das senkt letztlich die Implementierungskosten und macht Fertigkeiten viel billiger, weil die Leute die Einfachheit genießen und einfach die Beispiele von anderen Leuten übernehmen, anstatt umfangreiche Handbücher zu lesen oder einen Berater zu kaufen.
Frage: Ist Mandantenfähigkeit noch wichtig? Was sind die Gründe, warum sie in einer Cloud-Integrationsplattform wichtig ist?
Antwort: Multitenancy bringt definitiv eine erhebliche Kostensenkung mit sich. Technisch gesehen können Sie viele der Dinge, die wir heute besprochen haben, erreichen, indem Sie eine dedizierte virtuelle Maschine bei Amazon oder anderswo aufsetzen, und Sie können technisch das Gleiche erreichen. Aber wenn Sie eine virtuelle Maschine in Ihrer eigenen Umgebung aufsetzen, können Sie natürlich nicht die Dinge tun, die wir gerade über die gemeinsame Nutzung von Metadaten besprochen haben. Wenn Sie aber eine gemeinsame Umgebung haben, kann die Umgebung definieren, dass wir Metadaten gemeinsam nutzen oder dass wir Metadaten in einen Appstore einpflegen - wir arbeiten gemeinsam an Metadaten, aber wir halten die Daten selbst geheim und privat. Das ist die eigentliche Form, die Forrester als "Collaborative Tenancy" bezeichnet. Das bedeutet, dass die Teile, die privat sein müssen, wie die Datenflüsse, privat bleiben, aber die Teile, die kollaborativ sein können, wie die Metadaten, sehr kollaborativ sind. Diese Konzepte unterscheiden sich natürlich erheblich von dem, was man in einer Single-Tenant-Umgebung erreichen könnte.
Schließlich habe ich bereits das Beispiel erwähnt, dass Sie viel mehr Skalierbarkeit haben. Wenn in einer mandantenfähigen Umgebung ein Mandant nicht benötigt wird, schläft er ein. Er benötigt dann keine Infrastruktur mehr. Das bedeutet, dass sowohl die Infrastruktur als auch möglicherweise die Lizenzpreise transaktionsbasiert sind. In der alten Welt, schauen Sie sich Ihre ESBs an, sind sie alle CPU-basiert. Wenn sie ungenutzt herumliegen, sind sie immer noch teuer. Das ist alles ganz anders.
Frage: Wir hatten kürzlich eine Debatte über das Erbe eines Integrationsanbieters. Wie verändern sich traditionelle Anbieter? Können sie sich ändern? Was ist unter der Haube wichtig?
Antwort: Sie können die Software der Basisarchitektur nicht ändern. Das können Sie nicht. Wenn sie auf einer traditionellen Java-Umgebung basiert und mit einem traditionellen Objektmodell aufgebaut ist, können Sie sie nicht in eine JSON-Darstellung umwandeln. Das ist einfach nicht so einfach. Dennoch wird versucht, sie abzubilden. Am Ende können Sie natürlich Anwendungen, die in beiden Paradigmen geschrieben wurden, auf beide Arten bereitstellen, aber Sie werden nicht die gleiche Leistung erhalten. Das heißt, wenn Sie einen hohen Datenverkehr haben, die neuen Umgebungen in der Cloud, also zum Beispiel eine kundenorientierte Anwendung, ein altes GS zum Beispiel oder eine Anwendung für den Umgang mit Ihren Kunden, die auch mit Facebook verbunden ist und ein unvorhersehbares Datenverkehrsvolumen hat, denke ich, dass die neuen Middleware-Architekturen wie die von SnapLogic definitiv einige Vorteile haben. Am Ende geht es um die Kosten. Es geht um den Umfang der physischen Infrastruktur, die Sie für den Datenverkehr benötigen, und wenn Sie eine moderne Architektur verwenden, sind Sie definitiv in der Lage, den Datenverkehr zu bewältigen.
Informieren Sie sich auf unserer Veranstaltungsseite über kommende Web- und Live-Programme. Vielleicht finden Sie auch diesen Beitrag interessant - warum SOA dank des ESB tot ist.
