Dieser Beitrag erschien ursprünglich im Blog von Glenn Donovon.
Ich habe vor kurzem beschlossen, mich intensiv mit Cloud iPaaS (Integrationsplattform als Service) und insbesondere mit SnapLogic zu befassen, da ein guter Freund von mir dort am Aufbau des Named-Account-Programms mitwirkt. Es handelt sich um eine interessante Plattform, die meiner Meinung nach das Potenzial hat, die IT-Abteilung bei der "letzten Meile" des Cloud-Aufbaus im Unternehmen zu unterstützen. Dies liegt nicht nur an ihren Funktionen, sondern vielmehr an der Verlagerung der Softwareentwicklung und des Designs, die bei Unternehmen wie Google, Amazon und Netflix - und bei Startups, die sich keinen "Enterprise Technology Stack" leisten konnten - begonnen hat und nun ihren Weg in die Unternehmen findet.
Während der Diskussion mit meinem Freund wurde jedoch klar, dass man die Geschichte von Integrationsservern, EAI-Middleware, SOA, ESB und WS-Standards verstehen muss, um die Lektionen, die auf dem Weg zur tatsächlichen IT-Agilität gelernt wurden, in den richtigen Kontext zu setzen. Bevor wir jedoch beginnen, möchte ich mich selbst qualifizieren. Mein Standpunkt basiert auf meiner Tätigkeit als Vertriebsmitarbeiter für Unternehmenstechnologie, der Middleware mit geringer Latenz, standardbasierte Middleware, EAI-Middleware, einen SOA-Grid-Messaging-Bus sowie Anwendungen wie CRM, BPM und unternehmensweites Markt-/Kreditrisikomanagement mit massiven Systemintegrationsanforderungen verkauft hat. Ich habe zwar an der Universität studiert und in meinem Leben auch ein wenig programmiert (ich war eine Zeit lang als Datenbankberater für kleine Unternehmen tätig), aber ich bin kein Architekt, Programmierer oder gar Systemanalytiker. Ich habe aus nächster Nähe miterlebt, warum diese Technologien angeschafft wurden, wie sie sich im Laufe der Zeit entwickelt haben, was die Kunden davon hatten und wie sich all unsere Pläne und Bestrebungen auswirkten. Ich versuche hier also, eine Geschichte zu erzählen, die nicht nur für Middleware-Entwickler und CTO/Architekten verständlich ist. Okay, das war's, anschnallen.
Das Terrain
Lassen Sie uns einige Begriffe definieren - Middleware ist ein allgemeiner Begriff - ich verwende ihn, um mich auf Nachrichtenbusse/ESBs und Integrationsserver (EAI) zu beziehen. Die Geschichte dieser Bereiche hat uns zum heutigen Stand geführt und macht deutlich, wohin wir als Nächstes gehen müssen und warum die alte Art der Systemintegration und des Aufbaus einer SOA zugunsten von RESTful-Webdiensten und eines auf Mikrodiensten basierenden Designs im Allgemeinen verschwindet.
Integrationsserver - ob von IBM oder damaligen Herausforderern wie SeeBeyond (für die ich gearbeitet habe), der Sinn eines Integrationsservers bestand darin, die Praxis zu beenden, für jedes System/Projekt von Hand Code zu schreiben, um auf Daten/Systeme zuzugreifen. Diese wurden damals oft als "Punkt-zu-Punkt"-Integrationen bezeichnet, und beim Aufbau komplexer Systeme in großen Unternehmen vor Integrationsservern sahen die Datenflüsse zwischen den Systemen oft wie ein Teller Spaghetti aus. Wenn ich an ein Marktrisikoprojekt denke, an dem ich bei der Bank of New York gearbeitet habe, kommt mir das immer wieder in den Sinn. Die Datenflüsse von über 100 Integrationspunkten, von denen das Risikosystem Daten bezog, wurden in einem Diagramm dargestellt, das wir auf ein 11×17 großes Papier laminierten, um daraus eine Art Tischset zu machen. Es wurde für mich zum Symbol für diese Art von Problem. Es sah in etwa so aus:
(Bildnachweis: John Schmidt, anerkannte Autorität auf dem Gebiet der Integration Governance und Autor von Büchern über Integration Competency Centre und Lean Integration)
Also kam der "Integrationsserver" ins Spiel. Ziel war es, eine gemeinsame Schnittstelle und Werkzeuge für die Verbindung von Systemen bereitzustellen, ohne den Code von Grund auf neu schreiben zu müssen, damit Integrationen zwischen Systemen einfach zu erstellen und zu pflegen sind und gleichzeitig sicher und leistungsfähig sind. Eine weitere wichtige Motivation war die lose Kopplung von Zielsystemen und datenkonsumierenden Systemen, um beide von Änderungen des zugrunde liegenden Codes in beiden Systemen zu isolieren. Der daraus resultierende Dienst war im Wesentlichen als API verfügbar, es handelte sich um proprietäre Systeme und in gewissem Sinne waren sie letztlich Blackboxes, von denen man Daten konsumierte oder beisteuerte. Sie führten die Transformationen durch, verwalteten den Datenverkehr, luden die Daten effizient usw. Natürlich gab es auch Anbieter, die sich auf Massen-/Batch-Daten spezialisiert hatten, wie Informatica und später Ab Initio, aber es ist schon komisch, dass diese beiden sehr verwandten Welten nie erfolgreich zu einem einheitlichen Angebot zusammengeführt wurden.
Dieser Ansatz änderte jedoch nicht die Art und Weise, wie Softwaresysteme entworfen, entwickelt oder eingesetzt wurden, radikal. Vielmehr ging es darum, die Integrationsanforderungen zu isolieren und sie über einen speziellen Server und ein Toolkit besser zu erfüllen. Dieser Ansatz war für die Unternehmen von großem Nutzen, da er den Aufbau robuster Systemintegrationen ermöglichte und auch großen Unternehmen half, Softwarepakete einzuführen, für die wesentlich weniger Code geschrieben werden musste, aber letztendlich bot er nur marginale Verbesserungen bei der Entwicklungseffizienz, während er eine weitere Systemabhängigkeit (neues Tool, spezialisiertes Personal, laufende Betriebskosten) in den "Stack" einbrachte. Sicherlich könnte man Kompetenzzentren und "Fabriken" aufbauen, aber bis heute führen solche Ansätze zu mehr Bürokratie, mehr Abhängigkeiten und mehr Komplexität, während der Mehrwert im Vergleich zu dem, was ein Entwickler selbst mit RESTful Services/Micro-Services aufbauen kann, immer geringer wird. Und die meisten Dinge, die man heute integrieren möchte, haben bereits gut definierte APIs, so dass es oft ohnehin viel einfacher ist, Verbindungen herzustellen und Daten auszutauschen. Innovative Ideen wie "letztendlich konsistente Daten" und die unglaublichen Kosten- und Rechenvorteile von Open-Source- gegenüber proprietären Technologien, zusätzlich zu öffentlichen IaaS, die solche Rechenlasten auf Containerebene willkommen heißen - nun, sagen wir einfach, es ändert sich viel mehr als nur die Integration. Kluge Leute, mit denen ich spreche, sagen mir, dass die Verwendung eines ESB als Rückgrat eines auf Mikrodiensten basierenden Systems im Widerspruch zur Architektur steht.
Messaging-Bus/ESB - Dies ist ein System zur Verwaltung des Nachrichtenverkehrs auf einem Allzweck-Bus, über den ein Entwickler Nachrichten von Ziel- und Quelldiensten/-systemen veröffentlichen, abonnieren, verteilen und mehrfach übertragen kann. Diese Plattform ist älter als das Web und war in den späten 80er und 90er Jahren in spezialisierten Hochgeschwindigkeits-Messaging-Systemen für Trading-Floors sowie in der Fertigung und anderen industriellen Umgebungen zu finden, wo niedrige Latenzzeiten entscheidend waren und enorme Verkehrsspitzen die Norm waren. Der frühe Erfolg von Tibco im Bereich der Handelsräume beruhte auf der Tatsache, dass das Unternehmen eine servicebasierte Architektur für die Nutzung von Marktdaten zur Verfügung stellte, die skalierbar war und es außerdem ermöglichte, Systeme mit Hilfe von Services/Message Bus Design zu entwickeln. Diese erlaubten es solchen Systemen, sich den Fast-Echtzeit-Anforderungen solcher Umgebungen anzunähern, aber sie waren proprietär, enorm teuer und überhaupt nicht für die allgemeine Datenverarbeitung geeignet. Die Verwendung einer Dienst- und Busarchitektur mit Pub/Sub-, Broadcast-, Mehrpunkt- und Punkt-zu-Punkt-Kommunikation, die den Entwicklern als Dienste zur Verfügung stehen, war jedoch hervorragend geeignet, um Anwendungen von Datenabhängigkeiten zu isolieren und die Spitzen des Datenverkehrs zu bewältigen.
Im Laufe der Zeit wurde klar, dass der Aufbau von Systemen aus Diensten sehr vielversprechend war (wobei grundlegende Ideen aus dem objektorientierten Design übernommen wurden), und so kam die Idee der Webdienste auf. Ganze Standardisierungsgremien wurden gegründet und viele Open-Source- und andere Projekte entstanden, um den standardbasierten Ansatz für die Entwicklung und den Einsatz von Webservicesystemen zu unterstützen. Serviceorientierte Architekturen wurden der letzte Schrei - während meiner Zeit bei SeeBeyond arbeitete ich an einem Projekt für Travelers Insurance, bei dem wir viele ihrer Mainframe-Anwendungen als Webdienste bereitstellten. Dieser Ansatz sollte die Flexibilität der IT-Entwicklung erhöhen.
Doch im Laufe der Zeit wurde ein Problem offensichtlich. Die Kosten, das Fachwissen, die Komplexität und die Zeit, die mit dem Aufbau solcher elegant gestalteten und kontrollierten Systemrahmen verbunden sind, standen im Widerspruch zum schnellen Aufbau von Systemen. Ein guter Entwickler konnte etwas schaffen, das funktionierte und qualitativ hochwertig war, ohne auf all diese standardisierten WS-Dienste zurückgreifen und sich an deren Struktur anpassen zu müssen. Zu den zentralen Problemen gehörte die Verwendung von XML zur Darstellung von Daten, da die für die Umwandlung dieser Strukturen erforderliche Verarbeitungsleistung immer viel zu teuer war, als dass sie sich gelohnt hätte. SOAP war auch ein hochspezialisiertes Protokoll, das eine weitere Schicht von Systemen/Wissen/Abhängigkeiten/Komplexität in den Aufbau von Systemen mit einem hohen Integrationsgrad einbrachte.
Der gesamte WS-Rahmen war zu formalisiert, so dass unternehmungslustige Entwickler sich fragten: "Wie kann ich eine dienstbasierte Architektur zu meinem Vorteil nutzen, wenn ich ein System aufbaue, ohne mich auf all diesen Unsinn zu verlassen? An dieser Stelle kamen die RESTful-Webdienste ins Spiel, und dann JSON, das alles veränderte. Plötzlich waren neue, komplexe und ausgefeilte Webdienste nur noch über HTTP aufrufbar. Die Erstellung und Nutzung solcher Dienste wurde im Vergleich zur alten Methode trivial einfach. Leistung und Sicherheit konnten auf andere Weise verwaltet werden. Was verloren ging, war die Idee, vom Standpunkt des Systemdesigns aus mit "offenen System"-Standards zu arbeiten, aber es stellte sich heraus, dass dies in der Praxis angesichts des ganzen Overheads weniger wertvoll war.
Die IT-Sicht
Die IT-Führungskräfte ahnen bereits, dass die Messaging-Bus-Frameworks ihnen nicht den wichtigsten Vorteil verschafft haben, den sie in erster Linie anstrebten - Agilität -, und doch haben sie all diese Messaging-Infrastrukturen und all diese unglaublich gut funktionierenden Webdienste im Einsatz. In gewisser Weise kann man das alles als Teil dessen sehen, wie IT-Organisationen lernen, wie echte Agilität aussieht, wenn sie servicebasierte Architekturen verwenden. Ich glaube, dass viele bereit sind, den ganzen hochkomplexen und teuren Overhead, der mit Messaging-Bussen einherging, loszuwerden, wenn eine Plattform der Unternehmensklasse auf den Markt kommt, die ihnen dies ermöglicht.
Aber die IT liebt Integrationsserver nach wie vor. Ich denke, sie sind begierig auf einen legitimen, auf der Hybrid-Cloud basierenden Integrationsserver (iPaaS), der ihnen eine einfache Möglichkeit bietet, Schnittstellen für verschiedene Projekte zu geringeren Kosten als bei ESB-basierten Lösungen zu erstellen und zu pflegen, während er in der Cloud und vor Ort läuft. Er muss die Vorteile einer servicebasierten Architektur - Beziehungen auf Vertragsebene - ohne die Komplexität und den Aufwand von Messaging-Bussen bieten. Sie muss die Flexibilität von JSON nutzen und gleichzeitig eine Kontrolle über die Dienste auf Metadatenebene sowie ein umfassendes betriebliches Governance- und Management-Framework bieten. Außerdem muss sie massiv skalierbar und dezentral konzipiert sein, damit sie für diese zentrale Rolle in Unternehmenssystemen überhaupt in Frage kommt.
Der wahre Treiber der Cloud
Was bei all unserem technischen Fokus manchmal untergeht, ist die Tatsache, dass es vor allem die Wirtschaftlichkeit ist, die die Cloud-Einführung vorantreibt. Angesichts der enormen Kostenunterschiede, die sich beim öffentlichen Computing im Vergleich zu On-Premise- oder sogar ausgelagerten Rechenzentren auftun, weil IBM, Google, MSFT, AWS und andere zig Milliarden in ihre Dienste stecken, wird die öffentliche Cloud in Zukunft die bevorzugte Plattform für das gesamte Computing sein. Das Einzige, was in jeder guten IT-Organisation zur Debatte steht, ist, wie lange dieser Übergang dauern wird.
Viele große IT-Organisationen sind sich darüber im Klaren, dass der Wendepunkt bei den Kosten für IaaS und PaaS bereits erreicht ist. Dies ist bereits in vielen Cloud-Märkten geschehen - Salesforce hat Siebel erst dann wirklich verdrängt, als die jährlichen Abonnementgebühren niedriger waren als die Wartungsgebühren von Siebel vor Ort. Denken Sie daran, dass Salesforce keinen funktionalen Vorteil gegenüber Siebel hatte. Hinweis: Da die Wirtschaftlichkeit ausschlaggebend ist, geht es nicht darum, die eleganteste Lösung zu haben, sondern darum, die Aufgabe irgendwie zu erfüllen, auch wenn dies nicht schön ist oder Kompromisse erfordert.
Tieferer Hinweis: Stellen Sie einen guten Systemingenieur vor die Wahl, sich in einem Nest von Tools, Standards und Diensten zurechtzufinden, zusammen mit all den Leistungseinbußen, dem Overhead, den funktionalen Kompromissen und den Abhängigkeiten, die sie mit sich bringen, oder ein bisschen mehr Code zu schreiben und auf die Systemverwaltung zu achten, und er wird sich immer für Letzteres entscheiden. Mit anderen Worten: Komplexität und Abstraktion sind beim Aufbau von Systemen sehr teuer, und die Vorteile müssen wirklich groß sein, damit sich der Kompromiss lohnt. Ich glaube nicht, dass sich ESBs und WS-Standards als Rückgrat der SOA jemals so ausgezahlt haben, wie es nötig gewesen wäre. Und das wird auch nie der Fall sein. Die Branche hat viel dafür bezahlt, um diese Lektion zu lernen, aber es scheint, dass es eine große Abneigung gibt, dies offen zu diskutieren. Die Lektion? Einfachheit = IT-Flexibilität.
Die wichtigste Frage ist, welche Kernarbeitslasten von Unternehmen in die öffentliche Cloud verlagert werden können, und das ist noch nicht geklärt. Plattformen wie Apprenda und andere Hybrid-Cloud-Lösungen sind ein entscheidender Teil dieses Mixes, da man in der Lage sein muss, Daten und Prozesse unter den Gesichtspunkten Sicherheit/Privatsphäre und Leistung/Kosten den entsprechenden Ressourcen zuzuweisen. Eine künftige "Cloud"-App, die von einem Unternehmen entwickelt wird, kann einen Teil ihrer Daten auf Azure-Servern in drei verschiedenen Rechenzentren haben, um die Datenresidenz zu verwalten, andere Daten in On-Premise-Datenspeichern, auf Daten von SaaS-Apps zugreifen und wiederum auf andere Daten in supergünstigen einfachen Datenspeichern auf AWS zugreifen. Wenn ein hybrides iPaaS wie Snaplogic sich in diese Richtlinien einfügt, sich gut mit ihnen verhält und die Verbindung dieser Systeme erleichtert, hat es gute Chancen, ein zentraler Bestandteil des großen Umbaus der IT-Kernsysteme zu werden, den wir in den nächsten 10 Jahren beobachten werden. Der Grund dafür ist, dass sie dem Unternehmen das bietet, was es braucht: einen Integrationsserver, der RESTful Services, Microservices-basierte Architekturen und JSON ohne ESB nutzt.
Das alles kommt jetzt zusammen, und Sie werden ein wachsendes Interesse an der Abschaffung der alten Integrationsserver-/Nachrichtenbus-Architekturen in Organisationen sehen, die sich auf Transformation und Agilität als Kernwerte konzentrieren. Ich denke, dass die Führungskräfte der meisten IT-Organisationen bereit sind, die alten WS-Standards und Bus-/Message-/Service-Architekturen hinter sich zu lassen, aber ihre eigenen technischen Organisationen sind immer noch darauf ausgerichtet, so dass dies einige Zeit dauern wird. Es stimmt auch, dass Nachrichtenbusse nicht völlig abgeschafft werden, da es einen Platz für Messaging-Dienste in der Systementwicklung gibt - nur nicht als Klebstoff für SOA. Und natürlich werden Busse mit niedrigen Latenzzeiten auch weiterhin für die Entwicklung von echtzeitnahen Anwendungen, z. B. in der Technik oder auf dem Börsenparkett, eingesetzt werden, aber die Verwendung von Nachrichtenbussen als allgemeines Designmuster wird in den Hintergrund treten.
Unterm Strich sind die IT-Führungskräfte genauso frustriert darüber, dass sie beim Aufbau von Systemen mit Messaging-Bus/SOA-Mustern nicht die nötige Agilität erreicht haben, wie die Sponsoren aus den Unternehmen über die Kosten und Latenzzeiten dieser Systeme. Alle Beteiligten sind begierig auf das nächste Paradigma, und jetzt ist es an der Zeit, einen Dialog über diese neue Vision zu führen. Meiner Meinung nach ist dies einer der letzten entscheidenden Teile der IT-Infrastruktur, die modernisiert und Cloud-fähig gemacht werden muss, um die Workloads des Enterprise Computing in die Cloud zu verlagern, und ich denke, SnapLogic hat gute Chancen, Unternehmen bei der Umsetzung dieser Vision zu helfen.
______
Über den Autor
Glenn Donovon hat 23 Start-ups beraten, betreut oder war bei ihnen angestellt und verfügt über umfangreiche Erfahrung in der Arbeit mit B2B-IT-Unternehmen. Um mehr über Glenn zu erfahren, besuchen Sie bitte seine Website.
