Self-contained Systems – ein Architekturstil stellt sich vor

Um gerade die Entwicklung großer Systeme besser zu unterstützen, ist eine Aufteilung in mehrere Deployment-Einheiten sinnvoll. Self-contained Systems (SCSs) verfolgen genau dieses Ansatz.

In Pocket speichern vorlesen Druckansicht 8 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Eberhard Wolff

Um gerade die Entwicklung großer Systeme besser zu unterstützen, ist eine Aufteilung in mehrere Deployment-Einheiten sinnvoll. Self-contained Systems (SCSs) verfolgen genau dieses Ansatz.

Alle wesentliche Informationen zu SCSs finden sich auf der neuen Website http://scs-architecture.org/. Hier ein Überblick über die Eigenschaften:

  • Jedes SCS ist eine autonome Web-Anwendung. Die gesamten Daten, Logik und der Code für die Darstellung der Web-Oberfläche sind in dem SCS enthalten. So kann ein SCS seine Funktionalitäten erbringen, ohne auf andere SCSs angewiesen zu sein.
  • Für ein SCS ist immer genau ein Team verantwortlich. Ein Team kann jedoch durchaus mehrere SCSs betreuen. Andere Teams können nur Änderungen an einem SCS vorschlagen und vorbereiten, beispielsweise durch Pull Requests. Ob diese allerdings angenommen werden entscheidet das Team, dem das SCS "gehört".
  • Die Kommunikation mit anderen SCSs soll nach Möglichkeit zeitlich entkoppelt sein. Das gilt insbesondere für die Kommunikation, während ein SCS selbst einen Request bearbeitet. Idealerweise funktioniert ein SCS selbst dann noch, wenn die aufgerufenen SCSs zeitweise ausfallen. Beispielsweise können asynchrone Kommunikationsmechanismen genutzt werden, Werte zwischengespeichert werden oder Vorgabewerte genutzt werden.
  • Ein SCS kann eine API haben. Dies ist aber nicht unbedingt notwendig, da das SCS bereits eine Web-Oberfläche für die Benutzer hat. Für mobile Clients oder andere SCSs kann der Zugriff über eine API aber nützlich sein.
  • SCSs dürfen sich keine UI teilen. Schließlich soll ein SCS seine Features über seine eigene UI nutzbar machen.
  • Um eine enge Kopplung zu vermeiden, sollten SCSs sich keinen fachlichen Code teilen. Nur gemeinsamer technischer Code ist erlaubt. Als grobe Regel gilt: Nur Code, den man als Open Source veröffentlichen würde, darf zwischen zwei SCS geteilt werden.

SCSs sind also eine Alternative zu Monolithen. Sie stellen lokale Entscheidungen in den Mittelpunkt: Praktisch alle Technologie-Entscheidungen und die meisten Architektur-Entscheidungen betreffen nur ein SCS. Das verspricht, große und komplexe Projekte umsetzten zu können. Ein großes Projekt wird als SCS auf der Software-Ebene zu vielen kleinen und unabhängigen Modulen, an denen jeweils ein Team arbeitet.

SCSs haben auch Vorteile bezüglich der Verfügbarkeit: Wenn ein SCS ausfällt, funktionieren die anderen SCSs nach wie vor weiter. Ebenso können sie unabhängig voneinander skaliert werden. Hohe Last auf einem SCS kann das SCS alleine bearbeiten. Schließlich sind SCS leichter ersetzbar und es ist einfacher, neue Technologien in einem SCS auszuprobieren.

Die SCS-Idee hat sich in einigen Projekten schon bewährt. Diese Links geben einen Eindruck von der Nutzung und es gibt auch eine Abgrenzung gegen Microservices. Das gesamte Material über SCS steht unter einer Creative Commons Attribution-Sharealike Lizenz und den Code der Website gibt es bei Github. Man kann also selber Hand anlegen und Pull Requests einreichen. Auch Diskussionen sind erwünscht.

Danke an meine Kollegen Marc Jansing, Philipp Schirmacher, Silvia Schreier und Michael Vitz für die Kommentare zu einer früheren Version des Posts. ()