Nach einem globalen „Paukenschlag“ ist es medial wieder sehr ruhig um den „Deutsche Börse Cloud Exchange“ (DBCE) geworden. Dennoch werde ich immer wieder auf den Cloud-Marktplatz angesprochen – der die Ambitionen hat, den Infrastructure-as-a-Service (IaaS) Markt zu revolutionieren – und werde dabei um eine Einschätzung zu dessen Marktpotential und Zukunft gefragt. Nun, zusammenfassend komme ich ständig zur selben Aussage, dass ich, gemessen an der heutigen Situation, noch nicht an den DBCE glaube und ihm wenig Marktpotential einräume. Warum das so ist? Weiterlesen.

Zwei Geschäftsmodelle

Zunächst sehe ich im DBCE zwei Geschäftsmodelle. Das eine wird in 2014 zur Realität. Der Marktplatz für das Angebot und die Nachfrage von virtuellen Infrastruktur-Ressourcen (Rechenleistung und Speicherplatz), die von Anwendern für den realen Einsatz (Applikationsbetrieb, Daten speichern) genutzt werden sollen.

Bei dem zweiten Geschäftsmodell handelt es sich noch um Zukunftsmusik. Der Handel von virtuellen Ressourcen wie man es von den Futures kennt. Denn sind wir ehrlich. Was ist es, was eine Börse wirklich kann? Ihre eigentliche Aufgabe? Ihr Kerngeschäft? Den Transfer von kritischen Infrastrukturressourcen und Workloads organisieren und überwachen? Nein. Die Börse kann den Preis von virtuellen Gütern bestimmen und damit handeln lassen. Der IaaS-Marktplatz ist nur der Vorbote, um den Markt an dieses Handelsgeschäft heranzuführen und das dafür notwendige Angebot und die Nachfrage zusammenzubringen.

Anbieter und Anwender

Für einen Marktplatz werden grundsätzlich zwei Parteien benötigt. Die Anbieter und die Nachfrager, in diesem Fall die Anwender. Um die Anbieter wird sich der DBCE wenig Gedanken machen müssen. Ist der finanzielle, organisatorische und technische Aufwand relativ gering, wird die Angebotsseite relativ schnell Ressourcen zu bieten haben. Die Problematik besteht auf der Seite der Nachfrager.

Ich habe mich hierzu mit Reuven Cohen unterhalten, der mit SpotCloud im Jahr 2010 den ersten weltweiten IaaS-Marktplatz veröffentlicht hat. In der Spitze hatte SpotCloud 3.200 Anbieter(!) und 100.000 Server weltweit verwaltet. Die Nachfrageseite viel eher bescheiden aus.

Auch wenn Reuven im Jahr 2010 damit viel zu früh dran war, mache ich noch heute dafür fünf Themen verantwortlich, die den DBCE hemmen werden: Das Vertrauen, die Psychologie, die Use Cases, die Technik (APIs) und das Management.

Vertrauen und Psychologie

Die Idee hinter dem DBCE klingt theoretisch klasse. Aber warum ist der DBCE nun tatsächlich vertrauenswürdiger als andere IaaS-Marktplätze? Genießt eine Börse weiterhin dass Vertrauen für das sie als Institution steht bzw. stehen sollte? Hinzu kommt, dass IT-Entscheider ganz anders ticken. Der Großteil der Unternehmen ist weiterhin mit der Public Cloud überfordert und hat Angst die IT und Daten aus der Hand zu geben. Es gibt einen guten Grund, warum die Zahlen von Crisp Research zeigen, dass in Deutschland im Jahr 2013 nur etwa 210 Millionen Euro für Public Infrastructure-as-a-Service (IaaS) ausgegeben wurde. Hingegen lagen die Investitionen für Private Cloud Infrastrukturen bei 2,3 Milliarden Euro.

Das unterstreicht ebenfalls eine Forrester Studie, die besagt:

“From […] over 2,300 IT hardware buyers, […] about 55% plan to build an internal private cloud within the next 12 months.”

Daran wird auch ein unabhängiger Marktplatz nichts ändern. Im Gegenteil, selbst wenn der DBCE für mehr transparenz sorgen soll, schafft er eine weitere Komplexitätsebene zwischen den Anwendern und den Anbietern, die von den Anwendern erst einmal verstanden und adaptiert werden muss. Das spiegelt sich auch in den Use Cases bzw. Workloads wieder, die darauf laufen sollen.

Use Cases

Warum sollte man den DBCE nutzen? Das ist eine Frage, die nicht leicht zu beantworten ist. Warum sollte man über einen Marktplatz Ressourcen einkaufen, wenn ich sie auch von einem Anbieter direkt beziehen kann, der bereits über eine globale Reichweite, viele Kunden und eine bewährte Infrastruktur verfügt? Der Preis und die Vergleichbarkeit können ein entscheidendes Merkmal sein. Wenn die virtuelle Maschine (VM) bei Anbieter A heute ein wenig günstiger ist als bei Anbieter B, dann wird die VM bei Anbieter A genutzt. Wirklich? Nein, das würde die Anwendungsarchitektur dermaßen verkomplizieren, dass die Entwicklung für dieses Szenario in keinem Verhältnis zu dessen Nutzen steht. Cloud Computing ist eh schon viel zu kompliziert, dass ein kluger Cloud Architekt davon Abstand nehmen würde. Man sollte in diesem Zusammenhang auch nicht die technischen Hürden vergessen, die Cloud-Anwender bereits heute mit sehr weit entwickelten Cloud Infrastrukturen haben.

Ein Szenario was sich mit dem DBCE gut abbilden lassen würde ist ein Multi-Cloud Konzept um technische Risiken (z.B. Ausfall eines Anbieters) zu streuen.

Wofür wir zur nächsten und der wohl größten Hürde kommen – den APIs.

API und Management

Die Diskussionen um „den“ bevorzugten API-Standard in der Cloud hören nicht auf. Zum de-facto Standard für Rechenleistung und Speicherplatz haben sich Amazon EC2 (Compute) und Amazon S3 (Storage) entwickelt, die von so gut wie allen anderen Anbietern und Projekten unterstützt werden.

Der DBCE will sich quasi als Middleware zwischen die Anbieter und die Anwender setzen und für beide Seiten eine einheitliche eigene(!) Schnittstelle bieten. Hierzu setzt der DBCE auf die Technologie von Zimory, die zwar über offene Schnittstellen verfügt, welche aber proprietär sind. Anstatt sich auf einen bekannten Standard zu konzentrieren oder einen aus der Open-Source Gemeinde (OpenStack) zu adaptieren, versucht der DBCE einen eigenen Weg zu finden.

Frage: Mit dem Hintergrund, dass wir Deutschen, was das Thema Cloud angeht, uns bisher nicht gerade mit Ruhm bekleckert haben. Warum sollte sich der Markt auf einen neuen Standard einlassen der aus Deutschland kommt und dazu auch noch proprietär ist?

Ein weiteres Problem besteht in den Managementlösungen für Cloud Infrastrukturen. Entweder haben sich potentielle Anwender bereits für eine Lösung entschieden und stehen damit vor der Herausforderung die neuen APIs in irgendeiner Form zu integrieren oder Sie befinden sich weiterhin im Entscheidungsprozess. Hier besteht die Problematik darin, dass bisher keine gängige Cloud-Managementlösung die DBCE APIs unterstützt.

Systemintegratoren und Cloud-Broker

Es gibt zwei Zielgruppen in denen Potential steckt und die gleichzeitig die Tür zu den Anwendern öffnen können. Die Systemintegratoren (Channelpartner) und Cloud-Broker.

Ein Cloud Service Broker ist ein Drittanbieter, der im Auftrag seiner Kunden Cloud Services mit Mehrwerten anreichert und dafür sorgt, dass der Service die spezifischen Erwartungen eines Unternehmens erfüllt. Darüber hinaus hilft er bei der Integration und Aggregation der Services, um ihre Sicherheit zu erhöhen oder den originalen Service mit bestimmten Eigenschaften zu erweitern.

Ein Systemintegrator entwickelt (und betreibt) im Auftrag seiner Kunden ein System oder eine Applikation auf einer Cloud-Infrastruktur.

Da beide im Auftrag der Anwender agieren und die Infrastrukturen, Systeme und Applikationen betreiben, können sie die proprietären APIs adaptieren und stellen damit sicher, dass sich der Anwender damit nicht auseinandersetzen muss. Darüber hinaus können sowohl Systemintegratoren als auch Cloud-Broker den DBCE nutzen, um für sich kostengünstig Cloud-Ressourcen einzukaufen und ein Multi-Cloud Modell nutzen. Hierbei spielt die Komplexität der Systemarchitektur wieder ein Rolle, von welcher der End-Anwender aber nichts mitbekommen darf.

Eine Frage der Zeit

Ich habe in diesem Artikel mehr Fragen aufgeworfen als beantwortet. Ich möchte den DBCE auch nicht zu negativ bewerten, denn die Idee ist gut. Aber die oben genannten Punkte sind essentiell wichtig, um überhaupt ein Fuß in die Tür der Anwender zu bekommen. Dabei wird es sich um einen Lernprozess für beide Seite handeln, den ich auf etwa fünf Jahre schätze, bis dieses Modell bei den Anwendern zu einer signifikanten Adaptionsrate führt.