Als ITGAIN-Consultant weiß Ferdinand Prahst, wie der Betrieb von Datenbanken läuft. „Zusammen mit meinen Kollegen erbringen wir bei vielen unserer Kunden den sogenannten ‚managed database service (mds)‘. Das bedeutet wir betreiben als externe Experten die Datenbanken unserer Kunden in deren Rechenzentren. Wir beheben Störungen, führen die Maintenance durch und planen den Lifecycle“, erklärt Ferdinand Prahst. „Daher weiß ich, wie verzwickt die Arbeitsbeziehung zwischen Datenbankadministratoren und Entwicklern oftmals sein kann.“ Umso wichtiger sei es, ein neues Mindset zu etablieren, wenn sich beide Abteilungen annähern und gemeinsam an einem Strang ziehen sollen. Ist das geschafft, folgt der nächste Schritt.
Kollaboration ist der Schlüssel
Schon lange schreiben Entwickler ihre Anwendungen nicht mehr im Texteditor. Alles ist mittlerweile viel schneller, agiler geworden. Der Entwickler kann seine Codezeilen praktisch auf Knopfdruck im Frontend implementieren und das Ergebnis direkt sichtbar machen. Getestet wird schon, auch wenn die Anwendung noch nicht ganz fertig ist. „Für Datenbankadministratoren ist das oft zu schnell“, erklärt Prahst. „Vor allem beim Thema Sicherheit, Fehlertoleranz, Stabilität und Performance gibt es wenig Spielraum. Zwischen Entwicklern und Datenbankadministratoren muss daher die Kommunikation stimmen. Hierzu ist es hilfreich, wenn beide Seiten unter anderem auf Basis von Tools verknüpft sind.“ Die Frage lautet also: Mit welchen Programmen gelingt es, die kommunikativen Hürden zu überwinden?
Die Lösung heißt Open Source
Um sich der Antwort zu nähern, ist es entscheidend, die Unterschiede in der Arbeitsweise zu verstehen: Entwickler denken in Anwendungsversionen, Datenbankadministratoren in Releases des Datenbanksystems. Für einen Entwickler beginnt eine Anwendung mit Version 1. Es folgt eine Verbesserung 1.1, sie enthält etwa Fehlerkorrekturen oder neue Funktionen. Ein Datenbankadministrator hingegen arbeitet auf das nächste große Release-Update für die Datenbank hin, also eine nahezu neue Hauptversion. Und bis es so weit ist, muss so viel wie möglich getestet werden, damit gleich alles stimmt. Strukturänderungen an Datenbanken werden vom Datenbankadministrator selten oder gar nicht versioniert. „Um beide Abteilungen auf ein Level zu bringen, kann daher eine einheitliche Versionierung der Datenbanken eingefügt werden. Beide Abteilungen reden vom Gleichen, wenn sie von Versionen sprechen“, erklärt IT-Consultant Ferdinand Prahst. „Oder wir implementieren ein kollaboratives Tickettool für eine gemeinsame Kontrolle des Betriebs.“ ITGAIN arbeitet dabei am liebsten mit Open Source-Lösungen. „Dadurch sind wir vor allem eins: flexibel“, sagt Prahst. „Die Programme lassen sich ohne Weiteres auf die Bedürfnisse der Kunden zuschneiden.“ Ein Service auf den die Berater bei ITGAIN besonderen Wert legen.
Der Markt der Open Source-Lösungen ist groß. So gibt es unzählige Möglichkeiten, wie verschiedene Abteilungen ihre Kommunikation untereinander verbessern und die Arbeiten genauer aufeinander abstimmen können. Im Folgenden ein Beispiel, das vor allem Entwicklern und Datenbankadministratoren hilft, ihr neues DevOps-Mindset auch praktisch umzusetzen.
Liquibase
Mit Liquibase lassen sich Strukturänderungen an Datenbanken, wie Tabellen oder Abfragen, in Versionen einteilen. Entwickler und Datenbankadministratoren können mit dieser datenbankunabhängigen Open Source-Lösung gemeinsam Änderungen im Datenbankschema verfolgen, verwalten und anwenden. So sprechen beide Abteilungen immer von derselben Version der Anwendung und der Datenbank. Das hilft, die Grenzen im Kopf zu überwinden.
Eine andere Idee ist es mit einem gemeinsamen Tickettool Fehler zu verwalten, Probleme zu behandeln und Störungen zu identifizieren. Datenbankadministratoren, die normalerweise nicht immer mit solchen Tools arbeiten, können sich so an den Umgang mit ihnen und die kollaborativen Möglichkeiten solcher Lösungen gewöhnen. Auch hier haben beide Abteilungen Zugriff und können sich absprechen, was an welcher Stelle geprüft werden muss. „Tritt beispielweise in der Produktion eine Störung in einer Anwendung auf, so wird ein Ticket eröffnet. Gemeinsam mit den Entwicklern wird das Problem analysiert und wenn notwendig durch eine Fehlerkorrektur in der Anwendung behoben. Es kann aber auch vorkommen, dass ein Fehler in der Datenbank oder eine nicht optimal konfigurierte Datenbank die Ursache ist. Hier lernen dann beide Bereiche gemeinsam an einer Lösung zu arbeiten, ohne durch Fingerzeig auf den anderen die Fehler von sich zu weisen. Auch das ist ein zentraler Bestandteil der neuen Denkkultur“, führt Prahst aus.
Mit dem richtigen Werkzeug wird der DevOps Ansatz zum Game Changer für jedes Unternehmen."
FERDINAND PRAHST, LEAD CONSULTANT UND TEAMLEITER BEREICH OPERATIONAL SERVICES
Der richtige Werkzeugkasten
Liquibase ist nur eine Möglichkeit in einer großen Vielfalt von Open Source-Anwendungen, die ständig wächst. ITGAIN hat es sich daher zur Aufgabe gemacht, ihren Kunden den passenden Werkzeugkasten zur Verfügung zu stellen. Alle Programme, die von Consultants wie Ferdinand Prahst empfohlen werden, sind auf ihre Funktionalität geprüft und richten sich nach der bestehenden Infrastruktur der Kunden. „Wir müssen wissen, was am besten passt“, sagt Ferdinand Prahst. „Denn DevOps mit Open Source-Lösungen einzuführen ist immer eine große Herausforderung, die ein Umdenken erfordert. Doch wenn wir in kleinen Schritten vorangehen und mit guten Tools den Benefit dieses Ansatzes präsentieren können, dann ist mit DevOps plötzlich alles möglich.“