Das können Sie nicht virtualisieren!

In der IT bekommen wir das ständig zu hören: Ein Anbieter erklärt uns, dass sich ein System nicht virtualisieren lasse. Die Gründe dafür sind zahlreich. Auf der IT-Seite sind wir immer wieder schockiert, dass ein Anbieter eine derart unverschämte Behauptung aufstellt; und oft sind wir ebenso schockiert, dass ein Kunde (oder Vorgesetzter) ihm glaubt. Anbieter haben im Laufe der Jahre hart daran gearbeitet, diese Verkaufsmasche zu perfektionieren, und ich halte es für wichtig, sie zu sezieren.

Die eigentliche Ursache der Probleme besteht darin, dass Anbieter fast immer nach Wegen suchen, ihre eigenen Kosten zu senken und gleichzeitig die Gewinne aus den Kunden zu steigern. Das treibt vieles an, was man andernfalls als merkwürdiges Verhalten ansehen würde.

Eine Sache, die sehr, sehr viele Anbieter versuchen, ist, die Szenarien einzuschränken, unter denen ihr Produkt unterstützt wird. Auf diese Weise bringen sie sich in die Lage, darauf vorbereitet zu sein, schlicht keinen Support leisten zu müssen – Support ist teuer und unzuverlässig. Das ist eine gängige Strategie. In manchen Fällen ist dies so aggressiv, dass schlicht kein akzeptables Produktiv-Einsatzszenario überhaupt existiert.

Ein sehr verbreitetes Mittel hierfür besteht darin, kein einziges unterstütztes Betriebssystem zu unterstützen und damit die eigene Software des Anbieters de facto für veraltet zu erklären (heute würde das beispielsweise bedeuten, nur Windows XP und älter zu unterstützen). Ein weiteres Beispiel ist, nur Produkte zu unterstützen, die für den jeweiligen Anwendungsfall nicht lizenziert sind (ein Beispiel wäre, den Einsatz eines Produkts wie Windows 10 als Server vorzuschreiben). Und einer der häufigsten Fälle ist das Verbot der Virtualisierung.

Diese Szenarien bringen Kunden in schwierige Lagen, denn auf der einen Seite haben sie Branchen-Best-Practices, standardisierte Bereitstellungsrichtlinien, hauseigene Werkzeuge und Richtlinien, die einzuhalten sind; und auf der anderen Seite haben sie Anbieter, die ihnen oft ein ordnungsgemäßes Systemdesign, eine ordnungsgemäße Planung und Verwaltung untersagen. Diese Anforderungen stehen im Widerspruch zueinander.

Natürlich erwartet niemand, dass jeder Anbieter jedes mögliche Szenario unterstützt. Grenzen müssen gezogen werden. Doch zwischen der Unterstützung vernünftiger, gut bereitgestellter Systeme und der aktiven Forderung nach inakzeptabel schlechten Bereitstellungen klafft eine gewaltige Kluft. Wir hoffen, dass sich unsere Anbieter wie Geschäftspartner verhalten und ein gemeinsames Interesse an unserem Erfolg teilen oder zumindest am Erfolg ihres Produkts, und nicht unmittelbar darauf hinarbeiten, beides zu untergraben. Wir würden hoffen, dass für jedes vernünftige Bereitstellungsszenario zumindest ein Best-Effort-Support geleistet wird und dass für korrekt konzipierte Best-Practice-Szenarien wahrscheinlich ein garantierter Support angeboten würde.

Stellen Sie sich eine Welt vor, in der das Einhalten des Tempolimits und das Anlegen des Sicherheitsgurts Ihre Fahrzeuggarantie verletzen würde und Sie nur dann Support erhielten, wenn Sie rücksichtslos und ungeschützt führen!

Einige wichtige Dinge müssen über die Virtualisierung verstanden werden. Das erste ist, dass die Virtualisierung eine seit langem etablierte Branchen-Best-Practice ist und in jedem produktiven Bereitstellungsszenario für Dienste erwartet wird. Virtualisierung ist keineswegs neu; selbst im Markt der kleinen Unternehmen gehört sie nun schon seit weit über einem Jahrzehnt zur Kategorie der Best Practices und im Enterprise-Umfeld seit vielen Jahrzehnten. Wir sind längst über den Punkt hinaus, an dem der nicht virtualisierte Betrieb von Systemen als akzeptabel gilt, und das schließt Altbestände ein, die seit langer Zeit in Betrieb sind.

Es gibt natürlich, wie bei nahezu jeder Regel, stets seltene Ausnahmen. Manche Systeme benötigen Zugriff auf ganz spezielle Hardware, und eine Virtualisierung ist möglicherweise nicht machbar, obwohl dies mit modernem Hardware-Passthrough heute nahezu unbekannt ist. Und einige Systeme mit extrem niedriger Latenz lassen sich nicht virtualisieren, doch diese beschränken sich normalerweise auf die größten internationalen Investmentbanken und die aggressivsten Hedgefonds, und selbst die Mehrzahl dieser herkömmlichen Anwendungsfälle wurde durch Verbesserungen der Virtualisierung ausgeräumt, sodass selbst diese Situationen selten geworden sind. Doch unterm Strich gilt: Wenn Sie nicht virtualisieren können, sollten Sie traurig darüber sein, dass es nicht geht, und Sie werden genau wissen, warum es in Ihrer Situation unmöglich ist. In allen anderen Fällen muss Ihr Server virtuell sein.

Ist es nicht wichtig?

Wenn ein Anbieter Ihnen nicht erlaubt, den standardmäßigen Best Practices für gesunde Bereitstellungen zu folgen, was sagt das über die Meinung des Anbieters zu seinem eigenen Produkt aus? Sprächen wir über irgendeine andere Bereitstellung, würden wir sofort hinterfragen, warum wir ein System so schlecht bereitstellen, wenn wir vorhaben, uns darauf zu verlassen. Wenn unser Anbieter uns zu einem solchen Verhalten zwingt, sollten wir genauso reagieren – wenn der Anbieter sein Produkt nicht in demselben Maße ernst nimmt, in dem wir den geringsten unserer IT-Dienste ernst nehmen, warum sollten wir es dann tun?

Dies ist eine „Impedanz-Fehlanpassung“, wie wir in Ingenieurskreisen sagen, zwischen unseren Anforderungen (Produktivsysteme) und der Art und Weise, wie der Anbieter dieses Systems sie offenbar behandelt (Hobby- oder Unterhaltungssysteme). Wenn wir uns für unsere Unternehmen auf dieses Produkt verlassen müssen, brauchen wir einen Anbieter, der mit an Bord ist und geschäftliche Anforderungen versteht – der eine Produktiv-Denkweise hat. Wenn das Produkt nicht auf Unternehmen ausgerichtet oder nicht unternehmensreif ist, müssen wir uns dessen bewusst sein. Wir müssen hinterfragen, warum wir das Gefühl haben, einen Dienst produktiv einsetzen zu sollen, auf den wir uns verlassen und für den wir Support benötigen, der aber gar nicht für einen solchen Einsatz vorgesehen ist.

Wird es unterstützt? Wird es getestet?

Etwas, das aus Kundensicht oft übersehen wird, ist die Frage, ob die notwendigen Support-Ressourcen für ein Produkt überhaupt vorhanden sind. Es ist nicht ungewöhnlich, dass das Team, das ein Produkt betreut, geschrumpft wird oder sogar ganz verschwindet, das Unternehmen das Produkt aber weiterhin verkauft, in der Hoffnung, es so weit wie möglich auszuschlachten, und darauf setzt, sich entweder irgendwie durch ein Problem hindurchzuwursteln oder dem Kunden einfach das Geld zurückzuerstatten, sollte der Anbieter in einer Situation ertappt werden, in der er schlicht nicht in der Lage ist, Support zu leisten.

Die meisten Softwareverträge legen fest, dass der maximale Schaden, der vom Anbieter geltend gemacht werden kann, die Kosten des Produkts oder der für den Kauf aufgewendete Betrag ist. In einem Fall wie diesem trägt der Anbieter kein Risiko, wenn er ein Produkt anbietet, das er nicht unterstützen kann – selbst wenn er für den Support einen Aufpreis verlangt. Wenn es dem Kunden gelingt, das Produkt einzusetzen, prima, dann werden sie bezahlt. Wenn der Kunde es nicht kann und der Anbieter es nicht unterstützen kann, verlieren sie nur Geld, das sie ohnehin nie bekommen hätten. Der Kunde übernimmt das gesamte Risiko, nicht der Anbieter.

Dies legt natürlich nahe, dass es auch wenig bis gar keine fortlaufende Erprobung des Produkts gibt, und das sollte Anlass zu zusätzlicher Sorge geben. Nur weil das Produkt läuft, heißt das nicht, dass es weiterhin laufen wird. Mit einem nicht unterstützten oder, schlimmer noch, nicht unterstützbaren Produkt in Betrieb zu gehen, bedeutet, dass Sie sich im Laufe der Zeit immer stärker auf ein Produkt verlassen, dessen potenzielles Support-Niveau wahrscheinlich sinkt und das mit der Zeit langsam immer schlechter wird, während zugleich zu erwarten wäre, dass der Bedarf an Support und die Abhängigkeit von der Software zunehmen.

Wenn ein proprietäres Produkt produktiv bereitgestellt wird und die Entscheidung getroffen wird, auf Best-Practice-Bereitstellungen zu verzichten, um den Support-Anforderungen gerecht zu werden, wie passt das in eine Entscheidungsmatrix? Sollte das bedeuten, dass kein ordentlicher Support existiert? Auch hier deutet dies, wie zuvor, auf eine Fehlanpassung an unsere Anforderungen hin.

 

Wird es noch weiterentwickelt?

Wenn die Bereitstellungsanforderungen der Software alten, veralteten Praktiken folgen oder veraltete (oder nicht hinreichend aktuelle Software bzw. Design) voraussetzen, dann müssen wir die Wahrscheinlichkeit hinterfragen, dass das Produkt derzeit noch weiterentwickelt wird. In manchen Fällen können wir dies feststellen, indem wir den Software-Release-Zyklus eine Zeit lang beobachten, aber nicht in allen Fällen. Es besteht die begründete Befürchtung, dass das Produkt tot sein könnte und kein Entwicklungsteam mehr daran arbeitet. Der Code mag schlicht alt sein, technische Schulden, die in der Hoffnung verkauft werden, aus einer alten, aufgegebenen Codebasis noch ein paar letzte Dollar herauszuholen. Dieser Vorgang ist tatsächlich weit verbreiteter, als oft angenommen wird.

Kleineren Softwarehäusern gelingt es oft, ein erstes Softwarepaket zu entwickeln, es auf den Markt zu bringen und zum Verkauf anzubieten, doch sie sind nicht in der Lage, sich nach der/den ersten Veröffentlichung(en) den Erhalt oder die Neubesetzung ihres Entwicklungsteams zu leisten. Dies ist in der Tat ein sehr verbreitetes Szenario. Es lässt Kunden mit einem Produkt zurück, von dem zu erwarten ist, dass es im Laufe der Zeit immer weniger tragfähig wird, wobei die Bereitstellungsszenarien zunehmend riskanter werden und sich die Daten zunehmend schwerer herauslösen lassen.

 

Wie kann es unterstützt werden, wenn die Plattform nicht unterstützt wird?

Ein verbreitetes Paradoxon einiger extremerer Situationen ist Software, die, um als „unterstützt“ zu gelten, andere Software voraussetzt, die entweder nicht mehr im Support ist oder für den vorgesehenen Anwendungsfall nie unterstützt wurde. Häufige Beispiele hierfür sind die Anforderung, ein Serversystem auf einem Desktop-Betriebssystem zu betreiben, oder die Anforderung von Versionen von Betriebssystemen, Datenbanken oder anderen Komponenten, die überhaupt nicht mehr unterstützt werden. Letzteres Szenario ist erschreckend verbreitet. In einer solchen Situation muss man sich fragen, ob es denn überhaupt jemals eine Bereitstellung geben kann, in der die Software als „unterstützt“ gelten kann. Wenn ein Teil des Stacks immer außerhalb des Supports liegt, dann ist der gesamte Stack nicht unterstützt. Es gäbe stets einen Grund, aus dem der Support verweigert werden könnte, egal was passiert. Genau der Grund, aus dem wir folglich fordern würden, Best Practices zu meiden, würde gleichermaßen die Wahl der Software selbst von vornherein ausschließen.

Fehlt es an Branchenkompetenz und -wissen?

Vielleicht besteht das Problem, mit dem wir bei Software-Supportproblemen dieser Art konfrontiert sind, darin, dass das/die Team(s), das/die die Software erstellen, schlicht nicht wissen, wie gute Software gemacht wird und/oder wie gute Systeme bereitgestellt werden. Dies gehört zu den vernünftigsten und stichhaltigsten Gründen, die uns in diese Situation treiben könnten. Doch wie die anderen hypothetischen Gründe lässt es uns besorgt zurück über die Qualität der Software und die Frage, ob Support wirklich verfügbar ist. Wenn wir dem Anbieter nicht zutrauen, die sichtbarsten Teile des Systems ordnungsgemäß zu handhaben, warum sollten wir uns für die Teile, die wir nicht überprüfen können, als unsere Experten an ihn wenden?

Das große Problem

Das große, übergreifende Problem bei Software, die im Tausch gegen die Freischaltung ansonsten zurückgehaltenen Supports fragwürdige Bereitstellungs- und Wartungspraktiken verlangt, ist nicht, wie wir üblicherweise annehmen, eine Frage der allgemeinen Softwarequalität, sondern eine Frage tragfähiger Support- und Entwicklungspraktiken. Dass diese Probleme auf erhebliche Bedenken hinsichtlich des langfristigen Supports hindeuten, sollte uns nachdrücklich hinterfragen lassen, warum wir diese Pakete überhaupt auswählen und zugleich starken Support von ihnen erwarten, obwohl wir von Anfang an sehr sichtbare und sehr ernste Bedenken haben.

Es gibt natürlich Fälle, in denen keine anderen Softwareprodukte existieren, um einen Bedarf zu decken, oder keine von größerer Tragfähigkeit. Diese Situation sollte äußerst selten sein, und sollte eine solche Situation existieren, so wäre sie als bedeutende Marktchance für einen Anbieter anzusehen, der in genau dieses Segment einsteigen möchte.

Aus geschäftlicher Sicht ist es zwingend erforderlich, dass die Best Practices der technischen Infrastruktur nicht vollständig zugunsten einer blinden oder nahezu blinden Befolgung von Anbieteranforderungen außer Acht gelassen werden, die in jedem anderen Fall als rücksichtslos oder unprofessionell gelten würden. Warum versäumen wir es so oft, auf diese Weise Exzellenz von den Kernprodukten zu fordern, von denen unsere Unternehmen abhängen? Es setzt unsere Unternehmen einem Risiko aus, nicht nur durch die Handlung selbst, sondern weit mehr noch durch die Risiken, die durch die Existenz einer solchen Anforderung impliziert werden.