Self-contained System (SCS) — Architektur-Trend

Ein neuer Hype zieht seit einigen Monaten durch die Software-Architektur-Welt: Die Self-contained Systems; abgekürzt SCS. Wie so oft in der IT handelt es sich hierbei um teils bekannte Konzepte mit neuem Namen.

Alter Wein in neuen Schläuchen

Das Ziel von SC-Systemen ist eine saubere Modularisierung von Softwarekomponenten. Es sollen möglichst unabhängige und kleine Softwareeinheiten erschaffen werden. Ein SCS beinhaltet per Definition den Fullstack. Das heißt, Datenbank, Logik und (Web-)Frontend müssen Bestandteil eines solchen Systems sein. Jedes “geschlossene System” soll weitgehend autonom und unabhängig entwickelt werden können, um maximale Freiheit, Beschleunigung und Agilität in der Softwareentwicklung zu erreichen. In diesem Sinne ist die Zielsetzung der Self-Contained Systems absolut vergleichbar mit den Zielen der Microservice-Architekturen:

• Jedes SCS ist eigenständig und somit unabhängig von anderen Systemen deploybar
• Ein SCS soll eine möglichst kleine Einheit sein, die speziell für eine Aufgabe bzw. einen Anwendungsfall konzipiert ist.
• Programmiersprache und Frameworks können für jedes SCS autonom ausgewählt werden. (Keine technische Notwendigkeit sich auf bestimmte Techniken festzulegen; ggf. aber Organisatorische)
• Die Kommunikation zu anderen System erfolgt über eine Netzwerkschnittstelle (i.d.R. HTTP). Ein SCS ist somit extrem lose mit anderen Systemen gekoppelt (und weißt eine starke interne Kohäsion auf)
• Entwickler-Teams können entsprechend der SC-Systeme organisiert werden. Es erzeugt klare Verantwortlichkeiten und ermöglicht selbstbestimmtes Arbeiten (Gesetz von Conway)
• Die vielen Vorteile durch die erhöhte Unabhängigkeit zwischen den Systemen, geht mit dem Nachteil einher, eine größere Komplexität in der systemübergreifenden Interaktion zu bewerkstelligen (Versionierungskonflikte, Discovery-Services, Redundanzen, Resilient Software Design usw.)

Unterschiede Self-contained Systems zu Microservices

Was unterscheidet nun ein SCS von einem Microservice (MS)? Primär fällt auf, dass ein SCS wesentlich konkreter definiert ist als ein MS. Was ein Microservice beinhalten darf und was nicht, ist offen gelassen und wird in jedem Umfeld neu definiert. So finden sich in einigen Firmen sehr feingranulare Microservices, bei welchen jede kleine Teilfunktion extra gekapselt wird. Anforderungen wie “Ein Mikroservice darf nicht mehr als 30 Klassen und 5.000 Zeilen-Code erhalten” wären in so einem Umfeld üblich. Andere Firmen haben diese Einschränkungen nicht, sondern schneiden ihre Mircoservices horizontal. Das heißt, es werden eigenständige Microservices für Datenbankzugriffe, Logik/Services und Oberflächenfunktionen gebaut. Die Dritte Variante ist das vertikale Schneiden. Diese Services beinhalten eine komplett autarke (Mini-)Anwendung inkl. Datenhaltung, Logik und Oberfläche.

“Vertikal” ist das richtige Stichwort um ein Self-contained System einzuordnen. Ein SCS ist per Definition vertikal geschnitten und somit ein eigenständige Applikation über alle Layer.

Ein SCS ist ein Microservice der vertikal geschnitten ist.

Weitere Abgrenzungen eines Self-contained Systems (SCS) zu Microservices (MS):

• MS kommuniziert i.d.R. mit vielen Systemen. Ein SCS hat möglichst wenig Schnittstellen
• Die Schnittstellen eines MS werden i.d.R. über REST(http/JSON) realisiert. Die Integration von fremden Services sollte im SCS über die Oberfläche erfolgen (z.B. Links, Iframes, Includes, Ajax usw.)
• Ein SCS beinhaltet immer (Web)-Gui, Logik sowie Datenhaltung und ist somit eine eigenständig nutzbare Applikation
• Um eine einheitliche GUI und Usability über mehrere SCS zu realisieren, werden oft “shared Assets” verwendet. Gemeinsame Nutzung von CSS, Bildern, HTML-Snipptes und JavaScript-Code

Und SOA?

Wer erinnert sich noch an die Serviceorientierte Architektur (SOA)? 1996 durch das Marktforschungsunternehmen Gartner “erfunden” und in den ersten 10 Jahren dieses Jahrtausends stark in Mode. Die Definition von einer SOA ist recht abstrakt und laut Wikipedia wie folgt:

SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.

Betrachtet man nun SOA, Microservices und SCS, so ist festzustellen, dass die Architekturen quasi aufeinander aufbauen und jede Ausbaustufe in ihrer Definition ein Stück konkreter wurde:

SCS als Mainstream oder Schicksal der Portlets?

Wird die SCS-Architektur sich durchsetzen können und eine ähnlich hohe Akzeptanz erfahren, wie es mit Microservices der Fall war? Es gibt bereits große Vorzeigeprojekte die teilweise (Otto-Group) und auch fast vollständig (Galeria Kaufhof) die SCS- Richtlinien implementieren.

Ich persönlich glaube jedoch, dass der SCS-Ansatz kein Mainstream wird. Der promotete Ansatz, Mini-Awendungen zu bauen, die sich untereinander mittels GUI-Integration verbinden, ist nicht trivial. Die Anforderungen an das User-Interface sind heute extrem hoch: Einheitliches Design und Nutzerführung, schnelle Antwortzeiten und Responsive Webdesign. Der Trend geht Richtung Single-Page-Applications (SPA), die einen großen Teil der Logik clientseitig implementieren. Unter diesen Rahmenbedingungen ist es schwer vorstellbar, dass eine komplexe Webanwendung, die sich über frontend-integrierte Self-contained Systems zusammensetzt, die Anforderungen zufriedenstellend erfüllt. Eine Anwendungsarchitektur, die ein zentral implementiertes Frontend vorsieht, wird stets im Vorteil sein.

Viele andere Ansätze, wie iFrames und auch Portlets konnten sich nie im großen Stil durchsetzen, da sie in Sachen einheitliches Design und Usability stets benachteiligt waren. Mit den gleichen Problemen kämpft die SCS-Architektur.

In bestimmten Bereichen, z.B. für Enterprise-Anwendungen mit reduzierten Anforderungen an ein einheitliches Frontend, ist der SCS-Ansatz aus meiner Sicht sehr charmant. Hier spielt die Architektur ihre Vorteile aus und sorgt für eine robuste und wartbare Softwarelandschaft.

Weitere Informationen zu SCS finden sich auf der Website der geschätzten Kollegen der Firma innoQ: http://scs-architecture.org/