Kosten für Big-Data-Lösungen: Oracle Appliance versus Eigenbau
Die Kosten für eine Big-Data-Lösung sind schwer abzuschätzen. Nur eine genaue Analyse zeigt, ob eine All-in-one- oder Selbstbau-Lösung besser ist.
Dies ist der zweite Teil einer Serie über die Oracle Big-Data-Architektur. Der erste Teil stellte eine Reihe von Big Data-Plattformen auf Basis von Standard-Hardware und speziellen Big-Data-Appliances vor. Dieser Teil vergleicht nun die Kosten der beiden Ansätze.
Wer vor dem Problem steht, große Datenmassen zu managen, hat im Grunde zwei Möglichkeiten: Entweder man baut sich auf Basis von Standard-Hardware und Open-Source-Software ein eigenes Inhouse-System. Oder man kauft sich eine Appliance, die die notwendigen Komponenten bereits enthält. Die Vorteile liegen auf der Hand: Ein Standard-Hardwaresystem ist flexibel und hat einen guten Preis - zumindest oberflächlich betrachtet. Mit einer Appliance hingegen gestaltet sich die Umsetzung schnell und einfach - eine attraktive Alternative, wenn Sie über wenig interne Big-Data-Ressourcen verfügen.
Kosten für eine Oracle Big-Data-Architektur
Den bestmöglichen Ansatz für Ihre Oracle Big Data-Architektur zu finden ist keine simple Aufgabe. Bei der Planung eines Big-Data-Projekts gilt es zunächst einmal eine Kostenanalyse zu machen. Doch die ist nicht einfach.
Starten Sie die Kostenanalyse am besten mit der Appliance. Die vollständige Oracle Big-Data-Appliance kostet etwa 450.000 US-Dollar für ein 18-Knoten-Rack. Hinzu kommen saftige Jahresgebühren, wenn Sie Premier Support wollen. Damit sind Ihre Ausgaben aber noch nicht am Ende. Auch wenn Sie sich für den Premier Support entschieden haben, müssen Sie die Appliance noch hosten und den Betrieb aufrecht erhalten. Es ist zudem wahrscheinlich, dass Sie zusätzliche Software implementieren, Anwendungen entwickeln und das System an bestehende Data Warehouses oder relationale Datenbanken anbinden müssen. Kurzes Zwischenfazit: Die Appliance erscheint vielleicht auf den ersten Blick wie eine komplette Plattform, aber kein System ist eine Insel - und Sie werden immer einige interne Ressourcen zusätzlich benötigen.
Kosten für Standard-Komponenten
Kommen wir zur Alternative, der Kostenplanung für den Aufbau eines auf Standard-Komponenten basierenden Systems. Die ist leider noch schwieriger. Die Schätzung der Hardwarekosten für eine Oracle Big-Data-Architektur ist zunächst eine leichte Übung. Doch dies gilt nur, solange Sie sicher sein können, dass die erforderliche Netzwerk-Infrastruktur, wie zum Beispiel Switches und Bandbreite sowie alle anderen Peripheriegeräte, enthalten sind. In der Praxis ist das selten der Fall.
Zudem müssen Sie auch Software und Dienstleistungen berücksichtigen, die Sie unbedingt benötigen. Zum Beispiel brauchen Sie wahrscheinlich eine Anwendung für die Verwaltung Ihrer Hadoop-Cluster wie sie beispielweise von MapR, Cloudera oder Hortonworks angeboten werden. Ebenso müssen Sie sich um die notwendigen Ressourcen kümmern, um die laufende Verwaltung und Instandhaltung sicher zu stellen.
Möchten Sie andere Open-Source-Software in Ihre Plattform integrieren, wie zum Beispiel R Analytics oder MongoDB NoSQL-Datenbanken, dürfen Sie auch die Zeit und die erforderlichen Mittel nicht vergessen, um die Software zu implementieren und zu verwalten. Außerdem benötigen Sie Ressourcen, um die Hardware einzurichten und Hadoop mit anderen Systemen zu verbinden. Und Sie müssen den Zugriff auf Daten sicherstellen und die verschiedenen Systeme unterstützen. Vor allem sollten Sie ein Budget vorsehen für Data Scientists und Ingenieure, die Big Data verstehen und wissen, wie man Datenmassen in einer Hadoop-Umgebung verwaltet. Summa summarum stellen Sie ohne richtiges Know-how die Weichen für unerwartete Kosten und Risiken - und möglicherweise zu einem Projekt, das Sie ganz aufgeben.
Time to Market abschätzen
Ziemlich sicher werden Sie feststellen, dass die Zeit bis zur Inbetriebnahme eines Appliance-basierten Systems kürzer ist als bei einem Standard-Komponenten-System. Mit einer Appliance müssen Sie weder Server einrichten, noch diese vernetzen, weder grundlegende Software installieren noch all diese Komponenten zur zusammenarbeiten bringen. Laut einer Untersuchung der Enterprise Strategy Group im Auftrag von Oracle sparen Sie mit einer Appliance 30 Prozent Time-to-Market.
Alles was Sie beim Appliance-Betrieb tun müssen: Warten auf die zu bauende und zu testende Appliance. Diese Wartezeit können Sie für andere Zwecke als den Selbstbau eines Systems nutzen. Und: Je schneller Sie ein System bekommen, umso schneller können Sie mit der Datenanalyse beginnen - und von den Big Data Vorteilen profitieren.
Wetten auf die Zukunft
Natürlich sollten Sie auch etwas in die Zukunft blicken. Die Appliance kann perfekt auf Ihre aktuellen Bedürfnisse zugeschnitten sein. Aber was ist in zwei Jahren? Oder in fünf?
Angenommen, Sie möchten in absehbarer Zukunft bis zu 200 Terabyte (TB) Daten bearbeiten. Sie wollen das entweder mit einer einzigen 18-Knoten Oracle Big-Data-Appliance oder einem 100-Knoten-Standard System erledigen. Nehmen wir an, Sie bemerken in einem Jahr, dass Sie weitere zehn TB Daten hinzufügen müssen. Dann müssen sie abwägen. Mit der Oracle Appliance müssen Sie ein zweites 6-Knoten-Rack für 160.000 US-Dollar kaufen.
Haben Sie sich hingegen für eine Standard-Plattform entschieden, brauchen Sie nur fünf Rechner hinzufügen und konfigurieren. Das kostet zweifellos viel weniger Geld. Andererseits: Wenn Sie Ihre Datenkapazität in einem Tempo erweitern können, das die Größenordnung der Appliance nicht sprengt, werden Sie es wahrscheinlich einfacher finden, Ihre Racks zu skalieren als Standard-Hardware hinzuzufügen. Die muss schließlich wieder konfiguriert und mit komplexer Software eingerichtet werden.
Fassen wir also zusammen: Systeme, die auf Standard-Hardware basieren, bieten generell für die Zukunft eine höhere Flexibilität. Und es sind nicht nur die Risiken immer größerer Datenmengen, bei denen Flexibilität wichtig ist. Unser Verständnis von Big Data und die Art, wie wir damit umgehen, basiert auf einer relativ jungen Technologie, die sich schnell ändert. Selbst Google ist ständig auf der Suche nach neuen und besseren Möglichkeiten, um seine riesigen Datenmengen zu verarbeiten.
Eine Appliance unterliegt auf der anderen Seite hingegen einer bestimmte „Philosophie“ und wird mit einer bestimmten Konfiguration ausgeliefert. Was aber passiert, wenn diese Philosophie und Konfiguration nicht mehr die beste Strategie für den Umgang mit Big Data ist?
Auch die Cloud wird künftig bei Big Data wahrscheinlich eine größere Rolle spielen. Irgendwann wird die Zeit kommen, wenn die Cloud Unternehmen besser mit IT-Services versorgen kann, als dies In-House Technologie erledigt – egal ob Appliance- oder Commodity-basiert. Für einige Organisationen ist diese Zeit bereits angebrochen. Und was die Zukunft betrifft: Wenn Sie heute eine Appliance kaufen, werden Sie diese auch morgen noch effektiv nutzen können? Was ist, wenn sie Ihre Big-Data-Bedürfnisse nicht mehr bedienen kann? Mit Standard-Hardware haben Sie zumindest mehr Möglichkeiten, diese Systeme dann anderweitig zu nutzen. Aber auch bei diesen Systemen sollten Sie erst in die Zukunft schauen, bevor Sie sie kaufen.
Bauen oder Kaufen?
Es gibt viele Faktoren, die man bei der Entscheidung zwischen einem Appliance- und einem Commodity-basierten System berücksichtigen sollte. Wenn es Ihr Unternehmen mit Big Data eilig hat und mit so wenig Aufwand wie möglich eine Lösung bekommen möchte, ist eine Appliance wohl der richtige Weg.
Wenn Sie eine Appliance kaufen, kaufen sie nicht nur die Hardware, sondern auch den Service und die Kompetenz, die man für Implementierung und Management braucht. Wenn Sie andererseits über die notwendigen internen Ressourcen verfügen - einschließlich eines hohen Maßes an Know-how - können Sie von der Flexibilität profitieren, Ihr System selbst zu bauen. Das gilt vor allem dann, wenn Sie eine große Anzahl an ungenutzter Standard-Hardware herumstehen haben.
Wie auch immer: Keine Option sollte auf die leichte Schulter genommen werden. Beide Möglichkeiten haben einen hohen Preis - und ihre Risiken, die auf den ersten Blick nicht immer offensichtlich sind. Wie auch immer Sie sich entscheiden: Versuchen Sie die Gesamtkosten und die Time to Market realistisch einzuschätzen. Und vergessen Sie nie die Zukunft.
Über den Autor:
Robert Sheldon ist technischer Consultant und Autor mehrere Bücher, Artikel und Schulungsmaterial von Microsoft Windows, verschiedener relationaler Datenbanksysteme sowie Business-Intelligence-Design und -Implementierung.
