Cloud Computing Architektur

Architektur des Cloud Computing

("Architektur", SOA), entwickeln sich ständig weiter. Hochrangige Architektur des Cloud Computing nach IBM. Der Weg in die Cloud-Computing-Technologie ist keine leichte Aufgabe. Geschichte der Cloud; Die Definition der Cloud;

Vor- und Nachteile des Cloud Computing; Die Architektur der Cloud; Die technische Realisierung der Cloud.

Wolken-Computing: Überdenken für Architektur in der Cloud

Im Laufe der vergangenen zehn bis fünfzehn Jahre haben sich eine Vielzahl von architektonischen Paradebeispielen herausgebildet, die heute die Basis für Enterprise-Anwendungen bilden und in einer Vielzahl von Normen, Rahmen und Best Practices so stark verwurzelt sind, dass es schwierig ist, sie zu berücksichtigen. Die unreflektierte Anwendung dieser Parade auf Cloud-Anwendungen hat in der Praxis meist ernüchternde Ergebnisse zur Folge.

Vor allem die für Cloud Computing relevanten Merkmale Scalability, Streckbarkeit und Stabilität können auf diese Art und Weise nicht erreicht werden. Daher müssen wir überdenken, um das Potenzial der Cloud auszuschöpfen. Der vorliegende Beitrag befasst sich mit einigen der geänderten Konzepten und Ansätze für Cloud-Architekturen. Das Cloud Computing ist derzeit in Mode. Die klassischen Software-Architekturen für Enterprise-Anwendungen stossen in solchen Umfeldern an ihre jeweiligen Leistungsgrenzen.

Durch die strikte Verwendung von Transaktionsabläufen und die strikte Replizierung gewährleisten diese Lösungen eine jederzeit größtmögliche Konsistenz der Daten. Wenn man jedoch auf Forderungen nach fast unbegrenzter Flexibilität und Datenmengen trifft, dann sind diese Grundsätze nicht mehr gültig, weil sie diese nicht untermauern. Darüber hinaus eröffnet sich an dieser Position das Themenfeld der wirtschaftlichen Effizienz als weitere Triebkraft für Wolkenarchitekturen.

Bei den meisten Klassikern haben die meisten Lösungsansätze die Besonderheit, dass ihre Preise mit zunehmender Rechnerleistung und wachsendem Datenaufkommen unverhältnismäßig steigen, vor allem wenn eine Hochverfügbarkeit erwünscht ist. Auch Cloud-Architekturen müssen dieses Phänomen auflösen. Einige der " gewachsenen Fond " Ansätze für das Erstellen von Enterprise Applications der vergangenen zehn bis fünfzehn Jahre sind nicht auf Cloud-Szenarien übertragbar. Bei der Entwicklung von Enterprise Applications sind die Ergebnisse der Studie sehr unterschiedlich.

Eine Anpassung der Architektur und des Entwurfs an die geänderten Bedürfnisse ist erforderlich. Sie würde den Umfang dieses Beitrags überschreiten, wenn wir versuchen würden, eine umfangreiche Arbeit über die Architektur und das Design von Cloud-Anwendungen zu verfassen. Bild 1 gibt einen Gesamtüberblick über die oben genannten Cloud-Anwendungstreiber (rot dargestellt) und deren Zusammenhang mit den im folgenden detaillierter dargestellten Auslegungsgrundsätzen.

Daher ist es nicht zweckmäßig, diese Grundsätze bei der Gestaltung einer Cloud-Architektur zu isolieren, sondern die gegenseitigen Einflüsse und Interaktionen im Auge zu haben. Ist Hochverfügbarkeit in gewöhnlichen Geschäftsanwendungen eine Voraussetzung, werden in der Regel die Cluster- und High Availability (HA)-Angebote der Hard- und Software-Infrastrukturanbieter genutzt.

Die Problematik bei solchen Lösungsansätzen ist, dass sie einerseits nicht willkürlich skaliert werden und andererseits die Preise für diese Lösungsansätze mit der Skala unverhältnismäßig steigen. Das bedeutet, dass diese Lösungsansätze für fast jede beliebige Skalierbarkeit nicht geeignet sind. Vielmehr sind Cloudumgebungen in der Praxis auf einfacher Standard-Hardware und redundanter Ausführung angewiesen, um die Erreichbarkeit zu gewährleisten.

Fehler werden für die Applikationslogik nicht mehr offen gehandhabt, sondern müssen bei der Gestaltung der Applikation ausdrücklich berücksichtigt werden. Der Einsatz des klassichen Konsequenzmodells auf der Grundlage von ACID-Transaktionen[1] fördert nicht nur die Weiterentwicklung, sondern wirkt auch beruhigend auf die Verbraucher. Das so genannte CAP-Theorem[2] führt jedoch unter der Voraussetzung der willkürlichen Anpassbarkeit dazu, dass die Kohärenz nicht ohne Einschränkungen gewährleistet werden kann.

Damit ist jedoch nicht gemeint, dass ein Datenschrott erzeugt wird, sondern dass zugunsten der Erreichbarkeit stets die Datenkonsistenz unmittelbar gewährleistet ist. Vielmehr wird akzeptiert, dass die Angaben letztendlich einheitlich sind. Bei der Gestaltung von Cloud-Anwendungen heißt das vor allem, dass Stabilität gegenüber möglichen Datenschiefständen gegeben sein muss, da es vorkommen kann, dass Lesewerte nicht den momentanen Status widerspiegeln oder dass eine Instanz einen anderen Status repräsentiert als eine zweite zugehörige Instanz.

Unter keinen Umständen sollten jedoch in die Applikation eingebaute Verfahren integriert werden, die sich blindlings auf die Kohärenz der bearbeiteten Informationen abstützen. Bei sehr großen Anlagen ist es nicht mehr möglich, alle Informationen an einem Ort, d.h. in einer einzigen Datenbasis, zu hinterlegen, nachdem eine bestimmte Anzahl von Informationen gespeichert wurde. Vielmehr müssen Sie die Informationen auf eine Reihe von Standorten aufteilen.

Weil dezentrale Geschäftsvorfälle nicht willkürlich erweiterbar sind (zumindest wenn man die System-Verfügbarkeit hochhalten will ), muss man auf eine weitgehend unabhängige Distribution und Ablage der gesammelten Informationen umsteigen. Die Organisation der Informationen wird von Pat Helland in Gestalt von Einheiten empfohlen, die eigenständig verteilt werden können[3]. Man kann dann davon ausgegangen, dass sich eine einzige Einheit immer in einem für sich selbst einheitlichen Erhaltungszustand befinden kann, was die Weiterentwicklung begünstigt.

Sie sollten in diesem Fall eine Einheit nicht mit einer herkömmlichen Datenbank-Entität vergleichen. Unter einem Unternehmen wird in diesem Sinne in der Regel ein Bestellbegriff mit allen zugewiesenen Informationen verstanden. Bei herkömmlichen Cloud-Architekturen, bei denen der Status (Daten) über den ganzen Cloud verteilt wird, wird nur bis zu einem bestimmten Zeitpunkt vergrößert. Darüber hinaus wird der kommunikative Aufwand für die Vervielfältigung so groß, dass die Erreichbarkeit der Applikation nicht mehr garantiert werden kann.

Zur Entwicklung fast willkürlich skalierbarer Applikationen ist man auf sogenannte Shared Nothing-Architekturen angewiesen. Die Bezeichnung existiert auf unterschiedlichen architektonischen Ebenen, von der Beschlagtechnik bis zur Applikation. Im Allgemeinen besagt "Shared Nothing", dass die Bestandteile keinen Status auf der zugehörigen Stufe haben. Nur wenn die einzelnen Module so weit wie möglich getrennt von einander sind, können wir eine Applikation sowohl auf technologischer als auch auf betriebswirtschaftlicher Basis fast willkürlich dimensionieren.

Darüber hinaus trägt die Abkopplung der Komponenten dazu bei, die Applikation widerstandsfähiger zu machen und damit die Ausfallsicherheit zu erhöhen[4]. In der Tat bedeutet die Message-basierte asymmetrische Komunikation einen paradigmatischen Wechsel von der traditionellen Call-Stack-basierten Individualsoftware. Die oben genannten Grundsätze gehen einher mit einer erhöhten Skalierbarkeit der Applikation oder von Teilen davon. Es ist daher offensichtlich, dass beim Entwurf einer Applikation darauf geachtet werden muss, die nicht parallelen Teile einer Cloud-Applikation so klein wie möglich zu gestalten.

Anwendungsteile, die Nebenwirkungen haben, können nicht parallelisiert werden. Dies beinhaltet vor allem einen gemeinsamen Status zwischen mehreren Ausführungsthreads und den Zugriff auf die externen Server. Nebenwirkungen sollten in dieser Konstellation so weit wie möglich vermieden oder, falls unvermeidlich, deutlich gemacht werden. Es ist ratsam, im Sinn des oben dargestellten Prinzips des Shared-Nothing einen gemeinsamen Status zwischen Komponenten zu verhindern, die gleichzeitig ausgeführt werden.

Darüber hinaus ist es aber auch im Hinblick auf die Erreichbarkeit entscheidend, den Status eines Moduls im Arbeitsspeicher so gering wie möglich zu halten. Wenn ein Knoten ausfällt, möchten Sie keine verlorenen Dateien haben. Auf der anderen Seite heißt das Festhalten des Zustandes, die Prozessgeschwindigkeit im Vergleich zu derjenigen, bei der die gesammelten Informationen im Arbeitsspeicher aufbewahrt werden, zu verlangsamen.

Hochverfügbarkeit ist ein wesentlicher Bestandteil von typischen Cloud-Anwendungen. Das Verlassen der Anwendung oder das Nichtbeachten des Fehlers ist bei der Anfrage nach Verwendbarkeit sowieso keine Möglichkeit. Doch egal für welche Taktik Sie sich entschieden haben, der Einsatz von fehlenden Cloud-Anwendungen hat eine ganz andere Bedeutung als klassische E-Business-Anwendungen.

Die Skalierung einer Applikation in der kürzestmöglichen Zeit, d.h. innerhalb von wenigen Augenblicken, ist ohne eine automatisierte Bereitstellung und einen autom. automat. starten der einzelnen Applikationsteile einfach nicht möglich. Darüber hinaus ist bei der Anwendungsgestaltung darauf zu achten, dass diese Belastungs- und Skalierungsprobleme beachtet und umgesetzt werden, da sie standardmäßig noch nicht in der für wirklich plastische Applikationen erforderlichen Weise verfügbar sind.

Hier sind noch verschiedene andere Grundsätze nicht aufgeführt, die aber auch beim Entwurf von Cloud-Anwendungen berücksichtigt werden müssen. Ein weiteres Problem, das bei der Entwicklung von Cloud-Anwendungen berücksichtigt werden muss, ist die Security. Inzwischen gibt es eine Fülle von Fachliteratur, aus der weitere Handlungsempfehlungen für die Gestaltung von elastischen und hochverfügbaren Cloud-Anwendungen abgeleitet werden können.

Fazit: Viele der in den letzten Jahren als selbstverständliche Architektur- und Gestaltungsprinzipien für Enterprise-Anwendungen müssen im Kontext von Cloud-Anwendungen neu betrachtet werden, da Cloud-Anwendungen oft sehr unterschiedliche, nicht funktionsbezogene Ansprüche haben als klassische Enterprise-Anwendungen. Dementsprechend können viele Aufgabenstellungen in der Cloud-Umgebung nicht mehr in der üblichen Weise auf die Infrastruktur-Komponenten und -Systeme übertragen werden.

Selbstverständlich sind die Produzenten inzwischen auf den Cloud Hype angesprungen und versprachen die vollständige Cloud-Fähigkeit ihrer Produkt. Ein Großteil der Lösungen eignet sich für die Unterstützung von Cloud-Anwendungen bis zu einer bestimmten Größe. Bei fast jeder Erweiterbarkeit stossen jedoch fast alle Produktelösungen an ihre Leistungsgrenzen. Oftmals gibt es nichts mehr zu tun, als die Applikation selbst zu gestalten und zu implementieren.

Dabei sind wir davon Ã?berzeugt, dass Cloud-Applikationen die Architektur und das Erscheinungsbild von Applikationen in den nÃ??chsten Jahren gestalten und Ã?ndern werden. Im Moment sind wir jedenfalls im Bereich der wirklich dehnbaren und höchstverfügbaren Cloud-Applikationen noch ganz am Beginn, und es wird aufregend sein zu sehen (oder mitzugestalten), wie sich das Topic in den nÃ??chsten Jahren entwickeln wird.

Auch interessant

Mehr zum Thema