Was ist eine Race Condition?

Wir hatten in einem Projekt den Fall, dass mehrere Systeme Kundendaten in eine MQ geschrieben haben. Diese Kundendaten mussten am Zielsystem natürlich so schnell wie möglich verarbeitet werden. Jetzt gab es den Spezialfall, dass, wenn ein Kunde namens Altair im Zielsystem noch nicht existierte, dieser erstellt werden sollte.

Das System Kuchen schickte also seinen Kunden Altair in das Zielsystem. Dieses stellte fest, dass es den Namen noch nicht gab, und erstellte einen Kundeneintrag für diesen. Traditionsgemäss brauchte dieses Eröffnen eines Kundenkontos dabei einige Zeit, das im Hintergrund viele Dinge beachtet werden mussten.

Was passierte nun aber, wenn das System Müesli ebenfalls den Kunden Altair auf den Weg schickte, zeitgleich wie das System Kuchen? Dann entsteht eine sogenannte Race Condition, ein Zeitrennen dieser beiden Aufträge.

Warum ist das ein Problem?

Nun, wenn die beiden Aufträge den exakt gleichen Kunden erstellen würde, wäre das nicht so schlimm. Was ist jetzt aber, wenn eine ihre Daten aus unterschiedlichen Orten (etwa verschiedene Benutzeroberflächen) holen? Dann gibt es vielleicht, je nachdem welches System gewinnt, einen männlichen oder einen weiblichen Altair.

Oder ein falscher Kontostand? Nicht gut…

Noch schlimmer wäre es, wenn bei der gleichzeitigen Verarbeitung dieser Kundeneröffnungen ein Betrag zuerst abgefragt werden müsste, bevor man ihn wieder in die Datenbank schreiben würde.

Wenn etwa das System Kuchen zuerst den existierenden Kunden Ezio aus der Datenbank liest, dessen Kontostand abfragt und diesen dann um 20 Franken erhöht. Aus ursprünglich 50 Franken wird so ein Betrag von 70 Franken, welcher wieder in die Datenbank geschrieben wird.

Liest jetzt aber das System Müesli zur exakt gleichen Zeit die Daten, erhöht diese um 30 Franken auf 80 Franken, und schreibt diese in die Datenbank, nachdem System Kuchen seinen Arbeit gemacht hat, steht am Ende ein Betrag von 80 Franken – statt der Summe von 50 + 20 + 30 = 100 Franken.

Sehr gefährlich!

Okay und was macht man dagegen?

In der Programmierung gibt es viele Mechanismen, die sich diesem Problem annehmen. Wer sich dafür interessiert, wird früher oder später über die Begriffe Threadsafe, Concurrency oder Synchronize stolpern.

Das ist aber wieder eine ganz andere Geschichte…

Was ist DevOps?

DevOps ist ein Konzept, welches aus zwei Trends heraus entstanden ist: Zum einen gibt es den Trend namens Agile Systemadministration oder Agile Operations, welche das Ziel verfolgen, agile Konzepte auch den IT Betrieb zu bringen. Zum anderen steht dahinter die Idee, einen Nutzen daraus zu gewinnen, dass die Entwicklung und der Betrieb möglichst eng miteinander arbeiten, sei das entweder beim Erstellen oder beim betreiben einer Dienstleistung. Diese Zusammenarbeit soll über den gesamten Applikaitonslebenszyklus – oder moderner Servicelebenszyklus stattfinden, vom Design zur Entwicklung und Wartung einer Applikation.

Dev meint dabei nicht nur den bekannten Entwickler, sondern jede Person, die irgendwie an der Entwicklung einer Appliation beteiligt ist. Ops steht für alle möglichen Jobs im Betrieb: Systemadministrator, Datenbankadministratoren, Netzwerktechniker, Sicherheitsspezialisten etc.

Schlussendlich ist DevOps aber mehr als Entwicklung und Betrieb, mehr als die Tools und Prozesse, die dahinterstehen. Es steht für eine Philosophie, eine Einstellung, Dinge anders zu machen als in der Vergangenheit. Es ist das Schaffen einer Kultur, in der die Entwickler mit dem Betrieb zusammenarbeiten, immer mit dem Ziel, eine möglichst gute Software abzuliefern und am Laufen zu halten. Und alle Beteiligten arbeitet zusammen, um dieses Ziel zu erreichen.

Das Umdenken in der agilen Revolution

Bevor Agile unsere Welt kam schienen die Rollen klar verteilt: Die Devs waren die Macher, die Ersteller der Software, während die Ops die Personen waren, die sich um die Applikation in der Wartung gekümmert haben. Die Industrie hat aber festgestellt, dass diese zwei Rollen durchaus Synergieeffekte für sich nutzen können, wenn sie zusammenarbeiten.

Dieser Gedankenanstoss kam auch aus der agilen Ecke: Dort wird bis heute die Zusammenarbeit als eines der höchsten Werte gepriesen. Und das nicht nur zwischen diesen beiden, sondern zwischen allen Rollen. Gemeinsam soll in kurzen Iterationen das Produkt beziehungsweise das Inkrement stetig verbessert werden. Aus agiler Sicht macht es nur Sinn, wenn man die Interaktion eines Systems mit deren Umsystemen gemeinsam betrachtet und die Applikation als Ganzes betrachtet, statt nur den Code.

 Entwickler werden sich dabei vermehrt mit dem Thema der virtuellen Maschinen beschäftigen, während die Leute im Betrieb sich mit automatisierten Tests auseinandersetzen. Das ganze läuft dann bestenfalls unter einem Schirm von gemeinsamen Messzahlen (KPI = Key Performance Indicators).

Developer und Operations-Leute werden weiterhin bestehen

Genauso wie es unrealistisch isch, dass in einem Scrum Team jede Person ein Software Architekt ist, ist es nicht möglich, dass Leute im Betrieb plötzlich die gesamte Entwicklung übernehmen oder umgekehrt. Es ist aber sehr von Vorteil, wenn die Leute im Betrieb die Entwickler verstehen und auch die Entwickler ein gewisses Skill-Set haben, um betriebliche Herausforderungen zu meistern – Nicht zuletzt, wenn es einen Stellvertreter braucht, weil eine Person im Betrieb vier Wochen in die Ferien geht.

Das Identitätsmanagement Dilemma

Was ist Identitätsmanagement und warum ist es so wichtig?

Seit ich mit der Java Entwicklung angefangen habe, war ich immer der Meinung, der schwierigste Teil der Softwareentwicklung wäre die technische Umsetzung im Code selber. Das Bauen eines GUI’s, das Implementieren eines Webservices, das Einbauen von Logik im Backend etc.

Mit der Zeit merkte ich aber, dass dies nicht der grosse Brocken war, der den Aufwand schluckte. Ein weiterer grosser Brocken waren die Diskussionen mit den Stakeholdern zu ihren Anforderungen. Aber das ist nicht der Teil, auf den ich hier eingehen will. In diesem Beitrag spreche ich vom Aufbauen einer Architektur, von technischen Diskussionen mit Architekten und der Konzeption von etwas Neuem.

Damit ich einen konkreten Fall haben, den man anschauen kann, nehme ich an, dass die Migros eine „Superidee“ hat: Wegen Kosteneinsparungen hat die Migros keine Lust mehr, die Superpunkte ihrer Kunden selber zu speichern, und will einen Kanal zu Coop aufbauen, um die Verwaltung der Superpunkte an Coop abzugeben.

Die Vorstellung von Migros ist folgende: Der Kunde loggt sich in das Migros Portal ein und klickt auf einen Knopf „Ja, ich möchte von jetzt an meine Superpunkte von Coop verwaltet haben“ und ZACK meldet Migros den Kunden bei Coop an und übergibt die ausstehenden Superpunkte.

Und wo ist jetzt das Identitätsmanagement?

Identitätsmanagement befasst sich in der Welt der Datenverarbeitung mit der Verwaltung von Benutzerdaten, die einzelnen Personen zugeordnet sind. In diesem Beispiel haben wir gleich zwei Entitäten, welche Benutzer verwalten: Migros und Coop.

Die Synchronisation dieser zwei Systeme birgt jetzt aus architektonischer Sicht einige Herausforderungen:

– Technisch: Wie kommunizieren die zwei Firmen miteinander?
– Aus Datensicht: Beide Firmen benutzen andere Datentabellen / ID’s für ihre Kunden
– Rechtlich: Darf Migros Daten seiner Kunden aus rechtlicher Sicht überhaupt an Coop weiterreichen?
– Und ganz wichtig: Wie finden Migros und Coop heraus, dass sie vom gleichen Kunden sprechen?

Problem: Wie einigt man sich auf denselben Kunden?

Wir haben zum Beispiel den Kunden King Kong. Er ist Kunde bei Migros sowie auch bei Coop. King meldet sich nun beim Migrosportal an, klickt auf den Coop-Knopf und Migros übermittelt seine Daten an Coop. Coop nimmt die Daten und sucht den richtigen King Kong in seiner Datenbank.

Hier gibt es potentiell etliche Fehlervarianten, die passieren können:

– King Kong ist vor einem Jahr gezügelt, hat den Umzug aber nur Coop gemeldet -> Kunde matcht nicht
– King Kong hat bei der Eingabe seiner Adresse bei Coop einen Tippfehler gemacht -> Kunde matcht nicht
– Coop findet gleich drei King Kong’s, die alle ähnliche Daten gespeichert haben, welcher ist der richtige?
etc.

Natürlich kann man viele Attribute des Kunden nehmen, um diese in der Datenbank zu finden. Und die Wahrscheinlichkeit, dass es mehrere King Kong’s mit Geburtsdatum 02.02.1984 gibt, ist wohl gering. Doch Benutzerdaten sind jeweils nur so gut, wie sie gepflegt werden (das erinnnert mich daran, dass ich meinen Blumen wieder mal Wasser geben sollte).

Wie löst man dieses Dilemma?

Aus sicherheitstechnischer Sicht kann man diese Herausforderung lösen, indem man den Kunden sich selbst bei Coop authentifizieren lässt. Wie wir im Artikel Was ist 2-Faktor Authentifizierung? gesehen haben, ist ein Benutzername und ein Passwort dazu da, einen Kunden zu authentifizieren. Wenn der Kunde sich also bei Migros oder bei Coop anmeldet, dann können die Firmen sicher sein, dass es sich um den gleichen Kunden handelt.

Da es sich hier aber nicht um einen einfachen Login handelt, sondern quasi um einen doppelten Login (einmal bei Migros und einmal bei Coop) könnte man folgendermassen vorgehen:

1. Der Kunde loggt sich beim Migros Portal (mit seinem Migros Login) ein
2. Der Kunde drückt den Knopf „Ja, ich möchte von jetzt an meine Superpunkte von Coop verwaltet haben“
3. Das Migros Portal öffnet ein Popup, in dem es die Portalseite von Coop öffnet, und zeigt den Login
4. Der Kunde loggt sich beim Coop Portal ein (mit seinem Coop Login)
5. Da der Kunde sich selber authentifiziert hat, weiss Coop, dass es sich um den Kunden King Kong handelt.
6. Migros und Coop müssen nun noch ihre jeweiligen ID’s des Kunden austauschen und speichern.
7. Migros kann von nun an alle anlaufenden Superpunkte an den Kunden bei Coop schicken

Das ist jetzt nur mal die architektonische Idee. Für technische Details werde ich einen weiteren Blogeintrag schreiben.

Wie Sie sicherlich festellen können, ist die Umsetzung eines solchen Projektes durchaus aufwändig. Am Ende läuft es vielleicht auf einen Webservice hin, mit dem Migros an Coop melden kann „Kunde King Kong hat im Dezember 500 Superpunkte bekommen“ – Bis dieser Prozess aber läuft, sind viele Meetings und Workshops abzuhalten, Designs zu erstellen und Securityentscheidungen zu treffen.