Datenbanksysteme Teil 5

- Deepshore

Kosten – Lizenzen versus Open Source versus Subscription

Neben der rein technischen und konzeptionellen Betrachtung einer Datenbanktechnologie stehen aber auch immer die zu kalkulierenden Kosten im Fokus: Beschaffung, Herstellung, Betrieb und Wartung. Diese vier Blöcke summieren alles, was es zu beachten gilt. Noch bis vor Kurzem war es zu mindestens im relationalen Bereich relativ einfach, die Kosten zu kalkulieren. Man wählte zwischen den Produkten von IBM, Oracle oder Microsoft anhand der Preisliste oder der Supportmatrix von Lösungsanbietern eine Datenbank aus. Nun noch die Tagessätze der „Gold"-Partner verhandeln und gegebenenfalls zusätzlich die eigenen Mitarbeiter auf eine Herstellerschulung schicken. Dienstleistungskosten und Lizenzen für den Betrieb waren relativ einfach zu kalkulieren, da der Pfad ausgetreten und das durchschnittliche Know-how in der Regel ausreichend vorhanden war.

Mit PostgreSQL hat vor einiger Zeit eine Open-Source-Alternative die Bühne betreten, die den alten Platzhirschen zunehmend das Wasser abgräbt. In puncto Leistungsfähigkeit ist die Lücke nicht mehr groß bzw. in einigen Bereichen wie zum Beispiel der Storage-Skalierung sehen die klassischen Datenbankhersteller mittlerweile relativ alt aus. Leider ist es aber so, dass die Qualifikation der eigenen Mitarbeiter in diesem Technologiebereich schwieriger ist als bei einem klassischen Datenbanksystem, bei dem man einfach die vom Hersteller angebotenen Qualifikationsmaßnahmen nutzen kann. Und dass ein Open-Source-Projekt auch keine zugesicherten Systemeigenschaften liefert, erleichtert eine Kostenkalkulation auch nicht grade. Die Kalkulation der Herstellungskosten von Lösungen ist also schwieriger geworden. Hinzu kommen mittlerweile auch Lizenztypen aus dem Open-Source-Bereich, die sich inhaltlich deutlich differenzieren. Auf der einen Seite stehen hier die Apache-2.0-lizenzierten Produkte, die den echten Open-Source-Charakter widerspiegeln und auf der anderen Seite zum Beispiel BSL (Business Source License) oder GPLv3-lizenzierte (General Public License) Produkte wie MongoDB oder CockroachDB. Deren verändertes Lizenzrecht wird fast immer damit begründet, dass man sich gegen die großen Cloudhersteller wehren will, die das eigene Enterprise-Modell zerstören, indem sie das Open-Source-Produkt als Managed Service in der Cloud anbieten. Alleine diesem Aspekt könnte ein eigener Beitrag gewidmet werden. Deshalb belasse ich es an dieser Stelle bei dem Hinweis, auch bei Open-Source-Lizenzen das Kleingedruckte zu lesen.

Bei all den Unsicherheiten tun sich vor allem Großunternehmen damit schwer, alte Gewohnheiten infrage zu stellen und neue Wege zu beschreiten. Auch wenn sich Konzerne mit neuen Technologien befassen, sind in den Köpfen nicht selten die alten Support- und Wartungsstrukturen zementiert, was eine Kostengegenüberstellung (neu zu alt) nicht grade erleichtert. In Kombination mit einem gewissen Phlegma auf der organisatorischen Ebene resultiert das in einer großen Unbeweglichkeit auf der Lösungsebene. Dadurch werden Potenziale häufig gar nicht oder nur sehr wenig genutzt. Wir landen wieder bei den vier Grundsätzen für den erfolgreichen Einsatz neuer Technologien aus dem ersten Teil dieser Serie:

  1. Scouting
  2. Verproben
  3. Design
  4. Entscheiden

Da sich die IT-Organisation damit schwertut, Open-Source-Produkte in Eigenregie zu scouten, zu verproben, zu installieren, zu betreiben und zu warten, hat sich in den letzten Jahren ein neues Geschäftsmodell in diesem Segment entwickelt. Es nennt sich „Subskription" (Abomodell) und ist irgendwo zwischen einer klassischen Lizenz und der reinen Open-Source-Lizenzierung anzusiedeln. Der Fokus dieser Anbieter ist fachlich und technisch sehr heterogen, weshalb sich die Angebote auch nicht einfach vergleichen lassen. Was jedoch alle Anbieter gemeinsam haben, ist, professionellen Service für die Open-Source-Basis der verwendeten Produkte anzubieten. Es geht also auch darum, die Unsicherheiten bei der Einführung neuer Technologien zu verringern und eine etwas besser planbare Grundlage (Kosten) zu schaffen.

Im relationalen Bereich gibt es beispielsweise EnterpriseDB als kommerziellen Anbieter für PostgreSQL als Alternative zu Oracle und Co. EnterpriseDB (EDB) wirbt dabei mit bis zu 40 Prozent Kostenreduktion im Vergleich zum Oracle-Lizenzmodell. Darüber hinaus werden die Migrationshürden von Oracle hin zu PostgeSQL als besonders einfach beworben. Neben dem direkten Kostenvergleich mit den lizenzpflichtigen Softwareprodukten werden noch zusätzliche Features im Rahmen der Subskription angeboten. EDB bietet beispielsweise einen zusätzlichen Security Layer an, der in dieser Form nicht in der Open-Source-Community vorhanden ist. Große Unternehmen, die zwar eine bestimmte Technologie nutzen möchten, aber nicht in den eigenen Ausbau der Open Source Basis investieren wollen, können sich also gewünschte Add-ons auf diesem Weg beschaffen. Genau an dieser Stelle wird auch eine Schattenseite der Open-Source-Projekte deutlich. Sie sind an einigen Stellen eben nicht unbedingt so ausgereift und „fertig", als dass sie ohne jeden Zusatz in einer produktiven Enterprise-Umgebung eingesetzt werden könnten. Das gilt in erster Linie im relationalen Bereich, wo die lizenzpflichtigen Produkte über Jahre hinweg nach den Wünschen und Bedürfnissen der Kundenbasis weiterentwickelt wurden. Grade bei Fragen der Security ist es so, dass Implementierungen auf Basis von Open-Source-Projekten zusätzliches Know-how und Investments erfordern.

Bei verteilten Datenbanktechnologien ist der Markt dagegen anders strukturiert. Anbieter wie Oracle oder Microsoft spielen mit ihren Lizenzmodellen keine Rolle, da sich die Technologien erst vor wenigen Jahren am Markt etabliert haben. Mit ihnen kam gewissermaßen das Konzept der Community-Entwicklung (Open Source). Eben weil sich die Old Economy schwer damit tut, auf die neuen Technologien zu setzen, sind auch in diesem Segment kommerzielle Anbieter von Open-Source-Produkten entstanden. Die zwei bekanntesten sind vermutlich Cloudera/Hortonworks (Hortonworks Data Plattform) und Datastax (Datastax Enterprise). Deren Geschäftsmodell ist im Grunde gleich, jedoch mit einer etwas anderen Ausrichtung als EDB. Da der Fokus eher auf verteilten Lösungen liegt, werden auch vornehmlich analytische bzw. Big-Data-Themen beworben. Gerade bei Hortonworks, die nahezu den gesamten Hadoop-Kosmos mehr oder wenig gut integriert haben, ist dabei eine mächtige Plattform entstanden. Man könnte sich durchaus die Frage stellen, ob der Anbieter etwas über das Ziel hinausgeschossen ist, da es wohl nur sehr wenige Menschen gibt, die die Komplexität und Zusammenhänger aller Hadoop-Produkte wirklich kennen und verstehen. Insofern verwundert es auch nicht, dass viele Datalake-Projekte auf Basis einer Hortonworks-Data-Plattform zwar teuer waren, nicht aber den versprochenen Nutzen liefern konnten.

Datastax ist hier etwas klarer strukturiert und legt einen sichtbaren Schwerpunkt auf Cassandra und Spark. Garniert wird das Ganze mit etwas GraphDB und erweiterten Suchoptionen sowie einer ansprechenden Administrationsoberfläche. Technologisch ist es ein anderer Stack als bei Hadoop, obgleich Hadoop technisch ähnliche Projekte beinhaltet (zum Beispiel HBase versus Cassandra). Was besser ist? Das überlasse ich Ihrem Anwendungsfall und der vertrieblichen Argumentationskunst der kommerziellen Anbieter.


Tabelle: Implementierungen mit Datenbanksystem

Egal, für welches Modell Sie sich entscheiden. Es ist fundamental wichtig, dass die Techno­lo­gien wirklich verstanden werden. Das Risiko, mit einem Open-Source-Projekt zu scheitern und dabei unnötige Kosten zu produzieren, ist umso höher, je weniger technische Expertise bei einem Projektteam vorhanden ist. Ohne das passende Know-how kann auch die richtige Technologie völlig falsch verwendet werden. Auf der anderen Seite sind die „alten" rela­tio­nalen Technologien zwar teuer, jedoch auch vielfach erprobt und weitgehend bekannt. Für diese Produkte Fachpersonal oder Beratung zu bekommen, ist im Vergleich zum Open-Source-Bereich deutlich einfacher, da auch der Markt überschaubarer ist. Es gibt jedoch ge­nug fachliche Anwendungsfälle, deren Beantwortung mit den neuen Datenbank­techno­lo­gien deutlich besser und preiswerter funktioniert, als es mit den klassischen Anbietern möglich ist.

Es ist also wie immer: Ziel/Fachkompetenz * Innovationskraft = Ergebnis mit F, I ∈ [0;1]

Teilen