Welche Überlegungen sollten bei der Entwicklung oder Modernisierung einer Anwendung für die Cloud berücksichtigt werden?

Die Cloud-Technologie hat die Landschaft der IT-Architekturen revolutioniert und stellt eine Weiterentwicklung gegenüber traditionellen Computermodellen dar. Während die ersten Computermodelle auf Mainframes und Desktop-Computern basierten, hat sich die Architektur von Anwendungen im Laufe der Zeit stetig weiterentwickelt. Der Übergang zu Cloud-nativen Anwendungen stellt jedoch eine signifikante Veränderung dar, die weit über das hinausgeht, was herkömmliche IT-Systeme zu bieten haben. Dies betrifft nicht nur die zugrunde liegende Infrastruktur, sondern auch die Art und Weise, wie Anwendungen entwickelt und betrieben werden.

Cloud-basierte Anwendungen unterscheiden sich grundlegend von traditionellen IT-Anwendungen, insbesondere in ihrer Struktur und den Prinzipien, die ihre Entwicklung leiten. Die Cloud ermöglicht es, Rechenressourcen effizient zu teilen, während traditionelle IT-Systeme oft auf dedizierte Hardware angewiesen sind. Diese neueren Qualitäten der Cloud — wie etwa Skalierbarkeit und Flexibilität — sind Merkmale, die in der klassischen IT nicht in gleichem Maße vorhanden sind und die eine ganz neue Herangehensweise an das Design von Software erfordern.

Ein entscheidender Aspekt bei der Entwicklung von Cloud-Anwendungen ist die Architektur. Die Struktur einer Cloud-Anwendung muss nicht nur die speziellen Anforderungen der Cloud berücksichtigen, sondern auch die Praktiken der modernen Softwareentwicklung integrieren, die durch die Cloud erst richtig zur Geltung kommen. Hierbei spielen verschiedene Architekturansätze eine zentrale Rolle, um die vielfältigen Anforderungen zu adressieren. Eine der wichtigsten Grundlagen in diesem Zusammenhang ist die Anpassungsfähigkeit der Architektur, die es ermöglicht, Software effektiv auf der Cloud-Infrastruktur laufen zu lassen.

Dabei ist es wichtig zu verstehen, dass Cloud-Anwendungen nicht gänzlich neu und unbekannt sind. Ihre Grundprinzipien haben sich aus älteren IT-Technologien entwickelt. Von den klassischen Mainframe-Computern über Client-Server-Architekturen bis hin zu modernen Cloud-nativen Computermodellen, die heute den Standard darstellen, hat sich die Anwendungsarchitektur stetig weiterentwickelt. Diese Entwicklung ist nicht isoliert zu betrachten, sondern muss als Teil eines fortlaufenden Fortschritts in der IT-Welt gesehen werden.

Die Architektur einer Cloud-Anwendung unterscheidet sich jedoch von der herkömmlicher IT-Systeme, indem sie den Fokus auf die Flexibilität und Skalierbarkeit legt. Ein gutes Beispiel hierfür ist das Prinzip der Modularität. Cloud-Anwendungen sind häufig in modulare Einheiten unterteilt, die unabhängig voneinander skaliert, gewartet und aktualisiert werden können. Diese Modularität ist ein Merkmal, das in traditionellen IT-Architekturen oft nicht im gleichen Maße ausgeprägt ist. Hier wird eine klarere Trennung von Funktionalitäten angestrebt, die eine unabhängige Entwicklung und Skalierung einzelner Module ermöglichen.

Die Prinzipien der Cloud-Architektur beinhalten nicht nur eine grundlegende Struktur, sondern auch verschiedene Entwurfsentscheidungen, die die Anforderungen der Anwendung und ihrer Nutzer berücksichtigen. Eine wichtige Entscheidung, die zu Beginn eines Projekts getroffen werden muss, betrifft die Architektur, die für die Anwendung gewählt wird. Diese Wahl beeinflusst nicht nur die Funktionalität der Software, sondern auch die Art und Weise, wie sie entwickelt und betrieben wird.

Ein weiterer wichtiger Aspekt ist das Konzept der „technischen Schulden“. In der Softwareentwicklung bezeichnet dies den Aufwand, der notwendig ist, um bestehende Funktionalitäten zu erhalten und auszubauen. In der Cloud-Entwicklung kann es sinnvoll sein, technische Schulden bewusst einzugehen, um in der Anfangsphase eines Projekts schneller Ergebnisse zu erzielen. Doch auch hier gilt es, die langfristigen Konsequenzen zu bedenken. Ein Architekturansatz, der schnelle Ergebnisse liefert, kann später zusätzliche Kosten verursachen, wenn er nicht gut gewartet oder weiterentwickelt wird.

Ein weiterer zentraler Punkt bei der Wahl der Architektur ist die Skalierbarkeit. Cloud-Anwendungen müssen so gestaltet sein, dass sie bei Bedarf schnell und effizient wachsen können, ohne dass dies die Leistung oder Verfügbarkeit beeinträchtigt. Dies stellt eine grundlegende Anforderung dar, die in traditionellen IT-Umgebungen weniger im Vordergrund stand. Die Möglichkeit, Anwendungen und deren Komponenten in der Cloud unabhängig voneinander zu skalieren, ist eine der herausragenden Eigenschaften der modernen Architektur.

Wichtig ist zudem, dass die Architektur der Anwendung die Wartbarkeit und Weiterentwicklung der Software unterstützt. Wenn eine Anwendung von Anfang an so konzipiert ist, dass sie leicht zu ändern und zu erweitern ist, kann dies später den Entwicklungsaufwand erheblich reduzieren. Besonders in größeren Teams, die parallel an verschiedenen Modulen oder Komponenten arbeiten, ermöglicht eine gut durchdachte Architektur die Unabhängigkeit und Effizienz der einzelnen Entwicklungsstränge.

Es ist von großer Bedeutung, bei der Auswahl der Architektur die Komplexität der Anwendung und die spezifischen Anforderungen des jeweiligen Anwendungsfalls zu berücksichtigen. Eine Cloud-native Architektur, die speziell für die Cloud entwickelt wurde, kann viele Vorteile bieten, ist jedoch möglicherweise nicht immer die beste Wahl, wenn die Anwendung auf einer traditionellen Infrastruktur oder in einer Hybridumgebung betrieben werden soll. In solchen Fällen müssen auch hybride Architekturen und das Zusammenspiel von Cloud und On-Premise-Systemen bedacht werden.

Zusammenfassend lässt sich sagen, dass die Wahl der richtigen Architektur für eine Cloud-Anwendung von zentraler Bedeutung ist und in engem Zusammenhang mit der Auswahl der richtigen Technologien und Entwurfsmuster steht. Eine gut durchdachte Architektur bildet das Fundament für den Erfolg einer Anwendung in der Cloud und stellt sicher, dass sie den Anforderungen hinsichtlich Leistung, Skalierbarkeit und Wartbarkeit gerecht wird.

Was ist eine „Big Ball of Mud“ und warum kann es sinnvoll sein, damit zu starten?

Eine „Big Ball of Mud“ ist im Wesentlichen das Gegenteil einer gut durchdachten, sauberen Architektur. Sie zeichnet sich durch das Fehlen von Kapselung und Modularity aus, wobei alle Teile des Systems miteinander verknüpft sind, ohne klare Abgrenzungen oder Regeln. Variablen und Funktionen sind oft schlecht benannt, und die Struktur des Codes ist schwer nachvollziehbar. Hier herrscht häufig eine Mischung aus globalen Variablen und schlecht definierten Parametern, was den Code unübersichtlich und schwer wartbar macht. Viele Funktionen sind lang und unstrukturiert, und der Programmierer ist oft schwer zu verstehen. Dies wird durch das Fehlen einer klaren Dokumentation noch verschärft.

Zwar ist ein BBoM typischerweise ein anti-pattern, wird jedoch oft als pragmatische Lösung in der frühen Entwicklungsphase verwendet, insbesondere wenn es darum geht, schnell funktionierende Prototypen zu erstellen. Ein solcher Ansatz ermöglicht es Teams, schnell zu arbeiten und Feedback zu erhalten, ohne sich in der Komplexität einer ausgereiften Architektur zu verlieren. Zu viel Fokus auf eine perfekte Architektur kann verhindern, dass ein System überhaupt funktioniert und vorankommt.

In vielen Fällen, besonders bei der Entwicklung eines minimal funktionsfähigen Produkts (MVP), kann es sein, dass ein Team ein BBoM absichtlich schafft. Ziel eines MVP ist es, ein funktionierendes Produkt mit minimalem Aufwand und nur den nötigsten Funktionen zu erstellen. In solchen Fällen kann es effizienter sein, eine BBoM zu entwickeln, anstatt viel Zeit in die Gestaltung einer langfristig skalierbaren Architektur zu investieren. Das MVP ist dann ein erster Schritt, dessen Erfolg die Grundlage für spätere Erweiterungen und eine detailliertere Systemarchitektur bildet.

Doch die Herausforderung tritt später auf. Wenn das MVP erfolgreich ist und die Anforderungen steigen, muss das System oft überarbeitet werden. Die initiale BBoM, die in der frühen Phase ein Vorteil war, kann sich nun zu einem Problem entwickeln. Technische Schulden häufen sich, und der Code wird immer schwieriger zu pflegen und zu erweitern. Ein zu starker Fokus auf schnelle Ergebnisse und eine geringe Bereitschaft, in die Architektur zu investieren, kann langfristig zu einem schwer handhabbaren System führen.

Wichtig ist, dass der Start eines Projekts nicht immer durch eine perfekt durchdachte Architektur geprägt sein muss. Der Fokus sollte darauf liegen, ein funktionierendes System zu entwickeln, das schnell auf Veränderungen reagieren kann. In den frühen Phasen kann es sinnvoll sein, bewusst eine BBoM zu entwickeln, um schnell ein funktionsfähiges Produkt zu erstellen, das später weiter ausgebaut und verbessert wird. Die Entscheidung, in welchem Maß und zu welchem Zeitpunkt man sich mit Architekturfragen befasst, hängt stark von der Entwicklungsphase und den spezifischen Anforderungen des Projekts ab.

Es ist jedoch auch entscheidend, dass man sich bewusst ist, dass eine BBoM nicht das Endziel ist. Sie ist ein temporärer Zustand, der nur dann vorteilhaft ist, wenn es gelingt, das System später zu verbessern und die technischen Schulden zu verringern. Ein klares Verständnis der langfristigen Ziele des Systems und eine sorgfältige Abwägung der Architekturentscheidungen sind entscheidend, um zu verhindern, dass das System langfristig in einem Zustand der Unübersichtlichkeit verharrt.

Wie macht man Anwendungen zustandslos und warum ist das wichtig?

In der traditionellen IT-Architektur ist es üblich, Daten aus der Datenbank zu cachen, um Zugriffe zu beschleunigen. Dazu werden oft Instanzvariablen genutzt, die Daten zwischen Speichervorgängen im Speicher halten. Ein Beispiel hierfür ist ein Produktmanager, der Produkte in einer internen Map zwischenspeichert. Wenn ein Produkt angefragt wird, prüft die Methode zuerst den Cache und lädt die Daten nur bei Bedarf aus der Datenbank nach. Dieses Vorgehen erleichtert zwar schnelle Zugriffe, macht die Anwendung jedoch zustandsbehaftet, da der Zustand im Speicher der Anwendung gehalten wird.

Will man eine zustandslose Anwendung entwickeln, sollte man bewusst darauf verzichten, solche Daten im Anwendungsspeicher zu halten. Stattdessen werden Daten bei jedem Zugriff direkt aus der Datenbank geladen. Das reduziert die Komplexität der Anwendung, da keine Synchronisation von Cache und Datenbank mehr nötig ist und Fehlerquellen durch inkonsistente Zustände entfallen. Trotz Bedenken, dass diese Vorgehensweise ineffizient sein könnte, haben sich moderne Cloud-Architekturen und Datenbanksysteme so weiterentwickelt, dass schnelle Zugriffe auch ohne lokalen Cache möglich sind. NoSQL-Datenbanken verfügen oft über eigene Caching-Mechanismen, Netzwerkverbindungen sind schneller, und Replikationen verteilen die Last auf mehrere Datenbankinstanzen, was die Skalierbarkeit verbessert. Falls dennoch ein Cache nötig ist, sollten spezialisierte Backend-Dienste wie Redis oder Memcached genutzt werden, die als externe Caches fungieren und nicht Teil der Anwendung selbst sind.

Dieser Ansatz, Anwendungen zustandslos zu gestalten, ist zwar anspruchsvoll in der Entwicklung, lohnt sich jedoch vielfach. Er trennt die Verantwortlichkeiten sauber und ermöglicht die horizontale Skalierung (Replicable Application), die in Cloud-Umgebungen essenziell ist.

Wichtig ist, dass Zuverlässigkeit von Cloud-Anwendungen nicht durch die Unfehlbarkeit der Hardware erreicht wird – denn diese ist nie garantiert. Stattdessen wird durch Redundanz und Zustandslosigkeit sichergestellt, dass Ausfälle einzelner Komponenten keinen Ausfall der gesamten Anwendung verursachen. Dies bedeutet, dass man bei Cloud-nativen Anwendungen nicht auf teure, besonders zuverlässige Hardware setzen muss, sondern das Gesamtsystem durch Architekturprinzipien robust gestaltet.

Die Zustandslosigkeit einer Anwendung macht sie zudem threadsicher, da keine gemeinsamen Instanzvariablen zwischen Threads geteilt werden. Jede Ausführungseinheit arbeitet mit eigenen, temporären Variablen, deren Lebensdauer auf den einzelnen Aufruf begrenzt ist. Dies reduziert Fehler durch parallelen Zugriff und erleichtert die Fehlersuche.

Zusätzlich sollten Entwickler verstehen, dass das externe Halten von Sitzungs- und Domänenstatus eine Voraussetzung ist, um automatisches Failover und Lastverteilung in der Cloud zu ermöglichen. Nur so kann sich die Anwendung flexibel an veränderte Lastbedingungen an

Wie definiert man ein Software-Domain und warum ist Domain-Driven Design (DDD) entscheidend für den erfolgreichen Entwurf von Systemen?

Der Zweck von DDD ist es, die Komplexität von Softwarelösungen zu verringern, indem diese so präzise wie möglich auf die Anforderungen und Gegebenheiten der jeweiligen Domain abgestimmt werden. Dies gelingt besonders durch die Zusammenarbeit mit Experten aus dem entsprechenden Fachbereich. Wenn man Systeme modelliert, muss man dabei immer die richtigen Domain-Grenzen wählen, mit denen sowohl die Software als auch die organisatorischen Strukturen harmonisieren.

Innerhalb eines Systems ist es zudem wichtig, sich auf die Kern-Domains zu konzentrieren. Ein gutes Beispiel dafür ist das Bankwesen: Die Haupt-Domain bezieht sich hier auf alles, was mit Geld, Finanzen und Kundenbeziehungen zu tun hat. Doch innerhalb dieser Haupt-Domain existieren zahlreiche Subdomains wie das Privatkundengeschäft, das Investmentbanking oder die Kreditkartenabwicklung. In der Regel bestehen Domains aus mehreren Subdomains. Aber was genau unterscheidet eine Domain von einer Subdomain? Eine Domain kann Subdomains beinhalten, die wiederum Subdomains enthalten können. Jede Subdomain ist letztlich auch eine Domain. Eine Domain ist nur dann keine Subdomain, wenn das Modell keine übergeordnete Domain enthält.

Ein weiteres zentrales Konzept im DDD ist die Entwicklung eines gemeinsamen mentalen Modells, das von allen Stakeholdern genutzt wird, um über das System zu kommunizieren. Dieses Modell ist ein gemeinsames Verständnis der wichtigsten Konzepte, das allen Teams innerhalb einer Organisation als Grundlage dient. Die Herausforderung bei der Modellierung einer Domain besteht darin, die Subdomains sowie deren relevante Entitäten, Werte und Verhaltensweisen (wie Domain Events und Domain Services) zu beschreiben.

Jede Subdomain besitzt dabei ihre eigenen Grenzen (sogenannte "Bounded Contexts") sowie eine gemeinsame Sprache – die „Ubiquitous Language“. Diese Sprache spielt eine wichtige Rolle, da sie sicherstellt, dass alle Beteiligten mit denselben Begriffen und Definitionen arbeiten. Ein wesentliches Ziel ist es, Missverständnisse und Mehrdeutigkeiten zu vermeiden und die Kommunikation zwischen Entwicklern und Domänenexperten zu erleichtern.

Die Ubiquitous Language ist ein wesentlicher Bestandteil des DDD. Es handelt sich hierbei um eine präzise, fachlich abgestimmte Sprache, die von Entwicklern und Experten gemeinsam entwickelt wird und die das Domain Model widerspiegelt. Die Bedeutung der Begriffe innerhalb dieser Sprache wird dabei strikt durch die Perspektive der Domain-Experten bestimmt. Ein Entwickler muss sicherstellen, dass keine Begriffe verwendet werden, die unklar oder ungenau sind, um Missverständnisse in der Softwareentwicklung zu vermeiden.

Es ist wichtig, die Unterscheidung zwischen einer „Ubiquitous Language“ und einer „Universal Language“ zu verstehen. Eine Ubiquitous Language ist nicht universell anwendbar. Dasselbe Konzept kann in verschiedenen Subdomains unterschiedliche Bedeutungen haben. Ein anschauliches Beispiel hierfür ist die Entität „Konto“ in einem Bankensystem. Innerhalb der Subdomain „Kreditkarten“ könnte ein Konto zusätzliche Attribute wie „Kreditlimit“ oder „Gebühren“ aufweisen, während in der Subdomain „Sparkonto“ Attribute wie „Kontostand“ und „Zinsen“ relevant sind. Auch wenn beide Subdomains das gleiche Konzept „Konto“ verwenden, wird dieses je nach Kontext unterschiedlich modelliert. So entstehen keine Konflikte zwischen verschiedenen Subdomains, und jede Subdomain kann ihre eigene, spezifische Sicht auf das Konzept entwickeln.

Die Ubiquitous Language verändert sich im Laufe der Zeit, je nachdem, wie das Verständnis der Domain und ihrer Subdomains wächst. Sie ist nicht statisch, sondern entwickelt sich weiter, während neue Erkenntnisse gewonnen und neue Anforderungen formuliert werden. Es ist daher nicht erforderlich, ein einziges, allumfassendes Modell zu erstellen, das alle Konzepte für alle Subdomains abbildet. Vielmehr sollten Subdomains ihre jeweils eigene Sprache entwickeln, die auf ihre speziellen Anforderungen zugeschnitten ist.

Letztlich bleibt die wichtigste Herausforderung in der Modellierung, die richtigen Stakeholder zusammenzubringen, die eine gemeinsame Sicht auf die Domain entwickeln. Dieser Prozess erfordert Zeit und das Engagement aller Beteiligten. Ein häufiges Problem in agilen Organisationen ist es, den Modellierungsprozess zu schnell zu starten und die Details der Domain im Laufe der Entwicklung zu erarbeiten. Dies kann jedoch dazu führen, dass die Systemgrenzen zwischen Subdomains nicht korrekt definiert werden, was zu einem unklaren und schlecht wartbaren System führt.

Wie man mit Event Choreografie die Kommunikation zwischen Microservices gestaltet

In modernen Systemarchitekturen, die auf Microservices basieren, ist es von zentraler Bedeutung, wie verschiedene Komponenten miteinander kommunizieren. Eine der effektivsten Methoden, um diese Kommunikation zu gestalten, ist die Event Choreografie. Dabei geht es nicht nur um das Senden von Nachrichten zwischen den Komponenten, sondern darum, Ereignisse zu schaffen, die die Veränderungen im Zustand eines Systems darstellen. Diese Ereignisse ermöglichen es verschiedenen Komponenten, auf relevante Veränderungen zu reagieren, ohne dass sie direkt miteinander gekoppelt sind. Ein gutes Beispiel für diese Methode ist das Szenario, in dem Reiseereignisse und Reiseunterbrechungen auf Basis von externen Quellen verarbeitet werden, um Benachrichtigungen zu senden.

Ein solches System basiert auf der Event Choreografie, weil es eine hohe Flexibilität bietet. Wenn eine neue Datenquelle hinzugefügt werden soll, kann der entsprechende Event Notifier einfach eingebaut werden, ohne dass bestehende Komponenten geändert werden müssen. Auch die Art und Weise, wie Benachrichtigungen gesendet werden, kann angepasst werden, indem einfach neue Reactive Components hinzugefügt werden, die auf das jeweilige Event reagieren. Ein Vorteil dieser Architektur ist, dass selbst der Wechsel zu einer anderen Reiseagentur die Änderungen nur in einem einzelnen, isolierten Bereich des Systems erfordert.

Das Konzept der Event Choreografie zeigt, wie es möglich ist, verschiedene Microservices zu koordinieren, sodass Änderungen in einer Komponente auch andere Komponenten informieren können, ohne dass sie stark miteinander gekoppelt sind. Dies ermöglicht eine hohe Modularität und Erweiterbarkeit des Systems, da Änderungen und Erweiterungen nur dort vorgenommen werden müssen, wo sie wirklich erforderlich sind.

Im Grunde genommen beschreibt ein Event eine Änderung des Zustands eines Systems, die für andere Komponenten von Interesse sein könnte. Diese Änderungen können durch unterschiedliche Auslöser verursacht werden, wie etwa eine Datenbankaktualisierung, eine Änderung im Workflow oder die Erkennung eines Problems. Es genügt, wenn ein Event nur die minimal notwendigen Informationen enthält, um den Statuswechsel zu beschreiben. So könnte etwa ein Temperaturwechsel von einem Sensor erfasst werden, der dann das Ereignis „Temperaturänderung“ an andere Komponenten sendet. In diesem Fall ist es wichtig, die relevanten Daten, wie die neue Temperatur, zu übermitteln, ohne die internen Details des Sensors oder der zugrunde liegenden Infrastruktur preiszugeben.

Das Senden von Events ermöglicht es dem System, lose gekoppelt zu bleiben und gleichzeitig flexibel auf Änderungen zu reagieren. Ein weiteres wichtiges Prinzip, das in diesem Zusammenhang angewendet wird, ist das „Claim Check Pattern“, bei dem nur die nötigsten Informationen, wie etwa ein Schlüssel, übermittelt werden, um die Identifikation eines Objekts im System zu ermöglichen, ohne dabei zu viele Details preiszugeben.

Es ist jedoch von großer Bedeutung, sich bewusst zu machen, dass das Design von Events sorgfältig erfolgen muss. Besonders wichtig ist die Konsistenz der Datenstrukturen, die zur Darstellung eines Events verwendet werden. Ein gut durchdachtes Event Design stellt sicher, dass alle notwendigen Informationen vorhanden sind, um auf das Ereignis korrekt zu reagieren, ohne dass unnötige Daten übertragen werden. Dabei müssen Entwickler den Fokus auf die relevanten Daten legen, die für die Kommunikation zwischen den Komponenten notwendig sind, und gleichzeitig auf die Vermeidung von zu viel Komplexität achten.

Schließlich ist es wichtig, zu verstehen, dass das Erstellen und Versenden von Events nicht nur dazu dient, den aktuellen Zustand eines Systems zu kommunizieren, sondern auch um zukünftige Erweiterungen und Anpassungen zu erleichtern. Ein Event ist eine Möglichkeit, das System zu erweitern, ohne bestehende Komponenten zu verändern. Diese Vorgehensweise stellt sicher, dass das System robust und anpassungsfähig bleibt, während gleichzeitig die Lose Kopplung der Komponenten gewahrt bleibt.