Vom Monolithen wegkommen

Was ist eine skalierbare Software-Architektur?

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.

Die Kosten von monolithischen Systemen

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 welche 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.

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben