Software Development? Software Architecture? Moment, wenn man den Namen enableYou hört denkt man bisher an: Die Organisation kann viele coole, super-moderne cutting-edge Konzepte wie TEAL und wie man diese in Organisationen etabliert und lebt?
Super, dann ist jeder ja schon mal „on-message“. Aber wir sind noch in ganz anderen Sphären unterwegs. Ganz besonders im Feld des Software Developments und dem Consulting zur Implementation von Digitalen Produkten.
„Nanu?“, denkt man sich jetzt, dass ist ja nichts welt-bewegendes oder neues. Organisationen die solche Aufgaben erledigen gibt es wie Sand am Meer.
Das ist nichts Besonderes, mag man sich denken, doch wie viele können sagen dass sie dieses Thema mit sinnstiftender, nachhaltiger Profitabilität machen statt Lösungen zu finden die morgen uns den nächsten wiederholten Auftrag sichern.
Jetzt fragt man sich: „Wie möchtet ihr das denn erreichen?“ – Unsere Antwort ist recht einfach, hat aber Nuancen!
Wir nutzen und hebeln alle uns zu Verfügung stehenden und bekannten Mittel um eurem Ziel und Wunsch entgegen zu kommen.
Ihr möchtet ein Digitales Produkt mit uns entwickeln und benötigt Menschen die an Menschen denken, aber es gleichzeitig so nachhaltig wie möglich gestalten? – Das können wir. Unser Team vereint jahrelange Expertise im Software Development sowie auch in der Planung solcher Projekte.
enableYou ist in der Lage dazu eure IT-Infrastruktur und Architektur neues Leben einzuhauchen und durch moderne und (wo es passt) Cloud-native Architekturen zu ersetzen. Passend dazu ist es immer wichtig, dass IT-Systeme sehr oft ein Abbild der Organisationsstruktur sind, und auch nur dann transformiert wenden können, wenn die Menschen und das Framework drum herum eine zukunftsorientierte Perspektive abbilden.
Darum bieten wir auch im Tandem an dass wir eure Organisation entlang der TEAL-Prinzipien transformieren und dazu passend auch einen agilen und effizienten Entwicklungsprozess etablieren können.
Nun kommen wir aber zum Kernstück des Software Developments bei enableYou:
„Die Architektur machts.“
Die Wahl der richtigen Software Architektur ist ein entscheidender Faktor für den Erfolg von Softwareprojekten. Eine gut durchdachte Architektur legt den Grundstein für Skalierbarkeit, Wartbarkeit und Leistungsfähigkeit von Anwendungen. Hier werden wir euch einen umfassenden Überblick über verschiedene Arten von Softwarearchitekturen geben und ihre Vor- und Nachteile beleuchten. Von (traditionellen) monolithischen Architekturen bis hin zu verteilten Systemen werden wir die unserer Meinung nach wichtigsten Architekturmodelle betrachten und euch einen kleinen Rundumschlag bieten.
Im Folgenden präsentieren wir euch einige typische Architektur-Prinzipien von denen wir euch ein paar Details und Historische Fakten bzw. Einordnungen mitgeben möchten. Zum Schluss werden wir dann ein kleines enableYou-eigenes Resumee ziehen, was wir als IT-Consultants empfehlen.
Monolithic architecture
Die monolithische Architektur ist das traditionelle Modell für die Entwicklung von Anwendungen und hat schon seit Dekaden bestand.
Kurze Historie
Ursprung hat dieser Begriff in der (Bau-)Architektur. Er beschreibt Gebäude die die aus einem einzigen Stück Material, in der Vergangenheit aus Fels, geschnitzt, gegossen oder ausgegraben wurden. [1 Wikipedia]
Ebenfalls beschreibt ein „Monolith“ eine geologische Formation die aus einem singulären massiven Stein oder Fels besteht (z.B. Uluru, Northern Territory, Australia aka Ayers Rock).
Die Geschichte der monolithischen Architektur lässt sich bis in die Anfänge des Software Developments zurückverfolgen, als in den 1950er & -60er Jahren Großrechner aufkamen.
Diese frühen Computersysteme zeichneten sich durch eine zentralisierte Architektur aus, wobei ein einzelner Großrechner als Knotenpunkt für alle Rechenvorgänge diente. In den 1970er & -80er Jahren verlagerte sich der Schwerpunkt mit dem Aufkommen von PCs und dem Aufkommen von Client-Server-Modellen hin zu verteilten Systemen. Monolithische Architekturen blieben aber weiterhin bestehen.
In den Anfängen der Softwareentwicklung wurden Systeme mit einem zentralisierten Ansatz erstellt. Der gesamte Code, die Daten und die Logik waren in einer Anwendung oder einem System enthalten. Diese Systeme wurden für die Ausführung auf einem einzelnen Computer entwickelt und erforderten keine weiteren Komponenten. Und das machte damals Sinn, da Computer bei weitem nicht so leistungsfähig waren und der Entwicklungsprozess nicht so ausgefeilt war/-en wie heute. [2 Medium]
Hierbei handelt es sich um eine einzige Anwendung, bei der alle Komponenten und Funktionen in einer einzigen Codebase zusammengefasst sind (ergo das Analogon zu „aus einem Fels geschnitzt“).
Man mag sich fragen warum wir dieses Modell heute noch beleuchten, aber es hat durchaus noch seine Existenzberechtigung, in bestimmten Szenarien.
Betrachten wir doch mal seine Merkmale im Detail:
- Zentrale Struktur
In monolithischen Anwendungen sind alle Komponenten eng miteinander verknüpft und teilen sich denselben Speicher und dieselbe Datenbank.
Die Kommunikation zwischen den Komponenten erfolgt über direkte Methodenaufrufe oder das Teilen von Daten. - Einfache Entwicklung und Deployment
Da alle Komponenten in einer einzigen Anwendung zusammengefasst sind, ist die Entwicklung und das Deployment vergleichsweise einfach. Es ist keine komplexe Konfiguration oder Kommunikation zwischen verschiedenen Diensten erforderlich. - Skalierung(-sbeschränkungen)
Die Skalierbarkeit von monolithischen Anwendungen ist begrenzt, da sie als Ganzes skaliert werden müssen. Bei steigender Last müssen alle Komponenten gemeinsam skaliert werden, unabhängig davon, ob sie stark beansprucht werden oder nicht. - Wartbarkeit & Testbarkeit
Die Wartung und Tests in monolithischen Anwendungen können herausfordernd sein, da Änderungen an einer Komponente Auswirkungen auf andere Teile der Anwendung haben können. Das Debuggen von Fehlern und die Isolierung von Problemen können zeitaufwändig sein.
Die Kommunikation zwischen den Komponenten erfolgt über direkte Methodenaufrufe oder das Teilen von Daten.Layered architecture
Die „Layered architecture“ (zu Deutsch: Schichtarchitektur) ist ein weit verbreitetes Architekturmodell, das auf der Trennung von Zuständigkeiten basiert.
Hierbei werden die Funktionen einer Anwendung in separate Schichten aufgeteilt, die unabhängig voneinander agieren. Es basiert auf einem „Client–Server model“ und wird auch oft als Multi- oder n-tier architecture bezeichnet, dabei sind “tier” und “layer” hier austauschbare Begriffe. Am weitesten verbreitet ist die 3-tier architecture.
Kurze Historie
Diese Art von Architektur geht zurück auf das Jahr 1979 in der Keith Robinson eine 3-tier architecture vorschlug und erfreute sich seit der Jahrtausendwende großer Beliebtheit, ins besondere bei Webanwendungen. [3 grahamberrisford.com]
Man kann diese Architektur als Weiterentwicklung von Monolithen ansehen, da hier einige Defizite adressiert werden.
Zentrale Merkmale sind hier:
Klare Trennung der Verantwortlichkeiten
Die Layered architecture ermöglicht eine klare Trennung der Verantwortlichkeiten.
Jeder Layer ist für eine spezifische Funktion zuständig, z.B. der UI-Layer für die Benutzeroberfläche, der Business-Layer für die Logik und der Data-Layer für z.B. den Datenbankzugriff (typischer Anwendungsfall der 3-tier architecture).Lose Kopplung
Durch die Trennung in Layer werden die Abhängigkeiten zwischen den Komponenten verringert. Jeder Layer kommuniziert nur mit den unmittelbar benachbarten Layer, was die Wartbarkeit und Erweiterbarkeit verbessert.
Wiederverwendbarkeit
Die Layered architecture fördert die Wiederverwendbarkeit von Komponenten. Eine gut definierte Schnittstelle zwischen den Layern ermöglicht es, einzelne Layer unabhängig voneinander zu entwickeln und auszutauschen.
Komplexität der Kommunikation
Die Kommunikation zwischen den Layer kann komplex werden, insbesondere wenn eine große Anzahl von Layer vorhanden ist. Die klare Trennung der Verantwortlichkeiten kann zu einem erhöhten Kommunikationsaufwand führen.
Jeder Layer ist für eine spezifische Funktion zuständig, z.B. der UI-Layer für die Benutzeroberfläche, der Business-Layer für die Logik und der Data-Layer für z.B. den Datenbankzugriff (typischer Anwendungsfall der 3-tier architecture).Service-oriented architecture (SOA)
Die „Service-oriented architecture“ (zu Deutsch: dienstorientierte Architektur) ist ein Paradigma (und genauer gesagt ein ArchtekturMUSTER), bei dem Anwendungen aus unabhängigen und wiederverwendbaren Services bestehen. Diese Services kommunizieren über lose gekoppelte Schnittstellen.
Kurze Historie
Die serviceorientierte Architektur wurde entwickelt, um das Problem zu lösen, wie unterschiedliche Systeme so verbunden werden, dass sie systematisch zusammenarbeiten können.
Servicekomponenten
Die SOA organisiert Anwendungen um Services herum, die eigenständige Komponenten sind. Jeder Service bietet spezifische Funktionen an und kann unabhängig von anderen Services entwickelt, bereitgestellt und skaliert werden.
Lose Kopplung & Interoperabilität
SOA basiert auf einer lose gekoppelten Kommunikation zwischen den Services. Die Services können in verschiedenen Technologien implementiert sein und miteinander über standardisierte Schnittstellen kommunizieren, wie zum Beispiel Web Services (SOAP, REST).
Wiederverwendbarkeit & Flexibilität
Die SOA ermöglicht eine hohe Wiederverwendbarkeit von Services, da sie unabhängig voneinander entwickelt werden können. Neue Funktionen können einfach durch das Hinzufügen neuer Services oder die Aktualisierung bestehender Services implementiert werden.
Komplexität der Orchestrierung
Die Orchestrierung und Koordination der Services in einer SOA kann komplex sein. Die Verwaltung von Serviceaufrufen, Transaktionen und Ausfallsicherheit erfordert eine geeignete Architektur und Infrastruktur.
Es gibt bisher keine konkreten Industriestandards für den genauen Aufbau einer serviceorientierten Architektur, obwohl viele Branchenquellen ihre eigenen Prinzipien veröffentlicht haben. Einige davon umfassen z.B. Folgendes:
- Standardized service contract
Die Dienste unterliegen einer Vereinbarung, die gemeinsam in einem oder mehreren Contracts innerhalb einer bestimmten Reihe von Diensten definiert wird. - Service abstraction
Die Dienste fungieren als „black boxes“, das heißt, ihre innere Logik bleibt den Verbrauchern verborgen. - Service autonomy
Dienste sind unabhängig und steuern die Funktionalität. - Service statelessness
Dienste sind zustandslos, d. h. sie geben entweder den angeforderten Wert zurück oder werfen eine Ausnahme, wodurch Ressourcennutzung minimiert wird. - Service granularity
Sicherstellen, dass die Dienste eine relevante Funktionalität bieten und adäquat geschnitten sind.
Es haben sich noch viele weitere Prinzipien über die Zeit hinweg entwickelt. Weitere Details würden diesen Rahmen hier sprengen.
SOAs kommen in vielen unterschiedlichen Patterns, ein bekanntes ist die Implementation eines „Enterprise Service Bus“ (ESB).
Dieser bietet Kommunikation über ein gemeinsames Protokoll, einen sogenannten „Bus“, der Verbindungen zwischen Consumern (Verbrauchern) und Proividern / Producer (Anbieter) herstellt.
In der SO-Architektur wird typischerweise der gesamte Datenbankspeicher von allen Diensten gemeinsam genutzt.
Microservice architecture
Die „Microservice architecture“ ist ein Ansatz, bei dem Anwendungen aus kleinen, unabhängigen Diensten bestehen, die über klare Schnittstellen kommunizieren. Jeder Microservice ist für eine spezifische Funktion verantwortlich.
Kurze Historie
Über den Ursprung des Begriffs „Microservices“ gibt es zahlreiche Behauptungen, die „Ersten“ Erwähnungen spannen vom Jahr 1999 bis in die mid-2000er Jahre. Von diversen Präsentationen auf Konferenzen bis hin zu öffentlich zugänglichen Prototypen.
Der Marktanteil der implementieren Microservice-Architekturen im Enterprise Umfeld betrug 2020 >20%. [6 Wikipedia]
Microservices sind eine Evolution der SOAs, die bestimmte Defizite dessen adressiert, mit besonderem Augenmerk auf „Service granularity“.
Ein wichtiger Schritt bei der Definition einer Microservice-Architektur besteht darin, herauszufinden, wie groß ein einzelner Microservice sein soll.
Hierfür gibt es keinen definierten industriell anerkannten Konsens, da die richtige Antwort vom geschäftlichen und organisatorischen Kontext abhängt.
Generell gilt:
Dienste, die einer einzelnen Aufgabe gewidmet sind, z.B. dem Call eines Backend-Systems oder Durchführen einer bestimmten Berechnung, werden als „atomic services“ (atomaren Dienste) bezeichnet.
Ebenso werden Dienste, die solche atomaren Dienste aufrufen, um eine Ausgabe zu konsolidieren, als „composite services“ (zusammengesetzte Dienste) bezeichnet.
Die Merkmale einer Microservices-Architektur sind:
Unabhängige Dienste
Microservices sind eigenständige Dienste, die unabhängig voneinander entwickelt, bereitgestellt und skaliert werden können. Jeder Dienst kann in einer eigenen Technologie implementiert werden.
Skalierbarkeit & Flexibilität
Durch die Aufteilung einer Anwendung in Microservices können einzelne Dienste unabhängig voneinander skaliert und aktualisiert werden. Dies ermöglicht eine größere Flexibilität bei der Anpassung an die Anforderungen des Systems.
Vereinfachte Wartung & Erweiterbarkeit
Da jeder Microservice in sich geschlossen ist, können Teams unabhängig voneinander an den verschiedenen Diensten arbeiten. Dies erleichtert die Wartung und ermöglicht eine schnellere Entwicklung neuer Funktionen.
Herausforderungen
Microservices bieten viele Vorteile, aber auch Herausforderungen. Die Koordination zwischen den Diensten und das Management der Kommunikation erfordern zusätzliche Komplexität. Die Datenkonsistenz über verschiedene Services hinweg kann ebenfalls eine Herausforderung darstellen.
Event-driven architecture (EDA)
Die „Event-driven architecture“ (zu Deutsch: Ereignisgesteuerte Architektur) ist ein Paradigma, bei dem Anwendungen auf Ereignissen basieren, die zwischen Komponenten ausgelöst werden.
EDA nutzt Events, um die Kommunikation zwischen entkoppelten Anwendungen, Microservices oder verbundenen Geräten auszulösen und den Informationsfluss in Echtzeit zu ermöglichen. [7 thenewstack.io]
Ein Ereignis wird definiert als: kann als „a significant change in state“. [8 K. Mani Chandy Caltec 2006]
Events können sowohl von außen, als auch vom System selbst ausgelöst werden.
Ein Event kann Auslöser für eine Ereignisbehandlung sein, mit der das System reagiert. Eine ereignisgesteuerte Architektur hat kaum Kontrolle darüber, wann Daten verarbeitet werden.
Die EDA ergänzt die SOA (vielmehr ist es eine besondere Anwendung dessen, und kann auch mit Konzepten wie Microservices kombiniert werden), da Services durch Events ausgelöst werden können.
Kurze Historie
Um wirklich zu verstehen, worum es bei der EDA geht, ist es hilfreich, einen Blick zurück auf die Geschichte der verteilten Softwarearchitekturen und ihre Entwicklung in den letzten Jahrzehnten zu werfen.
Die erste Software der 1940er Jahre verwendeten eine Sub-routine, um einen Task basierend auf einer Reihe von Anweisungen auszuführen.
Das Design der Computerarchitektur entwickelte sich dann dahingehend, dass ein Orchestrierungssystem die Hauptaufgaben übernahm, welches mehrere Sub-routines remote ansteuern konnte. Aus dieser Struktur entstand das Request-Response-Paradigma.
Nachdem 1989 das World Wide Web erfunden wurde, ist HTTP zur bevorzugten Methode zur Bereitstellung verteilter Systeme, wobei Endpunkte (also URLs) Sub-routines offenlegten und darauf zugriffen. Diese wiederum versprach APIs eine Zukunft. Da sich die Geschäftsprioritäten mehr auf das Echtzeiterlebnis konzentrierten, sind APIs heute wichtiger denn je.
So landen wir im Heute, und Event-driven APIs bilden eine hervorragende Möglichkeit den Anforderungen moderner End-usern gerecht zu werden, die einen real-time Zugriff auf Informationen benötigen.
Die Merkmale einer Event-driven-Architektur sind:
Lose Kopplung & Skalierbarkeit
Event-driven-Architekturen fördern die lose Kopplung zwischen den Komponenten einer Anwendung. Jede Komponente reagiert auf Ereignisse, die sie interessieren, und die Kommunikation erfolgt über Ereignisnachrichten.
Echtzeitverarbeitung & Reaktionsfähigkeit
Durch die Verwendung von Ereignissen können Anwendungen in Echtzeit auf Änderungen reagieren. Komponenten können Ereignisse empfangen und entsprechende Aktionen auslösen, ohne auf synchronen Aufruf zu warten.
Event Sourcing & Command Query Responsibility Segregation (CQRS)
Ein weiteres Merkmal von Event-driven-Architekturen ist die Verwendung von Event Sourcing und CQRS. Event Sourcing speichert den Zustand einer Anwendung als eine Sequenz von Ereignissen, während CQRS die Trennung von Lese- und Schreiboperationen ermöglicht.
Herausforderungen
Bei der Umsetzung einer Event-driven architecture müssen einige Herausforderungen berücksichtigt werden. Die Komplexität der Event-Verarbeitung und das Management von Ereignissen erfordern eine geeignete Event-Bus-Infrastruktur.
Fazit
Die Wahl der richtigen Software Architektur ist entscheidend für den Erfolg eures Projekts.
- Monolithische Architekturen sind gut für kleinere Anwendungen geeignet, während Schichtarchitekturen eine bessere Trennung von Verantwortlichkeiten bieten.
- SOA ermöglicht die Wiederverwendbarkeit von Services, während Microservices eine hohe Skalierbarkeit und Flexibilität bieten.
- Event-driven-Architekturen eignen sich für echtzeitfähige Anwendungen.
Die beste Wahl hängt von den spezifischen Anforderungen und Zielen des Projekts ab. Ebenso lassen sich diverse Architektur Modelle miteinander koppeln und verbinden um das best-möglichste für die eigene Applikation zu gewinnen.
Sehr wichtig ist ebenfalls jenseits der Architektur der Applikation selbst auch das “drum-herum”, wie eine adäquate Development- und Testing-Infrastruktur.
Jenseits dessen richten sich Enterprise-Software Solutions auch nach der Organisationsstruktur des Unternehmens und müssen dazu passen.
Unabhängig von der gewählten Architektur ist es wichtig, die Vor- und Nachteile zu berücksichtigen und die richtigen Werkzeuge und Praktiken einzusetzen, um eine erfolgreiche Entwicklung und Bereitstellung von Softwarelösungen zu gewährleisten.
