Software plus Services (S+S)

S+S – wie funktioniert es ?

Das folgende Schaubild zeigt einen generischen Stack mit einer Strukturierung, die der Diskussion von Szenarien förderlich ist, indem sowohl alle Client Technologien aufgenommen wurden als auch das Hosting (im Sinne von Wie und Wo wird der Dienst bzw. die Software betrieben) in der untersten Ebene. Dazwischen finden sich die wichtigsten Infrastruktur Services genauso wie sehr unterschiedliche Blöcke im Applikationsbereich. Speziell relevant für Architekten ist außerdem die Tatsache, das sowohl technische Alternativen (u.a. Infrastructure, programmatic Access) als auch organisatorische (u.a. Hosting - unterste Ebene, Composition) berücksichtigt werden. Anhand dieser Grafik werden im Folgenden unterschiedliche Szenarien und ihre Auswirkungen bzw. die Aspekte von S+S (Build, Run, Consume, Monetize) konsistent diskutiert.

Zur Diskussion von Software plus Services ist es entscheidend, sein Augenmerk darauf zu richten, das die Geschäftsidee in der Regel Top-Down ansetzt, d.h. es wird z.B. eine Anforderung sein, mobile Endgeräte anzubinden, um Aussendienstmitarbeiter besser anzubinden. Die Geschäftsseite des Unternehmens wird hingegen nicht zuerst festschreiben, mit welchem Hostingmodell die IT die Lösung implementiert. S+S erlaubt nun die grosse Flexibilität, die Entscheidungen bzgl. des Wie bei der Implementierung auf die Randbedingungen der Geschäftsidee stärker abzustimmen als bisher, vgl. auch: Microsoft Plattform im Zeitalter von S+S Statt also die eigene IT als Fixum sehen zu müssen, da ein überschaubarer Wechsel zu einem Cloud-Hosting nicht angeboten wird, kann (in unserem Beispiel) ebenso Top-Down diskutiert werden, welche Architektur angemessen ist. Wir wollen im Folgenden ein solches Beispiel besprechen, verbunden mit konkreten Detail-Informationen, wie das Ansprechen eine SQL Server Data Services realisiert wird.

Beginnen wir mit einem der einfachsten Szenarios, bestehend aus einem Browser, über den auf statische Inhalte eines Webservers zugegriffen wird. Die Inhalte sind dabei im Dateisystem vor Ort abgelegt, Webserver, Datenspeicher und Browser liegen auf lokalen Systemen im Unternehmen.

In unserem Fall hat z.B. ein Informatik Student seine eigene Webseite implementiert, auf der er aktuelle Informationen für seine Mitstudenten anbietet und pflegt, wobei er den jeweils neuen Status direkt durch verändern der Inhalte lokal und anschließendem Reset des Webservers pragmatisch erreicht. Da er die Bedürfnisse seiner Kommilitonen gut kennt und engagiert an der Verbesserung aufgrund von Feedback arbeitet, wächst die Zahl der Besucher zu einem Ansturm, den er auf seinem eigenen PC und mit seiner Standard DSL Leitung (Upload !) nicht mehr bewältigen kann. Er denkt über einen Wechsel zum Hoster nach, möchte jedoch zuerst ein paar Fragen durchdenken: wie verändert sich die Architektur beim Wechsel zum Hoster Modell, also dem Auslagern des Webservers an einen Dienstleister?

Auch dort steht „physical dedicated“ in unserem Schaubild zur Verfügung, auch dort werden die statischen Inhalte aus dem Dateisystem (das jetzt wie die ganze (grüne) Infrastruktur beim Hoster steht) beliefert. Da der Zugriff über einen Browser erfolgt, ändert sich die Architektur nicht. Unser Student kann diese Änderung des Hosting Modells von on-Premise zu klassischem Hosting daher ohne grosse Aufwände realisieren.

Nach weiteren zwei Jahren ist aus dem Hobby-Angebot eine erfolgreiche werbefinanzierte Website geworden und unser Student entscheidet sich, inzwischen diplomiert, für den Aufbau seines eigenen Unternehmens auf dieser Grundlage. Er hat dazu ein Konzept entwickelt, wie mit rollenbasiertem Workflow individualisierte Webseiten für jeden Besucher entsprechend seiner Vorlieben angeboten werden können.

Der Jungunternehmer evaluiert für ein Cloud Hosting durch den Vendor (blau) Microsoft, da ihm Entwicklungsumgebung und Programmierplattform vertraut sind. Ursprünglich wollte er einfach beim klassischen Hoster bleiben, der natürlich auch die erhofften zukünftigen Wachstumsraten skalieren kann. Da er jedoch außerdem, bedingt durch die zahlreichen Profile, Informationen und insbesondere Metadaten wie Verknüpfungen und Tags vom starren Datei-basierten Speicherzugriff auf ein relationales Speichermodell wechseln will, müsste er bei seinem Hoster einen relativ teuren eigenen SQL Server dazu mieten.

Im Vendor (Cloud) Hosting nutzt er nun ebenfalls die SQL Schnittstelle, die SQL Server Data Services skalieren jedoch gemeinsam mit seinen Zugriffszahlen. Zudem hat er sich noch nicht zwischen REST und SOAP als Zugriffsmethode entschieden und würde gerne beides zuerst evaluieren.

Erste Schritte mit SQL Server Data Services (SSDS) - Teil 1: Registrierung und Grundlagen

Erste Schritte mit SQL Server Data Services (SSDS) - Teil 2.1: Zugriff auf SSDS mittels SOAP (Anlegen einer Authority)

Erste Schritte mit SQL Server Data Services (SSDS) - Teil 2.2: Zugriff auf SSDS mittels SOAP (Anlegen und Bearbeiten von Containern und Entitys)

Die Weiterführung dieses Gedankens finden Sie im Whitepaper‚ Alternative Betriebsmodelle für Webanwendungen: XPS | PDF