Mehr Speed im Banking mit DevOps

Speed, Benutzerfreundlichkeit und Zuverlässigkeit

Zwar lassen sich die Geschäftsfelder von Internetfirmen und Banken nicht eins zu eins vergleichen, dennoch gibt es auffällige Parallelen. Ob man wie Google Milliarden Suchanfragen pro Tag beantwortet oder als Bank Millionen von Börsentransaktionen durchführt. Am Ende des Tages zählen Speed, Benutzerfreundlichkeit und Zuverlässigkeit. All das ist ohne maximale Skalierbarkeit und Continuous Delivery nicht möglich.

Auf neuen Wegen mit DevOps

Wie lassen sich hunderte Softwareänderungen in einer komplexen Umgebung testen, sicher ausrollen und bei Bedarf wieder rückgängig machen? Hier kommt DevOps ins Spiel. Die Kombination aus Softwareentwicklung (Development) und dem IT-Betrieb (Operations) beschreibt Maßnahmen, mit denen sich Bruchstellen zwischen Anwendungsentwicklung und IT-Betrieb überwinden und die genannten Herausforderungen meistern lassen.

DevOps ist jedoch kein fertiges Produkt, sondern eine Methode, welche die Zusammenarbeit von Softwareentwicklung und IT-Betrieb beschreibt. Jeder IT-Dienstleister, so auch Adacor, muss ein eigenes Vorgehen erarbeiten und anschließend seinen Tool-Baukasten mit Software füllen. Daraus folgt, dass am Ende DevOps bei jedem Kunden und in jedem Projekt anders aussieht.

Bremsklötze Legacy-IT und Compliance

Banken kämpfen mit über Jahrzehnten gewachsenen IT-Infrastrukturen, komplexen Plattformen und komplizierten Schnittstellen-Architekturen. Als wäre das nicht genug, unterliegen sie umfangreichen Compliance-Vorgaben. Alleine die Ende 2017 von der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) eingeführten „Bankaufsichtliche Anforderungen an die IT“ (BAIT) machen deutlich, in welch komplexem Umfeld sich Banken mit ihrer IT bewegen. Die BAIT regeln unter anderem Themen wie IT-Sicherheit, Datensicherung und Anwendungsentwicklung. Will man in einem solchen Rahmen Continuous Delivery realisieren, führt an DevOps langfristig kein Weg vorbei. Der DevOps-Ansatz bietet die Basis für agile Weiterentwicklung, umfangreiche Sicherheit, Nachverfolgbarkeit, Einhaltung von Compliance und flexible Skalierbarkeit.

Continuous Delivery am Beispiel Mobile Banking

Ein typisches Beispiel verdeutlicht die Herausforderungen von Continuous Delivery und die Möglichkeiten, die DevOps in diesem Bereich ermöglicht. Eine Großbank bietet ihren Kunden weltweit eine mobile Banking-App, die mit dem zentral verwalteten Kernbankensystem kommuniziert. Der “Kern” der App ist in allen Ländern gleich, wird jedoch durch landesspezifische Module an die lokalen Gegebenheiten angepasst.

Neue Funktionen oder gesetzliche Vorgaben müssen täglich, Sicherheitsupdates teilweise stündlich weltweit ausgebracht werden. Auf der einen Seite müssen dafür die Apps auf den mobilen Endgeräten, auf der anderen Seite die Server in der jeweiligen Niederlassung aktualisiert werden. Hinzu kommt, dass je nach Zuspruch der Endkunden die Anzahl der verfügbaren Server in der jeweiligen Cloud hoch- oder runtergefahren werden muss. Ein derartig schnelles Entwicklungstempo kollidiert mit traditionellen Betriebskonzepten, die vorsehen, dass jedes Release manuell vom Betriebsteam auf einer Staging-Umgebung getestet wird und dann auf das Live-System ausgerollt wird. Bei einem Release pro Monat mag dies noch funktionieren, aber nicht bei täglichen oder stündlichen Updates.

So kann die praktische Umsetzung aussehen

Soll in dem genannten Beispiel etwa eine neue Software auf allen Servern installiert werden, dann war bisher viel manuelles Arbeiten angesagt. Der Administrator musste die Software für jedes System anpassen, sich sukzessive auf allen diesen Systemen einloggen, die entsprechende Datei installieren, das System eventuell neu starten, kontrollieren ob alles läuft – und nicht vergessen, sich am Ende wieder auszuloggen.

Sämtliche Vorgänge müssen natürlich irgendwo protokolliert werden, damit andere Admins diese nachverfolgen können und sie BAIT-konform sind. Entweder erfolgt das über einen Gatekeeper, auf dem man sich einloggt und von dort aus auf die Systeme zugreift. Dieser protokolliert dann alles. Oder man macht es manuell und muss dann auch alle Änderungen per Hand dokumentieren. Klar sein dürfte, dass bei händischem Vorgehen – vor allem, wenn man es an hunderten Servern durchführen muss – neben Langeweile auch Fehler vorprogrammiert sind.

All das kann man abstrahieren und automatisieren, wenn man sich in einer DevOps-Welt bewegt. Durch den Einsatz von DevOps kommt man weg davon, sich mit einzelnen Systemen zu beschäftigen. Dazu erstellt man Templates, programmiert also Code, der am Ende das macht, was bisher der Admin per Hand in die Shell des Servers eingegeben hat. Sämtliche Änderungen an den Vorlagen werden revisionssicher dokumentiert – der Admin spielt nur noch diese Templates aus.

Vor dem Ausspielen kann man alles auf einem Staging-System aufspielen und dort automatisierte Security-Tests anstoßen. Hier kann man das in Code “gegossene” Security-Framework der Bank gegen das Staging laufen lassen und so automatisch feststellen, ob das geplante Vorgehen den Sicherheitsrichtlinien der Bank entspricht. Das deckt auch das Vulnerability Management ab. Wenn die Tests bestanden werden, erfolgt automatisch eine Rückmeldung an das Automatisierungstool. Adacor verwendet dafür die Open-Source-Software Ansible von Red Hat. Ansible ermöglicht das Lifecycle-Management von Apps durch Anwendungsverteilung, Netzwerkautomation, Konfigurationsmanagement und Workflow-Orchestrierung. Im Abschluss sorgt Ansible zusätzlich für die Ausspielung der Änderungen auf allen Servern.

Das bedeutet, der sonst sehr aufwändige Prozess wurde stark automatisiert und verschlankt. Im Idealfall hat der Admin dabei keinen direkten Zugriff mehr auf Server, Dateien oder personenbezogene Daten. Dann braucht er das, was er tut, nicht mehr manuell zu dokumentieren.

Spiel nach festen Regeln mit dem Playbook

Wie eingangs beschrieben, gleicht kein DevOps-Projekt dem anderen. Damit man das Rad nicht immer wieder neu erfinden muss, nutzt Adacor Playbooks. Das Know-how und die Ergebnisse der Kooperation von Systemadministratoren und Entwicklern werden in Ansible-Playbooks gebündelt. Ein Playbook beinhaltet alle Befehle und Parameter, um ein neues System, Release oder einen Service online stellen zu können. Mittlerweile existiert eine ganze Bibliothek von Playbooks, auf deren Basis die Bereitstellung von Services – wie zum Beispiel Webserver, Application Server oder Datenbankserver – vollständig automatisiert erfolgen kann.

In welchen Bereichen macht es Sinn

Trotz der vielen Vorteile darf DevOps nicht als Allheilmittel gesehen werden. Wie bei allen IT-Projekten sollte bei Devops am Anfang die Analyse stehen: In welchen Umgebungen ergibt DevOps grundsätzlich Sinn, in welchen nicht? Für eine extrem sicherheitskritische Transaktionssoftware eignet sich DevOps eher weniger, für mobile Apps hingegen passt es hervorragend. Naturgemäß funktioniert DevOps am besten bei allem, was irgendwie auf einer Private oder Public Cloud laufen kann. Bei all dem darf natürlich das Thema Return on Investment nicht komplett aus den Augen verloren werden. Die Projekte von Adacor zeigen, dass der ROI bei innovativen Anwendungen wesentlich größer ausfällt als bei existierenden Anwendungen.

Die Zukunft gehört DevOps

Im Vergleich zu vielen anderen Ländern waren die deutschen Banken in der Vergangenheit eher träge, was die durchgehende Digitalisierung ihrer Prozesse und die Einführung smarter Kundentools anging. Das lag jedoch nicht an mangelnder Innovationsfreude, sondern vor allem an der extrem strengen Regulierung. Aber die Situation hat sich gewandelt – Gründe dafür sind der gestiegene Wettbewerbsdruck und die Möglichkeiten, die Cloud Computing und der DevOps-Ansatz bieten. Mittlerweile gibt es sehr gute Möglichkeiten, neue Anwendungen für den Bankensektor zu entwickeln und mit Internetfirmen auf Augenhöhe zu konkurrieren. Und immer mehr Banken nutzen dafür DevOps, vor allem im Investment Banking und bei Onlineservices.