© Michal Bednarek, 123RF

Eigentlich kann VMware kaum Gefallen am rasanten Aufstieg der Public Clouds finden, denn der gefährdet sein Geschäftsmodell. Wenn es aber doch sein muss, dann soll wenigstens vRealize dem Kunden das hybride Setup schmackhaft machen, das zum Teil bei ihm und zum Teil in der Public Cloud steht.

VMware macht sich seit Jahrzehnten in der IT einen guten Namen als Anbieter umfassender Virtualisierungslösungen. Zwar sind VMware-Produkte nicht selten mit üppigen Preisschildern versehen, doch für die aufgerufenen Beträge liefert der Hersteller solide Produkte. Wer schon mal mit ESXi und vSphere oder vCenter zu tun hatte, der weiß: Unter einer gut gestalteten Oberfläche finden sich die im Alltag meistbenötigten Funktionen im Kontext klassischer Virtualisierung, etwa die Migration eines Systems von einem Host auf einen anderen.

VMware beherrscht solche Aktionen aus dem Effeff: Live-Migration, Hochverfügbarkeit, vollständig automatischer Failover, wenn ein Server ausfällt – keine dieser Aufgaben stellt VMware vor große Hürden. Die Zuverlässigkeit ist ein Grund dafür, warum viele Administratoren sich Zeit ihrer Tätigkeit in der IT kaum mit den Produkten anderer Hersteller befassen. Frei nach dem Motto “Nobody ever got fired for buying VMware” nimmt man, was man kennt, und freut sich, dass es funktioniert.

Dann kam die Cloud

Nun ist es in der IT allerdings auch so, dass man mit der Zeit gehen muss. Wer heute in diesem Umfeld aktiv ist, hat einen der größten Umbrüche miterlebt, den es in der Branche bisher gab: den Umschwung von kleinen, lokalen Setups hin zu den großen Public Clouds.

Längst hat sich bei Admins wie Controllern die Erkenntnis durchgesetzt, dass der Betrieb von eigener IT-Infrastruktur heftig ins Geld geht. Er bindet Personal, die mit weitem Abstand teuerste Ressource überhaupt. Er bindet aber auch Geld in Form von Hardware und von Infrastrukturkosten für Kühlung, Strom (bis hin zu eventuell notwendigen Notstromaggregaten) oder weiteren Komponenten.

Kurzum: Die Idee, die eigene Hardware wegzuwerfen und den damit verbundenen Overhead an einen großen Anbieter wie Amazon oder Microsoft auszulagern, sorgt bei vielen Firmen für Begeisterung. Für die Anbieter lohnt sich dieses Geschäft ebenso: Weil AWS und Konsorten sämtliche internen Abläufe auf den Betrieb solcher Setups optimiert haben, können sie diese Dienstleistung besonders effizient anbieten. Gerüchten zufolge macht Amazon auf jeden US-Dollar Umsatz 97 Cent Gewinn.

Dass trotz zum Teil heftiger Preise die Kunden den Anbietern in Scharen zulaufen, zeigt, wie tief der Stachel der Kosten vom IT-Infrastrukturbetrieb im Fleisch vieler Unternehmen sitzt.

Gefahr für VMware?

VMware kann diese Entwicklung naturgemäß nicht gefallen, denn sie gefährdet das angestammte Geschäftsmodell des Unternehmens. Wer selbst keine IT-Infrastruktur mehr betreibt, der braucht vor Ort keine Virtualisierung mehr verlässt sich stattdessen auf die Funktionen der Cloud-Anbieter.

Dass Clouds keine Virtualisierung mit Failover und allem anderen klassischen Gedöns bieten, nutzen viele Firmen sogar als Gelegenheit, um alte Zöpfe abzuschneiden: Beim Umstieg in die Public Cloud kommt dann gleich auch die Anwendung per se auf den Prüfstand. Ergeben sich Vorteile aus der teilweisen oder vollständigen Portierung der Komponenten in die Cloud, geht man lieber diesen Weg, statt sich weiterhin selbst mit dem Betrieb zu befassen.

VMware fing deshalb schon vor einiger Zeit an, eine mehrgleisige Taktik im Hinblick auf den drohenden Bedeutungsverlust zu fahren. Auf der einen Seite hat das Unternehmen heute mehrere Technologien im Portfolio, die typische Virtualisierung mit VMware um Cloud-Aspekte erweitern. Konkret erwähnt seien etwa VMware NSX, eine Open-vSwitch-Erweiterung, die zu einer umfassenden, sehr komplexen Lösung für Software Defined Networking gereift ist, und VMwares OpenStack-Kompatibilitätsschicht. Letztere ermöglicht es, auf Basis der offenen OpenStack-APIs vCenter-Umgebungen zu steuern.

VMware will hier ganz offenbar Umsatz bei jenem Klientel mitnehmen, das sich nicht als Kunde von AWS oder Azure sieht, sondern als deren Konkurrenz – wahlweise mit einer privaten oder einer Public Cloud. Immerhin gibt es mehr als genug Endkunden, die aus rechtlichen Gründen oder wegen eigener Compliance-Vorschriften ihre Daten erst gar nicht auf den Servern von AWS oder Azure lagern dürfen. Potenziellen Plattformanbietern, die eben diese Kunden auf dem Kieker haben, greift VMware mit dem eigenen Cloud-Portfolio unter die Arme.

Die Zahl der Unternehmen, die sich als Plattformbetreiber sehen, dürfte allerdings gering sein – das gewohnte Umsatzniveau lässt sich mit diesen Firmen eher nicht halten. VMware geht daher auch direkt auf Kunden zu, die zwar Dienste wie AWS oder Azure teilweise nutzen wollen, parallel dazu aber weiterhin eigene Infrastruktur etwa für kritische Daten betreiben.

Unter dem Label vRealize vertreibt der Anbieter eine ganze Suite von Tools, die den Betrieb hybrider Workloads in Public Clouds auf der einen Seite und in privaten Virtualisierungsumgebungen auf der anderen Seite ermöglichen. Freilich steht hier VMware-Infrastruktur im Zentrum; primär richtet die Lösung sich an Kunden, die sich VMware ins eigene Rechenzentrum stellen. @L_Daraus ergibt sich freilich auch ein Migrationspfad: Will ein Unternehmen die eigene Infrastruktur reduzieren, wird vRealize von VMware das Werkzeug sein, das ihm dabei unter die Arme greift. Im Folgenden geht dieser Artikel auf die Komponenten von vRealize ein und hinterfragt deren Nützlichkeit für den Admin im Alltag.

Vier-Komponenten-Kleber

Wie Admins es von VMware wahrscheinlich gewohnt sind, verspricht die Firma im Hybrid-Cloud-Kontext von VMware vRealize nicht weniger als die Fähigkeiten einer eierlegenden Wollmilchsau.

Um nichts, so der Hersteller, müsse der Admin sich in einer vRealize-Umgebung mehr selber kümmern: Das Deployment von jeglichen Workloads über quasi jede Plattform hinweg sei ebenso problemlos möglich wie die Nutzung bestimmter Cloud-APIs, etwa AWS, Azure oder auch OpenStack, verspricht VMware. Wer bereits VMware-Produkte hat, kann diese ebenso problemlos einsetzen und direkt an vRealize koppeln.

Doch nicht nur um das Deployment kümmert vRealize sich, sondern auch um das Monitoring, Alerting und Trending im laufenden Betrieb und mithin um das automatische Skalieren von Workloads in die Breite. Gerät eine vom Admin gebaute Umgebung also zu arg aus der Puste, steckt vRealize entlang der Admin-Vorgaben selbst Ressourcen nach. Damit der Admin stets darüber im Bild ist, was die Umgebung gerade tut, gehört zu vRealize auch eine Lösung für zentralisiertes Logging.

Compliance-Vorgaben wird vRealize laut Hersteller gerecht, indem es sich an bestehende Prozesse wie etwa ITIL ankoppelt und diese unterstützt. Wem der vRealize-Umfang nicht ausreicht, der freut sich über die Erweiterungs-APIs. Die sind bei vRealize durchaus VMware-untypisch nicht nur offen gestaltet, sondern ermöglichen auch das Nachrüsten beliebiger Funktionen – wenn der Admin denn bereit ist, die Mühe oder das entsprechende Geld zu investieren.

Liest man VMwares Marketing-Prospekt zu vRealize, entsteht schnell der Eindruck, der Admin müsse quasi gar nichts mehr tun, außer sein Setup einmal auszurollen. Wie üblich trifft das aber keineswegs zu. vRealize nimmt den Admin zwar nicht alle Arbeit ab, entlastet ihn aber an mehreren Stellen erheblich.

Features automatisieren

Als Bollwerk innerhalb der Tool-Suite gilt vRealize Automation (Abbildung 1). Dabei handelt es sich im Grund um ein großes Orchestrierungs-Framework, das unter einer einheitlichen Oberfläche (und auf Wunsch hinter einheitlichen APIs) Funktionen in unterschiedlichen Cloud-Umgebungen aufruft (Abbildung 2). Was in der Theorie abstrakt klingt, erschließt sich in der Praxis recht schnell.

Abbildung 1: vRealize Automation ist die zentrale Deployment-Komponente von vRealize und kümmert sich um die Orchestrierung von Deployments. Quelle: VMware

Abbildung 2: Der Orchestrator als Komponente von VMware Automation kümmert sich um die zuverlässige Orchestrierung in Deployments. Quelle: VMware

Wer als Administrator schon einmal mit unterschiedlichen Cloud-Umgebungen zu tun hatte, der weiß, dass es dieselben Funktionen bei praktisch allen Anbietern in der einen oder anderen Form gibt. Das Anlegen einer virtuellen Maschine für einen spezifischen Zweck legt davon Zeugnis ab: Erst erstellt der Admin in aller Regel ein virtuelles Netz, das er mittels virtuellem Router mit einem physischen, externen Netzwerk verbindet. Dann legt er für die virtuelle Maschine ein ebensolches Speicher-Volume an, in der Regel auf Basis eines bestehenden Betriebssystemabbilds. Schließlich definiert er den SSH-Schlüssel, der in der VM aktiv sein soll, und startet die VM selbst. Kurze Zeit später steht sie einsatzbereit zur Verfügung.

Das Problem: Bei hybriden Workloads, die sich über mehrere Public Clouds oder über eine private und eine öffentliche Cloud erstrecken, muss man diese Arbeiten mehrmals erledigen. Obendrein steht einiger Integrationsaufwand an, um die Setups kompatibel miteinander zu halten. Wer etwa im eigenen Rechenzentrum OpenStack betreibt und ein geteiltes Setup zwischen OpenStack und AWS fahren möchte, braucht dafür mehrere Templates in den unterschiedlichen Sprachen der Orchestrierer. Das ist mühsam und im laufenden Betrieb auch eine Herausforderung.

Automation übernimmt das Ruder

Genau hier kommt vRealize Automation ins Spiel. Das Produkt versteht sich unter der Haube auf die Kommunikation mit den APIs verschiedener Public Clouds ebenso wie mit jenen von privaten Virtualisierungs-Setups. Logisch, dass vRealize Automation auch an bestehende vCenter-Setups andocken kann. OpenStack steht aber ebenso auf der Liste der unterstützen Umgebungen im eigenen Rechenzentrum.

Statt für jede Ziel-Umgebung eigene Templates zu bauen, baut der Admin mit vRealize Blueprints und Service-Beschreibungen standardisierter Dienste. Automation sorgt im Hintergrund dann dafür, dass diese auf Zuruf des Nutzers auf dem gewünschten Zielsystem passend ausgerollt werden. vRealize Automation ist in erster Linie also eine Abstraktionsebene für andere Cloud-Dienste, um eine einheitliche Oberfläche wahlweise in grafischer oder API-Form zu erschaffen.

Dass VMware verstanden hat, wer die Kernzielgruppe ist, macht die Anwendung dabei schnell deutlich: Bevorzugt sollen Anwender ein Self-Service-Portal nutzen, in dem sie sich den gewünschten Workload schnell zusammenklicken können. Zudem integriert vRealize Automation umfassende Governance-Features: Der Admin hinterlegt zunächst die Credentials für die Ziel-Clouds, doch kommt das Produkt auch mit eigener Rechteverwaltung daher. Bis auf die Ebene einzelner Nutzer lässt sich dadurch fein abgestuft festlegen, wer was darf. Dasselbe gilt für Quotas, die der Admin in vRealize Automation ebenfalls zentral verwaltet.

Wie üblich gibt VMware sich hier keine Blöße im Hinblick auf das unterstützte Ziel-Setup: Generische Clouds wie AWS oder Azure unterstützt der Hersteller ebenso wie eigene Produkte, etwa die SDN-Software NSX.

Deployments und Betrieb

Moderne Cloud-Ready-Anwendungen und besonders die Container-basierten Apps der Gegenwart stellen andere Anforderungen an den Betrieb als konventionelle Applikationen aus grauer Vorzeit. Klassisches Monitoring etwa muss in Clouds viel flexibler sein als in Legacy-Umgebungen, weil die Anzahl der zu überwachenden Instanzen sich schlagartig und dynamisch ändern kann.

Schon aus Gründen des Skalierens leben Workloads in Clouds davon, dass sie spezifisch nur die Dienste buchen und verwenden, die sie zum Zeitpunkt X tatsächlich brauchen. Ein Online-Shop für Fischereizubehör wird während der Angelsaison im Sommer etwa sehr viele Ressourcen brauchen, im Winter aber weniger Last haben. Moderne Web-Anwendungen sind deshalb so gebaut, dass sie auf Zuruf beliebig viele neue Instanzen ihrer selbst starten können, um die anliegenden Workloads auf mehr Schultern zu verteilen.

Zurecht erwartet der Admin, dass eine Management-Lösung für hybride Workloads diese Faktoren einbezieht und entsprechend behandelt. vRealize lässt den Admin an dieser Stelle nicht im Stich: vRealize Operations und Log Insight kümmern sich darum, dass er den Durchblick behält.

Skalieren, überwachen, umkonfigurieren

Die Operations-Komponente kümmert sich dabei um sämtliche Aufgaben, die nach dem initialen Deployment eines Setups im Alltag anfallen. Merkt sie etwa anhand voreingestellter Performance-Werte, dass die Umgebung zu langsam arbeitet, legt sie automatisch virtuelle Instanzen nach. Das klappt sowohl für konventionelle VMs wie auch für Container, deren Handhabung die gesamte vRealize-Suite problemlos beherrscht. Auch das Kapazitätsmanagement übernimmt vRealize Operations: Liegen RAM- und CPU-Nutzung bei gegebenen Instanzen zu hoch, startet es automatisch welche nach.

Gleichzeitig adaptiert Operations dynamisch die Konfiguration von Workloads in Cloud-Umgebungen. Ist nach einem Skaliervorgang also die Anpassung einzelner Werte in den Konfigurationsdateien notwendig, kann der Admin das im sogenannten Blueprint (Abbildung 3) für die jeweilige Umgebung festlegen. Operations beachtet solche Hinweise in seinen Templates und nimmt bei Bedarf die entsprechenden Änderungen vor.

Abbildung 3: In Blueprints legt der Admin nicht nur die Architektur virtueller Deployments fest, sondern auch, wann sei ein Skalieren in die Breite erfordern. Quelle: VMware

Nicht zu kurz kommt obendrein der Überwachungsaspekt: In vRealize Operations steht dem Admin ein Füllhorn von Funktionen zur Verfügung, um Zielinstanzen in Deployments auf Herz und Nieren zu überwachen. Das reicht von einfachen Tests wie der Frage, ob eine Instanz auf ICMP-Anfragen reagiert (»ping«), bis hin zu komplexen Checks, die der Admin in einen Blueprint in vRealize integrieren kann.

Sonderthema Log-Dateien

Sogar in Form einer eigenen Komponente widmet VMware sich in vRealize dem Thema Log-Dateien. Das ist in verteilten Umgebungen komplexer als in konventionellen Umgebungen, weil der Admin es hier mit mehr Komponenten zu tun hat. Nicht alle davon legen ihre Log-Meldungen in Dateien auf der Platte ab. Kommt etwa die Container-Lösung Podman zum Einsatz, führt sie für jeden Container eine eigene Log-Datei mit den Ausgaben des Standardausgabekanals »stdout« sowie des Standard-Fehlerkanals »stderr«. Verteilt sich ein Setup auf mehrere Cloud-Instanzen, steigert das die Komplexität nochmals erheblich. Im Falle eines Problems hantiert der Admin dann im schlechtesten Fall in verschiedenen Cloud-Umgebungen mit verschiedenen Techniken, um einen Fehler zu finden.

Hier rückt vRealize mit seiner Log-Insights-Komponente an. Sie aggregiert die Log-Meldungen und Dateien eines Setups, sofern der Admin sie zuvor entsprechend im Blueprint von vRealize Automate angegeben hat. Die tatsächliche Struktur des Deployments spielt dann keine Rolle mehr – vRealize trägt alle relevanten Log-Dateien stattdessen an zentraler Stelle zusammen und ermöglicht dem Admin den schnellen Zugriff (Abbildung 4).

Abbildung 4: Die tiefe Integration verschiedener VMware-Technologien wie NSX ist in vRealize Automation freilich perfekt umgesetzt. Quelle: VMware

Zusammengefasst gehen vRealize Operations und vRealize Log Insight als die verlängerten Arme von vRealize Automation durch: Was den virtuellen Setups ganz am Anfang mit auf den Weg gegeben wurde, überwachen die beiden Komponenten und sorgen dafür, dass alle vom Admin festgelegten Regeln auch erfüllt werden.

Hier spielt auch das Thema Compliance mit hinein: Das beachtet der Admin im Idealfall bereits, wenn er einen Blueprint für eine Applikation in vRealize Automation konfiguriert. Denn so erzwingt er, dass die einschlägigen Regeln auch tatsächlich zur Anwendung kommen, falls das Compliance-Konzept des Unternehmens das verbindlich vorschreibt. Durch manuelle Änderungen an Setups besteht zumindest die Gefahr, dass virtuelle Setups Compliance-Vorgaben nicht mehr einhalten. vRealize Operations schiebt dem einen Riegel vor, indem es den Zustand virtueller Setups stets mit dem Soll vergleicht und nötigenfalls durch händische Arbeit vorgenommene Änderungen revidiert.

Business-Integration mittels vRealize Business

Setups zu betreiben und mit den Compliance-Vorgaben im Einklang zu halten ist gut. In den meisten Fällen wünschen Unternehmen sich allerdings auch eine gewisse Form der Integration in bestehende Firmenabläufe.

Verlockend ist für den Admin vor Ort etwa die Idee, mal eben eine virtuelle Instanz auf AWS für einen Test auszurollen. Gelegentlich vergisst er allerdings im Anschluss, die VM wieder zu löschen. Acht Cent pro Minute klingen nicht nach viel Geld, doch bleibt so eine virtuelle Instanz einen ganzen Monat ungenutzt, schlägt sie mit stolzen 3500 Euro zu Buche. Nutzt ein Admin also vRealize, sollte er bereits beim Start von Workloads sehen können, welche Kosten bei den verschiedenen Clouds auf ihn zukommen. Ebenso sollte ein Automatismus existieren, der zu lange laufende Instanzen anhand festgelegter Regeln abschaltet.

Solche Funktionen implementiert vRealize Business for Cloud. Dessen wichtigstes Werkzeug ist ein zentrales Dashboard, in dem IT-Manager die bereits aufgelaufenen und die noch anfallenden Kosten im Überblick behalten. Auf Wunsch findet hier auch eine Kategorisierung statt: Unterschiedliche Nutzer und die durch sie verursachten Kosten lassen sich gruppieren, sodass man schnell erkennt, welche Projekte besonders hohe Kosten hervorrufen.

Erklärtes Ziel von vRealize ist es, Kosten über verschiedene Arten von Infrastruktur hinweg für Controller nachvollziehbar und vergleichbar zu machen. Beim Auswählen einer Target-Plattform für Workloads haben Admins so nicht nur die Möglichkeit, eine Entscheidung im bestmöglichen (weil günstigsten) Interesse der Firma zu treffen. Sie bekommen auch ein konkretes Gefühl dafür, welche Infrastruktur welche Art von Kosten hervorruft.

Voraussetzung dafür ist allerdings, dass jemand die für den eigenen Use Case anfallenden Kosten für Parameter wie vCPUs und vRAM in das Werkzeug einträgt. Je nach Vertrag mit den Cloud-Dienstleistern können die sich ja von Fall zu Fall durchaus unterscheiden (Abbildung 5).

Abbildung 5: Preisangaben und eine schnelle Übersicht verspricht der Business-Teil von vRealize, der besonders Controller freuen dürfte. Quelle: VMware

Praktischen Mehrwert liefert vRealize Business übrigens auch für Admins von privaten Clouds. Stattet der Admin den Nutzer, der sich via vRealize Business mit einer privaten Cloud verbindet, mit Admin-Rechten aus, liest das Werkzeug die aktuellen Nutzungsstatistiken von dort aus.

Hier implementiert vRealize dann eine Trending-Funktion: Reicht die Hardware für den zu erwartenden Workload im Zeitraum X nicht mehr aus, schlägt die Software Alarm und animiert den Admin dazu, Ressourcen nachzulegen. Das ist in privaten Clouds vorteilhaft, weil die Beschaffung zusätzlicher Hardware ja durchaus einiges an Vorlaufzeit erfordert. Hier hilft vRealize beim Planen.

Der Manager managed sich selbst

Unabhängig von allen externen Faktoren gehört zu vRealize ein fünfter Bestandteil, der als eine Art Metakomponente funktioniert. Die einzelnen vRealize-Komponenten müssen ja irgendwie erst einmal ihren Weg auf die Infrastruktur eines Kunden finden. Hier kommt der vRealize-Lifecycle-Manager ins Spiel, der sich genau darum kümmert. Er rollt die zuvor genannten Komponenten aus und integriert sie gleich auch mit zentralen VMware-Tools wie dem VMware-Marketplace. Aus dem heraus lassen sich fertige Anwendungsblaupausen direkt in die vRealize-Tools integrieren, etwa in vRealize Automator.

Einmal mehr zeigt sich, dass VMware in der Lage ist, seine eigenen Produkte nicht nur mit verlässlichem Lifecycle-Management auszustatten: Dem Anbieter gelingt es regelmäßig auch, um diese Werkzeuge herum funktionale Ökosysteme zu bauen, die den Admin weitgehend glücklich zurücklassen.

Vorsicht vor Lock-in

Entsprechend darf diesem Artikel eine Warnung am Ende nicht fehlen: So schön vRealize ist und so gut es funktioniert, so sehr sieht sich der Admin bei der Nutzung einem typischen Lock-in-Effekt gegenüber.

Wer seine internen Arbeitsabläufe einmal auf die VMware-Toolchain ausgerichtet hat, kommt davon kaum mehr los – jedenfalls nicht ohne erhebliche Investitionen. Die Migration bestehender vRealize-Setups in andere Werkzeuge ist praktisch unmöglich. Ist die enge Bindung an VMware für den Admin in Ordnung, stellt das kein Problem dar; vielen VMware-Kunden kennen das Prinzip ohnehin. Dennoch sollte der Admin diesen Effekt vorab in seine Überlegungen einbeziehen.

Und was kostet das?

Weniger erfreulich als die Technik ist aus Sicht des Autors bei VMware regelmäßig das Thema Lizenzkosten. Der Hersteller folgt einer sehr stark fragmentierten Preisstrategie, und von den vorgestellten Produkten gibt es zudem noch jeweils Standard-, Advanced- und Enterprise-Editionen.

VMware selbst gibt auf seiner Produkt-Homepage lediglich einige nebulöse Hinweise im Hinblick auf die gebotenen Funktionen, etwa dass die Enterprise-Edition alle Features böte, die es in vRealize grundsätzlich gibt, während die Standard-Edition lediglich Basis-Funktionalität offeriere. Wirklich schlau wird der Admin aus diesem Kauderwelsch allerdings nicht. Mehr noch: Ein auf der VMware-Website angeblich vorhandener direkter Feature-Vergleich der einzelnen Editionen war bei Redaktionsschluss ein Link ins Nirvana.

Letztlich wird, wie bei VMware üblich, also nur ein Plausch mit einem VMware-Vertriebler zu grundlegendem Durchblick führen. Der kann immerhin gleich ein konkretes Angebot mit tatsächlichen Zahlen liefern, an das bei VMware traditionell ohne Vertriebsmitarbeiter kein Herankommen ist. Immerhin: VMware weist explizit darauf hin, dass vRealize sich mit einer Multi-Cloud-Lizenz des Unternehmens ganz regulär verwenden lässt.

Fazit

VMware vRealize ist eine typische VMware-Lösung: Es lässt sich leicht installieren und betreiben und liefert dank umfassender Funktionen eine Wunschlos-glücklich-Lösung. Wer VMware ohnehin bereits im Haus hat und günstig an das Produkt herankommt, sollte über VMware vRealize als Lösung für den Betrieb von hybriden Setups nachdenken. Die feilgebotenen Funktionen erledigen, was der Hersteller verspricht, und fühlen sich so an, wie man es von VMware gewohnt ist.

Doch prüfe, wer sich ewig bindet: Hat man erst einmal mit vRealize Setups ausgerollt, gelingt der Umstieg auf eine andere Lösung nur unter großen Schmerzen. Der Lock-in-Effekt greift hart und erlaubt dem Admin später kaum noch eine Flucht. (jcb)