Wenn ein Ingenieur von Google, Amazon, Netflix oder sogar Spotify bei Thought Machine anfangen würde, würde er sich sofort wie zu Hause fühlen. Wir verwenden dieselben Tools. Unsere Prinzipien der Softwarearchitektur sind in all diesen Unternehmen identisch.
Eines der wichtigsten Dinge, die wir gemeinsam haben, ist unser Bekenntnis zu Microservices. Sie sind der Schlüssel zur Erstellung belastbarer, leistungsfähiger und skalierbarer Anwendungen, die sich leicht aktualisieren lassen. Ehrlich gesagt könnte Google Gmail nicht betreiben und Netflix würde ohne Microservices gar nicht funktionieren. Sie sind grundlegend.
Banken sind mit Microservices weniger vertraut. Und das ist noch höflich ausgedrückt. Banken hinken bei der Softwareentwicklung Jahrzehnte hinterher. Microservices sind etwas, das Banker kennenlernen müssen – und zwar schnell.
Hier ist also ein kurzer Meisterkurs darüber, was Microservices sind und warum sie das Bankwesen revolutionieren.
Traditionell werden Bankanwendungen als eine einzige Einheit gebaut – als Monolith. Der gesamte Code ist zusammengefasst – in riesigen, ausufernden Codebasen, die so einschüchternd sind, dass sich Ingenieure in ihrem Labyrinth verlieren.
Microservices sind die Alternative. Anstatt eines Monolithen werden Anwendungen in kleine, autonome Einheiten unterteilt, die sogenannten Microservices. Jeder Microservice läuft unabhängig und kann von einem dedizierten Team verwaltet werden. Die Microservices kommunizieren untereinander über APIs.
Was man erhält, ist ein Netzwerk aus kleinen, autarken Einheiten, die zusammenarbeiten, um eine einzige Anwendung zu bilden.
Das Schöne daran ist die Größe. Jeder Microservice wird kompakt und klar definiert gehalten. Im Silicon Valley gibt es die Vorstellung, dass ein Team, das an einem Microservice arbeitet, klein genug sein sollte, um von zwei Pizzen satt zu werden. Die berühmte „Two-Pizza-Regel“. Das sind sieben bis zehn Personen, je nachdem, wie hungrig sie sind. Ob wahr oder nicht – sie verdeutlicht die Überzeugung, dass ein Microservice eng genug gefasst sein sollte, damit ein kleines Team ihn verwalten kann.
Zum Beispiel besteht in Vault Core der Kern aus etwa 20 Microservices. Für jeden gibt es ein kleines Team, das ihn in- und auswendig kennt.
Und es gibt noch mehr
Aber es geht um mehr als nur die Größe. Aus technischer Sicht gibt es eine lange Liste fantastischer Gründe für den Einsatz von Microservices.
1) Microservices sind robust. Wenn ein einzelner Microservice eine Fehlfunktion aufweist, ist er der einzige Ausfall. Andere Microservices sind davon nicht betroffen. Vergleichen Sie dies mit einem Monolithen, bei dem ein Fehler das gesamte System zum Absturz bringen kann – diese Fähigkeit, Schäden zu isolieren und zu begrenzen, ist ein enormer Vorteil.
2) Microservices sind übersichtlicher. Aus Planungssicht ist es einfacher, eine Anwendung zu strukturieren, wenn man es mit klar abgegrenzten Teilen zu tun hat.
3) Das Problem der Skalierung wird durch Microservices gelöst. Eine Bank muss für Spitzenlasten gerüstet sein. Das kann der Moment sein, in dem am letzten Freitag des Monats die Gehaltsabrechnungen verarbeitet werden, oder der Black Friday, an dem Kunden wie verrückt einkaufen. Das bedeutet, dass Mainframes für Spitzenlasten ausgelegt sein müssen, die vielleicht nur eine Minute im Monat auftreten. Die restliche Zeit laufen die Server im Leerlauf. Zudem benötigt die Bank Disaster-Recovery-Systeme in der gleichen Größenordnung. Das ist katastrophal teuer.
Microservices skalieren individuell. Sie liegen in der Cloud und wachsen oder schrumpfen je nach Bedarf. Das eliminiert verschwendete Infrastruktur. Und massive Lastspitzen können problemlos bewältigt werden.
4) Das Aktualisieren von Microservices ist einfacher. Von allen Vorteilen ist dies der wichtigste. Im Vergleich zu monolithischen Architekturen ist der Unterschied gewaltig.
Hier ist der Grund: Ein Microservice kann aktualisiert werden, sobald das zuständige Team bereit ist. Es muss nicht gewartet werden, bis sich andere Microservices koordinieren. Jedes Team kann in seinem eigenen Tempo arbeiten (es sei denn, es gibt eine Änderung an der API, die andere Microservices betrifft, aber selbst dann ist der Einfluss auf eine kurze Liste relevanter Microservices begrenzt).
Dieser Ansatz ist weitaus besser. Teams können ihre Microservices nun in kleinen, schrittweisen Updates verbessern. Fehlerbehebungen gehen schneller: Sie lassen sich rasch identifizieren – das Team weiß, welche Änderung sie ausgelöst hat, und die Suchparameter beschränken sich auf den jeweiligen Microservice. Innovation wird beschleunigt. Und die Teams sind zufriedener, da sie ihr eigenes Schicksal bestimmen.
Monolithen sind bei Updates ein Albtraum. Änderungen werden alle sechs Monate in einem einzigen „Big Bang“-Upgrade ausgerollt. Fehler sind mühsam zu lokalisieren – Entwickler müssen sich durch Hunderte oder Tausende gleichzeitiger Code-Änderungen wühlen, um den Bug zu finden. Infolgedessen werden Entwickler bei Monolithen abgeneigt gegenüber Upgrades. Die Zeit vergeht, und der Monolith veraltet immer mehr. Das nächste „Big Bang“-Update muss einen immer größeren Rückstau an Upgrades enthalten, was den Sprung immer gefährlicher macht. Es ist ein Teufelskreis, der Bank-Entwicklern nur allzu bekannt ist.
Der Wechsel zu Microservices beendet diesen Kreislauf. Es ist möglich, die Anwendung kontinuierlich und reibungslos asymmetrisch zu aktualisieren, wobei jeder Microservice in seinem eigenen Tempo voranschreitet.
5) Microservices können ohne Ausfallzeiten aktualisiert werden. Ein Green/Blue-Deployment bedeutet, dass die aktualisierte Version parallel zur alten Version veröffentlicht und der Datenverkehr umgeleitet wird. Der Kundenservice bleibt unterbrechungsfrei. Sollte die Änderung aus irgendeinem Grund nicht erfolgreich sein, kann die alte Version wieder hochgefahren und der Datenverkehr zurückgeleitet werden, wodurch die Änderungen rückgängig gemacht werden. Keine Ausfallzeit.
Im Gegensatz dazu müssen Monolithen offline genommen werden – daher die gefürchtete Benachrichtigung von Banken: „Unser Service ist wegen Wartungsarbeiten vorübergehend nicht verfügbar“.
Microservices bei Thought Machine
Hier ist eine Frage, die uns oft gestellt wird.
„Wenn Microservices so großartig sind, warum sind sie im Bankwesen dann nicht weiter verbreitet?“
Dafür gibt es zwei Antworten. Die erste ist die archaische Natur von Bankensoftware. Viele Banken stecken in jahrzehntealten Systemen fest, die auf veralteten Prinzipien basieren. Diese alten Systeme zu aktualisieren ist nahezu unmöglich. Es fehlen nicht nur Microservices – es fehlt das letzte Jahrzehnt an technologischer Entwicklung.
Die zweite Antwort ist, dass der Betrieb von Microservices im Bankwesen schwierigist. Race Conditions bedeuten, dass nur präzise entwickelte Lösungen funktionieren. Stellen Sie sich ein Konto mit zwei Inhabern vor, bei dem beide gleichzeitig eine Auszahlung vornehmen. Ein Monolith bewältigt dies recht gut: Die einzelne Architektur in einem On-Premise-Rechenzentrum ermöglicht Reaktionszeiten von 1 Millisekunde. Konflikte sind daher seltener und leichter zu lösen. Microservices hingegen sind anfälliger für Race-Condition-Konflikte. Sie befinden sich in verschiedenen Cloud-Zentren: Berücksichtigt man die Lichtgeschwindigkeit als natürliche Grenze sowie den Widerstand in Glasfaserkabeln und andere Faktoren, können die Reaktionszeiten zwischen 200 Millisekunden und einer Sekunde liegen.
Deshalb sind Microservices im Core-Banking selten. Legacy-Anbieter konnten dieses Problem nicht lösen.
Heute sind Race Conditions lösbar. Aber diese Technologie wird derzeit nur von wenigen Organisationen beherrscht. Thought Machine ist weltweit führend im Core-Banking, weil wir uns voll und ganz der Ingenieurskunst verschrieben haben. Unsere Core-Banking-Engine, Vault Core, eliminiert Race-Condition-Konflikte auf eine Weise, die jedem anderen auf Microservices basierenden Bankensystem überlegen ist.
Deshalb setzen unter anderem Lloyds Bank, SEB, Atom bank und Standard Chartered auf Vault Core.
Ein weiterer wichtiger Punkt ist die Regulierung. Bei Thought Machine aktualisieren wir unsere Microservices nach einem monatlichen Zeitplan. Theoretisch könnten unsere Teams zwar jeden Microservice jederzeit aktualisieren, wie es bei Amazon oder Spotify der Fall ist, doch durch unsere enge Zusammenarbeit mit Banken und Regulierungsbehörden haben wir uns für einen vorhersehbaren Zeitplan entschieden, um die vollständige Einhaltung aller Vorschriften und Anforderungen zu gewährleisten.
Auch hier ermöglicht uns unser fundiertes Wissen in Technologie und Bankwesen eine Arbeitsweise, die unsere Wettbewerber schlichtweg nicht bieten können.
Die Vorteile für eine Bank
Tatsächlich bleibt die elegante Microservice-Architektur von Vault Core für unsere Kunden im Hintergrund. Vault Core besteht zwar aus Microservices, aber die Banken verbinden sich über eine öffentliche API, und genau diese Schnittstelle ist alles, was sie sehen.
Wir sprechen von „ganzheitlicher Konsistenz“. Banken erhalten eine konsistente API. Die Änderungen unter der Haube haben keine Auswirkungen auf die von den Banken genutzte Schnittstelle. Man könnte also argumentieren, dass Banker die Microservices getrost vergessen können.
Dennoch müssen Banken Microservices verstehen – sowohl um ihre eigenen internen Systeme zu konzipieren als auch um die Stärken von Vault Core nachvollziehen zu können.
Die Einführung von Vault Core bedeutet grenzenlose Skalierbarkeit. Die Nachfrage kann schwanken, und Vault Core skaliert reibungslos mit und passt sich den Gegebenheiten an.
Mit Vault Core bauen Banken auf dem denkbar stärksten Fundament. Die Robustheit unserer Microservice-Architektur erlaubt es uns, Updates sicher durchzuführen, Fehler zu eliminieren und Verbesserungen ohne Ausfallzeiten zu implementieren. Das reduziert das Risiko um ein Vielfaches – und das bei deutlich geringeren Kosten.
Das sind phänomenale Vorteile.
Google, Apple, Netflix und Spotify basieren auf Microservices. Dank Thought Machine ist es nun an der Zeit, dass auch das Bankwesen davon profitiert.
