Microservices@Netfonds

Als wir uns 2017 dafür entschieden haben eine eigene Software Plattform aufzubauen – damals noch mit dem Projektnamen „Fundsware 2.0“ – war uns sehr schnell klar, dass dieses Projekt für die Netfonds AG das Fundament für die Zukunft legt.  

Neben der Zukunftsfähigkeit und der Skalierbarkeit spielte für die Technologie und Architekturentscheidung vor allem Sicherheit und Einfachheit eine herausragende Rolle. Ein (kleiner) Monolith lässt sich vielleicht von einem eingespielten Team aus 3-5 Personen gut entwickeln und warten, aber spätestens, wenn man mit mehreren verteilten Teams und über Ländergrenzen hinweg an einem System arbeitet wird die Koordination extrem herausfordernd. Und jeder Entwickler kennt den Auto Vergleich: „Ich habe den rechten Außenspiegel angeschraubt und plötzlich ist der Stoßdämpfer hinten links in Flammen aufgegangen“.

Unsere Microservice Regeln

All unsere Anforderungen erfüllen unsere Microservice Regeln die wir im Laufe der Zeit immer wieder den aktuellen Gegebenheiten anpassen.

• Wir konzentrieren uns aus unsere Kernkompetenz, die Erstellung guter Produkte und überlassen den Betrieb von Hardware und Infrastruktur den Anbietern deren Kernkompetenz dies ist.  Der Fokus liegt bei der Netfonds IT ganz klar darin die eigene Software weiterzuentwickeln. Wir sind kein Cloud Anbieter – unsere Kernkompetenz ist es nicht Datenbanken oder Kubernetes Umgebungen zu betreiben. Aus diesem Grund kaufen wir diese Dinge bei einem Hyperscaler ein.
• Wir wollen jederzeit im Sprint in der Lage sein unsere Plattform oder Teile unserer Plattform auf den aktuellen Entwicklungsstand zu bringen. Zu diesem Zweck setzen wir eine CI/CD Pipeline ein, die basierend auf dem Commit in den korrekten Branch einen Buildprozess anstößt, der ein fertiges Dockerimage erzeugt, welches voll automatisch in der Kubernetes Umgebung unseres Cloud Anbieters gestartet wird (selbstverständlich nicht in Produktion).
• Unsere Microservices sind stateless. Dadurch, dass wir unsere Microservices stateless gestalten sind wir in der Lage jederzeit zu skalieren und mehr Ressourcen einzusetzen, falls diese benötigt werden.
• Wir reduzieren Abhängigkeiten zwischen einzelnen Services um die Komplexität zu reduzieren. Entsprechend unserer Strategie betrachten wir Microservices auch nur als solche, wenn die Schnitte, die die Services voneinander trennen, bis auf Datenbank Ebene gehen.
• Wir wollen, dass die Services so unabhängig wie möglich voneinander sind und nehmen dafür gerne in Kauf, dass jeder Service eine eigene Datenbank verwendet. Und weil es auch bei der Wahl der Datenbanken sehr auf den jeweiligen Einsatzzweck, den Datendurchsatz und das Volumen ankommt entscheidet jedes Scrum Team selbst, ob es MySQL, MongoDB oder Cassandra einsetzt oder eine Technologie benötigt, die aktuell noch nicht im Einsatz ist. Die Datenbank ist in unserer Strategie auch soetwas wie der heilige Gral des jeweiligen Services. Nicht einmal unser internes Datenmanagement erhält Zugriff auf die Datenbank – nur der Service selbst darf lesen und Schreiben.
• Wir speichern Daten lieber mehrmals, anstatt auf einer Normalisierung zu beharren. Joins über Servicegrenzen hinweg sind bewusst teuer – lieber speichern wir die Daten redundant und aktualisieren diese synchron und asynchron.
• Wir vermeiden zirkuläre Abhängigkeiten und nutzen bedarfsgemäß Synchrone und Asynchrone Kommunikation. Unserer Strategie nach kann das jeweilige Team am besten Entscheiden, ob es gewisse Informationen von anderen Services adhoc oder asynchron benötigt. Deswegen ermöglichen wir einzelnen Services direkten Rest Zugriff auf andere Services, während andere über CRUD Operationen asynchron informiert werden.
• Wir beachten Faktoren der referentiellen Integrität bereits im „Definition of Ready“ Stadium einer Story.

Auf Grund dieser Regeln war ein IT Wachstum und eine Skalierung, wie sie in den letzen 5 Jahren stattgefunden hat erst möglich und diese Regeln bilden das Fundament unserer zukunftsfähigen IT Architektur.

Bild: Canva