„Der Weg in die Cloud ist weder einfach, schnell noch preiswert“

JavaSPEKTRUM: SDI ist Ihrer Meinung nach deutlich billiger als entsprechende Cloud-Services. Wieso?

Benke: Alle unsere Benchmarks und alle unsere Berechnungen ergeben das. Eigentlich ist das angesichts der Aufwände auch nicht verwunderlich, die ein Cloud-Provider leisten muss, um einen sicheren, regelungskonformen und attraktiven Infrastruktur-Service anzubieten. Außerdem müssen die Provider mit ihren Services auch Geld verdienen. Wenn ich da als Mittelständler maßgeschneidert ran gehe, habe ich am Ende vom Tag eine passgenauere und preiswertere Lösung. Selbst der „natürliche“ Vorteil eines Cloud-Providers, sein höheres Einkaufsvolumen und der damit günstigere Einkaufspreis, reicht nicht so weit, als dass er seine Services preiswerter anbieten kann, als wir sie selbst in unserer SDI produzieren können.

››Durch die Ausgaben für die Cloud kannibalisiere ich das Budget für die eigene Plattform‹‹

Gilt der Kostenvorteil von SDI für alle Infrastrukturbereiche – also Compute, Storage und Networking? Oder ist er in bestimmten Bereichen besonders hoch?

Generell gilt das für alle Bereiche. Der nachgewiesene Effekt ist unterschiedlich. Ganz massiv ist er im Bereich Compute und Storage. Networking ist schwierig, weil man dort nur schwer vergleichen kann. Der positive Kosteneffekt ist dennoch vorhanden, aber da der Networking-Anteil beim normalen Kunden nicht so groß ist, bleiben die Vorteile in diesem Bereich übersichtlich.Generell gilt, je näher ein Unternehmen an den Standards der Cloud-Anbieter agiert, desto attraktiver ist die Cloud. Aber in der Regel kann kein Anbieter alle deine Anforderungen erfüllen, also braucht man mehrere Cloud-Anbieter, die wiederum unterschiedliche Herangehensweisen haben. Wenn du mit einer mittelständischen IT oder wie in meinem Fall mit mehreren mittelständischen IT-Landschaften kommst, hast du natürlich einen Bauchladen von Applikationen. Es nützt mir eigentlich gar nichts, wenn mir ein Provider beispielsweise 70 Prozent der Applikationen in die Cloud bringt. Den Rest muss ich dann doch noch on-premise fahren. Dieser Anteil wird im Betrieb aber relativ gesehen teurer, weil ich die eigene Infrastruktur ja weiter betreiben muss. Das heißt, durch die Ausgaben für die Cloud kannibalisiere ich das Budget für die eigene Plattform, weil ich die eigene Economy of Scale verliere. Deshalb ist Cloud bei uns die Ausnahme. Wir versuchen, die Skaleneffekte selbst hinzubringen.

Wie groß ist der Unterschied zwischen Ihrer eigenen SDI und den Cloud-Angeboten?

Wir verrechnen auf Basis eines Servicekatalogs interne Servicepreise. Dieser Katalog ist zumindest in Teilen vergleichbar mit entsprechenden Cloud-Angeboten. Bei Storage sind wir im Schnitt 60 Prozent billiger als AWS. Zum Beispiel planen wir ein neues Colocation-Rechenzentrum. Wir haben da einen TCO-Vergleich (Total Cost of Ownership) inklusive Linkup, Klima und Strom angestellt. Bei vergleichbaren Kapazitäten wären wir bei AWS aus TCO-Sicht um den Faktor 5 teurer.

Allein um klare Argumente für Ihre Strategie zu haben, müssen Sie sehr genau benchmarken. Wie machen Sie das?

Das ist viel Handarbeit. Grundlage dafür ist die interne Service-Preis-Verrechnung, die wir aufgrund des Benchmark-Gedankens entwickelt haben. Wir haben die Verrechnung zunächst gemacht, um mit marktvergleichbaren Preisen sehen zu können, wo wir preislich gegenüber Cloud-Service-Providern liegen. Erst später haben wir diese Service-Preise auch für die interne Verrechnung genutzt.

Dann hätten Sie ohne den bepreisten Service-Katalog keine Argumente für Ihren Weg?

Naja, etwa 50 Prozent der Argumente hätte ich dann nicht mehr. Die andere Hälfte der Argumente beziehen wir durch Ausschreibungen von großen Projekten. Wir lassen Systemhäuser und Cloud-Provider spezifizierte Projekte anbieten und verlangen von ihnen unter anderem auch TCO-Berechnungen für fünf Jahre oder länger. So können wir auch bei neuen Projekten genau belegen, was – übrigens unter Berücksichtigung der Abschreibungen – teurer ist. Dabei ist der Faktor oft ähnlich wie bei dem Colocation-Beispiel. Das heißt, selbst wenn ich mit einem Hyperscaler supergut verhandle und ihn 30 oder 40 Prozent im Preis drücken kann, komme ich niemals auf den niedrigen Preis, den ich zahle, wenn wir das selbst machen.

Eines der wesentlichen Versprechen der Cloud ist die quasi unendliche Skalierung. Ihre Kapazitäten bleiben aber trotz Software definierter Zuordnung von Workloads endlich.

Die sind genauso endlich wie bei einem Cloud-Provider. Am Ende des Tages zählt, wie viel Geld man in die Infrastruktur steckt. Das ist das Schöne an Software Defined. Je nach Softwarearchitektur sind die Grenzen erst einmal übersichtlich. Man kann eigentlich in jeder Dimension sehr bedarfsorientiert wachsen. Vernünftigerweise macht man das in Blöcken. Ich kann deshalb nicht auf den Euro genau steuern, aber in überschaubaren Tranchen von 10 bis 30 000 Euro. Das sind Größenordnungen, die wir bei unserem IT-Bedarf auch unterjährig unkompliziert und schnell durchbekommen, wenn es nötig ist.
Schrumpfen kann ich so natürlich nicht. Das kann ich nur, wenn Kapazitäten bei mir rausaltern und ich sie nicht durch Neues ersetze. Damit habe ich auch ein gewisses Schrumpfungspotenzial. Aber ich habe es noch nie gebraucht. Auch in Unternehmen, mit denen ich früher als Berater zu tun hatte, war der Schrumpfungsbedarf nicht vorhanden. Das ist bei sehr großen und datenintensiven Unternehmen wie Netflix oder stark saisonalen Geschäften sicher anders. Aber bei uns spielt das Schrumpfen eine so geringe Rolle, dass man das getrost vernachlässigen kann.

Sie haben kurz Architekturen erwähnt. Welche Architekturen sind denn im Bereich SDI die üblichen?

Grundsätzlich spielt erst einmal eine Rolle, ob man Scale-out- oder Scale-up-Architekturen einsetzt. Viele der Appliances in diesem Umfeld unterstützen ausschließlich Scale-out. Das heißt, es werden einer bestehenden Appliance keine weiteren Ressourcen wie Speicherplatten, CPU usw. hinzugefügt, sondern weitere Appliances, damit der Bedarf gedeckt wird. Das nennt man horizontale Skalierung. Das führt oft dazu, dass Sekundärkosten wie weitere Lizenzierungen nötig werden. Wir verlangen deshalb, dass die Systeme auch Scale-up unterstützen, also vertikal durch größere Platten oder leistungsfähigere CPUs oder I/O-Bausteine performanter gemacht werden können. Das macht uns flexibler, weil wir dann nicht alles aufrüsten müssen, sondern beispielsweise nur die CPU oder nur den Speicherplatz oder nur das RAM.

Das klingt nach viel Detailarbeit und der Notwendigkeit von tiefgehendem Know-how in den verschiedenen Infrastrukturbereichen. Brauchen Sie persönlich und Ihre Mitarbeiter mehr Know-how für SDI als für Cloud?

Das ist eine der Gretchenfragen. Ich denke, dass man auch für die Cloud einen großen Skill braucht, weil man auch da immensen Blödsinn machen kann. Du brauchst für SDI ein gewisses Skillset in deiner eigenen Mannschaft, aber auch bei den Systemhäusern, mit denen du zusammenarbeitest. Das sind aber keine exotischen Kenntnisse, sondern das ist Know-how, das zum Wissenskanon jedes Informatikers gehören sollte. Das ist keine Raketenwissenschaft, aber IT-Professionals sollten natürlich auch darauf achten, dass ihr Wissen aktuell ist.
Mir begegnen einfach zu oft Mindsets, die zum Wissensstand von vor 15 oder 20 Jahren gehören. Aber eigentlich war es nie so einfach wie heute auch mit einem mittelständischen IT-Budget und handelsüblichem Personal, sich mit dem Thema SDI auseinanderzusetzen und da auch große Schritte zu machen. Aber natürlich investiere ich etwas Zeit und Geld, um das Wissen meiner Mitarbeiter aktuell zu halten oder neuen Mitarbeitern in dieser Sache aufs Pferd zu helfen. Das gilt auch für mich. Als IT-Chef muss ich sowohl die kaufmännischen Dinge steuern, aber ich muss auch die technischen Zusammenhänge begreifen, um zum einen Hersteller und Systemhäuser richtig aufzugleisen und zum anderen diese Themen auch intern adäquat zu adressieren. Die Mitarbeiter finden es übrigens toll, dass sie ein bisschen gefordert werden und nicht nur Schema-F machen sollen. Sie freuen sich, dass sie praktisch jeden Tag neue Tricks lernen.

››Es ist meine Aufgabe, die komplexe Technologie, die wir brauchen, zu möglichst günstigen Kosten zur Verfügung zu stellen‹‹

Sie schwimmen mit Ihrer Strategie klar gegen den Mainstream an. Ist das nicht furchtbar anstrengend? Sie suchen die Öffentlichkeit, um zu erklären, welche Vorteile Ihr Vorgehen hat. Woher dieser Eifer?

Klar ist das für mich etwas aufwendiger. Aber mir geht es auch darum, das Wissen zu verbreiten, um diesen Markt zu erhalten. Wenn sich mehr Unternehmen für SDI entscheiden, wird das auch für die Anbieter interessanter und stellt so sicher, dass ein ausreichend breites Angebot bestehen bleibt. Das hat aber auch mit Berufsethos zu tun. Es ist meine Aufgabe, die komplexe Technologie, die wir brauchen, zu möglichst günstigen Kosten zur Verfügung zu stellen. Wenn ich hauptsächlich auf Cloud setze, kann ich das nicht. Mit der SDI-Strategie habe ich dagegen zuweilen mehr IT-Budget als ich ausgeben kann. Warum soll ich den Herstellern Geld schenken, wenn ich meiner Firma damit andere gute Dienste erbringen kann. So sind wir zum Beispiel zu einem Mitarbeiter-WLAN gekommen, das auch 30 000 Euro gekostet hat, die wir an anderer Stelle eingespart haben.

Setzen andere IT-Chefs zu leichtfertig auf die Cloud?

Das würde ich so nicht sagen, aber sie schöpfen die Möglichkeiten ihrer eigenen IT-Abteilungen nicht aus. Von jedem Euro IT-Wertschöpfung gehen heute 40 Cent direkt in die USA. Wollen wir uns das auf Dauer als Gesellschaft leisten?

Wenn IT-Chefs ihre Möglichkeiten nicht ausschöpfen, kann das auch daran liegen, dass ihr technisches Verständnis nicht tief genug geht? In den letzten Jahren ist ja sehr viel stärker Wert auf die Management-Fähigkeiten von CIOs gelegt worden als auf ihr technisches Know-how. Tut sich da jetzt im technischen Bereich eine offene Flanke auf?

Das sehe ich ganz deutlich so. Die tayloristischen Silo-Strukturen in der IT verstärken den Trend zu Management-Entscheidungen zusätzlich. Die Manager der Silos trachten danach, ihr Budget und Risiko zu isolieren. Deshalb kann sich der Plattformgedanke nicht wirklich gegen den Silo-Ansatz durchsetzen. Den Preis dafür zahlen wir dann alle.

Ist es für Entwickler eigentlich schwieriger, für eine SDI zu entwickeln als für eine Cloud-Infrastruktur?

Idealerweise sollten sie es gar nicht merken. Wenn Entwickler und Infrastrukturleute miteinander reden, können wir sogar Mehrwerte für sie schaffen, die in einer Cloud-Umgebung nicht zu realisieren wären. Beispiel: Wir an dem sogenannten „Virtual Commissioning“. Das ist eine etwas weiter gefasste Form des Digital Twins. Damit sind wir in der Lage, in kürzester Zeit an das Produkt angepasste Testumgebungen zur Verfügung zu stellen, die in der Cloud gar nicht konfigurierbar wären. Ich sehe also für Entwickler in SDI-Umgebungen deshalb eher zusätzliche Möglichkeiten als zusätzliche Aufwände. Aber im Regelbetrieb sollte da keiner etwas bemerken.

››Die low hanging fruit ist Storage‹‹

Wie sieht das mit den Werten für Time to Production aus? Brauchen Sie länger, als das in der Cloud der Fall wäre?

Wir schaffen nicht das berühmte Kreditkarten-Szenario, das besagt, dass man innerhalb von zwei Minuten nach dem Bezahlen mit Kreditkarte loslegen kann. Aber wir schaffen es, eine komplette Applikationslandschaft innerhalb von zwei Tagen produktionsreif zu machen. Wir haben zum Beispiel im vergangenen Jahr eine komplette Augmented-Reality-Plattform innerhalb von 5 Wochen ausgerollt und zwar von meiner Unterschrift beim Software-Lieferanten bis zum ersten Einsatz eines Technikers, der mit der AR-Brille in die USA gereist ist. Das ist natürlich weit entfernt vom berühmten Knopfdruck, aber für eine mittelständische IT sind wir da sehr kompetitiv unterwegs.

In welchen Bereichen setzen Sie auf SDI?

Eigentlich quer durch den Garten. Unser Zielbild umfasst den gesamten IT-Betrieb. Soweit sind wir noch nicht, aber wir arbeiten dran. Wir haben unsere Clients komplett umgestellt und sind dabei, auch unsere Server, Betriebssysteme und Applikationen Software Defined aufzustellen. Man kann mit SDI übrigens klein anfangen. Wir haben vor einigen Jahren ganz simpel mit Skripten begonnen. Und wenn man sich später dann mit Orchestrierungstools auseinandersetzt, merkt man, dass die eigentlich auch Skripte benötigen. Beim weiteren Ausbau haben wir unsere Skripte in entsprechende Open-Source-Tools zur Orchestrierung integriert. Und wenn wir neue Ausschreibungen machen, achten wir auf die entsprechenden Schnittstellen, damit wir das weiter benutzen können, was wir schon haben

Wenn Sie mit Kollegen sprechen, die überlegen, einen ähnlichen Weg zu gehen, was raten Sie denen, wo sie beginnen sollen?

Die low hanging fruit ist Storage. Das ist meistens ziemlich simpel zu realisieren und rechnet sich fast immer. Typischerweise geht es dabei um so viel Geld, dass man sofort das Ergebnis bemerkt. Der zweite Rat ist, die Mitarbeiter in diese Richtung zu entwickeln, dass sie skripten, also automatisieren und sich ihre Werkzeuge dafür zurecht legen. Und dann sollte man irgendwann eine Bestandsaufnahme machen, um zu sehen, was einem noch zum zusammenhängenden SDI fehlt. Wenn man schon in einem guten Umfang geskriptet hat, ist das oft gar nicht mehr viel. Oft reichen einige zusätzliche Schlüsselkomponenten, mit denen sich das Bild vervollständigen lässt.

In welchen Feldern benutzen Sie Cloud oder tun Sie das bei der Hahn Group gar nicht?

Im Human-Ressource-Bereich setzen wir eine Software-as-a-Service-Lösung ein, mit der wir aber offengestanden nicht sehr zufrieden sind, weil die Kosten binnen Jahresfrist um das Doppelte angestiegen sind. Ein von uns vor einem Jahr übernommenes Start-up hat bisher komplett auf Cloud gesetzt. Da haben wir erlebt, was passiert, wenn man ohne klare Betriebsstrategie in die Cloud geht. Das kann ein Albtraum werden. Wir ziehen das Unternehmen gerade aus der Cloud raus. Von daher wissen wir inzwischen, wie viele versteckte Kosten beim Cloud-Betrieb von Infrastruktur auftauchen können und wie komplex und teuer es ist, aus der Cloud wieder auszuziehen. Der Weg in die Cloud ist weder einfach, schnell noch preiswert. Wenn ich das trotzdem Quick and Dirty mache, dann kommt da etwas noch Schlimmeres raus als eine On-premise-IT mit ganz viel Schatten-IT.

Kann man die SDI-Strategie Ihres Hauses auch in eine friedliche Koexistenz mit der Cloud bringen?

Ja, das geht bei uns. Die Cloud-Hyperscaler verstehen VMWare und andere Hypervisoren. Wir können nahtlos mit unserer eigenen SD-Infrastruktur und Cloud-Infrastrukturen arbeiten. Deshalb nennen wir unser Konzept intern auch Hybrid-Cloud-Konzept. Wir verbauen uns nichts. Aber ich sehe zurzeit keinen Grund, in die Cloud zu gehen. Die größten Spareffekte erreicht eine mittelständische IT durch Standardisierung und Automatisierung, nicht durch die Cloud. Allerdings – und vielleicht erklärt das auch ein Stück weit ihren Erfolg – nimmt die Cloud dem Mittelständler die organisatorischen und zwischenmenschlichen Mühen ab, die ihm eigene Standardisierungs- und Automatisierungsprogramme abverlangen würden. Aber dafür zahlt er einen hohen Preis, in Geld, in Abhängigkeit und in ungeklärten Daten-Besitzverhältnissen aus dem operativen IT-Betrieb.

Das Interview führte Christoph Witte, E-Mail: cwitte@wittcomm.de, Fotoquellen: VOICE - Bundesverband der IT-Anwender e.V.