Skalierbare Software-Architekturen

Wird Software in einem agilen Team entwickelt, so müssen Prinzipien und Praktiken befolgt werden, um langfristig mit konstanten Kosten entwickeln zu können. Prinzipien wie SOLID und DRY (Don't Repeat Yourself) sorgen dafür, dass der Code flexibel und erweiterbar bleibt und somit die Kostenkurve für zukünftige Features nicht steigt. Wird das agile Vorgehen auf ein Multi-Team-Umfeld ausgeweitet, so kommt ein weiterer wichtiger Faktor ins Spiel: die Kosten der Kommunikation zwischen den Teams.

Monolithische Systeme

Arbeiten alle Teams an einer gemeinsamen Codebasis mit gemeinsamer Datenhaltung, so steigen die Abstimmungskosten. (mögliche Kommunikationsbeziehungen bei n Teams = n(n-1)/2 )

Ein gemeinsam gepflegtes monolithisches System verursacht Kosten in verschiedenen Bereichen: 

  • Diskussionen und Abstimmungen über gemeinsam genutzten Code. Wer darf wann was ändern?
  • Upstream-/Downstream-Abhängigkeiten von Code verschiedener Teams. Wann kann was released werden?
  • Durch Übergeneralisierung von Schnittstellen für die Verwendung in mehreren Teams können Schnittstellen zu umfangreich werden, um allen möglichen Verwendungsformen gerecht zu werden. Darunter kann dann die Lesbarkeit leiden und es entstehen Kosten durch schwerere Nutzbarkeit.
  • Gemeinsame Nutzung von Datenbanken erschwert die Veränderung der bestehenden Schemata.

Neue Architekturparadigmen

Viele Unternehmen haben festgestellt, dass dieser monolithische Ansatz in einem agilen Umfeld nicht funktioniert und Features nicht mehr schnell entwickelt und ausgerollt werden konnten. Neue Architekturparadigmen wurden entwickelt:

  • Amazon wurde ursprünglich als monolithisches System mit zentraler Datenhaltung implementiert. 2001 wurde deutlich, dass mit dem bisherigen Ansatz das System nicht weiter skalieren konnte. Bei Amazon wurden daraufhin Micro-Services mit jeweils eigener Datenhaltung als Architekturprinzip definiert. Jeder Aufruf von "amazon.de" involviert intern mehr als 100 Services der verschiedenen Teams. (https://queue.acm.org/detail.cfm?id=1142065)
  • Das System bei NetFlix war ein großer Monolith mit riesiger Datenbank. Auch hier hat man das System in 450 Micro-Services zerlegt, die jeweils eigene Datenhaltung betreiben.
  • Bei Spotify gilt als Schlüsselprinzip, dass Teams als "Autonomous squads" agieren und das No-Shared-Data-Prinzip verfolgen
  • Twitter setzt auf hohe Entkopplung und asynchronen Datenaustausch über REST-APIs

Micro-Services-Architektur

Die Lösungen, die in den verschiedenen Kontexten entwickelt wurden, ergeben ein wiederkehrendes Schema einer Micro-Services-Architektur:

  • Definition einer simplen Grundarchitektur, in die die konkreten Features verschiedener Teams unabhängig voneinander eingebettet werden können.
  • Teams werden nicht nach Schichten geschnitten, sondern nach Features. Sie entwickeln voneinander unabhängig komplette Features, die von der UI bis zur Datenhaltung alles beinhalten. Die Features der Teams teilen sich keinen Code und haben keine gemeinsame Datenhaltung (Shared-Nothing-Leitbild).
  • Die Features werden als getrennt deploybare Einheiten in die Grundarchitektur eingebettet. Die Kommunikation geschieht über ein gemeinsames Protokoll (z.B. über HTTP in einer REST-Architektur).

Hierbei kann es durchaus vorkommen, dass Daten redundant in verschiedenen Features gehalten werden oder ähnliche Hilfsklassen in verschiedenen Teams entstehen. Diese Redundanz wird aber bewusst in Kauf genommen, weil die Vorteile der Kommunikationsreduktion überwiegen.

Wir selbst haben bei der Mitentwicklung des otto.de-Shops, der nach oben beschriebenen Prinzipien erstellt wurde, die Vorzüge des Micro-Service-Architektur-Stils schätzen gelernt. (http://dev.otto.de/2013/04/14/architekturprinzipien-2/)

Einen ausführlichen Artikel zum Thema skalierbare Architekturen und über das Spannungsfeld von Kommunikationskosten zu Redundanz finden Sie in der agile review 01/14. Die agile review können Sie über unseren Shop bestellen.