Warum ist das Schreiben über die Arbeit mit Open-Source von Bedeutung?
Für Unternehmen, die bisher hauptsächlich mit kommerzieller Software gearbeitet haben, erfordert es eine grundlegende Neuausrichtung und eine Veränderung der Denkweise, um Open-Source in vollem Umfang zu verstehen und seine Vorzüge optimal zu nutzen.
In diesem Beitrag möchten wir mögliche Hindernisse aufzeigen und die Probleme ansprechen, die uns in Gesprächen mit Kunden über die Migration von DB2, MS SQL Server, Oracle oder anderen kommerziellen Lösungen zu PostgreSQL aufgefallen sind.
Es scheint drei Hauptargumente zu geben, die Unternehmen davon abhalten, Open-Source-Datenbanken einzuführen:
– Mangelnde Zuständigkeit
– Das abstrakte Konzept der “Community”
– Technische Herausforderungen
Mangelnde Zuständigkeit
Wenn Sie eine Lösung kaufen, die von einem einzigen Anbieter von Anfang bis Ende entwickelt wurde, liegt die Verantwortung für etwaige Ausfälle, gescheiterte Implementierungen von Funktionen und Inkompatibilitätsprobleme bei diesem Anbieter. Sie können stets auf Online-Formulare, Fehlerbehebungshandbücher, Chats oder Telefonnummern zurückgreifen, die Ihnen das Sicherheitsnetz bieten, nach dem Sie suchen.
Das Dilemma besteht darin, dass Sie erst feststellen, ob der Chat oder das Online-Formular wirklich hilfreich sind, wenn Ihr System bereits ausgefallen ist und die Software NICHT funktioniert. Dennoch wird dies oft als Verkaufsargument während der Kaufentscheidungsphase präsentiert.
Tatsächlich erfordert es in der Realität bei Problemen mit der Software zahlreiche Eskalationen und Gespräche, bis Sie die benötigte Unterstützung erhalten. Ganz zu schweigen davon, dass es keine sofortigen Datenbankkorrekturen geben wird, nur weil Sie ein Problem mit der Software haben.
Auch im Fall von Open-Source-Lösungen erhalten Sie nicht sofort einen Lösungsansatz, weshalb die allgemeine Annahme, dass kommerzielle Lösungen sofortige Korrekturen bieten, im Kontext von Open-Source nicht wirklich relevant ist. Hierbei ist durchweg harte Arbeit erforderlich, um Unterstützung zu erhalten – sei es durch finanzielle Beiträge (bei kommerziellen Datenbanken) oder durch die Bereitstellung von Ressourcen (bei Open-Source-Lösungen).
Das abstrakte Konzept der “Community”
Der Begriff “Postgres-Community” zeigt sich in vielfältigen Facetten, ohne eine klare, einheitliche Definition. Die PostgreSQL-Webseite beschreibt eine Gemeinschaft, die in Mailinglisten, im Postgres Slack und auf IRC aktiv ist. Doch neben diesen offiziellen Kanälen existieren auch inoffizielle Gruppen und Plattformen, die eine Bandbreite von
Benutzern, Dienstleistern, Postgres-Entwicklern, Mitarbeitern, Befürwortern sowie jenen, die eine Migration zu Postgres in Erwägung ziehen, einschließen. Im Gegensatz dazu bieten kommerzielle Datenbanken oft geschlossene Communitys für Premium-Kunden an oder erlauben die Suche nach Antworten in öffentlichen Foren und Chats. Aber die direkte Interaktion mit den Kern-Entwicklern und -Mitarbeitern der Datenbank ist hierbei selten möglich.
Die anfängliche Fülle an Kanälen bei Postgres mag verwirrend erscheinen, wenn es darum geht, wohin man sich wenden soll – sei es für eine einfache Datenbankfrage, das Einbringen eines Funktionsvorschlags, das Melden eines Fehlers oder das Erkunden zukünftiger Features. Tatsächlich gestaltet sich jedoch all dies bei Postgres wesentlich einfacher als bei einer kommerziellen Datenbank.
Dies resultiert aus der Vielfalt der Teilnehmerprofile in den verschiedenen Kommunikationswegen. Jede Mailingliste fokussiert sich auf einen bestimmten Aufgabenbereich, jedoch wird Ihnen bei abweichenden Fragen die richtige Richtung gewiesen oder Ihre Anfrage sogar beantwortet. Telegram-Kanäle beherbergen eine Vielzahl von Fachexperten (DBAs, Entwickler, nicht-technische Spezialisten), was Ihnen unabhängig von Ihrer Fragestellung eine Antwort ermöglicht.
Die Postgres-Community besteht aus leidenschaftlichen Menschen, die das Voranschreiten von Datenbankentwicklung und -implementierung interessiert. Hierbei handelt es sich nicht um bezahlte Beteiligungen, wodurch ein noch höheres Maß an Engagement und Service entsteht als bei kommerziellen Lösungen.
Es ist von Bedeutung, dass Sie sich aktiv an den vielfältigen Aktivitäten der Community beteiligen, um die Vorteile von Open-Source vollständig auszuschöpfen. Dies kann die Teilnahme als Sprecher an Community-Konferenzen, das Verfassen von Blogbeiträgen für “Planet Postgres“, die Mitarbeit als Freiwilliger in der Postgres-Gemeinschaft, das Teilen von Entwicklungserfolgen (Postgres-Utilities, Datenbankverwaltungstools usw.) mit der Community oder die Teilnahme am Commitfest (Verfassen und Überprüfen von Patches) beinhalten – und vieles mehr.
Natürlich erfordert dies eine Veränderung der Teamkultur, weg von Individualismus hin zu einem kollektiven Ansatz.
Es liegt in Ihrer Entscheidung, ob Sie diese Aktivitäten mit Ihrem firmeninternen Team durchführen oder einen Anbieter wählen, der ein integraler Bestandteil der Community ist und somit als Schnittstelle zwischen Ihrem Team und der Gemeinschaft fungieren kann.
Technische Herausforderungen
Neben den kulturellen und betrieblichen Herausforderungen gibt es einige technische Aspekte, die berücksichtigt werden müssen, wenn der Wechsel von kommerziellen Datenbanken zu Postgres in Erwägung gezogen wird.
Datensicherung
Es existieren diverse leistungsfähige Lösungen für Backups und Wiederherstellungen in Postgres. Angefangen bei pg_basebackup bis hin zu effizienten Optionen wie pgBackRest oder WAL-G. Allerdings stellt die Vielfalt dieser Lösungen im Gegensatz zum einheitlichen Ansatz von ORACLEs RMAN eine Herausforderung dar. Es bedarf einiger Aufwand, die passende Lösung für Ihr Setup zu finden. Aber wenn Sie eine Lösung gefunden haben, die reibungslos mit Ihrer Konfiguration arbeitet, wird sie sich bewähren.
Umschreiben von Code
In etablierten Systemen findet sich oft eine Menge datenbankspezifischer Code, der überarbeitet werden muss, um mit anderen Datenbanken zu funktionieren. Gespeicherte Abläufe sind ein gutes Beispiel hierfür. Trotz des Einsatzes von ORMs und hilfreichen Tools wie ora2pg, die eine nahezu 100%ige Umwandlung des Oracle-Schemas in Postgres ermöglichen, ist das Resultat oft noch weit vom Ideal entfernt. Konvertierter Code verhält sich mitunter anders und erfordert nach der Migration manuelle Optimierungen.
Stagnierender Code
Es kommt vor, dass Teile eines Systems nicht aktiv weiterentwickelt werden, insbesondere bei ausgereiften Unternehmenssystemen. Während das Entwicklerteam sich auf die Implementierung neuer Funktionen konzentriert, bleibt ein Teil der alten Codebasis erhalten. In solchen Fällen fehlt oft das Verständnis für bestimmte SQL-Abfragen und deren Umstrukturierung. Hier können Tools wie IvorySQL oder Orafce hilfreich sein. Während es ratsam ist, solche Kompatibilitätsschichten langfristig zu überarbeiten, können sie die Migration erleichtern und weniger arbeitsintensiv gestalten, ohne dabei Betrieb und Verfügbarkeit zu gefährden.
Limitationen von PostgreSQL
Eine häufige technische Herausforderung, der Unternehmen bei der Planung einer Migration begegnen, ist die Frage, ob PostgreSQL eine bestimmte Funktion genauso gut beherrscht wie ihre bevorzugte kostenintensive kommerzielle Datenbank. Besonders wenn geschäftskritische Systeme stark von einer spezifischen Funktion X abhängen. Dies könnte Partitionierung, Replikation oder Backup-Strategien umfassen. Diese Funktionen werden oft von der bevorzugten kommerziellen Datenbank als optimale Lösung präsentiert. Natürlich kann das stimmen, da kommerzielle Datenbanken das Ergebnis von tiefgreifendem Wissen und Leidenschaft von Wissenschaftlern, Ingenieuren und Geschäftsleuten sind.
Strukturprobleme
Durch jahrelange Koexistenz mit kostenpflichtigen Datenbanklizenzen könnte die Systemstruktur ernsthaft beeinträchtigt sein. Kosteneinsparungen könnten dazu geführt haben, dass statt eines effizienten Scale-out-Ansatzes eine “imposante” monolithische Datenbank verwendet wurde. Obwohl solche Migrationen anspruchsvoll sein können, bieten sie möglicherweise die Chance, die Struktur zu optimieren und gleichzeitig Betriebskosten zu senken.
Die Bewältigung dieser technischen Hürden erfordert eine umfassende Planung und eine fundierte Entscheidungsfindung, um die Migration so reibungslos wie möglich zu gestalten.
Gleichzeitig dürfen wir nicht außer Acht lassen, dass Postgres genau das erreicht hat – viele seiner Funktionen spiegeln jene der kommerziellen Lösungen wider. Auch wenn die Implementierung variieren mag, erfüllen sie dennoch ihren Zweck. Bei anderen Lösungen hingegen könnten Umwege nötig sein.
Zusammenfassend lässt sich feststellen, dass diese umfassenden kommerziellen Lösungen praktisch sind. Allerdings kann es, angesichts ihrer hohen Kosten, von Vorteil sein, Alternativen in Betracht zu ziehen und letztendlich nach einer besseren Lösung Ausschau zu halten – wie beispielsweise PostgreSQL.
Ilya Kosmodemiansky
CEO und Mitgründer, Data Egret
Ilya hat über 15 Jahre Berufserfahrung in der IT-Branche und hat Data Egret vor 10 Jahren gegründet, um den Maßstab im Datenbanken-Support für PostgreSQL höher zu setzen sowie unseren Kunden eine zuverlässige Datenbankleitung gewährleisten zu können. Ilya hat eine aktive Rolle in der Entwicklung der PostgreSQL Gemeinschaft inne, so ist er Direktor beim PostgreSQL Board und Sponsorship Committee of PostgreSQL Project, Mitorganisator von Anwendergruppen und Treffen (PostgreSQL User group Frankfurt am Main, DevOpsSaar meetup) und ist einer der Organisatoren von den Community Konferenzen (PGConf.EU, FOSDEM).
Direktor, Data Egret
Valeria ist seit 7 Jahren aktives Mitglied der PostgreSQL Community sowie als Marketing- und Geschäftsentwicklungsdirektor bei Data Egret tätig. Sie ist Chair der US Postgres User Group Association sowie Mitglied der Postgres Funds Group und wurde für die PostgreSQL Person of the week interviewt.
Valeria sieht ihre Aufgabe darin, die Postgres-Benutzerbasis durch Advocacy-Aktivitäten zu erweitern und die Transparenz der Postgres-Community-Operationen zu erhöhen.