Liebe Leser,
ich war vor kurzem auf einem abendlichen Microsoft Architect Forum Event in Wien. Die Themen lauteten „Windows Azure Update“ und „Der Architekt im Zeitalter von Cloud Computing“. Zu Beginn wurden einige neue – durchaus sehr interessant wirkende – Features von Windows Azure vorgestellt. Darüber hinaus fand eine sehr spannende Podiumsdiskussion von ehemaligen und aktuellen Microsoft Architekt-Evangelisten statt. Im Rahmen der Diskussion wurden einige sehr spannende Ansichten kundgetan, welche mich durchaus zum Nachdenken angeregt haben. Im Folgenden möchte ich einige Quintessenzen wiedergeben, welche ich aufgenommen bzw. für mich gebildet habe.
Kostenbetrachtung
Im Gegensatz zu Architekturen der vergangenen Jahre ist gerade in Verbindung mit Cloud Computing ein KPI (Key Performance Indicator) besonders wichtig geworden. Dabei handelt es sich um den sogenannten TCO (Total Cost of Ownership). Dieser Wert beschreibt im konkreten Kontext die Kosten, welche gesamtheitlich betrachtet in Verbindung mit einer vorliegenden Architektur entstehen. Bei herkömmlichen Lösungen lässt sich dieser sehr schwer fassen bzw. beziffern. Durch Cloud Computing und der damit einhergehenden pay-per-use Philosophie entsteht eine Kostentransparenz, welche die Kosten wieder in einen zentralen Blickwinkel rückt und uns Architekten dadurch zur Konzeption einer kosteneffizienten Gesamtlösung zwingt. Schöne Architektur über alles und um jeden Preis ist damit passé.
Business Value
Der oberste Wert, an dem sich ein Architekt orentieren sollte, ist der Business Value, der hinter einer umzusetzenden Lösung steckt. Architekten sind heutzutage mehr denn je dazu angehalten, dass das Systemdesign und die Systemarchitektur nach den Grundsätzen des BCM (Business Capability Management) ausgerichtet und dem konkreten Geschäftszweck und –wert angepasst sind. Die IT als Selbstzweck war seit jeher eine schlechte Idee. Im Hinblick auf Business Value und Kostentransparenz muss die IT an das vorliegende Geschäft angepasst werden und sollte darüber hinaus sogar in vielen Fällen als Business Enabler dienen. Dies bedeutet natürlich auch, dass nicht immer die perfekte Lösung gefragt ist, sondern vielmehr die auf das jeweilige Geschäft (und die damit verbundenen Anforderungen) am besten passende. Die Rolle des Architekten in diesen Zeiten beinhaltet deshalb noch stärker denn je die Aufgabe der Brückenbildung zwischen Fachbereich(en) und IT um gerade die Kundenbedürfnisse genau zu erfassen und danach zu handeln.
Systemgrenzen / Systemdesign
Die Architektur von zukünftigen nachhaltigen Cloud-Lösungen kann mehrere grundsätzliche Ausprägungen annehmen. Die aktuell am erfolgversprechendste und auch mit der geringsten Einstiegshürde für Kunden verbundene ist vermutlich jene einer Hybrid-Cloud. Dabei werden Teile der Services bzw. Daten in der Cloud und andere on-premise gehostet. Die beiden Ufer werden durch die Cloudanbieter-Infrastruktur wie beispielsweise den Windows Azure AppFabric ServiceBus miteinander verbunden. Daraus resultiert natürlich eine essenzielle und entscheidende Herausforderung für den Architekten: er muss eine intelligente Serviceisolierung und die dazugehörigen Servicegranularitäten festlegen. Diese Aufgabe ist unter anderem stark von den jeweils vorherrschenden Governance- und Compliencebestimmungen eines Unternehmens oder gar eines Landes abhängig.
Versionierung
Ein nicht zu vernachlässigendes Thema in Bezug auf Serviceorientierung – und nichts anderes ist eine cloudbasierte Lösung in der Regel – ist Serviceversionierung. Überlegungen hierzu existieren bereits seit längerem und besonders durch das Aufkommen von SOA (Service Oriented Architecture) wurden diese vakant. Ein möglicher Ansatz, welcher mir ganz gut gefällt, ist die Lösung der Versionierungsproblematik auf organisatorischer Ebene. Hierbei werden für alle Servicebetreiber und Servicekonsumenten geltende Policies in Bezug auf Lebensdauer und Servicegenerationen festgelegt. Der Einsatz von Servicefassaden für alle in Betrieb befindlichen Generationen ist ebenfalls verpflichtend. Solche Policies findet man nicht nur unternehmensintern, sondern auch bei großen Anbietern von unternehmensübergreifenden oder öffentlichen Services, wie diese zum Beispiel von Amazon angeboten werden.
Stateless Behaviour
Ein weiteres Faktum bei der Erstellung einer Architektur unter der Verwendung von Cloud-Technologie ist, dass Services in der Cloud stateless sein müssen! Mit Hilfe von Queues und persistenten Storagemöglichkeiten (wie SQL Azure, Table Storage oder Blob Storage) können Services natürlich (laufend) Informationen über deren State ablegen, welche dann im Falle eines Serviceausfalles bzw. Neustart des Services (auf irgendeiner virtuellen Instanz) wieder ausgelesen werden können. Diese Logik ist jedoch ebenfalls von Anfang an vorzusehen und aktuell auch selbst zu implementieren.
Fazit
Im Hinblick auf oben genannte Punkte und natürlich darüber hinaus bin ich mir sicher, dass Architekten aktuell und in unmittelbar bevorstehender Zukunft vor neuen spannenden Herausforderungen gestellt sind. So wie sich die IT in einem ständigen Wandel befindet, so trifft dies auch auf die Handlungsweisen und Aufgaben eines Architekten zu. Wir befinden uns in einer spannenden Zeit und es ist an uns, diese mitzugestalten.
Euer
JL@coopXarch
Keine Kommentare:
Kommentar veröffentlichen