Inhaltsverzeichnis Kapitel Titel

Transkript

1 ÜR ÖCK ÄNNER 2015

2 Inhaltsverzeichnis Kapitel Titel 1 Microsoft Azure, der Einstieg in die Cloud 2 Azure Webseiten 3 Azure SQL 4 Azure Storage 5 Azure Virtuelle Maschinen 6 Azure mit der Powershell 7 Visual Studio Online 8 Beispielprojekt

3 Hamboeck / Azure für Entwickler Über dieses Buch Der Einstieg in Microsoft Azure ist aufgrund der vielen angebotenen Dienste nicht ganz einfach. Dieses Buch soll Abhilfe schaffen. Der erste Teil dieses Buches richtet sich an Entwickler, oder Teamleiter, die einen Einsteig in die Microsoft Cloud Plattform wagen wollen. In acht Kapiteln werden dem Leser schrittweise verschiedene Dienste in der Cloud näher gebracht, bis ein abschließendes Projekt eine mögliche Anwendung implementiert.

4 Hamboeck / Azure für Entwickler Über den Autor Berndt Hamböck ist leidenschaftlicher.net Softwareentwickler. Seine Schwerpunkte liegen auf der Microsoft Azure Plattform, sowie der mobilen Entwicklung mit Xamarin. Des Weiteren ist er fasziniert von den SQL Server Business Intelligence Server und Tools, und dem Bereich Big Data mit Machine Learning. Die Spiele-Entwicklung mit Unity und Visual Studio ist da ein spannendes Freizeitvergnügen, für das Ihm allerdings selten Zeit bleibt. "Die Microsoft Azure Plattform ist eine faszinierende Möglichkeit neue Technologine zu testen und diese hochverfügbar zu vernünftigen Preisen der ganzen Welt zur Verfügung zu stellen" Berndt Hamböck Autor Bei Fragen, oder Anregungen zu dem Buch schreiben Sie einfach eine an: hamboeck@soft-dat.com Falls Sie dem Autor auf Twitter folgen möchten dann ist auch das

5 Hamboeck / Azure für Entwickler 1 1 Microsoft Azure, der Einstieg in die Cloud In diesem Kapitel werden die Vorteile einer Cloud Lösung beschrieben. werden die Vorbehalte für einen möglichen Cloud-Einstieg beschrieben. wird erklärt, wo sich die Microsoft Cloud befindet. werden die Fülle vorhandener Dienste aufgeführt. wird der eigene Azure-Account angelegt. Für einen Techniker ist es in der heutigen Zeit - der auch noch sein eigenes Tagesgeschäft zu betreuen hat - sehr schwer jede Technologie die interessant erscheint - selbst auszuprobieren. Man weicht also auf Magazine, Blog-Einträge, Twitter Feeds und Release Notes aus um sich ein erstes Bild zu machen. Da ist es dann umso verständlicher, wenn man durch diverse Presseartikel der Cloud ein wenig skeptisch gegenüber steht und vielleicht auch den eigenen Einstieg in die Cloud dann erst einmal auf unbestimmte Zeit verschiebt. Das ist meiner Meinung nach sehr schade, denn Microsoft gibt sich auf diesem Gebiet sehr viel Mühe und hat in diesem Bereich in den letzten Jahren wirklich sehr viel Arbeit, Zeit und Geld investiert. Wir als (mögliche) Anwender der Cloud können hier profitieren und sollten dies auch. In diesem Kapitel sehen wir uns mögliche Vorteile einer Cloud-Lösung an und werden auch einen kostenlosen 30-Tage Account anlegen. Frei nach dem Motto: Ausprobieren kostet ja erst einmal nichts.

6 2 Hamboeck / Azure für Entwickler 1.1 Was ist die Cloud? Dafür lassen sich bestimmt viele Definitionen finden, aber für Entwickler für die dieses Buch geschrieben wurde bedeutet es, dass sich Anwendungen und Daten nicht mehr auf dem lokalen Rechner, sondern auf fremden Servern, in einem, oder mehreren Datacenter befinden. Der Cloud-Betreiber stellt in diesen Datacenter verschiedene Dienste zur Verfügung. Applikationen und Daten nutzen diese verschiedenen Dienste, dabei gelangt nur zur Abrechnung, was im Abrechnungszeitraum auch tatsächlich verwendet wurde. Die Dienste stehen bei Bedarf weltweit zur Verfügung und können auf Wunsch entsprechend (hoch-) skaliert werden. 1.2 Was ist Azure? Microsoft Azure ist die Cloud-Lösung von Microsoft. Microsoft kündigte im Jahr 2008 erstmals eine eigene Cloud-Lösung an: ursprünglich mit dem Namen Windows Cloud, danach unter Windows Azure, seit 2014 mit dem Namen Microsoft Azure. Microsoft setzt mit Azure neue Maßstäbe, wenn es um die Möglichkeiten für Infrastrukturlösungen geht oder was Lösungen für das Entwickler-Team anbelangt. Azure stellt einzelne Dienste zur Verfügung und es kommen laufend neue Dienste hinzu: alleine auf der TechEd 2014 Europe in Barcelona wurden in der Keynote sechs weitere davon präsentiert. 1.3 Vorteile einer Cloud Lösung Ich denke, daß ein (teilweiser) Umstieg auf eine Cloud-basierte Lösung in einem Unternehmen fünf Vorteile mit sich bringen kann: 1. Es wird nur bezahlt, was auch tatsächlich an Leistung beansprucht und verwendet wird. 2. Es fallen monatliche, (weitgehend) berechenbare Kosten an. 3. Die Definition von Standard Systemen wird gefördert. 4. Ein vereinfachtes und schnelleres Deloyment zu Endanwendern wird unterstützt. 5. Man benötigt weniger In-House Techniker. Zu den Kosten möchte ich etwas später noch in diesem Kapitel kommen, die anderen Vorteile sollten in den nachfolgenden Kapiteln deutlich herausgearbeitet werden. Trotz dieser unbestreitbaren Vorteile, sind natürlich auch Gegenargumente zu erwarten, wenn von dem Wunsch einer firmenübergreifenden Cloud-Lösung die Rede ist. 1.4 Vorbehalte gegen eine Cloud Lösung Ich sehe den Vorgesetzten förmlich vor mir, wenn Sie ihm einen Einstieg einer Cloud- Lösung vorschlagen. Den Vortrag, den Sie sich möglicherweise anhören dürfen, wo denn die Daten überall auftauchen würden, was das denn nur wieder kosten würde, und überhaupt, wie man auf so eine Schnapsidee kommen kann.

7 Hamboeck / Azure für Entwickler 3 Abbildung 1.1: Viele Vorbehalte existieren, die einem Einstieg in die Cloud entgegenstehen. Neben all den - teilweise auch leider unsachlichen - Presseartikeln bestehen natürlich manche Ängste durchaus zu Recht, und sollten natürlich auch angesprochen und diskutiert werden, bevor ein etwaiger Einstieg in die Cloud erfolgen kann. Das sind Punkte, wie etwa: Security wo, und wie sicher sind meine Daten? Kontrolle habe ich diese weiterhin über meine Daten? Kosten habe ich hier die volle Kostenkontrolle? Diesen Themen sollten wir uns eingehender widmen, bevor wir ein mögliches Einstiegszenario für Entwickler - in Microsoft Azure andenken. 1.5 Security wo, und wie sicher sind meine Daten? Microsoft speichert alle Daten, die sie bereit sind in der Cloud abzulegen, in sogenannten Azure-Regionen, wo sich die Datacenter befinden. Derzeit gibt es davon weltweit über 100 dieser Datacenter in 17 Regionen. Microsoft selbst nutzt diese für ihr eigenes Angebot an Cloud-Diensten. Davon gibt es mittlerweile mehr als 200, einige davon sind uns wohlbekannt, wie Bing, MSN, Outlook.com, Office 365, OneDrive, Skype, Xbox Live und eben die gesamte Microsoft Azure Plattform.

8 4 Hamboeck / Azure für Entwickler Abbildung 1.2: Alle Azure Regionen weltweit auf einen Blick. Zur Zeit (Dezember 2014), verwenden mehr als 1 Milliarde Anwender und 20 Millionen Microsoft-Kunden diese Dienste. Um die Erhaltung dieser Dienste kümmert sich das Microsoft Cloud Infrastructure & Operations (MCIO) Team. Seit der Eröffnung des ersten Datacenter im Jahr 1989 mittlerweile gibt es mehr als 100 davon ca. $15 Milliarden wurden in die Infrastruktur investiert, und wenn man den Focus in Betracht zieht, den die Azure Plattform für Microsoft hat, dann ist kein Ende der Investitionen abzusehen. Die Sicherheit der Daten garantiert Microsoft auf verschiedene Art und Weise. Das beginnt mit physischen Kontrollen, wie Videoüberwachung, Ausweiskontrollen und Fingerabdrucksensoren in den Datacenter. Von den anwesenden Security-Diensten ganz zu schweigen. Ausgemusterte Festplatten, die geheime Daten beinhalten, werden ausnahmslos vernichtet. Bleibt immer noch der Zugriff auf die Daten über das Internet selbst. Hier setzt Microsoft verschiedene Mechanismen ein, um sich zu schützen, lässt aber auch externe Prüfer in die Datacenter, die Überprüfungen durchführen und z. B. folgende Zertifizierungen vergeben:

9 Hamboeck / Azure für Entwickler 5 Tabelle 1.1 Azure Datacenter Zertifizierungen Zertifizierung ISO/IEC 27001:2005 SOC 1 and SOC 2 SSAE 16/ISAE 3402 Cloud Security Alliance Cloud Controls Matrix Federal Risk and Authorization Management Program (FedRAMP)/ Federal Information Security Management Act (FISMA) Payment Card Industry (PCI) Data Security Standards (DSS) Level Kontrolle habe ich diese weiterhin über meine Daten? Möglicherweise ist es firmenintern nicht einfach zu vertreten, wenn die eigenen Daten das eigene Rechenzentrum verlassen sollen und quasi an den Cloud-Anbieter übergeben werden sollen. Auch aus rechtlicher Sicht kann dies zu Problemen führen, da die Daten z. B. die EU nicht verlassen dürfen. Glücklicherweise kann der Ablageort der eigenen Daten definiert werden. Dass die Daten in einer der 17 Azure Regionen gespeichert werden, das ist soweit einmal klar, aber in welcher dieser Regionen, bzw. in welchem Datacenter? Nun, die Wahl des Speicherortes liegt in erster Linie einmal bei uns selbst, da für die Azure Dienste während des Anlegens die Region anzugeben, bzw. auszuwählen ist. Der Ort kann durch Vorgaben definiert sein (Stichwort EU), oder beispielsweise auch durch die Lokation der Anwender vorgegeben sein die Daten sollten aus Performance-Gründen möglichst nahe bei den Anwendern gespeichert sein. Oder verschiedene Dienste, die zusammenarbeiten (Stichwort: geringer Network-Traffic) wie z.b. Azure Webseiten und Azure SQL sollten sich per Definition möglichst im gleichen Datacenter befinden. Die Azure-Region und die zugehörigen Orte sind in Tabelle 1.2 zu sehen, die Auswahl erfolgt wie gesagt nach eigenen Kriterien. Tabelle 1.2 Azure Datacenter nach Region Azure Region Central US Ort Iowa

10 6 Hamboeck / Azure für Entwickler East US East US 2 US Gov Iowa US Gov Virginia North Central US South Central US West US Virginia Virginia Iowa Virginia Illinois Texas California North Europe West Europe Ireland Netherlands East Asia Southeast Asia Hong Kong Singapore Japan East Japan West Saitama Prefecture Osaka Prefecture Brazil South Sao Paulo State Australia East Australia Southeast New South Wales Victoria Jetzt sind uns die Orte bekannt, aber ist es immer eine gute Lösung, wenn die Daten nur an einer einzigen Stelle gelagert werden? Was würde im Falle eines Desasters im Datacenter in Irland passieren? Natürlich wären diese im SCHLIMMSTEN Fall verloren, aber wir als Azure-Dienst-Anwender können hier einiges dagegen tun - das bedeutet aber nicht nur Backups der Daten anzulegen (schaden wird es dennoch niemals). Wir können uns nämlich auch dafür entscheiden, wie unsere Daten und in welche Regionen unsere Daten repliziert werden. Wir sehen das später im Kapitel über den Azure Storage.

11 Hamboeck / Azure für Entwickler 7 Wir wissen also, wo unsere Daten gespeichert sind, bzw. wo die Maschinen tatsächlich physikalisch existieren (wenn die genauen Orte auch ein kleines Geheimnis von Microsoft sind). Wichtig ist für uns, dass wir jederzeit auf unsere (virtuellen) Maschinen und unsere Daten zugreifen können. Und das ist 24h x 7 Tage lang gegeben. Wir können über das Azure Management Portal jederzeit unsere Dienste einsehen, anlegen, bearbeiten, oder auch löschen. Auch eigene Lösungen können mit den Azure Management APIs entwickelt werden, wie wir ebenfalls in einem eigenen Kapitel sehen werden. 1.7 Kosten habe ich hier die volle Kostenkontrolle? Zuerst einmal kann gesagt werden, dass sowohl der Start mit Microsoft Azure kostenlos ist, als auch das Beenden des Accounts und der zugehörigen Abonnements nichts kostet. Für einen Azure Account können mehrere Abonnements angelegt werden, z. B. eines über eine bestehende MSDN Subscription, worüber dann einige Dienste abgerechnet werden sollen (um die MSDN-Gutschrift aufzubrauchen), ein weiteres Abonnement, über welches Kosten über eine bestimmte Kreditkarte abgerechnet werden, usw. Alles was nun zwischen dem Anmelden und der Abmeldung passiert kostet möglicherweise Geld. Wieviel? Nun, das hängt von folgenden Faktoren ab: Der Anzahl der genutzten Diensten Möglicherweise von der Region des genutzten Dienstes Der Dauer der Nutzung des Dienstes im Monat Wichtig ist an dieser Stelle, es wird nur verrechnet, was auch verbraucht wurde, bei den meisten Services ist das auf die Minute genau (und nicht automatisch z. B. ein ganzer Monat), bzw. der tatsächliche (von Azure ausgehende) Datenverkehr. Vorberechnen und überprüfen lassen sich die Kosten im Preisrechner, dieser ist hier zu finden: Abbildung 1.3: Kategorien des Kostenrechners

12 8 Hamboeck / Azure für Entwickler Der Preisrechner unterteilt die Dienste in fünf verschiedene Kategorien und es lässt sich ein was-wäre-wenn Szenario auf einfachste Weise sofort online durchspielen. Falls z. B. eine SQL-Server Web-Edition benötigt wird, auf den keine allzu großen Herausforderungen zukommen werden, dann reicht vermutlich eine Maschine mit 1 Core, 3.5 GB Ram und 10GB SSD-Speicherplatz. Dieser kommt auf im Monat falls dieser 24h x 7 Tage zur Verfügung steht. Abbildung 1.4: Beispiel des Kostenrechners Sobald ein Azure Account aktiviert wurde (und somit auch ein Abonnement angelegt wurde), und Dienste in Verwendung sind, sind die aktuell anfallenden Kosten jederzeit online einsehbar. Die verbrauchte Datenmenge, oder Rechenzeit ist aufgelistet und das gesamte Guthaben, bzw. der anfallende Rechnungsbetrag aufgelistet, diese Details ist jederzeit abrufbar unter:

13 Hamboeck / Azure für Entwickler 9 Abbildung 1.5: Aktuelle Kosten im Blick. Des Weiteren ist es möglich eine Abrechnungsbenachrichtigung einzurichten, um per E- Mail informiert zu werden, sobald eine festgelegte Summe überschritten wird. Es kann dann

14 10 Hamboeck / Azure für Entwickler dementsprechend reagiert werden, indem Dienste (z. B. virtuelle Maschinen) beendet werden, oder der Ressourcen-Verbrauch reduziert wird (z. b. Speicherplatz, Redundanzen). Wie man somit sehen kann, komplette Kostenkontrolle, jederzeit und überall, ich denke das klingt so verlockend, dass man es direkt einmal ausprobieren sollte. 1.8 Der eigene Azure Account über MSDN Sollte ein MSDN-Abonnement vorhanden sein, dann lohnt sich die Anmeldung, bzw. das Anlegen eines Azure Abonnements über das MSDN Portal, da hier jedes Monat Gutschriften zum Verbrauch von Azure Services zur Verfügung stehen. Die Höhe hängt von der Art der MSDN Subscription ab. Nachfolgend sind die aktuellen Guthaben (Stand Dezember 2014) für die jeweilige MSDN-Subscription aufgelistet inklusive einer etwaigen Anwendungsmöglichkeit für die Premium-Edition. Abbildung 1.6: MSDN-Credits Diese Guthaben reichen auch für einen längeren Zeitraum, da beim MSDN-Abonnement auch reduzierte Stundensätze inkludiert sind. Es wird ein Rabatt in Höhe von 33% auf virtuelle Windows-Computer und ein Rabatt in Höhe von 25% auf Cloud-Dienste, HDInsight und Webseiten gewährt. Des Weiteren kann die vom MSDN-Abonnement abgedeckte Software zu Entwicklungs- und Testzwecken ohne weitere Kosten unter Azure, z. B. für virtuelle Maschinen genutzt, werden. Um ein Abonnement mit den Azure Benefits anzulegen, muss man sich im MSDN Portal anmelden und über die Management Seite

15 Hamboeck / Azure für Entwickler 11 den Link für das Aktivieren von Microsoft Azure verwenden. Abbildung 1.7: Aktivieren der MSDN-Benefits Sollte noch kein Azure Account bestehen, dann ähneln sich die Schritte wie im nächsten Abschnitt beschrieben. Falls schon ein Azure Account vorhanden ist können die MSDN- Benefits ebenfalls genutzt werden, da es ja kein Problem ist, mehrere Abonnements anzulegen. 1.9 Der eigene Azure Account als Trial Um in die Microsoft Azure Plattform einzusteigen, benötigt man einen Azure Account. Diesen kann man einmalig pro Microsoft Account für 30 Tage kostenlos verwenden, bzw. für Testzwecke einsetzen. Um diesen Testzugang anzulegen, benötigt man einen Browser seiner Wahl und schon kann es los gehen unter:

16 12 Hamboeck / Azure für Entwickler Abbildung 1.8: Azure Startseite Durch den Klick auf den Link rechts oben, bzw. unten in der Mitte kann es auch schon fast losgehen mit der kostenlosen Testversion, zuvor sehen wir noch, was uns diese Testversion bietet. Abbildung 1.9: Features der Azure Testversion

17 Hamboeck / Azure für Entwickler 13 Es ist deutlich zu erkennen, dass wir 1 Monat Zeit haben, um insgesamt bis zu 150,-- an Azure-Diensten (in dieser Zeit) zu nutzen. Im nächsten Schritt werden wir aufgefordert uns mit einem Microsoft-Konto (welches noch niemals einen Azure-Testaccount verwendet hat da ansonsten dieses Angebot nicht genutzt werden kann) anzumelden. Abbildung 1.10: Anmelden mit dem Microsoft-Konto. Nun folgen noch vier Schritte, um in den Genuss des Test-Abonnements zu kommen: Eingabe der persönlichen Informationen (diese werden aus dem Microsoft-Konto übernommen) Eingabe einer Mobilfunknummer (auf diese wird umgehend eine SMS mit einem Verifizierungscode gesendet) Eingabe der Kreditkarteninformationen (diese werden aber nicht zur Verrechnung verwendet, sondern zur (zusätzlichen) Feststellung der Identität benötigt) Einverständniserklärung

18 14 Hamboeck / Azure für Entwickler Abbildung 1.11: 4 Schritte zur Registrierung Nach Eingabe der Informationen folgt die Zusammenfassung und durch Drücken des Kaufen -Buttons wird das Azure Test-Abonnement gestartet. Gekauft wird nicht wirklich etwas, da keinerlei Kosten anfallen können. Wird das Guthaben verbraucht, werden die Azure Services gestoppt. Die Kreditkarte wird zu keinem Zeitpunkt belastet.

19 Hamboeck / Azure für Entwickler 15 Abbildung 1.12: Erstellen des Abonnements Das Azure Abonnement wird erstellt und nach erfolgter Aktivierung erfolgt die Weiterleitung zur Seite: Jetzt erhält man die Möglichkeit, den Azure Account vollständig zu aktivieren, das bedeutet, dass bei weiterer Nutzung über den Testzeitraum hinaus, bzw. nach Verbrauch des Guthabens, monatliche Kosten anfallen. Es besteht keinerlei Zwang dies an dieser Stelle zu tun, die Default-Einstellungen sind in Ordnung, es muss nichts angepasst werden, wenn Azure nur mit dem Guthaben für 30 Tage getestet werden möchte. Abbildung 1.13: Test-Abonnement Aktivierungs-Information

20 16 Hamboeck / Azure für Entwickler Jetzt ist der Blick frei für den aktuellen Kontostand des Azure Abonnements. 30 Tage und 150 stehen zur Verfügung und warten darauf verwendet zu werden. Abbildung 1.14: Übersicht Test-Abonnement Nach dem Ablauf der 30 Tage, bzw. nach dem Verbrauch der 150 was früher eintritt - werden die Dienste gestoppt. Nach Ablauf der 30 Tage ist das Abonnment inaktiv (abgelaufen), es kann aber wieder aktiviert werden, dann sind allerdings auch die monatlichen Kosten für die anfallenden Dienste zu tragen. Optional kann auch ein neues Abonnement angelegt werden und Azure Dienste in dieses neue Abonnement übernommen werden. Rechts oben befindet sich der Link zum Azure Portal, in dieses kann nun gewechselt werden, um Azure Dienste anzulegen Das Management Portal Nachdem der Test-Account angelegt wurde wird man zum Azure Management-Portal unter der URL weitergeleitet. Da ja alle Dienste nicht mehr vor Ort in einem, oder mehreren Datacenter von unserem aktuellen Standort liegen, ist

21 Hamboeck / Azure für Entwickler 17 ein gutes Online-Verwaltungstool für den Cloud-Anwender essentiell. Dieses Verwaltungstool nennt man das Azure Management Portal. Beim erstmaligen Einstieg wird man mit einem Wizard begrüßt. Abbildung 1.15: Einführungs-Wizard für das Azure Management Portal Dieser Wizard stellt auf vier Seiten die wichtigsten Schritte zur Bearbeitung der Azure Dienste vor. Der erste Schritt zeigt beispielsweise, wie man zur Abmeldung, oder zur aktuellen Rechnungsübersicht gelangt.

22 18 Hamboeck / Azure für Entwickler Abbildung 1.16: Demo Hauptmenü Das Erstellen eines neuen Azure Services wird im nächsten Schritt erläutert. Abbildung 1.17: Demo Neu erstellen für ein Service Danach wird die Befehlsleiste vorgestellt, diese befindet sich immer am unteren Bildschirmrand und passt sich dem aktuell gewählten Azure Service an.

23 Hamboeck / Azure für Entwickler 19 Abbildung 1.18: Demo Befehle für ein Azure Service Hin und wieder gibt es Benachrichgungen in der Befehlsleiste zu sehen. Dies können Warnungen sein, wie etwa ablaufende Test-Accouts, oder aktuelle Fehler, wenn etwas einmal nicht klappen sollte, wie man sich das vorstellt, z. B. das Anlegen eines Azure Services. Abbildung 1.19: Demo Benachrichtigungen Nachdem der Wizard beendet wurde, erscheint das Portal so, wie man es bei jedem weiteren Einstieg zu Gesicht bekommt. Auf der linken Seite ist der Bereich ALLE ELEMENTE angewählt und in der Mitte sind diese Elemente aufgelistet. Es befindet sich zumindest ein Element in dieser Auflistung, das Standardverzeichnis (Azure Active Directory).

24 20 Hamboeck / Azure für Entwickler Abbildung 1.20: Azure Portal Dieses kann man durch Anklicken des kleinen Pfeils Details dieses Azure Services. anwählen und gelangt so zu den Abbildung 1.21: Details des Active Directory Services Man gelangt wieder zurück zu der Übersichtsseite durch Drücken des großen Zurück- Buttons in der linken oberen Ecke. Abbildung 1.22: Navigation zur Übersichtsseite Diese Art der Navigation ist für alle zur Verfügung gestellten Azure Services gleich. Was uns noch fehlt ist die Anwahl eines einzelnen Bereiches auf der linken Seite, um ein neues Azure Service anzulegen. Bereiche gibt es einige zu entdecken, diese werden auch regelmäßig erweitert und nachfolgend ist der aktuelle Stand von Dezember 2014 aufgeführt.

25 Hamboeck / Azure für Entwickler Azure Dienste Die Fülle an Azure-Diensten ist mittlerweile nahezu überwältigend und es fällt einem relativ schwer hier noch Schritt zu halten, so schnell werden neuen Dienste zur Verfügung gestellt, bzw. bestehende Dienste erweitert. Microsoft unterscheidet 4 verschiedene Kategorien, um die Azure Dienste einzugliedern: Compute, bzw. Server Data-Services App Services und Netwerkdienste Nachfolgend eine Aufstellung der verfügbaren Dienste, je nach Kategorie. Diese sind, wie bereits erwähnt, eben eine ganze Menge an Diensten, ich werde in den nächsten Kapiteln einige davon herausgreifen (diese sind in der Tabelle fett dargestellt) und diese näher beschreiben. Da dieses Buch eher auf die Entwickler-Gemeinde abzielt sind dies natürlich die Dienste, die für diese Zielgruppe relevant sein könnten. Alle anderen Dienste finden eine kurze Erwähnung, bzw. Erläuterung.

26 22 Hamboeck / Azure für Entwickler Tabelle 1.3 Azure Dienste nach Region Azure Dienste (Dezember 2014) COMPUTE Websites Virtual Machines Mobile Services Cloud Services Batch DATA SERVICES SQL Database Storage HDInsight Managed Cache Backup Redis Cache Site Recovery StorSimple Machine Learning DocumentDB Azure Search APP SERVICES BizTalk Services Active Directory Service Bus Media Services Notification Hubs Multi-Factor Authentication Scheduler Visual Studio Online CDN Automation RemoteApp API Management Event Hubs NETZWERK Dienste Virtual Network Traffic Manager ExpressRoute Data Factory Stream Analytics

27 Hamboeck / Azure für Entwickler Zusammenfassung Dieses Kapitel widmete sich Überlegungen, die für einen bzw. gegen einen möglichen Cloud- Einstieg stehen. Die Microsoft Cloud-Lösung befindet sich physisch in einer der 17 Azure- Regionen mit den zugehörigen Orten. Es wird mittlerweile eine Fülle von Diensten angeboten, es sollte also für nahezu jede Anwenderschicht etwas Passendes zu finden sein. Die Azure-Cloud ist nicht gänzlich kostenlos, die Dienste verursachen monatliche Kosten, es wird allerdings nur das abgerechnet, was auch verbraucht wurde, dies zumeist minutengenau. Der Anwender behält die volle Kontrolle über die Kosten und diese werden auch jederzeit transparent dargestellt und sind jederzeit einsehbar. Der eigene Azure Account ist schnell angelegt, mit einer MSDN-Subscription sind monatliche Benefizien verbunden, die auch genutzt werden sollten, da diese sonst verfallen. Ein 30-tägiges Test- Abonnement kann einmalig für einen Microsoft-Account verwendet werden, mit diesem stehen sofort 150,-- während der Testzeit zur Verwendung verschiedener Azure-Dienste zur Verfügung. Ich kann nur sagen: Microsoft Azure, wir kommen! Ich bin mir ziemlich sicher, dass wir, einmal dabei, immer auf die Cloud zurückgreifen werden. Im nächsten Kapitel werden wir unseren ersten Azure Dienst nutzen, die Azure Webseiten.

28 24 Hamboeck / Azure für Entwickler 2 Azure Webseiten In diesem Kapitel werden die Vorteile von Azure Webseiten erläutert werden zwei eigene Webseiten angelegt verschiedene Deployment-Varianten beschrieben Skalierungsmöglichkeiten dargestellt Staging-Slots und Swaps verwenden die Kosten für Azure-Webseiten ermittelt Den sanftesten Einstieg in die Cloud-Entwicklung bieten mit Sicherheit die Azure Webseiten. Diese sind, wie wir sehen werden, einfach zu konfigurieren und einfach zu deployen und bieten den Vorteil, dass sich Entwickler nur noch um die Software zu kümmern haben, aber nicht unbedingt um die physische Umgebung in der die Web-Applikation läuft. Azure Webseiten dienen dazu, Web-Seiten oder aber auch komplette Web-Applikationen in Azure zur Verfügung zu stellen. Es ist ein einzelner Dienst, der aber bei Bedarf mit weiteren Azure Diensten wie z. B. Datenbanken, Active Directory, Office365, oder Messaging - kombiniert werden kann. Azure Webseiten stellt also eine Plattform für die eigene Webseite, oder Web-Applikation zur Verfügung, beschränkt den Entwickler aber keineswegs, denn es können auch Nicht-Microsoft-Dienste angebunden werden, wie Twitter oder DropBox.

29 Hamboeck / Azure für Entwickler Warum Azure Webseiten? Bisher waren wir als Entwickler gewohnt, eine Webseite bzw. eine ASP.Net Web-Applikation in Visual Studio zu erstellen und diese dann in einen IIS zu deployen. Das Infrastruktur- Team stellte zumindest zwei Server zur Verfügung einen für den Testbetrieb und einen für den produktiven Betrieb. Wenn etwas im Betrieb nun nicht funktionierte, war entweder der Fehler beim Entwickler zu suchen (die Web-Applikation funktioniert nicht entsprechend), oder bei der Hardware, dem Netzwerk, dem Betriebssystem, der Installation, bzw. Konfiguration des IIS auf dem Server wobei hier meist das Infrastruktur-Team bei der Behebung des Problems mithalf. Die volle Verantwortung liegt also so lange bei der eigenen Mannschaft, so lange die Web-Applikation im eigenen Datacenter liegt, wie Abbildung 1 ganz links darstellt. Abbildung 3.1: Webseiten im eigenen Datacenter, oder unter Windows Azure. Dies kann nun schrittweise vereinfacht werden, bis hin zu den Azure Webseiten, wo sich Microsoft um alles, wirklich alles, außer der Web-Applikation selbst kümmert. Das bedeutet nicht nur, dass Updates/Security Fixes automatisch eingespielt werden, sondern auch, dass die Web-Applikation unter Last automatisch skaliert sei es durch Load-Balancer, mit stärkeren Maschinen bei Last, oder Geo-Redundanzen der Webseite. Dazwischen gibt es noch als Optionen weitere Abstufungen, wie die eigene virtuelle Maschine, oder Web- Applikationen, die sich in das Corporate-Network als Intranet-Anwendungen einfügen lassen. Die Idee hinter den Azure Webseiten ist, erst einmal mit der eigenen Webseite oder Web- Applikation einfach loslegen zu können, diese jederzeit nach den eigenen Wünschen

30 26 Hamboeck / Azure für Entwickler skalieren zu lassen, ohne sich um die Beschaffung und Inbetriebnahme der Infrastruktur zu kümmern. Entwickelt werden kann mit jeder beliebigen Programmiersprache, sei es ASP.Net, PHP, oder Node.JS. Nach dem Deployment stehen Tools für das Monitoring der Performance, bzw. zur Diagnose bei Fehlern und Problemen zur Verfügung. Im Azure Management Portal können sofort Anpassungen durchgeführt werden, um einen reibungslosen Betrieb der Azure Webseite zu erreichen. Für die weitere Entwicklung stehen Staging-Slots zur Verfügung, um die Änderungen vorab testen zu können. 3.2 Anlegen der ersten eigenen Webseite In diesem Abschnitt wollen wir zwei eigene Webseiten anlegen, eine für eine Webseite, bzw. Web-Applikation und eine zweite, um eine Blogging-Webseite zu erstellen. Für das Erstellen der Webseite gibt es verschieden Möglichkeiten, sei es durch Visual Studio, oder das Azure Management Portal. Auch für das Deployment stehen fast schon unzählige Varianten zur Verfügung, einige davon möchte ich beschreiben Über Visual Studio Im Zuge des Erzeugens einer neuen ASP.NET-Web Applikation kann auch gleichzeitig die Azure Webseite erzeugt werden. Dazu benötigt man Visual Studio 2015 und wählt ein neues Projekt, Web und ASP.NET Web Application aus, vergibt einen sprechenden Namen (in meinem Fall svobi ). Abbildung 3.2: Neue Web Applikation in Visual Studio

31 Hamboeck / Azure für Entwickler 27 Im zweiten Schritt wird es gleich spannend, hier ist das Häkchen für Host in the Cloud zu setzen. Abbildung 3.3: Hosting Option aktivieren Nach erfolgter Anmeldung mit dem Azure Account, besteht die Möglichkeit eine neue URL zu vergeben, die Azure Subscription zu wählen, die Region und eine Datenbank. Abbildung 3.4: Eintragen des Namens

32 28 Hamboeck / Azure für Entwickler Falls die Azure Webseite schon existiert, erscheint eine entsprechende Fehlermeldung, wäre die Webseite in Azure noch nicht reserviert, dann würde diese nun angelegt werden. Ich möchte an dieser Stelle den Versuch abbrechen und das Anlegen einer Azure Webseite im Management Portal vorstellen Im Azure Management Portal Der erste Schritt, um eine neue Webseite im Azure Management Portal anzulegen, ist auf den Reiter für die Webseiten zu wechseln. Der zweite Schritt ist den NEU-Button zu drücken, der links unten im Portal ersichtlich ist. Abbildung 3.5: Anwählen des Azure Webseiten-Bereichs im Portal und der Neu-Button Nun ist der Auwahlbereich zu sehen, der Bereich SERVER und WEBSITE sind bereits vorausgewählt. Es gibt nun drei verschiedene Möglichkeiten eine neue Webseite im Azure Management Portal anzulegen. Abbildung 3.6: Erfassen der Webseite Die erste Variante ist die Schnellerfassung. Mit der Schnellerfassung sind folgende beiden Werte auszuwählen:

33 Hamboeck / Azure für Entwickler 29 URL Das Feld muss eine Zeichenfolge mit 2 bis 60 Zeichen enthalten und darf nur Buchstaben, Zahlen und Bindestriche enthalten. Das erste und letzte Zeichen im Feld muss jeweils ein Buchstabe oder eine Zahl sein. Die gesamte Adresse muss weltweit eindeutig sein (im azurewebsites.net-namensbereich). Die Webseite ist nach dem Anlegen durch folgenden Link erreichbar: in dem Beispiel in Abbildung 3.6 also durch Wir werden später noch sehen, wie auch ein eigener Domänenname für die Azure Webseite verwendet werden kann. WEBHOSTINGPLAN wo, d. h. in welcher Region und Datacenter die Webseite physikalisch existiert. Falls dieser bereits exisitiert, dann kann optional auch ein neuer Webhostingplan erstellt werden, um die Webseite in einer anderen Region abzulegen, um beispielsweise den Anwendern in den USA, oder Asien die Webseite im wahrsten Sinne des Wortes näher zu bringen. Abbildung 3.7: Neuer Webhostingplan Anschließend ist die Region zu wählen, diese legt wie in Kapitel 1 beschrieben den Speicherort der Daten fest.

34 30 Hamboeck / Azure für Entwickler Abbildung 3.8: Region für den neuen Webhostingplan Durch Klick auf den Button wird die Webseite sofort angelegt und kann bereits im Browser aufgerufen werden. Die zweite Variante ist BENUTZERDEFINIERT ERSTELLEN. Abbildung 3.9: Benutzerdefiniert erstellen Durch die Anwahl dieses Punktes ändert sich der rechte Bereich und es kann zusätzlich (optional) eine Datenbank ausgewählt werden und die Bereitstellungsvariante (Deployment) konfiguriert werden.

35 Hamboeck / Azure für Entwickler 31 Abbildung 3.10: Eingabemaske bei benutzerdefinierter Erstellung Natürlich können beide Punkte auch nachträglich konfiguriert werden, wenn zuvor die SCHNELLERFASSUNG gewählt wurde, tatsächlich werden wir das Deployment später nachträglich konfigurieren. Für die Datenbank stehen drei Auswahlmöglichkeiten zur Verfügung. Abbildung 3.11: Auswahl der Datenbank

36 32 Hamboeck / Azure für Entwickler Für unsere Zwecke benötigen wir (vorerst) keine Datenbank. Falls Sie noch keine Webseite angelegt haben, so tun Sie dies bitte nun mit einem eigenen Namen, den Sie sich bitte merken. Egal für welche Variante Sie sich entschieden haben (Schnellerfassung, oder Benutzerdefiniert erstellen), es sollte jetzt eine neue Webseite ihre eigene - vorhanden sein (in meinem Beispiel ist das die svobi -Webseite). Sie können ihre eigene Webseite gleich gerne einmal mit dem Browser ihrer Wahl aufrufen (die URL hierfür ist Nun sollten wir noch gleich eine zweite Webseite anlegen. Der Dienst Azure Webseiten liefert auch vorgefertigte Webseiten mit, die sofort einsatzbereit sind, den sogenannten Katalog, womit wir bei der letzen, der dritten Variante wären. Abbildung 3.12: Erstellung aus Katalog Beispiele aus dem Katalog sind CRM Systeme, wie Drupal, Joomla, oder auch Wordpress, oder leere ASP.NET, bzw. PHP, oder Node.JS Webseiten, es wird aber beispielsweise auch Tomcat unterstützt. Wie man sehen kann, versucht Microsoft hier allen derzeitigen Web- Standards genüge zu tun, ohne dabei auf irgend eine Art einzuschränken. Ich würde gerne eine zweite Webseite anlegen, diese soll den Blog für die erste Webseite bereitstellen. Dazu bietet sich aus dem Katalog die BlogEngine.NET Vorlage an.

37 Hamboeck / Azure für Entwickler 33 Abbildung 3.13: BlogEngine.NET als Vorlage für die Webseite Auf der zweiten Seite ist wiederum eine weltweit eindeutige URL, sowie die Region einzutragen, bzw. auszuwählen.

38 34 Hamboeck / Azure für Entwickler Abbildung 3.14: Name der Webseite mit BlogEngine.NET Durch Drücken des Buttons wird die zweite Webseite erstellt. Beide Webseiten stehen nun im Browser zur Verfügung und zwar mit folgenden URLs: Abbildung 3.15: Eigener Blog aud dem Azure Webseiten-Katalog

39 Hamboeck / Azure für Entwickler 35 Die beiden Webseiten existieren nun, die svobiblog -Webseite macht was sie soll (diese stellt einen Blog ins Internet), da ja ein Template verwendet wurde. Die erste Webseite wartet allerdings noch, um mit Inhalt gefüllt zu werden. D. h. wir müssen unseren eigenen Content auf diese Webseite bringen, zuvor sollten wir uns aber kurz ein wenig mit dem Azure Management Portal und den Eigenschaften der Azure Webseiten beschäftigen. 3.3 Eigenschaften der Azure Webseite Für unsere angelegten Azure Webseiten sehen wir uns nun an, wie man zu den Eigenschaften navigiert und welche Bereiche es für eine Webseite gibt. Dazu wählen wir die erste der beiden Webseiten aus. Abbildung 3.16: Anwählen der Webseite im Azure Management Portal Wir befinden uns nun im Bearbeitungsbereich für diese eine, gewählte, Webseite. Abbildung 3.17: Bearbeiten der Webseite svobi Es sind folgende Bereiche zu sehen: DASHBOARD Überblick und essentielle Informationen über die Webseite, wie die Verbindungsdaten, Site-URL, FTP-Daten und Veröffentlichungsprofil (für Visual Studio). Von hier können auch einige der Punkte direkt angewählt werden, die in anderen Bereichen liegen (Protokolle, Diagnose, Skalierung konfigurieren, usw.). BEREITSTELLUNGEN Informationen über das Deployment (wann hat wer welche Dateien eingespielt).

40 36 Hamboeck / Azure für Entwickler ÜBERWACHEN Informationen über die Webseite selbst (Anforderungen, Menge der ausgehenden und eingehenden Daten, CPU-Zeit und HTTP-Serverfehler). WEBAUFTRÄGE - Hintergrundtasks mit Verwendung von Webaufträgen (WebJobs), diese können wiederkehrend, nach einem Zeitplan, oder bei Bedarf ausgeführt werden. KONFIGURIEREN diverse Konfigurationseinstellungen, wie Domänennamen, SSL- Verbindungen, Authentifizierung/Authorisierung, Standarddokumente, Handlerzuordnungen und virtuelle Verzeichnisse. Dazu gehören auch Diagnose- Einstellungen die Webseite betreffend, aber auch der Webanwendung selbst. Des weiteren findet man hier Entwicklereinstellungen, wie Applikations-Keys und Connenction-Strings. SKALIEREN wählen des Hostingplans, dieser beeinflusst die Kosten und die verbundene Leistungsfähigkeit der Webseite. Festlegen der Kapazität (Instanzgrösse und Anzahl der Instanzen optional nach Zeit). VERKNÜPFTE RESSOURCEN verwendete Datenbanken und Speicherkonten. SICHERUNGEN zeitgesteuerte Sicherungen auf ein Speicherkonto. Einige dieser Bereiche werden wir im Laufe des Kapitels noch kennen lernen. Beginnen wir aber nun mit dem Deployment einer Webseite, oder wie kommt nun der eigene Content auf die eigene Azure Webseite. 3.4 Deployment einer eigenen Webseite Es gibt verschiedene Möglichkeiten, um die eigene Web-Applikation zu einer Azure Webseite zu deployen:

41 Hamboeck / Azure für Entwickler 37 Abbildung 3.18: Unterstützte Veröffentlichunsmethoden für Azure Webseiten Außerdem besteht natürlich immer die Möglichkeit direkt aus Visual Studio seine Web- Applikation zu einer Azure Webseite zu deployen Deployment mit Visual Studio 2015 Eine Web-Applikation in Visual Studio kann zu einer bestehenden Azure Webseite deployed werden. Dazu muss im Solution Explorer die rechte Maustaste am Projekt gedrückt werden und danach der Menüpunkt Publish im Popup-Menü angewählt werden. Abbildung 3.19: Veröffentlichen aus Visual Studio über den Solution Explorer Im neu erscheinenden Fenster muss Microsoft Azure Websites gewählt werden und Visual Studio listet alle bestehenden Webseiten für die Azure Subscription(s), auf die der Anwender Zugriff hat, auf.

42 38 Hamboeck / Azure für Entwickler Abbildung 3.20: Auswahl der Azure Webseite Deployment mit Visual Studio ist also eine recht einfache Sache, aber sehen wir uns andere Möglichkeiten an, beginnen wir mit den Git-Deployment-Optionen Git-Deployment zu einer Azure Webseite Dazu wird ein Account auf github.com benötigt. Dabei wird zwischen einem kostenlosen Account und einem Account, der monatlich $7 kostet, unterschieden. Bei einem kostenlosen Account sind keine privaten Repositories möglich, es kann also jedermann auf den Source Code zugreifen. Nach dem Anlegen des Accounts muss ein Repository auf GitHub mit einem beliebigen Namen angelegt werden. Dabei wird geprüft, ob der Name für das Repository noch verfügbar ist.

43 Hamboeck / Azure für Entwickler 39 Abbildung 3.21: Anlegen des Repositories auf GitHub Zusätzlich besteht die Möglichkeit ein.gitignore File (für Visual Studio) anzulegen, das ist praktisch, da somit sofort alle Dateien ausgenommen sind, die von Visual Studio jederzeit selbständig hergestellt werden können (z. B. Verzeichnisse, wie build, obj, debug, release, usw.). Desweiteren ist eine Readme.md-Datei bei GitHub Projekten Standard, diese wird angezeigt, wenn man sich im Browser das Repository ansieht. Um nun in dieses GitHub-Repository zu deployen, sind 4 Schritte notwendig: 1. Im Azure Management Portal auf den Link klicken. 2. GitHub als Quelle für den Source-Code wählen.

44 40 Hamboeck / Azure für Entwickler Abbildung 3.22: GitHub als Quelle 3. Bei Githhub anmelden. Wird das erste Mal aus dem Azure Portal auf GitHub zugegriffen, dann müssen die Berechtigungen für Microsoft Azure freigegeben werden. Abbildung 3.23: Berechtigungen auf GitHub für Azure freigeben

45 Hamboeck / Azure für Entwickler 41 Nach erneuter Eingabe des GitHub-Passwortes hat Azure die Zugriffsberechtigungen auf das GitHub-Repository. 4. Auswählen des Repositories und der Branch. Abbildung 3.24: Repository und Branch in GitHub Nun wird jedes Mal, sobald Source-Code Änderungen in dem GitHub Repository eingecheckt werden diese Änderungen automatisch von der Azure Webseite übernommen. Eine zweite Option des Git-Deployments ist über ein lokal Git-Repository, also eines, welches nicht auf GitHub gehostet wird. 3.5 Lokales Git-Repository und Deployment zu einer Azure Webseite Um mit Git lokal unter Windows arbeiten zu können, muss der GitHub Client für Windows installiert werden, dieser ist frei verfügbar unter

46 42 Hamboeck / Azure für Entwickler Abbildung 3.25: Download von GitHub für Windows Nachdem der ca. 43 MB große Installer heruntergeladen wurde und installiert wurde stehen drei neue Programme auf dem PC zur Verfügung. Abbildung 3.26: GitHub für Windows Nun kann es auch schon mit dem Anlegen des eigenen, lokalen Git-Repositories losgehen, dazu ist die GitHub-Applikation zu starten. Diese erfordert beim ersten Start die Login-Daten für GitHub.

47 Hamboeck / Azure für Entwickler 43 Abbildung 3.27: GitHub-Windows Client, erster Start Nach erfolgreicher Anmeldung ist der nächste Schritt das Anlegen eines neuen lokalen Repositories, dies erfolgt durch Drücken des Buttons in der linken oberen Ecke. Jetzt fehlen noch die Daten für das lokale Repository, wie soll es heißen und wo befindet es sich auf der lokalen Festplatte.

48 44 Hamboeck / Azure für Entwickler Abbildung 3.28: Anlegen des lokalen Repositories Nachdem das Repository angelegt wurde schaltet die Ansicht um und wir erkennen, dass es vorhanden ist und dass zwei Dateien angelegt wurden (.gitignore und.gitattributes). Abbildung 3.29: Das angelegte lokale Repository Nun sind drei Schritte notwendig, um die Webseite durch ein lokales Git-Repository zu aktualisieren: 1. Im Azure Management Portal das Deployment durch das lokale Git-Repository konfigurieren, das heißt im Bereich DASHBOARD für die Webseite auf den folgenden Link klicken: Es öffnet sich das Auswahlfenster, wo die Bereitstellungsmethode gewählt werden kann, hier wählen wir Lokales Git-Repository.

49 Hamboeck / Azure für Entwickler 45 Abbildung 3.30: Bereitstellungsmethode Lokales Git-Repository Wir erhalten die Bestätigung, dass das Repository bereit ist und nur noch auf Source Code von uns wartet. Abbildung 3.31: Azure Webseite ist bereit für das lokale Git-Repository

50 46 Hamboeck / Azure für Entwickler 2. Anlegen der lokalen Webseite im lokalen Git-Repository. In dem lokalen Verzeichnis muss nun die Webseite angelegt werden, als Beispiel dient hier eine einfache index.html Seite, diese kann z. B. erst einmal so aussehen und danach natürlich frei erweitert werden, um zu einer richtig großen und schönen Webseite anzuwachsen: <html> <head></head> <body> <h1>deployed durch lokales Git-Repository</h1> </body> </html> Tabelle 3.1: index.html Seite 3. Nun fehlt noch das Einchecken, d. h. sozusagen das Commitment der Webseite zu Azure. Dazu wird die Git-Shell benötigt, die per Default wiederum die PowerShell verwendet. Es muss in das lokale Git-Verzeichnis und darin in das Repository gewechselt werden (in meinem Fall C:\GitDeploment\Svobi). Abbildung 3.32: Git-Shell im lokalen Repository Fast geschafft, nun müssen noch alle neuen Dateien zu Git hinzugefügt werden, dies geschieht mit dem Befehl git add. und eingecheckt (committed) werden, das wiederum erledigt der Befehl git commit m initial commit für uns. Das dauert ein paar Sekunden und wir erhalten die Rückmeldung, was alles in dem Repository passiert ist.

51 Hamboeck / Azure für Entwickler 47 Abbildung 3.33: Hinzufügen und einchecken in Git Im Azure Management Portal lässt sich der Erfolg im Bereich BEREITSTELLUNGEN für diese Webseite nachweisen. Es ist das Datum der Durchführung, sowie der Autor und das Login für die Azure Webseite ersichtlich. Auf Wunsch sind auch die betroffenen Dateien ersichtlich. Abbildung 3.34: Erfolgreiche Bereitstellung Die finale Kontrolle der Bereitstellung kann im Browser erfolgen, dazu ist die Adresse der Azure Website mit dem Domänennamen azurewebsites.net zu kombinieren.

52 48 Hamboeck / Azure für Entwickler Abbildung 3.35: Die veröffentlichten Änderungen Während der Entwicklung kommt man mit diesen Möglichkeiten sehr gut zurecht. Sobald man allerdings mit seiner Webseite in Produktion geht, ist es nicht mehr wünschenswert, dass jede durchgeführte (committete) Änderung auch sofort online verfügbar ist. Erst nach Überprüfung der Änderungen wäre es sinnvoll, wenn diese aktiv sind. Damit wären wir bei einem weiteren Feature der Azure Webseite angelangt, dem Staging. Zuvor aber noch einmal ein kleiner Ausflug zur Konfiguration, denn wir sollten uns vorab ansehen, welche Funktionalität und Leistungsfähigkeit mit den Azure Webseiten zur Verfügung gestellt werden, das kann wiederum frei konfugiert werden, wirkt sich aber wiederum auf die Kosten aus, die jedes Monat anfallen. 3.6 Webhosting-Pläne Im Azure Portal für eine angelegte Webseite unter dem Punkt SKALIERUNG finden wir den WEBHOSTINGPLAN-MODUS. Abbildung 3.36: Auswahl des Webhosting-Plans Es gibt vier verschiedene Modi, das Verständnis derselben ist essentiell um die Arbeitsweise der Webseite und auch deren Verrechnung zu verstehen.

53 Hamboeck / Azure für Entwickler Modus Kostenlos Im Modus KOSTENLOS können bis zu 10 Webseiten (pro Region) betrieben werden. Die Web-Applikation muss eine 32-Bit WebApp sein. Der maximale Speicherplatz beträgt 1GB, das Datenlimit (ausgehend) beträgt 165MB pro Tag. Auch die CPU-Zeit ist auf 60 Minuten pro Tag beschränkt. Der maximal verwendete Memory-Speicher darf 1024MB in der Stunde nicht überschreiten. Die optional verwendbare MySQL Datenbank darf 20MB nicht überschreiten. All diese Limits gelten allerdings für ALLE Webseiten (bis zu 10) gemeinsam pro Region. Wird eines der Limits überschritten zeigen die betreffenden Webseiten bei einem Aufruf im Browser an, dass diese derzeit nicht erreichbar sind. Die Webseiten laufen nicht auf einem eigenen Rechner, sondern mit anderen Azure Webseiten gemeinsam auf der gleichen physikalischen Maschine Modus Freigegeben: Im Modus FREIGEGEBEN können bis zu 100 Webseiten mit max. 10 Webhosting-Plänen betrieben werden. Die Web-Applikation muss ebenfalls eine 32-Bit WebApp sein. Der maximale Speicherplatz beträgt 1GB gemeinsam für alle Webseiten des Hosting-Plans. Es gibt kein Datenlimit für ausgehende Daten, der Traffic wird allerdings verrechnet (mehr dazu unter Kosten einer Webseite). Der maximal verwendete Memory-Speicher darf 1024MB in der Stunde nicht überschreiten. Auch die CPU-Zeit ist auf 240 Minuten pro Tag beschränkt. Diese Einschränkung gelten allerdings PRO Webseite und nicht wie im Modus KOSTENLOS für alle Webseiten gemeinsam (das wiederum wirkt sich allerdings auch auf die Verrechnung aus). Die Webseiten laufen ebenfalls mit anderen Webseiten auf der gleichen Maschine. Der Vorteil ist, dass ab dem Modus FREIGEGEN ein eigener Domänenname mit der Azure Webseite verbunden werden kann Modus Basic: Im Modus BASIC können bis zu 500 Webseiten mit max. 10 Webhosting-Plänen betrieben werden. Die Web-Applikation kann eine 32-Bit, oder 64-Bit WebApp sein. 1 Staging Slot ist verfügbar. Ab diesem Modus laufen die Webseiten auf einer dedizierten physikalischen Maschine, damit verbunden bestehen keine Einschränkungen bezüglich der Verwendung der CPU-Zeit und des verwendeten Memorys. Microsoft garantiert eine Verfügbarkeit von 99.9% Modus Standard Zusätzlich zu den Möglichkeiten, die der Modus BASIC bereits bietet ist es möglich noch besser zu skalieren, vor allem Zeit- bzw. CPU-abhängige Skalierung ist in diesem Modus möglich und es stehen 5 Staging Slots zur Verfügung.

54 50 Hamboeck / Azure für Entwickler Welcher Modus ist der Richtige? Für Azure-Einsteiger, bzw. für Webseiten-Betreiber, wo nur geringe Zugriffe zu erwarten sind, ist der Modus KOSTENLOS bestimmt interessant. Ist mehr Traffic zu erwarten, oder wird ein eigener Domänenname benötigt, dann ist der Modus SHARED eine günstige Alternative, wenn es sich um wenige Webseiten handelt. Handelt es sich um Webseiten, bzw. Web-Applikationen, die höhere Ansprüche stellen als die bisher genannten, sind im Modus BASIC sehr gut aufgehoben. Muss allerdings abhängig von der Last, oder zu einer bestimmten Zeit die Webseite besser skalieren, dann ist der Modus STANDARD zu empfehlen. D. h. werden z. B. jeden Freitag aufwendige Berechnungen angestoßen, dann kann im Modus STANDARD ein weiterhin reibungsloser Zugriff auf die Webseite erreicht werden, trotz der höheren Belastung. Auch wenn plötzlich ein riesiger Anstieg der Zugriffsraten erreicht wird, z. B. durch eine -Promotion, dann wird ebenfalls ein Zusammenbruch durch das automatische Skalieren erreicht werden können. Ein genauer Vergleich der Limits der verschiedenen Modi ist im Anhang zu finden. 3.7 Skalieren der Webseite Webhostingpläne - und die zugehörigen Webseiten - für KOSTENLOS und FREIGEGEBEN teilen sich die Hardware mit anderen Webseiten. Das bedeutet nicht, dass hier Daten von anderen Webseiten sichtbar, oder erreichbar wären, aber dass hier (auch aus diesem Grund) keinerlei SLA von Seiten Microsoft garantiert werden kann. Skalierung gibt es hier ebenfalls keine, es kann keine weitere Instanz der Webseite aktiviert werden, da das Limit in beiden Modi bei einer Instanz liegt. Abbildung 3.37: Skalierung im Modus Kostenlos/Freigegeben Im Modus BASIC und STANDARD steht eine eigene Maschine zur Verfügung, d. h. nur die eigene Webseite, bzw. Webseiten greifen auf Ressourcen dieser Maschine zu. Ab dem Modus BASIC kann auch die Instanzgröße (Klein, Mittel, oder Groß) der zugrunde liegenden virtuellen Maschine - gewählt werden. Diese virtuelle Maschine wird von Azure automatisch gemanaged, d. h. dass z. B: Betriebssystem-Updates automatisch eingespielt werden. Es können bis zu drei Instanzen gewählt werden.

55 Hamboeck / Azure für Entwickler 51 Abbildung 3.38: Skalierung im Modus BASIC, Auswahl von 3 Instanzen Die Istanzgrößen unterscheiden sichin der Anzahl der CPU-Kerne und in der Größe des verfügbaren Arbeitsspeichers. Die ungewohnte Größe des Arbeitsspeichers ergibt sich daraus, dass der Rest für das unterliegende OS der VM reserviert ist, bzw. benötigt wird. Abbildung 3.39: Skalierungseinstellungen im Modus BASIC Im Modus STANDARD können bis zu zehn Instanzen gewählt werden. Das Limit ist allerdings nicht unbedingt sinnvoll, da ab ca. 8 Instanzen ein weiterer Webhostingplan im Modus STANDARD im Preis günstiger ist. Zusätzlich zu BASIC kann hier noch abhängig von der CPU-Last, oder nach einem Zeitplan skaliert werden.

56 52 Hamboeck / Azure für Entwickler Abbildung 3.40: Zusätzliche Skalierungseinstellungen im Modus STANDARD Das Einrichten eines Zeitplanes ist relativ flexibel. Zu beachten ist, dass das Wochenende am Freitag um Uhr 20:00 beginnt und am Montag um Uhr 08:00 endet. Generell beginnen Tage per Default um Uhr 08:00 und enden um Uhr 20:00, dies kann natürlich angepasst werden. Die Sommer- und Winterzeit wird je nach Region berücksichtigt. Abbildung 3.41: Erstellen eines Zeitplans im Modus STANDARD

57 Hamboeck / Azure für Entwickler 53 Wie erwähnt ist der Zeitplan eine gute Variante vorhersehbare hohe Lasten, wie den Tag, bzw. Nacht-Rhythmus der Firmenkollegen, oder Kunden abzubilden, sowie wiederkehrende Lasten, wie komplexe Berechnungen zu bestimmten Tagen abzufangen. Allerdings sind nicht aller Ereignisse vorhersehbar, so können schon mal Zugriffe auf die eigene Webseite (unvorhersehbar) in die Höhe schnellen, was eine erhöhte CPU-Last zur Folge hat, was möglicherweise die Webseite in die Knie zwingt. Dem kann aber mit der Einstellung NACH METRIK SKALIEREN vorgebeugt werden. Dabei ist die Einstellung auf CPU zu setzen und die Grafik daneben liefert eine Übersicht, wie viele Instanzen in den letzten Tagen verwendet wurden. Im Gegensatz zu BASIC kann nun die minimale Instanzenanzahl (in Abbildung 3.X sind das 2) und die maximale Instanzenanzahl (in dem Beispiel wurden 5 gewählt) konfiguriert werden. Zusätzlich wird der gewünschte CPU-Bereich festgelegt (zwischen 60% und 80%). Azure überprüft alle fünf Minuten die CPU-Leistung und erhöht, bzw. reduziert die Instanzen entsprechend dem gemessenen Wert. Eine minimale Instanzenanzahl von 1 kann somit für maximal ca. 5 Minuten unangenehme Folgen für den Zugriff auf die Webseite haben. Abbildung 3.42: Zusätzliche Skalierungseinstellungen bei Standard Die zusätzlichen Einstellungsmöglichkeiten im Modus STANDARD sind ein klarer Vorteil zu BASIC, da hier unter Umständen Kosten eingespart werden können, da die zusätzlichen Instanzen nur dann verwendet werden, wenn die Einstellungen für die CPU-Last, oder des Zeitplans zuschlagen. Also genau nach dem Prinzip: Pay only what you use. Werden die zusätzlichen Instanzen nur manches Mal (über das Monat) verwendet, werden nur die Minuten der zusätzlichen Nutzung verrechnet. Wird niemals die CPU-Last erreicht und existiert kein zusätzlicher Zeitplan, dann wird auch nur für 1 Instanz bezahlt.

58 54 Hamboeck / Azure für Entwickler 3.8 Deployment mit Staging Ein sogenannter Staging-Slot, im Modus BASIC steht 1 zur Verfügung, im Modus Standard stehen 5 zur Verfügung, dient dazu, Änderungen an der Webseite bereit zu stellen. Das Test-Team, oder noch besser der Auftraggeber der Webseite kann die Änderungen testen und diese anschließend final frei geben. Idealerweise hat das QA-Team einen eigenen Staging-Slot. Sobald die Änderungen abgenommen wurden kann der Produktionsslot und der Staging-Slot unterbrechungsfrei getauscht werden. D. h. es findet keinerlei Ausfall der Webseite statt. Wichtig zu verstehen ist, welche Einstellungen bei dem Switch zwischen der Produktion und dem Staging-Slot übernommen werden und welche nicht, da es hier sehr leicht zu ungewollten Fehlern kommen kann (z. B. bei Datenbankverbindungen). Konfigurationseinstellungen, die sich beim Swap ändern, sind im Bereich KONFIGURIEREN zu finden: Allgemeine Einstellungen App-Einstellungen (VORSICHT) Verbindungszeichenfolgen (VORSICHT) Handlerzuordnungen Virtuelle Anwendungen und Verzeichnisse Monitoring und Diagnose-Einstellungen Einstellungen, die nicht übernommen werden: Publishing endpoints SSL-Zertifikate Eigene Domännamen Sowie die Skalierungseinstellungen (Bereich SKALIERUNG) Man kann erkennen, dass das Azure Staging dazu gedacht ist, die Version in einem Staging-Slot bereit zu stellen, die auch in Produktion gehen soll. In dem Staging-Slot sollten vor dem Switch die Einstellungen, z. B. für die Verbindungszeichenfolgen kontrolliert werden, da diese auf die Produktiv-Datenbank zeigen sollte und nicht auf eine Test-Datenbank. Nach dem Swap können die Einstellungen wieder geändert werden, um z. B. der QA wiederum die Möglichkeit für Tests zu geben. Aber wie bereits erwähnt wäre ein eigener Staging-Slot für die QA besser, um hier Fehler zu vermeiden. Um einen Staging-Slot anlegen zu können, muss sich die Webseite im Modus BASIC (1 Staging Slot), oder STANDARD (5 Staging-Slots) befinden. Die beiden Modi KOSTENLOS und FREIGEGBEN unterstützen kein Deployment mit Staging!

59 Hamboeck / Azure für Entwickler 55 Abbildung 3.42: Staging ist nur in BASIC und STANDARD verfügbar Ist der Modus für die Webseite BASIC, oder STANDARD kann das Staging konfiguriert werden, und zwar im Bereich DASHBOARD. Abbildung 3.44: Bereich DASHBOARD, um Staging einzurichten Hier ist rechts der Link zu finden, um die Konfiguration für den Staging-Slot zu starten: Der Name des Staging-Slots ist einzugeben, z. B. staging, der finale Name beinhaltet den Namen der Webseite mit ebendiesem Namen in Klammern, in meinem Fall also svobi (staging). Zusätzlich kann die bestehende Konfiguration aus der aktuell produktiven Version gecloned werden, oder falls schon mehrere Staging-Slots angelegt wurden, aus einem dieser.

60 56 Hamboeck / Azure für Entwickler Abbildung 3.45: Name des Slots und Klonen der Konfiguration Der Staging Slot wurde angelegt und im Azure Management Portal direkt unter der zugehörigen Webseite angezeigt. Dieser kann nun durch Anwählen, genau wie jede andere Webseite auch, konfiguriert werden. Abbildung 3.46: Neuer Staging-Slot unterhalb der Webseite Im Bereich DASHBOARD ist rechts die URL zu erkennen, diese ist in meinem Fall: Webseiten-Swap im Azure Management Portal Möchte man den Staging-Slot und den aktuellen Produktions-Slot tauschen, ist das nur einen Mausklick am unteren Bildschirmrand entfernt

61 Hamboeck / Azure für Entwickler 57 Abbildung 3.47: Tauschen des Staging- und Produktions-Slots Ein Bestätigungsfenster öffnet sich und die Quelle (der Staging-Slot) und das Ziel (üblicherweise die Produktive-Webseite) kann gewählt werden. Abbildung 3.48: Quelle und Ziel für den Swap Der Button führt den Swap sofort aus Webseiten-Swap mit der Powershell Ist die Azure Powershell installiert und das Azure-Abonnement importiert (siehe Kapitel 6) kann der Swap auch programmgesteuert durchgeführt werden. Dazu ist zuerst die Powershell zu öffnen und danach sind die notwendigen Kommandos abzusetzen. Ein erster Überblick über die Befehle die Azure Webseiten betreffend erhält man mit help AzureWebsite.

62 58 Hamboeck / Azure für Entwickler Abbildung 3.49: Verfügbare PowerShell Befehle für Azure Webseiten In diesem Fall ist der Befehl Switch-AzureWebsiteSlot der Gesuchte, allerdings klappt das nur, wenn nur zwei Slots vorhanden sind (der Produktive-Slot und der Staging-Slot). Das Kommando wird so abgesetzt: Switch-AzureWebsiteSlot -Name siteslotstest Abbildung 3.50: PowerShell Webseiten-Swap Diese Variante ist für Entwickler und Administratoren natürlich fantastisch, es muss nicht unbedingt der Umweg über das Management Portal gegangen werden Zugriff auf Staging unterbinden Der Staging-Slot ist, wie jede andere Azure Webseite auch, von überall erreichbar. Dies ist nicht unbedingt erwünscht und soll möglicherweise nur aus dem Intranet verwendet werden können. Möglicherweise möchte man auch verhindern, dass keine Informationen nach außen gehen, die noch nicht veröffentlicht werden sollen. In dem Beispiel bisher wurden zwei URLs angelegt und verwendet: und

63 Hamboeck / Azure für Entwickler 59 Um nun den Zugriff auf den Staging-Slot zu unterbinden sollte eine rule in der web.config hinterlegt werden. Zugriff sollen nur die IP-Adressen erhalten, die hier auch eingetragen sind: <system.webserver> <rewrite> <rules> <rule name="block traffic to staging" stopprocessing="true"> <match url=".*" /> <conditions> <!-- staging site host name --> <add input="http_host" pattern="^svobi\-staging\." /> <!-- white listed IPs --> <add input="remote_addr" pattern="123\.123\.123\.1" negate="true"/> <!-- more IPs --> <!-- <add input="remote_addr" pattern="123\.123\.123\.2" negate="true"/> --> </conditions> <action type="customresponse" statuscode="403" statusreason="forbidden" statusdescription="site is not accessible" /> <!-- This one will rewrite url to specified file --> <!-- <action type="rewrite" url="error.html" appendquerystring="false" /> --> <!-- This one will redirect to another site --> <!-- <action type="redirect" url= appendquerystring="false" /> --> </rule> </rules> </rewrite> </system.webserver> Tabelle 3.2: Web.config um den Zugriff auf Staging zu limitieren Sollte nun ein http request zur die Staging-Webseite durchgeführt werden, dann wird ein HTTP 403 Response zum Client zurück geschickt, alternativ könnte der Request auch umgeleitet werden. White-Listed IP-Adressen können hingegen auf die Webseite zugreifen. Nach einem erneuten Swap auf die Produktion greift die erste Rewrite-Rule nicht und alle Anfragen werden wie gewünscht beantwortet. 3.9 Verwenden des eigenen Domänennamens Die eigene, bzw. die Firmen-Webseite ist erst so richtig perfekt mit dem eigenen Domänennamen. Dazu muss die Domäne, die zuvor bei einem Domänenbetreiber gekauft

64 60 Hamboeck / Azure für Entwickler wurde, mit der Azure-Webseite im Azure Portal verbunden werden. Zusätzlich sind beim Domänenprovider DNS-Einträge zu setzen, um zu überprüfen, ob man auch der Eigentümer der Domäne ist. Dies ist für Azure Webseiten ab dem Webhosting-Plan FREIGEGEBEN möglich. Sollte für die Webseite also noch der Webhostinplan KOSTENLOS eingestellt werden, so ist dieser im Menüpunkt SKALIEREN zuerst auf FREIGEGEBN, BASIC, oder STANDARD umzusetzen. Abbildung 3.51: Webhostinplan FREIGEGEBEN, oder höher Danach kann der eigene Domänenname mit der Azure Webseite verknüpft werden, und zwar im Menüpunkt KONFIGURIEREN und mit dem Link.

65 Hamboeck / Azure für Entwickler 61 Abbildung 3.52: Es öffnet sich ein Dialog, wo der gewünschte Domänennamen einzugeben ist. Um diesen Schritt erfolgreich zu meistern, müssen beim Domänenanbieter seiner Wahl DNS-Einträge gesetzt werden. Abbildung 3.53: Die benötigten DNS-Einstellungen für meinen Provider (world4you.com) sind nachfolgend zu sehen. Es ist der CNAME (canonical name) zur Azure-Webseite zu setzen. Zusätzlich zeigt der A-Resource-Record (dieser verbindet dann den Domänennamen mit einer IP-Adresse) auf die IP-Adresse der Azure-Webseite.

66 62 Hamboeck / Azure für Entwickler Abbildung 3.54: CNAME und A-Ressource-Record Einträge für eine Azure-Webseite Die Änderung der DNS-Einträge beim Provider können bis zu 20 Minuten betragen, sollte es also nicht gleich funktionieren, dann ist vermutlich nur etwas Geduld nötig. Wenn es geklappt hat, dann ist die Azure Webseite nun (auch) mit dem eigenen Domänennamen erreichbar Kosten der Webseite Für alle Dienste bei Azure gilt, dass nur das bezahlt wird, was auch tatsächlich verwendet wird. Um die Kosten, die für die Webseite(n) im Monat anfallen berechnen zu können, ist der Azure Preisrechner sehr hilfreich, diesen findet man unter: DE/pricing/calculator/ In Abbildung 3.X ist eine Beispielkalkulation für zwei kleine Instanzen (1.6 GHz CPU, 1.75 GB RAM) zu sehen, mit einem angenommenen ausgehenden Traffic von 100GB im Monat (die ersten 5GB sind immer kostenlos). Abbildung 3.51: Preiskalkulation für 2 Instanzen im Modus STANDARD

67 Hamboeck / Azure für Entwickler 63 Wird im Modus Standard zusätzlich nach CPU, oder Zeit skaliert, so kommen noch die aufgelaufenen Minuten für die weiteren Instanzen dazu. Im Modus KOSTENLOS, FREIGEGEBEN und STANDARD spielt es für die Preiskalkulation keine Rolle, wie viele Webseiten pro Webhostingplan verwendet werden. Anders sieht es allerdings im Modus FREIGEGEBEN aus, hier wird für JEDE einzelne Webseite der berechnete Preis fällig, da in diesem Modus ja keine dedizierte Maschine verwendet wird. Abbildung 3.52: Kosten für 8 Webseiten im Modus FREIGEGEBEN Es kann also durchaus sinnvoll sein hier mehrere Möglichkeiten durchzuspielen, da in dem oben angezeigten Fall mit den 8 Webseiten es - auch von den Kosten her - bestimmt eine bessere Lösung auf den Modus BASIC (mit einer dedizierten Maschine) zu wechseln ( 41,56 pro Instanz im Monat Stand Dez. 2015), bzw. auf den Modus STANDARD, falls man noch bei Bedarf mit zumindest einer zusätzlichen Instanz skalieren möchte. Zusätzliche Kosten können noch bei Verwendung einer Datenbank anfallen, bzw. bei Verwendung des Azure Storage. Diese Kosten sind extra zu berechnen und zu den Kosten zu addieren. Der vollständige Kostenrechner ist hier zu finden: Es spricht aber nichts dagegen mit der kostenlosen Variante erst einmal zu starten und eben erst später die Webseite für die eigenen Bedürfnisse anzupassen.

68 64 Hamboeck / Azure für Entwickler 3.11 Zusammenfassung Für den Einstieg in die Welt von Microsoft Azure bieten sich Azure Webseiten an. Man hat hier die Möglichkeit sich mit dem Azure Management Portal auseinanderzusetzen, sowie eine erste Webseite weltweit zur Verfügung zu stellen. Die Möglichkeiten des Deployments sind hier vielfältig. Sowohl für kleine Entwicklungsteams, als auch für größere gibt es interessante Varianten, wie das Git Deployment, Visual Studio Online, oder möglicherweise auch die DropBox. Die Skalierungsmöglichkeiten sind vielfältig und der MODUS Standard lässt bezüglich Performance keine Wünsche offen. Die Möglichkeit des Stagings ist für Entwickler wie auch für die QA interessant, um die Produktion von der Entwicklung zu trennen und doch jederzeit (nach Abnahme) fliegend Änderungen in Produktion bringen zu können. Der eigene Domänenname kann natürlich ebenfalls verwendet werden. Der Einstieg in die Cloud-Entwicklung wäre somit geschafft. Es lässt sich erahnen, welche Leistungsvielfalt die Microsoft Cloud noch zu bieten hat, sehen wir uns also gleich einen weiteren Dienst an, Azure SQL.

69 Hamboeck / Azure für Entwickler 65 3 Azure SQL Datenbanken In diesem Kapitel wird die Architektur von Azure SQL beschrieben wird das Anlegen einer Datenbank erläutert werden Feature-Unterschiede zu einer On-Premise Installation beschrieben das Sicherheitskonzept erläutert Die Datenbank, bzw. der Datenbank-Server in der Cloud. Möchte ich das? Beziehungsweise möchte mein Unternehmen das wirklich? Die provokante Gegenfrage müsste lauten: Warum nicht? Ja, die Daten liegen dann nicht mehr im Haus, sie liegen in einem Datacenter bei Microsoft. Ich kann gut verstehen, dass dies für manche Bereiche bzw. Unternehmen NIEMALS erlaubt werden kann bzw. auf Grund von bestimmten Richtlinien niemals möglich sein kann. Wenn Sie also in solchen Bereichen arbeiten, dann können Sie dieses Kapitel nun gerne überspringen und mit dem nächsten fortfahren. Gut, sie sind also immer noch hier. Generell gibt es zwei Möglichkeiten eine, oder mehrere SQL Datenbanken unter Azure zu betreiben entweder in einer virtuellen Maschine, oder als Azure SQL Database Service. In diesem Kapitel wird hauptsächlich letztere Variante beschrieben. Sie haben vermutlich bereits einen, oder mehrere lokale SQL Server mit einer, oder mehreren Datenbank(en). Wie bekommt man diese nun ins Azure? Was sind die Unterschiede zu einer lokalen Installation? Nun, vorab, vielleicht sehen wir uns ein paar Gemeinsamkeiten an, um die Sicherheit zu gewinnen, dass ein Azure Datenbank-Server, bzw. eine Azure SQL Datenbank eine gute Alternative zu einer lokalen Installation ist, oder aber auch eine interessante Möglichkeit ist, seine Daten zusätzlich in der Cloud zu speichern.

70 66 Hamboeck / Azure für Entwickler Zu jedem Azure Account können eine, oder mehrere Azure Subscriptions angelegt werden (wie im Kapitel 1 bereits geschehen). Jede dieser Subscriptions kann nun bei Bedarf mehrere Azure SQL Server anlegen und jeder Azure SQL Server kann mehrere Datenbanken hosten. Diese haben genauso wie eine lokale Installation die Systemdatanbanken master und tempdb. In der master Datenbank (unter Azure kostenlos) sollten keine User-Daten liegen, sondern nur Berechtigungen und das Auditing. Es werden also nur Logins angelegt und keinerlei Business-Daten abgelegt. Das Azure SQL Database Service verwendet weiterhin das Tabular Data Stream (TDS) Protokoll wiederum wie ein lokaler Server - was bedeutet, dass heute bereits vorhandene Datenbank-Applikationen sich auch auf eine Azure SQL Datenbank verbinden können. Also im Großen und Ganzen genauso, wie es auch in einer lokalen Installation der Fall ist. Allerdings wird jede Datenbank im Azure SQL Database Service drei Mal auf drei verschiedene physische Server repliziert, um Hochverfügbarkeit zu erreichen (der erste klare Vorteil zu einer lokalen Installation). Azure SQL Server muss man als logische Server sehen, nicht als physische Server, d. h. wir wissen nichts über die darunter liegende Hardware, wie die Maschine oder auch über die Disks, die vorhanden sind. Das müssen wir nicht, und ganz ehrlich, das wollen wir auch nicht. Mit einem Azure Datenbank-Server, bzw. einer Azure Datenbank können wir das tun, was wir als Entwickler am besten können: Uns auf die Daten zu konzentrieren, d. h. den logischen Teil und nicht den physischen. Wir sprechen hier also über eine SAAS Lösung (Software as a Service). Ein Azure Database Server ist für uns praktisch ein TDS-Endpoint, wo die Daten drei Mal gespeichert werden. Womit wir bei der Architektur angekommen wären, diese sollten wir uns einmal genauer ansehen. 3.1 Azure SQL Architektur Die SQL Azure Architektur setzt sich aus vier Layern zusammen, diese Layer sind: Client Layer wie gewohnt der Layer mit dem die Applikation im Endeffekt mit der Datenbank mittels ADO.Net oder ODBC über TDS kommuniziert. Das kann eine WinForms-Applikation, eine WPF-Applikation oder beispielsweise ein WCF-Service, welches möglicherweise selbst in Azure gehostet ist, sein. Services Layer - beinhaltet spezielle Azure Funktionalitäten, wie das Provisioning also das Anlegen einer Datenbank, das Billing und Metering nun wissen wir, woher die Rechnung kommt, das Routing die Weiterleitung der Anfragen aus der Client-Applikation an die Datenbank, und

71 Hamboeck / Azure für Entwickler 67 den Partition Manager dieser kennt den Ort der primären und der beiden sekundären Datenbanken. Platform Layer beinhaltet mehrere physische SQL Instanzen und Dienste. Jede Instanz wird von SQL Azure Fabric gemanaged, welches auch das Herzstück in diesem Layer ist. Es kümmert sich um Load Balancing, automatischen Failover und der Replikation der Server. Infrastructure Layer repräsentiert die Administration der physische Hardware und des Betriebssystems. Abbildung 3.1: Azure SQL Architektur

72 68 Hamboeck / Azure für Entwickler 3.2 Anlegen eines Azure SQL Servers Wenn in einer lokalen SQL Server-Installation eine Datenbank angelegt wird, so ist diese in der Instanz des SQL Servers zu finden, für den diese auch angelegt wurde. Jede SQL Azure Datenbank, die in einer Azure Subscription angelegt wird, ist ebenfalls unter einem Server-Namen ansprechbar. Im Gegensatz zu einer lokalen (On-Premise) Installation handelt es sich hier allerdings nur um einen logischen Server und keinen physischen Server. Wir erinnern uns, dass bereits erwähnt wurde, dass jede Azure SQL Datenbank sofort nach dem Anlegen insgesamt drei Mal vorgehalten wird. Man spricht von der primären Datenbank und von den Sekundär-Datenbanken. Wird ein Insert-Statement von einem Clinet in die Azure SQL-Datenbank geschrieben, dann wird die Zeile in die primäre Datenbank (bzw. in das Transaction-Log) geschrieben und asynchron auf die beiden Sekundären. Der Client erhält erst eine Erfolgsmeldung, wenn das Schreiben in der primären Datenbank und zumindest in einer der beiden sekundären Datenbanken erfolgreich war. Dieser Vorgang passiert völlig autonom und ist nicht transparent für die Applikation, die diesen virtuellen SQL Server verwendet und auch nicht für die Administratoren sichtbar. Aus diesem Grund erhalten wir für die Verbindung also nicht wirklich einen Server- Namen, da es diesen EINEN Namen ja nun einmal gar nicht gibt, sondern einen TDS- Endpoint, der für die Verbindung verwendet wird. Eine eingehende Verbindung geht nun also vom Client-Layer (via TDS) durch den Service-Layer, bis er schließlich im Platform-Layer angekommen ist. Aber was passiert nun tatsächlich im Platform Layer? Hier verstecken sich nun physische SQLServer-Installationen, die sogenannten Data Nodes. Jedes Data Node besteht aus einer SQLServer Installation. In einem Data Node existiert eine Datenbank, welche partitioniert ist bis zu 650 Partitionen (der Begriff Partition hat hier nichts mit den im SQLServer bekannten Partitionen zu tun). Jede Partition enthält eine Azure SQL Datenbank, entweder eine primäre, oder eine der beiden sekundären.

73 Hamboeck / Azure für Entwickler 69 Abbildung 3.2: Data Nodes mit den primären und sekundären Datenbanken Jedes Data Node hat Prozesse laufen, welche als Azure Fabric bezeichnet werden. Diese kümmert sich um folgenden Ablauf: 1. Failure detection: tritt ein Fehler an einem der drei Datenbanken auf (primäre, oder sekundäre) wird der Reconfiguration Agent gestartet. 2. Reconfiguration Agent: kümmert sich um die Wiederherstellung, wenn eine primäre, oder sekundäre Datenbank ausgefallen ist. Wenn eine primäre Partition ausfällt wird diese durch eine der sekundären ersetzt, d. h. diese ist nun die primäre Datenbank und es gibt nur noch eine sekundäre Datenbank, bis dann nach einiger Zeit der Partition Manager eine zweite sekundäre Datenbank aktiviert. 3. PM (Partition Manager) Location Resolution: sendet Meldungen an den Partition Manager im Service Layer. 4. Engine Throttling: stellt sicher, dass allen Datenbanken Ressourcen zur Verfügung

74 70 Hamboeck / Azure für Entwickler stehen und nicht eine einzelne Datenbank den gesamten logischen Server lahmlegt. 5. Ring Topology: Verwaltet die physikalischen Maschinen in einem Cluster (bis zu 1000 Maschinen in einem Datacenter) als logischen Ring, das bedeutet, dass jede Maschine zwei Nachbarn hat, was im Endeffekt eine Ringanordnung ergibt. Somit kann ein Ausfall einer Maschine entdeckt und darauf reagiert werden. Das bedeutet also für unsere Datenbank, dass diese drei Mal vorhanden ist und mit anderen Datenbanken auf drei physischen SQLServer Installationen liegt. Dies erklärt auch, warum das Transact-SQL-Statement USE DATABASE unter Azure nicht erlaubt ist, da sonst eine Applikation auf andere Datenbanken zugreifen könnte. Es ist somit auch klar, dass unsere Datenbank sich System-Ressourcen mit anderen Datenbanken teilt. So ist das auch mit dem Transaction-Log. Es exisitiert auf einem Datanode nur eine bereits angelegte und vorgenullte (verhindert Verzögerungen bei Autogrowth-Vorgängen) - Log-Datei für alle Partitionen (also Datenbanken), was den Vorteil des schnelleren Speicherns bietet. Allerdings wirft dies auch Fragen zum Thema Backup auf, denen wir uns später noch widmen. Außerdem bringt dieser geteilte Log-Datei auch neue Einschränkungen mit sich (man denke an den Schutz von Ressourcen für die bis zu 649 anderen Datenbanken auf dem Server). Somit ist es verständlich, dass man keinen Datenbank-Server in Azure anlegt, sondern einen logischen Server - es wird Zeit dies auch zu tun Anlegen eines logischen Servers Um eine Azure SQL Datenbank anzulegen, muss entweder im Zuge des Anlegens dieser oder schon zuvor ein logischer Server mit angelegt werden. Dies ist im Azure Management Portal durch Anwahl des Bereichs SQL-DATENBANKEN auf der linken Seite und danach durch einen Klick auf SERVER möglich. Abbildung 3.3: Anlegen eines logischen Datenbank-Servers unter Azure Dieser logische Server erhält nach dem Anlegen automatisch einen Namen - die Region, der Benutzername für die Administration, sowie das Passwort sind frei wählbar. Die Region sollte der Region entsprechen, die den Anwendern am nächsten ist bzw. in der gleichen Region wo auch weitere Azure Dienste( wie z.b. Azure Webseiten) installiert sind, die diesen Datenbankserver verwenden. Damit kann eine optimale Performance zwischen diesen Diensten gewährleistet werden.

75 Hamboeck / Azure für Entwickler 71 Abbildung 3.4: Anlegen des logischen Servers mit Namen, Kennwort und Region Nach dem Anlegen des Servers kann dieser im Azure Management Portal angewählt werden. Abbildung 3.5: Angelegter logischer Datenbankserver Ist der Datenbank-Server angewählt, kann der Link für die Verwaltung angewählt werden: Abbildung 3.6: Details des logischen Servers und der Link zur Verwaltung

76 72 Hamboeck / Azure für Entwickler Diese Aktion liefert allerdings eine Fehlermeldung, da die momentane IP-Adresse nicht in den Ausnahmeregeln der Azure Firewall konfiguriert ist - das lässt sich aber mit Drücken des JA auf der linken Seite sofort beheben. Abbildung 3.7: IP-Adresse zur Firewall hinzufügen Danach öffnet sich ein weiteres Browser-Fenster und die Silverlight Applikation zur Verwaltung ist zu sehen. Abbildung 3.8: Verwaltungsfenster für Azure SQL Server Zu sehen ist der Name des Servers, sowohl im Azure Management Portal, als auch in der Verwaltungs-Applikation. In meinem Beispiel ist das nh8xlt6qwd, bzw. der komplette Name ist nh8xlt6qwd.database.windows.net, womit auch schon alle Informationen zur Verfügung stehen, um einen Connection-String zusammenzubauen: Data Source=nh8xlt6qwd.database.windows.net;Initial Catalog=master;User ID=svobi;Password=*********** Azure SQL Server Connection String Dieser setzt sich aus der Data Source, der User ID und dem Passwort zusammen. Alle drei Werte, die während des Anlegens selbst vergeben wurden. Auch eine Verbindung über

77 Hamboeck / Azure für Entwickler 73 das Sql Server Management Studio (Tip: für den doch komplexen Server-Bezeichnungen kann über den SQL Server Configuration Manager ein Alias für den logischen Server vergeben werden), oder Visual Studio ist problemlos möglich allerdings nur von Rechnern, die in der Firewall Rule vorhanden sind. Abbildung 3.9: Anmeldedialog in SSMS, bzw. in Visual Studio 2015 Bestehende Applikationen könnten wir nun also verbinden, aber bisher existiert noch keine Datenbank in unserem Datenbankserver unter Azure. Es wird Zeit dies zu ändern, zuvor sollten wir uns aber den Unterschieden in der Funktionalität zwischen einer Azure SQL Datenbank und einer On-Premise Datenbank widmen! 3.3 Fehlende SQLServer Features in Azure SQL Azure SQL unterstützt derzeit nur ein Subset an Features im Vergleich zu einer lokalen Installation, die Einschränkungen sind bereits merkbar, wenn man versucht, eine bestehende Datenbank unter Azure SQL zum Laufen zu bekommen. Das wird vermutlich erst einmal kläglich scheitern, da bestimmt Features verwendet wurden, die es hier schlicht und einfach nicht gibt. Eine Aufstellung der fehlenden SQL Server Features ist in der nachfolgenden Tabelle dargestellt.

78 74 Hamboeck / Azure für Entwickler Fehlende SQL Server Funktionalität in Azure SQL Master Data Services Change Data Capture Auditing Datenkomprimierung Extended Events Common Language Runtime (CLR) Verwaltung externer Schlüssel/Erweiterbare Schlüsselverwaltung (EKM-Provider) FILESTREAM-Daten (FileTables) Integrierte Volltextsuche User-Defined Aggregates (UDAs) User-Defined Types (UDTs) SQL Server-Replikation Transparente Datenverschlüsselung Erweiterte gespeicherte Prozeduren Datenbankspiegelung Service Broker Tabellenpartitionierung Typisiertes XML und XML-Indizierung Datenbanksicherung und Wiederherstellung SQL Server-Agent/-Aufträge Ressourcenkontrolle (Resource Govenor) Sammlung von Leistungsdaten (DataCollector) Richtlinienbasierte Verwaltung (Policies) Tabelle 3.1: Feature.Unterschiede SQLServer und Azure SQL Ich möchte ein paar der fehlenden Punkte herausgreifen, um deren Bedeutung für Entwickler herauszustreichen und zu beschreiben, wo möglicherweise Handlungsbedarf in bereits existierenden Applikationen besteht, wenn diese unter SQL Azure laufen sollen. 1. Heap-Tabellen also Tabellen ohne Clustered Index - finden keine Unterstützung in SQL Azure (ausser in der tempdb). Das ist nicht wirklich eine große Sache, da eine Tabelle mit einem Clustered Index sowieso meist die bessere Wahl gegenüber einer Tabelle ohne Clustered Index ist. Durch den beschriebenen Aufbau von Azure SQL sind Cross-Datenbank-Refenzen in SQL Azure nicht möglich.das bedeutet, dass ein USE- Statement nicht existiert. Es gibt auch kein Statement, wie CREATE TABLE tempdb.dbo.test ( col1 int not null ) ist nicht erlaubt, möglich ist hingegen CREATE TABLE #Test ( col1 int not null ) In einem herkömmlichen SQL Server können Daten aus verschiedenen Datenbanken kombiniert werden, wenn man den Namen vollqualifiziert angibt - in einer Azure SQL funktioniert dies nicht. 2. Aus dem vorigen Punkt ergibt sich damit auch, dass Linked Server in Azure SQL nicht existieren.

79 Hamboeck / Azure für Entwickler Fulltext Indizierung und Fulltext Search wird derzeit nicht unterstützt. 4. Der Default für den Transaction Isolation Level in SQL Azure ist READ_COMMITTED_SNAPSHOT - im SQL Server hingegen READ_COMMITTED. Dies kann ebenfalls Auswirkungen auf Client Applikationen haben. 5. Es gibt keinen SQL Server Agent in SQL Azure. Es gibt also keinerlei Unterstützung für Funktionalitäten, wie Jobs, Change Data Capture, DataCollector, Policies oder weitere Features, die den SQL Server Agent benötigen. 6. Fehlende Data Encryption (sowohl auf Column-Level Ebene als auch transparente Data Encryption) 7. Keine Unterstützung für user defined Common Language Runtime (CLR) Assemblies. Auch die von Microsoft implementierten CLR Features werden nicht unterstützt (wie z. B. NEWSEQUENTIALID(), oder die Geo-Datentypen GEOGRAPHY und GEOMETRY). 8. Keine FILEGROUPS 9. Keine System Tabellen. Würde also beispielsweise in Applikationen über die System Tabellen die Struktur der Datenbank dynamisch ausgelesen, müsste dieser Teil der Applikation umgeschrieben werden. Data Management Views sind allerdings vorhanden und wurden im Dezember 2014 sogar um weitere 44 DMVs ergänzt. 10. Backup/Restore, so wie man es von einem lokalen SQL Serverkennt, existiert unter Azure SQL nicht. Die Daten selbst sind gegen Hardwareausfall ja geschützt, aber was ist mit fehlerhaften Eingaben von Anwendern wenn ein Anwender etwas löscht, was er nicht sollte? Normalerweise würde der Administrator die Datenbank mittels Transaction-Log Backups wieder herstellen, in Azure SQL ist das allerdings etwas anders, dazu später noch mehr. Sollten diese Hindernisse erfolgreich gemeistert sein und die Datenbank unter Azure SQL laufen, können allerdings zur Laufzeit durchaus weitere, bisher nicht bekannte Probleme auftreten, da unter Azure SQL die zur Verfügung stehenden Ressourcen limitiert werden. Die Datenbank ist ja schließlich nicht alleine auf dem Server im Datacenter, sondern teilt sich diesen mit anderen Datenbanken. Folgendes sollte in der eigenen Applikation beachtet werden: 1. Auf einem lokalen SQL Server wird eine Verbindung, die Idle ist, nahezu niemals beendet. Falls dies dennoch geschieht, dann ist ein schwerwiegender Fehler aufgetreten. In SQL Azure wird eine solche Verbindung nach 30 Minuten beendet, eine Fehlermeldung wird nicht geworfen, da ja keine aktive Anfrage läuft. Errst bei der nächsten Verwendung der Verbindung kommt es zu einem Fehler. Dies ist in einer Applikation zu beachten, insbesondere, wenn man auf Connection Pooling setzt. 2. SQL Azure beendet Transaktionen, die länger als 24 Stunden laufen. Die Fehlernummer ist

80 76 Hamboeck / Azure für Entwickler 3. Sessions, die mehr als eine Million Locks produzieren werden beendet. Falls dies geschieht, tritt die Fehlermeldung auf. Die Dynamic Management View (DMV) sys.dm_tran_locks liefert Informationen zu Locks in SQL Azure. 4. Log-File Größe: Verbindungen, die in einer einzelnen Transaktion mehr als 2GB an Log-Speicherplatz benötigen, werden von Azure SQL beendet. Der Fehlercode wird retourniert. 5. Sollten Sessions in Azure SQL länger als 20 Sekunden auf freien Speicher warten, dann werden andere Sessions, die mehr als 16MB über einen Zeitraum von 20 Sekunden verbraucht haben, beendet. Begonnen wird bei der ältesten Sessions und solange, bis genügend Speicher für die anderen Sessions zur Verfügung stehen. Wenn die Verbindung aus diesem Grund beendet wurde, erhält man die Fehlernummer Wie man deutlich erkennen kann, ist ein gutes Fehlerhandling in Applikationen bestimmt nicht von Nachteil, auch die Unterscheidung des Fehlers ist von Vorteil, da möglicherweise ein sofortiger zweiter Versuch der gewünschten Transaktion erfolgreich abgeschlossen werden kann. Jetzt wollen wir aber eine neue Datenbank unter Azure SQL anlegen, dazu gibt es mehrere Möglichkeiten. 3.4 Anlegen einer Datenbank in Azure SQL Das Anlegen einer Azure SQL Datenbank kann auf verschiedene Arten erfolgen Anlegen einer DB mit dem Windows Azure Management Portal Im Azure Management Portal können Azure SQL Datenbanken auf 3 verschiedene Arten angelegt werden - mittels Schnellerfassung, Benutzerdefiniert, oder durch Importieren. Sehen wir uns die ersten beiden Varianten gleich einmal an, das Importieren verschieben wir auf einen ezwas späteren Zeitpunkt in diesem Kapitel. SCHNELLERFASSUNG Nach erfolgter Anmeldung im Azure Management Portal kann umgehend eine neue Azure SQL-Datenbank angelegt werden, dazu ist auf der linken Seite in auf die Auswahl SQL- DATENBANKEN zu klicken und auf das +NEU Icon links unten. Abbildung 3.10: Anlegen einer neuen Datenbank im Azure Management Portal

81 Hamboeck / Azure für Entwickler 77 Es öffnet sich ein neues Fenster, wobei der Bereich Datendienste, SQL-DATENBANK und SCHNELLERFASSUNG bereits vorausgewählt sind. Es sind nur noch Werte für den Datenbanknamen, das Abonnement und den Server anzugeben, bzw. auszuwählen. Abbildung 3.11: Anlegen einer neuen Datenbank Ein bereits existierender logischer Server kann in der Auswahlliste angewählt werden, falls noch kein Server angelegt wurde, dann kann an dieser Stelle ein neuer Server angelegt werden. Nicht zu vernachlässigen ist die Region des Datenbankservers, da dieser mit einer etwaigen Web-Applikation gemeinsam verwendet wird. Diese beiden sollten für optimale Performance in der gleichen Region angesiedelt sein. Nach dem Drücken des folgenden Links ist die Datenbank auch schon verfügbar: Dabei handelt es sich um eine Standard Datenbank vom Typ S0, mit einer maximalen Größe von 250GB. Abbildung 3.12: Erstellte Datenbank mit dem Namen sqldb1.

82 78 Hamboeck / Azure für Entwickler Falls man mehr Kontrolle über die Erstellung haben möchte, bietet sich die zweite Variante, das Benutzerdefinierte Erstellen an. BENUTZERDEFINIERT ERSTELLEN Der Vorgang ist zu Beginn der Gleiche wie bei der Schnellerfassung, im Azure Management Portal auf der linken Seite auf die Auswahl SQL-DATENBANKEN klicken und auf das + Icon links unten anwählen, danach allerdings BENUTZERDEFINIERT ERSTELLEN verwenden. Abbildung 3.13: Anlegen einer benutzerdefinierten Datenbank im Azure Management Portal Es öffnet sich ein neues Fenster und es können nun mehrere Werte eingegeben, bzw. angewählt werden. Name, Abonnement und Server haben die gleiche Bedeutung, wie während der Schnellerstellung. Allerdings wurde hier als Beispiel ein existierender virtueller Azure Datenbankserver ausgewählt. Die Sortierung ist bereits passend vorausgewählt, eine Kontrolle schadet allerdings nicht, da eine Sortierung nach dem Erstellen der Datenbank nicht mehr geändert werden kann. Die Standardsortierung ist "SQL_Latin1_General_CP1_CI_AS": Lateinisches Wörterbuch, Codepage 1 (CP1), Groß-/Kleinschreibung (Case-Insensitive, CI) und Akzente (Accent- Sensitive, AS).

83 Hamboeck / Azure für Entwickler 79 Abbildung 3.14: Anlegen einer neuen Datenbank im Azure Management Portal Die Auswahl der Dienstebene wirkt sich auf die Leistungsfähigkeit und am Ende auch auf die Kosten aus, die später noch beleuchtet werden. Sehen wir uns zuerst an, für welchen Anwendungsfall eine Dienstebene die geeignete Wahl sein könnte. Die BASIC-Dienstebene stellt eine Datenbank mit maximal 2GB zur Verfügung und eignet sich hervorragend zum Einstieg in die Welt der Azure SQL-Datenbanken. Also z. B. schon während der Entwicklung einer Anwendung, denn dafür benötigt man häufig keine hohe Leistung. Möglicherweise auch als Produktivumgebung, wenn die Datenbank im Einzelbenutzermodus verwendet wird, da in dieser Verwendungsart normalerweise keine hohen Parallelitäts- und Leistungsansprüche an die Datenbank gestellt werden. Die Dienstebene BASIC bietet eine ideale Umgebung für die kostengünstige Datenbankentwicklung.

84 80 Hamboeck / Azure für Entwickler Wird eine Datenbank benötigt, die mehrere Benutzer gleichzeitig unterstützen muss - wie es z. B. für Webseiten mit mäßigem Datenverkehr oder Anwendungen für einzelne Abteilungen in einer kleinen Firma der Fall ist - die also einen höheren Ressourcenbedarf als bei BASIC haben, eignen sich die STANDARD-Dienstebene. Datenbanken bis zu 250GB sind hier möglich. Werden zahlreiche gleichzeitige Anforderungen gestellt oder hohe Spitzenlasten erzielt wie z. B. bei einer Website mit starkem Datenverkehr oder einer Anwendung, die zum Ausführen ihrer Vorgänge einen hohen Bedarf an CPU-, Arbeitsspeicher- oder E/A- Ressourcen hat oder aber auch wenn ein Datenbankvorgang über einen längeren Zeitraum mehrere CPUs nutzt - empfiehlt sich die Verwendung der PREMIUM-Dienstebene. Auch wenn schnelle Antwortzeiten unbedingt notwendig sein müssen, dann ist diese Dienstebene zu empfehlen, da hier die PREMIUM-Dienstebene sicherstellt, dass Rechenleistung verfügbar ist. Hier sind Datenbanken bis zu 500GB möglich. Die Web- und Business-Dienstebene der Azure SQL-Datenbank werden im September 2015 eingestellt. Basic, Standard und Premium werden die Web und Business Dienstebenen ersetzen. Abbildung 3.15: Erstellte Datenbanken, sqldb1 als benutzerdefinierte Datenbank Anlegen mit PowerShell Eine alternative zum Anlegen mit dem Azure Management Portal ist das Anlegen der Datenbank mittels der PowerShell. Aufruf-Beispiel mit einem vorhandenen Server: New-AzureSqlDatabase -ServerName "nh8xlt6qwd" -DatabaseName "svobi4ps" -Edition "Basic" -MaxSizeGB 1 -Collation "SQL_Latin1_General_CP1_CI_AS"

85 Hamboeck / Azure für Entwickler 81 Abbildung 3.16: Anlegen der svobi4ps Datenbank mittels PowerShell Anlegen mit Microsoft SQL Server Management Studio oder Visual Studio Eine weitere Alternative beim Anlegen der Datenbank ist das Anlegen mittels SQL Server Management Studio (SSMS). Als Servername ist der logische Datenbank-Server einzugeben und als Login und Passwort die Zugangsdaten, die zum Zeitpunkt des Anlegens des logischen Datenbank-Servers vergeben wurden. Abbildung 3.17: Anmeldung im SSMS Wenn die IP-Adresse in den FireWall-Rules im Azure Management Portal hinterlegt wurde, dann sollte der Zugriff auch klappen. Sollte der Anwender allerdings eine dynamische IP- Adresse besitzen, wie sie von manchen DSL-Providern vergeben wird, dann erscheint die folgende Fehlermeldung:

86 82 Hamboeck / Azure für Entwickler Abbildung 3.18: Fehlermeldung bedingt durch die Firewall-Rule Nachdem die Firewall-Rules angepasst wurden, wird der Zugriff nun klappen und im Object Explorer im SSMS erscheint nahezu das gewohnte Bild. Das Icon für den Server zeigt an, dass wir nun mit unserem Azure SQL Datenbankserver verbunden sind und nicht mit einer lokalen Installation. Nun kann wie gewohnt eine neue Datenbank durch Klick mit der rechten Maustaste auf den Datenbank-Knoten im Object-Explorer angelegt werden. Abbildung 3.19: SSMS Object Explorer und neue Datenbank Script. Alternativ dazu klappt natürlich auch das Anlegen der neuen Datenbank mittels TSQL-

87 Hamboeck / Azure für Entwickler 83 Abbildung 3.20: Neue Datenbank svobi5ssms Dieses TSQL-Statement würde die WEB-Dienstebene verwenden - was sich im Azure Management überprüfen lässt. Abbildung 3.21: Ändern der Dienstebene nach dem Anlegen im SSMS Der komplette Befehl zum Anlegen der Datenbank lässt uns auch die Größe der Datenbank angeben und als zweite Option die gewünschte Dienstebene, was sicherlich die empfehlenswertere Variante ist, da wie bereits erwähnt WEB (und BUSINESS)Dienstebenen nicht mehr aktiv sind und mit September 2015 ganz eingestellt werden. CREATE DATABASE svobi6ssms (MAXSIZE=1GB, EDITION='Basic') GO Das erfolgreiche Erzeugen der Datenbank lässt sich auch im Azure Management Portal überprüfen.

88 84 Hamboeck / Azure für Entwickler Abbildung 3.22: Neue Datenbank svobi5ssms im Azure Management Portal Code: Außerdem kann in Windeseile eine Kopie der Datenbank erstellt werden - mit dem TSQL- CREATE DATABASE svobi6ssmscopy AS COPY OF svobi6ssms Der Kopiervorgang passiert asynchron, d. h. die sofortige Rückmeldung im SSMS bedeutet nicht, dass der Vorgang schon beendet ist. Aber der aktuelle Status der Kopier- Operation kann mittels Abfrage der DMV dm_database_copies ermittelt werden: SELECT * FROM sys.dm_database_copies Anlegen mit C# und SQL Commands Als Entwickler legen wir auch gerne unsere Datenbanken per Code an, das klappt ebenfalls hervorragend mit den bekannten SqlClient-Kommandos. Man benötigt eine SqlClient Connection mit dem passenden ConnectionString und ein SQLCommand mit dem create database -statement. Code-Snippet 1: Anlegen mit SQLCommand using System; using System.Data.SqlClient; namespace CreateAzureDatabase class Program

89 Hamboeck / Azure für Entwickler 85 static void Main(string[] args) string connectionstring = "Data Source=nh8xlt6qwd.database.windows.net;Initial Catalog=master;User ID=svobi;Password=XXXXXXXX"; string sql = "CREATE DATABASE svobi6dev (MAXSIZE=1GB, EDITION='basic');"; using (SqlConnection connection = new SqlConnection(connectionString)) try Console.WriteLine("Connecting"); connection.open(); Console.WriteLine("Connected, now creating database"); SqlCommand command = new SqlCommand(sql, connection); command.executenonquery(); Console.WriteLine("Database created!"); catch (Exception ex) Console.WriteLine("Database creation FAILED:"); Console.WriteLine(ex.Message); Console.ReadKey(false);

90 86 Hamboeck / Azure für Entwickler Nach dem Ausführen der DOS-Applikation ist die Datenbank vorhanden, was wiederum im AzureManagement Portal nachzuweisen ist. Abbildung 3.23: Möglicherweise besteht aber auch schon eine SQL Server Datenbank, die in Azure SQL importiert werden soll - das wäre unser nächstes Thema in diesem Kapitel. 3.5 Importieren einer Datenbank zu Azure SQL Ein einfaches Backup und Restore Szenario, wie es bei lokalen SQL Server Installationen gang und gäbe ist, Datenbanken zu exportieren bzw. zu importieren, ist in Azure SQL nicht möglich. Das Schema als auch die Daten einer SQL Server Datenbank können zu Azure SQL nur mittels einer BACPAC-Datei migriert werden. Zu beachten sind die bereits erwähnten Einschränkungen, da in Azure SQL nun einmal nicht alle Features einer lokalen SQLServer Installation zur Verfügung stehen. Zum Ausprobieren des Imports eignet sich eine leere Datenbank, oder die für Azure SQL angepasste Version der Adventureworks 2012 Datenbank. Diese ist hier zu finden: und enthält alle notwendigen Skripte um die Adventureworks 2012 Datenbank lokal, oder auch sofort unter Azure SQL anzulegen. Um nun eine lokale Datenbank in Azure SQL zu importieren, kann im SSMS durch Rechts- Klick auf die lokal existierende Datenbank, danach durch Anwählen von Tasks Deploy Database to Windows Azure SQL Database eine Datenbank mit Hilfe eines Wizards angelegt werden.

91 Hamboeck / Azure für Entwickler 87 Abbildung 3.24: Es öffnet sich ein Fenster mit einem Wizard, der die gesamte Komplexität zum Erzeugen der BACPAC-Datei und dem Anlegen der Datenbank vor uns versteckt. Der Wizard verwendet die BACPAC-Datei um auch sofort die Datenbank anzulegen, es wird lediglich die Verbindung zum Azure Datenbank-Server benötigt (nh8xlt6qwd.database.windows.net, sowie Username und Passwort). Derzeit stehen in diesem Dialog leider nur die beiden veralteten Dienstebenen WEB und BUSINESS zur Verfügung. Es empfiehlt sich also im Anschluss die Dienstebene im Azure Management Portal anzupassen.

92 88 Hamboeck / Azure für Entwickler Abbildung 3.25: Im Azure Management Portal ist die importierte Datenbank zu sehen. Abbildung 3.26: Die migrierte Datenbank im Azure Management Portal

93 Hamboeck / Azure für Entwickler 89 Nach dem Anwählen der Datenbank kann über den Menüpunkt SKALIEREN die Dienstebene angepasst werden. Abbildung 3.27: Anpassen der Dienstebene In der Praxis kann das SQL Database Migration Wizard Tool durchaus hilfreich sein, wenn es sich um den Import einer bestehenden lokalen Datenbank handelt. Dieses ist hier zu finden: Es unterstützt den SQLServer ab Version 2008R2 bis Anlegen einer Datenbank klappt somit schon hervorragend auf verschiedene Arten - kommen wir nun zu einem Szenario, welches unvermeidbar ist. Was macht man im Fehlerfall, was, wenn Daten teilweise oder komplett wieder hergestellt werden müssen und wie kann man sich darauf vorbereiten? 3.6 Backup & Restore Wenn doch einmal etwas passiert, wenn Daten bzw. Datenbank wieder hergestellt werden müssen, dann wird es interessant. Für das Disaster Recovery in Azure SQL Database gibt es vier Varianten. 1. Die einfachste Option ist das Point in Time- Restore. Dieses wird automatisch mit einer Azure SQL Datenbank mitgeliefert. D. h. es werden automatisch tägliche Backups (um Mitternacht) angelegt und dann wird ein Datenbank-Restore, je nach Dienstebene, für Zeiträume innerhalb der letzten 7, 13, oder 35 Tage durchgeführt. 2. Die Geo-Restore Option ist dem Point in Time Restore ähnlich, nur dass das tägliche Backup in einer anderen geographischen Region (siehe Kapitel 1) als der originalen Datenbank-Region abgelegt wird. Falls also in einem Datacenter etwas Schlimmes passieren würde, wären die Daten in der zweiten Region immer noch vorhanden. Wie beim Point in Time Restore, ist das Geo-Restore in Azure SQL fix integriert und für alle Dienstebenen vorhanden Die beiden besten Azure SQL Disaster Recovery Optionen sind die Standard Geo- Replikation und die Active Geo-Replikation. Beide Optionen replizieren Änderungen

94 90 Hamboeck / Azure für Entwickler von der primären Datenbank in die beiden sekundären Datenbanken. Dies geschieht asynchron, die Transaktionen werden gepuffert und blockieren den Client nicht. Der große Unterschied zwischen diesen beiden ist das Zeitfenster, innerhalb dem die Datenbank wieder verfügbar ist, und der maximale Datenverlust. Des Weiteren ist die sekundäre Datenbank bei der Standard Geo-Replication nicht lesefähig, bei der Active Geo-Replication allerdings schon, was diese zu einem idealen Kandidaten für Reporting-Applikationen macht (sofern man die Premium Dienstebene gewählt hat). Die nachfolgende Tabelle zeigt die verschiedenen Optionen und die zugehörige Dienstebene, wobei folgendes angeben ist: - RTO steht für Recovery Time Objective - das ist die maximale Downtime bevor die Applikation, bzw. Datenbank nach einem Fehlerfall wieder zur Verfügung steht und - RPO steht für Recovery Point Objective - das ist der maximale aktzeptable Datenverlust zwischen dem Zeitpunkt der letzten Sicherung und des Systemausfalls. Disaster Recovery Typ Basic Standard Premium Point-in-time restore Jeder Restore Point der letzten 7 Tage Jeder Restore Point der letzten 14 Tage Jeder Restore Point der letzten 35 Tage Geo-restore RTO < 24 Stunden RPO < 24 Stunden RTO < 24 Stunden RPO< 24 Stunden RTO < 24 Stunden RPO < 24 Stunden Standard geo-replication Nicht verfügbar RTO < 2 Stunden RPO < 30 Minuten RTO < 2 Stunden RPO < 30 Minuten Active geo-replication Nicht verfügbar Nicht verfügbar RTO < 1 Stunden RPO < 5 Minuten Tabelle 3.2: Optionen für das Point in Time Restore nach Dienstebenen Weitere Möglichkeiten, um die Datenbank auch selbst zu sichern sind: 1. Eine einfache Möglichkeit die Datenbank unter Azure zu sichern ist das database copy -Kommando, der Nachteil hierbei ist, dass die Kosten für eine zweite Datenbank zu tragen sind. 2. Mit der Verwendung des BACPAC-Exports in den Azure Blob Storage, können die Kosten für eine zweite Datenbank vermieden werden. Blob-Storage ist um ein Vielfaches billiger als eine weitere Datenbank. Allerdings hat man hier wiederum genauso wenig die Möglichkeit, ein transactional oder differential Backup durchzuführen, wie man es von der On-Premise Variante gewohnt ist.

95 Hamboeck / Azure für Entwickler Mittels 3rd-Party-Tools, die den Bulk-Copy Vorgang vereinfachen. Ich möchte an dieser Stelle zwei Tools nennen, die in C# geschrieben sind. Zum einen ist das das SQL Azure Backup Tool, hier zu finden: und SQL Azure BCP, welches den Load-Prozess mittels einer XML Datei definiert, es ist hier zu finden: Wie auch immer man sich entscheidet, es schadet bestimmt nicht, die eine oder andere Variante schon im Vorfeld zu testen, damit man im Fehlerfall weiß, welche Möglichkeiten zur Verfügung stehen. Weiter geht es mit dem Point in Time Restore. 3.7 Durchführen eines Point in Time Restore Im Azure Management Portal kann die tägliche Sicherung einer Azure SQL Datenbank wieder hergestellt werden. Dazu ist die Datenbank anzuwählen und der Button Wiederherstellen zu drücken. Abbildung 3.28: Es öffnet sich ein neues Fenster in dem der Name der neuen Datenbank anzugeben ist, sowie der Wiederherstellungszeitpunkt. In dem unteren Beispiel handelt es sich um eine Datenbank mit der Dienstebene BASIC, damit stehen maximal 7 Tage zur Verfügung. Die Datenbank kann nicht unter dem gleichen Namen wie die existierende wieder hergestellt werden. Also muss die Datenbank mit einem neuen Namen wieder hergestellt werden, dann die Originaldatenbank gelöscht werden und danach die neue Datenbank auf den alten Namen geändert werden.

96 92 Hamboeck / Azure für Entwickler Abbildung 3.29: Das Wiederherstellen der Datenbank dauert einige Zeit, sogar bei kleinen Datenbanken dauert dies einige Minuten. Der Vorgang kann mit der DMV sys.dm_operation_status überwacht, bzw. überprüft werden. Select * from sys.dm_operation_status where operation = 'DATABASE RESTORE' Ein Teil des Ergebnisses sieht wie folgt aus: Abbildung 3.30: Ergebnis der DMV nach dem Restore Die Datenbank kann im SSMS gelöscht werden und die neue Datenbank auf den originalen Namen umbenannt werden. drop database [hambodb] go alter database [hambodb_ t18-29z] modify name = [hambodb] go

97 Hamboeck / Azure für Entwickler 93 Es könnte allerdings auch interessant sein, eine lokale Datenbank in Azure selbst zu sichern, was ebenfalls möglich ist und nachfolgend gezeigt wird. 3.8 Backup einer On-Premise Datenbank in den Azure Storage Das Microsoft SQL Server Backup to Microsoft Azure -Tool ermöglicht die Sicherung in den Azure-BLOB-Speicher, und verschlüsselt und komprimiert SQL Server-Sicherungen, die lokal oder in der Cloud gespeichert werden. In SQL Server 2014 ist diese Tool bereits in SSMS integriert, für ältere Versionen steht es als Download zur Verfügung: Bevor Backups erstellt werden, muss ein Storage Account (svobistore) und ein zugehöriger Container (dbrestore) vorhanden sein. Also benötigen wir zuerst einmal ein Speicher-Konto. Dieser ist über das Azure Management Portal gleich einmal angelegt. Dazu in der Dienst-Auswahl den Speicher auswählen und den NEU Button drücken. Abbildung 3.31: Neuer Speicher Dienst Es öffnet sich ein neues Fenster, in dem der Name des Speicher-Kontos anzugeben ist, die Region, wo die Daten gespeichert werden und die Art der Daten-Replikation. Dazu mehr erst im nächsten Kapitel, ich habe für dieses Beispiel folgende Werte angegeben: 6. URL: svobistore 7. Standort: Nordeuropa 8. Replikation: Lokal redundant

98 94 Hamboeck / Azure für Entwickler Abbildung 3.32: Anlegen des Speicher-Kontos Sobald das Speicher-Konto angelegt ist, sollten wir uns gleich den Zugriffsschlüssel merken, diesen benötigen wir dann nämlich im SSMS, um die BACPAC-Datei in einen Container des Speicher-Kontos hochzuladen. Diesen erhalten wir durch Drücken des Buttons ZUGRIFFSSCHLÜSSEL VERWALTEN in der unteren Menüleiste, wenn der neu angelegte Speicher-Dienst angewählt ist. Abbildung 3.33: Anzeige des Zugriffschlüssels Es öffnet sich ein neues Fenster, wo der Name des Speicherkontos und die beiden Zugriffschlüssel angezeigt werden. Der primäre Zugriffschlüssel kann mittels des kleinen Buttons rechts neben dem angezeigten Schlüssel in das Clipboard kopiert werden. Abbildung 3.34: Zugriffschlüssel kopieren

99 Hamboeck / Azure für Entwickler 95 Jetzt muss noch der Container innerhalb des Speicher-Kontos angelegt werden. Ich habe diesen dbrestore genannt. Abbildung 3.35: Storage und Container für das Backup im Azure Management Portal Der nächste Schritt ist, den Zugriffsschlüssel im SQL Server als Credential zu hinterlegen. Das Anlegen des Credentials mit dem Namen AzureCredentials für den Container svobistore funktioniert am besten im SSMS mit ein paar Zeilen T-SQL: IF NOT EXISTS (SELECT * FROM sys.credentials WHERE credential_identity = 'AzureCredentials') CREATE CREDENTIAL AzureCredentials WITH IDENTITY = 'svobistore',secret = '<storage access key>' ; Ist der Storage-Account und der Container vorhanden, sowie die Credentials im SQL Server hinterlegt, dann kann es mit dem Backup losgehen. Im SSMS ist dann auf der Datenbank mittels der rechten Maustaste und den Menüeinträgen Tasks-> Backup die Datenbanksicherung zu konfigurieren. Abbildung 3.36: Backup der AdventureWorks 2012 Datenbank

100 96 Hamboeck / Azure für Entwickler Es öffnet sich das altbekannte Backup-Fenster, es muss allerdings als Ziel URL angewählt werden (der Default FILE darf nicht beibehalten werden). Die SQL Credentials, die wir zuvor angelegt haben, sollten in der Auswahl zur Verfügung stehen. Der Azure Storage Container ist unser Container mit dem Namen dbrestore. Abbildung 3.37: Konfiguration des Backups in den Azure Storage Wurde nicht das CREATE CREDENTIAL Statement ausgeführt, dann kann das Gleiche auch mit dem Create -Button erreicht werden - allerdings benötigt man dann ein AzurePublishSettingsFile, das man mit der PowerShell und dem Befehl: Get- AzurePublishSettingsFile erhält. Optional sollte allerdings auch das direkte Browsen zu folgender URL klappen: Danach kann das File in dem Dialog ausgewählt werden und der Storage Account angegeben werden. Der Create-Button legt dann das CREDENTIAL an. Mit dem OK Button wird das Backup in den Azure Storage gestartet und im Azure Management Portal ist das Resultat einsehbar.

101 Hamboeck / Azure für Entwickler 97 Abbildung 3.38: Adventureworks 2012 Backup als Azure Page Blob Code: T-SQL Statement für das Backup in den Azure Speicher-Dienst USE master; GO IF NOT EXISTS (SELECT * FROM sys.credentials WHERE credential_identity = 'AzureCredentials') CREATE CREDENTIAL AzureCredentials WITH IDENTITY = 'svobistore',secret = '<storage access key>' ; -- Display the newly created credential SELECT * from sys.credentials -- Create a backup in Windows Azure Storage. BACKUP DATABASE AdventureWorks2012 TO URL = ' bak' GO WITH CREDENTIAL = 'AzureCredentials',COMPRESSION,STATS = 5; Damit befindet sich das Backup im Speicher-Dienst. Es empfiehlt sich auch das Restoren der Datenbank vorab einmal zu testen, damit im Fall des Falles alles gut geht.

102 98 Hamboeck / Azure für Entwickler 3.9 Restore einer On-Premise Datenbank aus dem Azure Storage Das einzige Problem bei der Durchführung des Restore ist, dass SSMS den Zugriff auf den Storage-Dienst und den zugehörigen Container mittels einer sogenannten SHARED ACCESS SIGNATURE erhält. Am einfachsten bekommt man diesen mit dem Tool Azure Storage Explorer, dieses ist hier zu finden: Nach der Installation und dem Verbinden mit dem eigenen Speicher-Dienst, kann die SHARED ACCESS SIGNATURE erzeugt werden. Abbildung 3.39: Azure Storage Explorer und Shared Access Signature. Der für das SSMS benötigte Teil sieht in meinem Beispiel so aus:

103 Hamboeck / Azure für Entwickler 99 sv= &sr=c&sig=4XdkEbH3seTzowt3BHHrn%2B51IKPsOpkL55WLKdhEOCU%3D&st= T23%3A00%3A00Z&se= T23%3A00%3A00Z&sp=rwl Jetzt ist auch schon alles vorhanden, was wir benötigen: die SHARED ACCESS SIGNATURE, um ein Credential für den Speicher-Dienst und dem zugehörigen Container anzulegen.. Code: T-SQL Statement für das Restore aus dem Azure Speicher-Dienst -- Create a Shared Access Signature credential CREATE CREDENTIAL [ WITH IDENTITY='SHARED ACCESS SIGNATURE', SECRET = 'sv= &sr=c&sig=4XdkEbH3seTzowt3BHHrn%2B51IKPsOpkL55WLKdhEOCU%3D&st= T23%3A00%3A00Z&se= T23%3A00%3A00Z&sp=rwl' GO USE master; GO RESTORE DATABASE AdventureWorks2012 FROM URL = ' bak' WITH CREDENTIAL = 'BackupCredential', REPLACE, MOVE 'AdventureWorks2012' TO 'C:\Backup\AdventureWorks2012.mdf', MOVE 'AdventureWorks2012_log' TO 'C:\Backup\AdventureWorks2012_log.ldf'; GO Damit sind wir für den Ernstfall perfekt gerüstet. Backups werden in der Cloud gespeichert. Im Ernstfall kann die lokale Datenbank wieder hergestellt werden. Kommen wir abschließend zu den Kosten einer Azure SQL Datenbank.

104 100 Hamboeck / Azure für Entwickler 3.10 Kosten der Azure SQL Datenbank Am einfachsten ist hier die Berechnung wiederum mit dem Azure Preisrechner Zur Wahl stehen die drei Dienstebenen BASIC, STANDARD und PREMIUM und die Leistungsebenen S0, S1 und S2, bzw. P1, P2 und P3. Abbildung 3.40: Kosten für Basic, Standard und Premium für 1 Datenbank (Stand Dez. 2014) Nicht zu vergessen ist der ausgehende Datenverkehr, dieser ist noch zu den Kosten aufzuaddieren (die ersten 5GB pro Monat sind frei). Abbildung 3.41: Kosten für ausgehende Daten von 200GB pro Monat (Stand Dez. 2014) 3.11 Zusammenfassung Azure SQL weist einige Unterschiede zu einer On-Premise Installation auf. Dies kann anfangs zu Problemen führen, wenn eine bestehende Datenbank zu Azure SQL migriert

105 Hamboeck / Azure für Entwickler 101 werden soll. Sobald diese Probleme der Datenbankstruktur und auch in der dazugehörigen Applikation überwunden sind, werden die Vorteile allerdings überwiegen. Tägliche Backups, die auswählbaren Dienstebenen können einem das Leben in einer Produktionsumgebung erleichtern. Die anfallenden Kosten sind berechenbar, alternative Speicherungsmöglichkeiten sehen wir uns im nächsten Kapitel an.

106 102 Hamboeck / Azure für Entwickler 4 Azure Storage In diesem Kapitel werden die Vorteile einer Cloud Lösung beschrieben. werden die Vorbehalte für einen möglichen Cloud-Einstieg beschrieben. wird erklärt, wo die Microsoft Cloud sich auf unserem Planeten befindet. die Fülle vorhandener Dienste aufgeführt. Seit längerem setzen sich in manchen Bereichen sogenannte NoSQL-Datenbanken durch. Auch Microsoft bietet diese Speicherungsmöglichkeit unter Azure an. Dieses Kapitel widmet sich dieser Art der Datenspeicherung unter Microsoft Azure, sowie wann welche der angebotenen Möglichkeiten verwendet werden kann. Stürzen wir uns also in das Abenteuer der NoSQL-Welt und fangen einmal mit der generellen Unterscheidung an, wie Daten abgelegt werden können: Zur Verfügung stehen uns 1. relationale Datenbanken und 2. NoSQL Datenbanken. Zerpflücken wir einmal 1. und danach 2., dann werden wir sehen, dass Microsoft hier wieder einmal mit Azure sehr innovativ unterwegs ist und uns schon heute Optionen für morgen anbietet! Als Entwickler wollen wir die angebotenen Möglichkeiten natürlich auch testen, mehr als einen Azure Account brauchen wir dazu erst einmal nicht, diesen haben wir ja seit Kapitel 1.

107 Hamboeck / Azure für Entwickler Relationale Datenbanken Ich selbst war sechs Jahre bei Sybase und kann daher voll und ganz verstehen, dass Microsoft den Source Code von Sybase vor langer Zeit gekauft hat und daraus ein großartiges Produkt mit dem Namen Microsoft SQLServer gemacht hat. Aber was macht relationale Datenbanksysteme so großartig? Ich bin mir ziemlich sicher, dass die meisten meiner Leser gelangweilt an die Decke starren, aber da sollten wir kurz durchtauchen, um möglicherweise im Anschluss eine komplett NEUE Welt (der Daten) kennen zu lernen und zu verstehen. Den Grundstein für relationale Datenbanksysteme (kurz RDBMS) legte ein gewisser Edgar Codd (von IBM), der im Jahre 1970 (also sogar vor meiner Zeit) zwölf Regeln aufstellte (Codd's 12 rules), die genau definieren, was denn ein System können sollte, um ein RDBMS zu sein. In den frühen 80er Jahren haben sich dann die ersten Hersteller mit diesem Thema auseinandergesetzt, und voila die Datenbanken, so wie wir sie (in den meisten Unternehmen) kennen, haben das Licht der Welt erblickt. Wir verwenden also einen Datenbankserver, der uns eine oder mehrere Datenbanken zur Verfügung stellt. In einer Datenbank befinden sich wiederum eine oder mehrere Tabellen in einem bestimmten Schema, mit Spalten von einem definierten Datentyp und natürlich unseren hoch geschätzten Datenzeilen ohne die unsere Datenbank recht leer aussehen würde. Wir finden in unseren Datenbanken Primärschlüssel, Fremdschlüssel und (hoffentlich auch) Indexe. Stored Procedures, Funktionen und Views wollen wir natürlich auch nicht vergessen. Wenn Daten geschrieben/gelesen/gelöscht werden, werden dazu von unseren Applikationen Transaktionen verwendet. Dass unsere Datenbank jederzeit konsistent ist (Stichwort ACID - Atomicity, Consistency, Isolation und Durability sichergestellt durch Transaktionsprotokoll, Locking Mechanismen und Isolation Level) setzen wir natürlich voraus. Beim Design und der Definition der Tabellen verwenden wir die Normalisierung, um die Redundanz der Daten zu minimieren und Anomalien im Bereich UPDATE und DELETE zu eliminieren bzw. um relationale Datenintegrität sicher zu stellen. Als Abfragesprache benutzen wir standardisiertes SQL. Ich denke, das war es im Schnelldurchlauf - zwar recht kompakt, aber hoffentlich verständlich zusammengefasst. In Summe doch etwas Großartiges, was sich in all den Jahren auf Basis dieser 12 Regeln entwickelt hat! CAP-Theorem RDBMS sind eine feine Sache, allerdings geraten wir mit den, in den letzten Jahren immer häufiger auftretenden, großen Mengen an Daten ein klein wenig in Schwierigkeiten. Diese wollen nicht mehr so recht in einen einzigen Server hineinpassen (irgendwann hat auch das Aufrüsten mit größeren und leistungsstärkeren Festplatten, zusätzlichem Speicher und stärkeren Prozessoren ein Ende erreicht), also werden diese zu einem verteilten System. Das ist aber nicht der einzige Grund. Neben dem Ressourcenmangel gibt es aber noch weitere Gründe: Netzwerk-Bandbreite - die Performance auf einem einzigen Server ist abhängig davon,

108 104 Hamboeck / Azure für Entwickler wie schnell eingehende Anfragen empfangen und ausgehende Resultate gesendet werden können. Wenn die Netzwerklast die Kapazität des Netzwerkes übersteigt, kommt es zu Ausfällen und im Endeffekt zu unglücklichen Anwendern. Regionsabhängige Server möglicherweise wird es notwendig, Anwenderdaten in dem Land zu speichern, in dem diese anfallen (unter Azure gibt es die Auswahlmöglichkeit zwischen 15 Regionen, wo die Daten abgelegt werden können). Gründe dafür können gesetzlicher Natur sein, oder eben wieder die Performance (Latenz der Datenzugriffe) sein. Wenn Anwender in verschiedenen Teilen der Welt verstreut sind, ist es eben vermutlich besser, mehr als einen Server zur Verfügung zu stellen. Wenn zumindest einer dieser eben genannten Gründe zutrifft, dann werden relationale Datenbanken verteilt. Nun, das bringt uns zum sogenannten CAP-Theorem, da solche verteilten UND weiterhin leistbaren Systeme nur zwei, der drei folgenden Eigenschaften (die wir an relationalen Datenbanken so schätzen) erfüllen können: (C) Strong Consistency - Konsistenz: Jeder Client (gemeint sind Anwendungen, bzw. die Anwender) sieht zur selben Zeit dieselben Daten, auch bei Datenänderungen eben auch bei Transaktionen mit 2-Phase-Commits. (A) High Availability - Verfügbarkeit: Alle Anfragen von Clients an das Datenbanksystem werden jederzeit und mit akzeptabler Antwortzeit beantwortet. (P) Partition-Tolerance - Ausfallstoleranz: Das gesamte Datenbanksystem muss weiterhin stabil laufen, auch wenn einer der eingesetzten Server ausfällt oder neue Server hinzugefügt werden. Auch der Ausfall einer Kommunikationsverbindung muss verkraftet werden können, ohne dass die Clients etwas davon bemerken. Damit Daten auch nach Ausfall eines Servers vorhanden sind, werden sie repliziert auf verschiedenen Servern gespeichert. Relationale Datenbanksysteme sind am ehesten im Bereich CA zu finden. Konsistenz der Daten hat üblicherweise bei den relationalen Systemen oberste Priorität (mittels Transaktionen und ACID). Den Anforderungen nach Ausfalltoleranz und Verfügbarkeit wird man meist durch sehr hochwertige und sehr leistungsfähige Hardware (im wahrsten Sinne des Wortes) Rechnung tragen. Grafisch lässt sich das so darstellen:

109 Hamboeck / Azure für Entwickler 105 Abbildung 4.1: Was ist aber nun mit CP und PA? Hier können die NoSQL-Datenbanken eine Lücke schließen und so betreten wir das Land der NoSQL-Datenspeicherung (und wir können an dieser Stelle auch erahnen, warum). 4.2 NoSQL Datenbanken Beginnen wir zuerst mit der Definition von NoSQL: Wir könnten uns mit dem Namen Not only SQL zufrieden geben, aber da steckt mehr dahinter, nämlich die Datenbanken der nächsten Generation, diese sind nicht-relational verteilt Open-source, sowie horizontal skalierbar. Man könnte somit geneigt sein zu sagen: So ziemlich das Gegenteil von dem, was man (zumindest als Entwickler) bisher so geschätzt hat. Aber es kommt noch dicker, es gibt da noch weitere Anregungen, was eine NoSQL-Datenbank so bietet: einfache Replikation, ein simples API sehr grosse Datenmengen

110 106 Hamboeck / Azure für Entwickler und das Allerbeste hebe ich mir für den Schluss auf: Schema-Frei und EVENTUELL konsistent. Das eventuell konsistent beschränkt sich allerdings auf einen Zeitraum, letztendlich sind die Daten in einem konsistenten Zustand. Ich hoffe, die alteingesessenen Datenbank-Hasen unter euch sitzen immer noch halbwegs gerade auf dem Sessel (dabei habt ihr möglicherweise ein simples API sogar überlesen, was so viel bedeutet, wie Non-SQL als Abfragesprache)? Ja, das ist schon starker Tobak, klingt aber durchaus durchdacht, wenn wir uns die fünf NoSQL-Technologien ansehen, die es am Markt gibt: Key/Value Stores speichern der Daten mit einem Partition Key und einem Row Key. Column Stores quasi eine Erweiterung der Key/Value Stores um eine weitere Gruppierung. Document Stores Speicherung von Objektstrukturen im JSON-Format. Graph Databases wenn die Beziehungen zwischen den Daten im Vordergrund liegen Big Data Analytics Analysieren von (unvorstellbar) großen Datenmengen. Da ein Bild mehr als 1000 Worte sagen kann, möchte ich die NoSQL-Technologien grafisch veranschaulichen: Abbildung 4.2: Ich möchte nun jede einzelne dieser NoSQL-Technologien beleuchten und deren Einsatzgebiete herausstreichen Key/Value Stores Es gibt hier verschiedene Implementierungen, in Microsoft Azure heißt der NoSQL Key/Value Store, Azure Table Storage. Um Daten im Table Storage zu speichern, wird eine Tabelle (heißt zwar so, hat aber keine Ähnlichkeit mit einer relationalen Datenbanktabelle)

111 Hamboeck / Azure für Entwickler 107 mit einem 2-teiligen Schlüssel und weitere Spalten für die Daten selbst benötigt. Dieser 2- teilige Schlüssel besteht aus: einem Partition-Key, nach diesem wird die Tabelle partitioniert und dem Row Key, dieser identifiziert die Zeile eindeutig INNERHALB der Partition (fast so wie der gewohnte Primary Key, aber eben nur beinahe). Weitere Entitäten (unsere altbekannten Spalten) können nach Belieben angelegt werden und haben einen Namen, einen Datentyp und (vermutlich) einen Wert. Ich hatte erst vor kurzem einen interessanten Anwendungsfall für einen Key/Value Store: Es sollte ein Sicherheitssystem mit sechs Kameras realisiert werden, diese laden die Bilder alle zwei Sekunden in die Azure Cloud (als Blob-Storage) hoch. In dem Key/Value Store wurde folgende Information gespeichert: Partition Key: Der Name der Applikation Row Key: Die ID der Kamera Daten: Der Name des aktuellen Azure Blobs und die Aufnahmezeit Natürlich wäre es möglich gewesen, eine relationale Datenbank zu verwenden, aber hier war der Preis ausschlaggebend, da der Azure Table Storage mit dem Azure Blob Storage sehr günstig ist und diese Lösung nur auf wenige im Jahr (ca. 25,--) kommt. Azure Table Storage ist, wie andere Implementierungen auch, auf Massendaten ausgelegt. Die Partitionen einer einzelnen Tabelle können sich über mehrere Maschinen verteilen. Ein Szenario also, wo wir mit relationalen Datenbanksystemen möglicherweise in Schwierigkeiten punkto Kosten kommen, da sie mit Sicherheit höher liegen. Dieses horizontale Partitionieren der Daten wird Sharding genannt. Windows Azure Table Storage führt das Sharding im Hintergrund aus und skaliert damit automatisch bei großen Datenmengen. Aber wie werden die Probleme gelöst, die bei relationalen Systemen auftreten würden? Jede Abfrage an einem Key/Value Storage kann nur eine Partition ansprechen, Joins sind nicht möglich. Darauf muss natürlich bereits während der Entwicklung der eigenen Applikation Rücksicht genommen werden. Wie eingangs erwähnt: Auch wir Entwickler müssen umdenken und diese neueren Konzepte erst umsetzen lernen. Daten, die also gemeinsam abgefragt werden wollen, müssen auch innerhalb einer Partition liegen das gilt übrigens auch für Transaktionen, diese gelten nur über eine Partition Column Stores Microsoft Azure bietet HBase (mit HDInsight, also Hadoop) als NoSQL Column Store Implementierung an. HBase, bzw. Column Store-NoSQL-Datenbanken erinnern stark an eine relationale Datenbank, da die Daten in Tabellen gespeichert werden, Zeilen, Schlüsseln, Spaltenfamilien, Spalten und Werte sind auch vorhanden. Also alles wie gehabt, nur ein neuer Name? Mitnichten. In HBase ist jede Datenzeile durch einen Key definiert, diese Datenzeile beinhaltet eine, oder mehrere Spalten, welche selbst wiederum Key/Value-Pairs darstellen.

112 108 Hamboeck / Azure für Entwickler Die Spaltennamen müssen nicht vordefiniert werden, das bedeutet, dass das Schema hier ebenfalls wiederum kein fixes ist im Gegensatz zu relationalen Datenbanken. Die Spalten in einer Datenzeile werden sortiert nach ihrem jeweiligen Namen abgelegt. Zusätzlich speichert HBase zu jeder Zeile einen Zeitstempel zur Versionierung - mit ab. Würde ein neuer Wert in eine der Spalten eingetragen, bleibt der alte Wert weiterhin erhalten. Anwendungsfall gefällig? Facebook-Messaging, dort wird genau diese Technologie verwendet, wobei als Zeilenschlüssel die Benutzer-IDs verwendet werden, als Spalten- Bezeichner Wörter, die in den Nachrichten der Anwender vorkommen, allerdings wird der Zeitstempel anders verwendet, da sich gesendete Nachrichten nicht mehr verändern können, es wird die Nachrichten ID abgelegt. Die beschriebene Art der Datenspeicherung ist ideal, wenn sehr viele Spalten in einer Datenzeile vorhanden sind und spezielle Bereiche gesucht werden. Dieser Satz, umgelegt auf das FaceBook-Messaging Szenario könnte einen zum Nachdenken bringen, was denn wohl alles mit dieser Technologie möglich ist. Als Entwickler kann man sich das als geschachtelte Hashtable oder Dictionary, mit einer Tiefe von 2 oder 3 Levels vorstellen. Was die Performance angeht, ist HBase skalierbar, wenn also mit großen Datenmengen von mehreren Gigabyte, oder sogar Terabyte gearbeitet wird, dann ist HBase interessant. Des Weiteren kann HBase Daten schnell replizieren, sodass im Fehlerfall fehlerhafte Knoten recht problemlos wieder hergestellt werden können Document Stores In einem Document Store werden sogenannte Dokumente gespeichert, darunter darf man sich aber nicht z. B Word Dokumente oder PPT-Dateien vorstellen. Was aber könnte es dann sein? Ein Beispiel: In einer relationalen Datenbank haben wir Tabellen und Spalten. Also ein festgelegtes Schema für die abzulegenden Daten. Was aber ist, wenn die Struktur, die wir als Entwickler verwenden, nicht in dieses Schema passt? Wie oft mussten wir schon das Datenbank-Schema in die Objekt-Struktur pressen, die man in der Anwendung verwendet? Natürlich wieder genau anders herum, wenn die Applikations-Daten persistiert werden sollen. Das war und ist lästig für den Entwickler. Hier wäre es um einiges einfacher, wenn das in der Applikation verwendete Format durchgängig in einem Document Store - zur Verfügung stehen könnte. Ein anderes Szenario wäre ein WCF-Service, welches Daten mittels Entity-Framework einliest und diese an einen HTML/JavaScript Client übertragen soll. Das ideale (universelle) Format dafür ist JSON (JavaScript Object Notation). Die Daten, die übertragen werden sind nun ebenso ein Dokument, welches in einem Document Store abgelegt werden könnte. Also eigentlich ein Objekt oder eine Objektstruktur als Dokument. Ein weiterer Anwendungsfall wäre ein Einkaufswagen in einer Shopping-Applikation. Die abgelegten Produkte haben unterschiedliche Eigenschaften also Objekte mit unterschiedlichen Strukturen - die durch das lose Schema einer JSON-Datei problemlos

113 Hamboeck / Azure für Entwickler 109 vorgehalten werden können was in einer relationalen Datenbank ungleich schwieriger wäre. So ein Einkaufswagen könnte im JSON-Format so aussehen: In einer DocumentDB können natürlich komplexere und längere Dokumente gespeichert werden, man stelle sich einen Blog-Eintrag und die zugehörigen Kommentare vor, ein Summenfeld mit der Anzahl der Kommentare, Erscheinungsdatum, usw. Die Azure DocumentDB befindet sich momentan in der Preview-Phase und kann für die neugierigen Entwickler unter euch getestet werden Graph Databases Was wäre, wenn die Verbindung zwischen den Daten genauso wichtig, oder sogar wichtiger wäre als erst einmal die Daten selbst? Ich durfte drei Jahre lang an einem Projekt zur Bekämpfung von Geldwäsche mitarbeiten, wo wir genau den eben angesprochenen Fall hatten. Es ist interessant, wie Überweisungen, Personen und Firmen in Beziehung stehen und zuerst einmal gar nicht die zugrunde liegenden Daten selbst. In so einem Fall sind Graph Databases der geeignete Anwendungsfall.

114 110 Hamboeck / Azure für Entwickler Unter Azure gibt es keinen Vertreter dieser Gattung, der populärste ist hier Neo4J, welches aber unter Azure verwendet werden kann. Wie der Name schon erahnen lässt, werden die Daten als Graph abgelegt. In Neo4J werden die Daten als Knoten bezeichnet, die Verbindungen zwischen den einzelnen Knoten sind Beziehungen. Sowohl Knoten als auch Beziehungen können Eigenschaften aufweisen die uns nun schon gut bekannten Name/Value Pairs. Neo4J arbeitet (mittlerweile wenig überraschend) ohne festem Schema, somit können die Eigenschaften jede beliebige Information beinhalten. Eine typische Abfrage in Neo4J beinhaltet den Startpunkt (ein einzelner Knoten im Graphen), die zu matchenden Daten, und die Knoten, zu dem Beziehungen und Eigenschaften zu retournieren sind Big Data Analytics Hier sind wir bei einem meiner Lieblingsthemen angelangt. Hadoop, bzw. unter Microsoft Azure HDInsight. Dazu gibt es einen eigenen Blog-Eintrag, auf den ich an dieser Stelle gerne verweisen möchte, da die Beschreibung von MapReduce, Hive und Pig dieses Mal den Rahmen sprengen würde. 4.3 Datenkonsistenz in NoSQL-Datenbanken Da Daten zu mehreren Servern repliziert werden - einer verteilt die Daten an mehrere stellt sich die Frage der Datenkonsistenz beim Zugriff auf ebendiese, da das Verteilen der Daten Zeit benötigt. Was passiert nun, wenn Clients auf diese Daten in der Zeit während die Synchronisation läuft zugreifen? Welche Daten sind denn nun für diese Clients sichtbar? In der NoSQL-Welt unterscheidet man zwischen Strong Consistency und Eventual Consistency. Aus der relationalen Welt sind wir Strong Consistency (read committed) gewohnt, das heißt alle Clients sehen immer die gleichen (korrekten) Daten, auch, wenn sofort noch während das Schreiben der Daten läuft - gelesen wird. Wenn das System nun nur Eventual Consistency unterstützt würden Clients alte Daten geliefert bekommen, da diese eventuell auf einen Server zugreifen, wo die Daten noch nicht synchronisiert wurden. Klingt absurd und unbrauchbar? Nun, ist es wirklich so wichtig in einem Blog die allerletzten Kommentare (sofort) zu sehen? Oder in einem FaceBook Beitrag? Man sieht also, es kommt ein wenig auf die Anwendung an, wofür das System eingesetzt wird. Zwei weitere Consistency Level, die zwischen den beiden genannten liegen sind Bounded Staleness und Session. Ersterer garantiert konsistentes Schreiben mit verzögerten Lesezugriffen für alle Clients, letzterer garantiert die Datenkonsistenz für den aktiven Client für seine eigenen Lese- und Schreibzugriffe. Wie sieht das unter Microsoft Azure aus? Azure Table Storage verwendet Strong Consistency, garantiert also die aktuellen Daten bei einem lesenden und schreibenden Zugriff durch mehrere, bzw. verschiedene Clients.

115 Hamboeck / Azure für Entwickler 111 Azure DocumentDB lässt uns die freie Wahl zwischen Strong, Bounded Stateless, Session, oder Eventual Consistency. HBase verwendet Strongly Consistent Lese- und Schreib-Zugriffe Die Wahl des Consistency-Levels beeinflusst natürlich die Performance des Systems, wird Strong Consistency eingesetzt ist das die langsamste Variante für Lese- und Schreibzugriffe, Eventual Consistency die Schnellste. 4.4 RDBMS und/oder NoSQL? Wie sollen nun neue Projekte entwickelt werden? Setzen wir in Zukunft NUR NOCH auf NoSQL? Fügen wir die NoSQL-Technologien erst einmal zu dem zuvor gezeigten Bild hinzu, so ergibt sich ein Gesamtbild und wir können uns überlegen, wie wir weiter vorgehen könnten: Abbildung 4.3: NoSQL ist typischerweise eine gute Wahl, wenn es sich um unstrukturierte, bzw. Daten ohne festem Schema handelt. Das Schema muss nicht extra er- bzw. gefunden werden,

116 112 Hamboeck / Azure für Entwickler Erweiterungen mit neuen Feldern sind in Hinsicht auf die Speicherung - problemlos zu verarbeiten. Eine denormalisierte Form der Daten wird nicht nur favorisiert, sondern ist sogar notwendig, da keinerlei Joins, zumindest in der Art und Weise wie diese in relationalen Systemen gehandhabt werden, Unterstützung finden. Lösungen, die mittels NoSQL implementiert werden, lassen sich häufig einfach besser skalieren als relationale Datenbanklösungen. Das Hinzufügen weiterer Datenknoten ist einfach, die Daten werden meist repliziert, daraus ergibt sich in Summe auch einen besseren Schutz gegen Datenverlust. Allerdings bieten die NoSQL-Lösungen nicht die Möglichkeit von ACID-Transaktionen über mehrere "Tabellen". Desweitern gilt natürlich, dass komplexe und/oder dynamische Abfragen, bzw. Berichte am besten von einem relationalen Datenbanksystem bedient werden. Die Abfragemöglichkeiten von NoSQL-Lösungen sind dafür einfach zu limitiert was ja auch nicht im Sinne der Erfindung wäre. Wie sehr häufig im Leben gibt es nicht das allgemein gültige Kochrezept, es muss also nicht immer das Eine oder das Andere sein. Für bestimmte Gesamtlösungen kann ich mir ohne Weiteres eine Hybrid-Form - die Kombination eines relationalen Systems mit einem NoSQL-System vorstellen. Microsoft ist mit Windows Azure und den angebotenen Storage-Möglichkeiten im NoSQL- Bereich meiner Meinung nach ein Vorreiter und Visionär. Hier wird Technologie geboten, die die meisten Unternehmen noch nicht ausreichend anzuwenden wissen. Die Möglichkeiten, die sich hier für Entwickler und Firmen bieten, um neue Applikationen und Dienste anbieten zu können, sind großartig und werden vermutlich erst in den nächsten Jahren ihr volles Potential entfalten. Wir alle müssen uns erst auf diese Technologien einlassen und ihnen auch das Vertrauen entgegen bringen, das diese meiner Meinung nach auch verdienen. Es sind nicht neue Technologien, da diese größtenteils schon jahrelang im Einsatz, aber der breiten Business-Community bisher verborgen geblieben sind. Microsoft leistet hier mit der Azure Plattform eine großartige Möglichkeit all diese Technologien zu testen und neue Visionen umzusetzen. 4.5 Ablegen von Daten mit Azure Storage In diesem Abschnitt wird das Speichern und Abrufen von Daten in den Windows Azure- Speicherdiensten beschrieben. Die Windows Azure-Speicherdienste setzen sich aus den folgenden Elementen zusammen: BLOBs Speichern unstrukturierter Binär- und Textdaten. Warteschlangen Speichern von Nachrichten für den späteren Zugriff durch Clients und Bereitstellen einer zuverlässigen Messagingstruktur für die Kommunikation zwischen Rolleninstanzen. Tabellen Speichern nicht relationaler, allerdings strukturierter Daten.

117 Hamboeck / Azure für Entwickler 113 Um diese Unter-Dienste verwenden zu können, ist ein Speicherkonto anzulegen. Ein Speicherkonto wird mit einem eindeutigen Namen angelegt und stellt somit einen eindeutigen Namespace für die spätere Verwendung von Blobs, Warteschlangen und Tabellen bereit. Die Grenzen eines Speicherkontos unter Azure sind derzeit: 200 TB Blob-, Warteschlangen- und Tabellendaten. Maximal 20 Speicherkonten unter einem Abonnement. Speicherkosten basieren auf vier Faktoren: Der Speicherkapazität die Menge des verwendeten Speichers Der Speichertransaktionen die Anzahl der Lese- und Schreibvorgänge im Azure- Speicher. Datenausgang - wenn eine Anwendung, die nicht in der gleichen Region ausgeführt wird auf die Daten in Ihrem Speicherkonto zugreift, fallen Gebühren für den Datenausgang an (gleichgültig, ob es ein weiterer Cloud-Dienst, oder eine andere Anwendung ist). Dem Replikationsschema abhängig vom gewählten Schema fallen verschieden Kosten an, dazu nachfolgend mehr. Beim Anlegen des Speicherkontos ist die Art der Replikation anzugeben, es gibt hier 4 Auswahlmöglichkeiten. Abbildung 4.4: Auswahl der Daten-Replikation Bei der Auswahl sollte man sowohl auf die persönlichen Anforderungen - wie z. B. MÜSSEN diese an einem einzelnen Ort gespeichert bleiben (Unternehmensrichtlinien), bzw. MÜSSEN diese an einem anderen (zweiten) Ort gespeichert werden (Datensicherheit) - als auch auf die anfallenden Kosten achten. Die Auswahlmöglichkeiten sind im Detail:

118 114 Hamboeck / Azure für Entwickler Lokal redundanter Speicher (LRS) die Daten werden drei Mal innerhalb des gleichen Rechenzentrums repliziert. Die Daten verlassen den Standort nicht, und sind gegen Hardware-Ausfälle gesichert. Georedundanter Speicher (GRS) - die Daten werden (asynchron, weitere drei Mal) an einem sekundären Standort in einer zweiten Region repliziert werden. Auf diese Weise wird Failover zum zweiten Standort im Falle eines größeren Ausfalls am primären Standort ermöglicht. Ein Zugriff auf diese zweite Region ist nur im Katastrophenfall möglich. Lesezugriff (georedundant) empfohlen für Produktiv-Systeme, die auf den Azure Storage zugreifen, da von der zweiten Region die Daten jederzeit gelesen werden können. Zonenredundant erst seit August 2014 verfügbar und ist technisch zwischen dem LRS und GRS angesiedelt, da hier ebenfalls 3 Kopien der Daten über 2 bis 3 Datacenter abgelegt werden. Alle drei Kopien bleiben in der gleichen Region, kann aber vom System auf eine zweite Region ausgedehnt werden. Derzeit ist die Nutzung noch auf block blobs eingeschränkt. Anlegen eines Speicher-Kontos: Um Daten in Azure zu speichern muss zuerst ein Speicher-Konto angelegt werden. Das ist innerhalb von wenigen Minuten im Azure Portal unter erledigt. Dazu wählt man auf der linken Seite Speicher an und klickt auf das große + Zeichen darunter.

119 Hamboeck / Azure für Entwickler 115 Abbildung 4.5: Danach sind folgende Schritte durchzuführen: Der Punkt Schnellerfassung ist anzuwählen (im Gegensatz zu anderen Diensten gibt es hier keine andere Auswahlmöglichkeit) Im Feld URL, ist der Name des Speicher-Kontos anzugeben. Im Prinzip ist dieser frei wählbar, es müssen 3-24 Buchstaben, bzw. Nummern sein. Die komplette URI (der eingegebene Name mit.core.windows.net) wird später dazu verwendet die Blob-, Queue-, oder Tabellen-Speicher für diese Azure Subscription anzusprechen. Die Standardendpunkte für ein Speicherkonto haben die folgenden Formate: o o o Blob-Dienst: <speicherkonto>.blob.core.windows.net Tabellendienst: <speicherkonto>.table.core.windows.net Queuedienst: Die Region, bzw. Affinitäts-Gruppe, wo der Speicher physikalisch von Azure abgelegt wird. Es empfiehlt sich der zu dem Anwender nächstgelegene Speicherort, also z. B. Nordeuropa, bzw. Westeuropa für Deutschland. Österreich und die Schweiz. Falls der Speicher-Dienst gemeinsam mit z. B. einer Webseite, oder HDInsight verwendet wird, dann sollte die Region mit dem anderen Dienst übereinstimmen, um die Performance (spürbar) zu erhöhen. Die Art der Daten-Replikation, die für dieses Speicher-Konto von Azure angewendet

120 116 Hamboeck / Azure für Entwickler werden soll. Geo-Redundant ist der Default und bedeutet, dass die Daten zusätzlich in einem zweiten Datacenter gespeichert werden. Falls es sich um Testdaten handelt, empfiehlt es sich aus Kostengründen hier auf Lokal-Redundant umzustellen, die drei malige redundante Speicherung im gleichen Datacenter ist hier ausreichend sicher für diese Daten. Abschließend kann der Dienst mittels SPEICHERKONTO ERSTELLEN angelegt werden. Sofern das nicht schon in Kapitel 2 geschehen ist, sollten wir das gleich einmal durchführen, ich habe den Store svobistore genannt, die Region ist die Gleiche, wie ich diese in Kapitel 2 für Azure SQL verwendet habe. Mehr zu den Regionen wurde in Kapitel 1 geschrieben. Das Abonnement haben wir ebenfalls aus Kapitel 1, die Replikation ist Lokal redundant, d. h. die Daten verlassen mein Datacenter in Nordeuropa nicht, auch nicht zu einem zweiten Datacenter in der gleichen Region. Abbildung 4.6: Anlegen eines Speicherkontos Das Speicherkonto wird umgehend erstellt und ist im Azure Portal sofort anwählbar Abbildung 4.7: Angelegtes Speicherkonten Wird ein Speicherkonto angeklickt, dann ist am unteren Rand ein Menü mit 3 Buttons sichtbar.

121 Hamboeck / Azure für Entwickler 117 Abbildung 4.8: Aktionen für das Speicherkonto Die möglichen Aktionen sind: Zugriffschlüssel verwalten: Wenn ein Speicherkonto erstellt wurde, generiert Azure zwei 512-Bit-Speicherzugriffsschlüssel, die für die Authentifizierung verwendet werden können, bzw. müssen, wenn ein Zugriff auf das Speicherkonto erfolgen soll mehr dazu gleich, wenn auf Blobs mit C# zugegriffen wird. Domäne verwalten das Speicherkonto kann mit dem eigenen Domänennamen verknüpft werden siehe Kapitel Azure Websites Löschen wird das Speicherkonto nicht mehr benötigt, kann es gelöscht werden. Die Art der Replikation die sich auch auf die Kosten auswirkt kann im Azure Management Portal am Azure-Storage unter KONFIGURIEREN überprüft werden. Abbildung 4.9: Kontrolle der Replikation im Azure Management Portal Mit einem angelegten Speicherkonto können nun Daten gespeichert und abgelegt werden, zuvor sollten aber ein, zwei nützliche Tools installiert werden Nützliche Tools für den Azure Storage Microsoft stellt die Azure Tools for Visual Studio zur Verfügung, mit diesen können Blob-, Queue-, und Table-Container in einem Storage Account begutachtet und auch bearbeitet werden, diese werden mit dem Azure SDK installiert, welches hier zu finden ist:

122 118 Hamboeck / Azure für Entwickler Abbildung 4.10: Visual Studio Server Explorer Als weiteres Tool bietet sich der Azure Storage Explorer an, dieser wurde bereits im Kapitel 3 verewendet und ist hier zu finden: Abbildung 4.11: Azure Storage Explorer

123 Hamboeck / Azure für Entwickler 119 Nun sind wir perfekt gerüstet, um den Azure-Storage anzuprogrammieren Verwenden des BLOB-Speichers - Übersicht Ich habe als Beispiel eine kleine WPF-Applikation gewählt, diese kann folgende Funktionalität am Azure-Blob-Storage zeigen: eine beliebige Datei in den Blob-Storage hochladen und speichern den Inhalt des Blob-Storage anzeigen eine Datei aus dem Blob-Storage herunterladen eine Datei aus dem Blob-Storage löschen Die GUI für diese Desktop Applikation sieht wie folgt aus, das komplette Beispiel ist im Software-Download für dieses Buch zu finden: Abbildung 4.12: WPF Blob-Storage Applikation Um diese Applikation zu bauen, sind folgende Schritte notwendig: Erstellen der GUI Hinzufügen des NuGet Packages (WindowsAzure.Storage) Konfigurieren des Connection-Strings zum Blob-Storage Erstellen einer Klasse zur Kommunikation mit dem Azure Blob-Storage Die Beispielapplikation soll Dateien zu einem Azure-Storage-Container hochladen,

124 120 Hamboeck / Azure für Entwickler herunterladen, den Inhalt abfragen, sowie löschen können Verwenden des BLOB-Speichers - Implementierung Das Erstellen der GUI lasse ich in diesem Kapitel außen vor, diese ist in der Abbildung sehr gut zu erkennen, wir können uns also gleich dem Hinzufügen des NuGet Packages widmen, dieses hat den Namen WindowsAzure.Storage: Abbildung 4.13: NuGet Package WindowsAzure.Storage Im nächsten Schritt benötigen wir den Connection String, dafür legen wir am Besten ein Application-Setting an: Name: AzureStorageConnectionString Type: String Scope: Application Value: DefaultEndpointsProtocol=https;AccountName=svobistore;AccountKey =nzojxxv2dog9mbmya+la5rzgylmzrj+8ozquhzptrwuq2bxadbsq/cet3wl0rqw +ztdr0dniqt29i35xqwapda== Der AccountName ist der Name des Blob-Storage, den AccountKey erhält man über ZUGRIFFSCHLÜSSEL VERWALTEN (wie weiter oben beschrieben).

125 Hamboeck / Azure für Entwickler 121 Abbildung 4.14: Application-Setting für den Connection String Jetzt kann es auch schon losgehen mit dem eigentlichen Anprogrammieren des Azure- Blob-Storages. Dazu empfiehlt es sich eine neue Klasse anzulgen, ich habe dieser Klasse zwei Properties verpasst: ConnectionString: Das Application Setting, um Zugriff auf den Azure-Storage zu erhalten ContainerName: der Name des Containers innerhalb des Azure Blob-Storage Außerdem eine Methode, die eine Referenz auf den Container innerhalb des Azure-Blob- Storages retourniert. Diese legt den Container an, sollte dieser noch nicht innerhalb des Storage-Accounts vorhanden sein. Gerüst für die Klasse, um den Azure Blob-Storage anzusprechen using System.Collections.Generic; using System.Diagnostics; using System.IO; using System.Threading.Tasks; using Microsoft.WindowsAzure.Storage; using Microsoft.WindowsAzure.Storage.Blob; namespace AzureStorageDemo class SvobiStorageBlob public static string ConnectionString get; set; public static string ContainerName get; set; private static async Task<CloudBlobContainer> GetBlobContainer() //CloudConfigurationManager.GetSetting(ConnectionStringName) // Retrieve storage account from connection string. CloudStorageAccount storageaccount = CloudStorageAccount.Parse(ConnectionString); // Create the blob client. CloudBlobClient blobclient = storageaccount.createcloudblobclient(); // Retrieve reference to a previously created container.

126 122 Hamboeck / Azure für Entwickler CloudBlobContainer container = blobclient.getcontainerreference(containername); await container.createifnotexistsasync(); return container; Jetzt können wir uns zu dem Azure-Blob-Storage mit dem zugehörigen Container verbinden, es ist an der Zeit auch etwas mit dem Container zu tun. Beginnen wir mit dem Upload einer Datei. Code für den Upload in den Azure Blob-Storage-Container public static async void UploadBlob(string sourcefilename, string blobname) CloudBlobContainer container = await GetBlobContainer(); // Retrieve reference to a blob CloudBlockBlob blockblob = container.getblockblobreference(blobname); // Create or overwrite the blob with contents from a local file. using (var filestream = File.OpenRead(sourceFileName)) await blockblob.uploadfromstreamasync(filestream); Nun fehlt eigentlich nur noch der Aufruf aus dem Client heraus. Ich setze im Click-event für den Button zum Hochladen den ConnectionString und den Namen des Containers, danach wird unsere Methode zum Hochladen mit den zugehörigen Parametern (lokaler Dateiname und gewünschtem Dateinamen im Blob-Storage) aufgerufen. Da die Methode asynchrone Methoden verwendet, ist auch die Methode für den Click-Event mit async gekennzeichnet. Es wird zwar kein Resultat retourniert, der Aufruf müsste also nicht abgewartet werden, aber möglicherweise wird dieser Code ja später einmal erweitert. Auch ein try/catch-block würde in keinster Weise schaden, aber würde diesen Code (und auch den nachfolgenden) aufblähen, darum wurde in den Code-Beispielen weitgehend darauf verzichtet. Client Aufruf für den Upload in den Azure Blob-Storage-Container private async void UploadBlobButton_Click(object sender, RoutedEventArgs e) SvobiStorageBlob.ConnectionString = Properties.Settings.Default.AzureStorageConnectionString; SvobiStorageBlob.ContainerName = "svobiblobs"; var fullfilename = FileNameTextBox.Text;

127 Hamboeck / Azure für Entwickler 123 var filename = System.IO.Path.GetFileName(fullFileName); await SvobiStorageBlob.UploadBlob(fullFileName, filename); Wollen wir doch gleich einmal sehen, ob das auch wirklich geklappt hat und lesen wir den Inhalt des Containers zurück. Code für den Inhalt des Azure Blob-Storage-Container public static async Task<IEnumerable<IListBlobItem>> ListBlobs() CloudBlobContainer container = await GetBlobContainer(); IEnumerable<IListBlobItem> items = container.listblobs(null, false); foreach (IListBlobItem item in items) if (item.gettype() == typeof(cloudblockblob)) CloudBlockBlob blob = (CloudBlockBlob)item; Debug.WriteLine("Block blob of length 0: 1", blob.properties.length, blob.uri); else if (item.gettype() == typeof(cloudpageblob)) CloudPageBlob pageblob = (CloudPageBlob)item; Debug.WriteLine("Page blob of length 0: 1", pageblob.properties.length, pageblob.uri); else if (item.gettype() == typeof(cloudblobdirectory)) CloudBlobDirectory directory = (CloudBlobDirectory)item; Debug.WriteLine("Directory: 0", directory.uri); return items; Der Client ruft die Methode wiederum auf und nimmt die Liste in Empfang, diese kann mittels DataBinding z. B. an eine ListBox gebunden werden, wie in diesem Beispiel geschehen. Client Aufruf für den Inhalt des Azure Blob-Storage-Containers private async void ListBlobButton_Click(object sender, RoutedEventArgs e) SvobiStorageBlob.ConnectionString = Properties.Settings.Default.AzureStorageConnectionString; SvobiStorageBlob.ContainerName = "svobiblobs"; var items = await SvobiStorageBlob.ListBlobs(); BlobsListBox.ItemsSource = items;

128 124 Hamboeck / Azure für Entwickler bool blobsavailable = items.count() > 0; DeleteBlobButton.IsEnabled = blobsavailable; DownloadBlobButton.IsEnabled = blobsavailable; Eine Datei, die hochgeladen werden kann, möchte man möglicherweise auch wieder herunterladen. Ich habe nachfolgend zwei Methoden implementiert, um einen Azure-Blob aus dem Container herunterzuladen. Eine, die Binärdaten herunterlädt, eine zweite, die den Blob als Text-Datei speichert. Oft kennt man ja das Format, da kann es durchaus nützlich sein eine Text-Datei auch gleich als solche zu speichern, bzw. eine Binärdatei, wie ein Bild (.png,.jpg, usw.) auch als ebensolche. Code für das Herunterladen einer Datei aus dem Azure Blob-Storage-Container public static async Task DownloadBinaryBlob(string blobname, string localfilename) CloudBlobContainer container = await GetBlobContainer(); CloudBlockBlob blockblob = container.getblockblobreference(blobname); using (var filestream = File.OpenWrite(localFileName)) blockblob.downloadtostream(filestream); public static async Task<string> DownloadTextBlob(string blobname) CloudBlobContainer container = await GetBlobContainer(); CloudBlockBlob blockblob = container.getblockblobreference(blobname); string text = string.empty; using (var memorystream = new MemoryStream()) await blockblob.downloadtostreamasync(memorystream); text = System.Text.Encoding.UTF8.GetString(memoryStream.ToArray()); return text; Jetzt fehlt uns noch die Möglichkeit eine Datei aus dem Azure-Storage-Container zu löschen. Code für das Löschen einer Datei aus dem Azure Blob-Storage-Container public static async Task DeleteBlob(string blobname) CloudBlobContainer container = await GetBlobContainer();

129 Hamboeck / Azure für Entwickler 125 // Retrieve reference to the blob CloudBlockBlob blockblob = container.getblockblobreference(blobname); // Delete the blob. await blockblob.deleteasync(); Werden sehr große Datenmengen im Azure Blob-Storage benötigt, dann ist ein Upload möglicherweise nicht mehr möglich, da dieser zu lange dauern würde. Für solche Fälle bietet Microsoft den Azure Import/Export-Dienst für die Übertragung von Daten an Blob-Speicher an. Mit diesem Dienst ist es seit Mai 2014 möglich, Festplatten per FedEx an ein Microsoft Data-Center zu schicken, dort werden die Daten mit dem internen Microsoft Netzwerk in den Azure Storage von ebendieser Festplatte geladen, bzw. bei dem umgekehrten Weg aus dem Blob-Storage auf die Festplatte gespeichert. Folgende Voraussetzungen sind dabei zu beachten: Die Festplatte kann bis zu 4TB groß sein und MUSS mit BitLocker verschlüsselt sein. Es muss eine 3.5 Zoll SATA II/III interne Festplatte sein, allerdings listet Microsoft kompatible USB Devices. Microsoft stellt ein Tool zur Vorbereitung der Festplatte bereit, dieses nennt sich WAImportExport.exe und kann hier gefunden werden: US/download/details.aspx?id=42659 Nach der Vorbereitung der Festplatte kann im Azure Management Portal o o o o o Der Import/Export Job angelegt werden die Shipping-Adresse des Data-Centers ausfindig gemacht werden ein unterstützter Paketdienst angezeigt werden die Tracking-Nummern für die Sendungsverfolgung erfasst werden der Job gemanaged und gemonitored werden.

130 126 Hamboeck / Azure für Entwickler Abbildung 4.15: Anlegen eines Import/Export Jobs Widmen wir uns nun der nächsten NoSQL-Datenspeicherung, dem Azure Tabellenspeicher Verwenden des Tabellenspeichers Wenn eine große Datenmenge vorhanden ist, dann ist der Table Storage um einiges günstiger als Azure SQL. Nur, der Name ist für Datenbankhasen etwas irreführend, wie gesagt handelt es sich bei dem Table Storage um eine NoSQL-Datenspeicherung. Man kann den Table Storage quasi wie eine indizierte, sequentielle Datei verstehen. Es muss ein Partition Key (vom Typ string) für die Table angelegt werden, die so partitionierten Daten bleiben somit zusammen. Jetzt stellt sich die Frage, wie man den Partition Key vergibt. Daten innerhalb der gleichen Partition werden schneller gefunden, verschiedene Partitionen erlauben allerdings ein paralleles Suchen. Handelt es sich um Kundendaten, dann kann eine Partition nach Ländern der Kunden sinnvoll sein, oder nach einem gewissen Range der Kunden IDs. Zusätzlich wird ein Row Key benötigt (ebenfalls ein string), die beiden Keys gemeinsam ergeben den Primary Key für die Tabelle wobei der Row Key innerhalb der Partition eindeutig sein muss. Das wäre beispielsweise die Kunden ID, was als Row-Key allerdings nur recht selten sinnvoll ist, das ergibt sich aus dem Aufbau und den Möglichkeiten der Datenabfrage im Table Storage. Ja, wie kann man nun Daten im Table-Storage suchen? Es gibt ja eigentlich nur einen Clustered Index, der sich aus dem Partition Key und dem Row-Key zusammensetzt. Daraus ergibt sich, dass die performanteste Abfrage genau diese beiden Spaten einschließt. Die

131 Hamboeck / Azure für Entwickler 127 zweit beste Abfrage enthält nur den Partition-Key, gefolgt von einer Abfrage die eine Range von Partition-Keys, oder Row-Keys beinhaltet. Ganz schlecht sind Abfragen, die weder den Partition-Key, noch den Row-Key in der Abfrage inkludieren. Aber warum ist das so? Durch die zugrunde liegende Architektur des Azure Storage. Der sogenannte Partition Layer speichert die verschiedenen Objekte und verarbeitet die damit verbundenen Transaktionen. Der Partition Layer besteht aus dem Partition Manager, Partition Servers, und dem Lock Service. Der Partition Manager teilt die Objekte in RangePartitions auf und weist jede dieser RangePartition einem Partition Server zu, der wiederum den späteren Zugriff auf die gespeicherten Objekte sicherstellt. Durch das Lock Service ist garantiert, dass zu jedem Zeitpunkt nur ein Partition Server eine RangePartition zur Verfügung stellt. Wenn nun eine Abfrage mit (zumindest) dem Partition Key angegeben wird, dann wird auch nur ein Partition Server angesprochen. Werden in der Abfrage allerdings mehrere Partitionen abgefragt, dann wird mit hoher Wahrscheinlichkeit auch mehr als ein Partition Server angestoßen (ein Partition Server ist für mehrere Partitionen zuständig), was natürlich sowohl gut (parallele Abfrage), als auch schlecht ist (mehr Daten, längere Laufzeit der Abfrage, als bei nur einer Partition). Wenn nun kein Partition-Key oder Row-Key in der Abfrage angegeben wird, dann muss ein Table Scan durchgeführt werden. Indem ja auch kein Partition-Key angegeben wurde wird die Abfrage zu jedem Partition Server geschickt (falls ein Partition Key angegeben wird, dann wird die Abfrage nur zu einem spezifischen Partition Server gesendet und es wird nur ein Partition Scan durchgeführt). Daraus ergibt sich auch, dass es mit dem Azure Table Storage durchaus auch sinnvoll sein kann, die gleichen Daten in verschiedenen Tables bei großen Datenmengen, sonst auch in der gleichen Table - auf unterschiedliche Art (Partition-Keys, aber auch Row-Keys) zu speichern, je nachdem wonach sehr häufig gesucht wird der Nachteil ist hier die notwendige Synchronisation der Daten bei Änderungen. Als Beispiel sei hier ein Bestell-System angeführt mit drei Tabellen Customer, Order und OrderDetail. Eine ideale Partitionierung KÖNNTE wie folgt aussehen: Tabelle Partition-Key Row-Key Otpimierte Suche Customer Sales Region Customer ID nach Region und Kunden ID Order Customer ID Order ID für alle Bestellungen eines Kunden OrderDetail Order ID Product ID nach Bestellung und dem Produkt Tabelle: 4.1: Beipiel für den Partition-Key und Row-Key mehrerer Tabellen Da das Schema nicht streng vorgegeben ist, können verschiedenste Daten in einer Tabelle abgelegt werden, aber davon ist eher abzuraten, die Kollegen werden es Ihnen

132 128 Hamboeck / Azure für Entwickler danken, wenn diese einmal die Applikation warten müssen, weil sie auf Urlaub sind. Zu beachten ist auch die Größe eines Objektes, welches im AzureTable Storage gespeichert wird: Die gesamte Zeile darf 1MB nicht überschreiten Eine Spalte darf 64KB nicht überschreiten. Maximal sind 255 Spalten erlaubt (3 Spalten sind reserviert Partition-Key, Row-Key und der TimeStamp) Verwenden des Tabellen-Speichers Übersicht Ich habe die zuvor gezeigte WPF-Applikation erweitert, diese soll Datensätze aus einer JSON-Datei zu einem Azure-Table-Storage-Container hochladen und zwar jeden Datensatz einzeln, aber auch in einem Batch-Modus. Zusätzlich sollen Abfragemöglichkeiten gezeigt werden. Abbildung 4.16: WPF Azure Table Beispiel-Applikation Um diese Applikation zu bauen, sind folgende Schritte notwendig: Erstellen der GUI Hinzufügen des NuGet Packages (WindowsAzure.Storage) Konfigurieren des Connection-Strings zum Storage Account

133 Hamboeck / Azure für Entwickler 129 Erstellen einer Klasse zur Kommunikation mit dem Azure Table-Storage Also gleich an s Werk, die ersten Punkte sind schon im letzten Abschnitt erklärt, es kann also gleich mit der Klasse zur Kommunikation mit dem Azure-Table-Storage angelegt werden. Die Daten, welche in dem Azure Table Storage gespeichert werden sollen, kommen aus der AdventureWorksDW2012 Datenbank. Dbei handelt es sich um die Kundendaten aus dieser Datenbank, die Abfrage, die verwendet wurde liest das Country, den CustomerKey und den DisplayName aus der Datenbank aus und sieht folgendermaßen aus: SELECT g.englishcountryregionname as 'Country', c.customerkey, c.firstname + IsNull(' ' + c.middlename + '.', '') + ' ' + c.lastname as DisplayName FROM DimGeography g INNER JOIN DimCustomer c ON g.geographykey = c.geographykey Das Resultat wurde als CSV exportiert und in eine JSON-Datei umgewandelt. Die Datei ist im Code-Download enthalten und stellt jeden einzelnen Kunden zur Verfügung, das sieht z. B. so aus: "Country":"Australia", "CustomerKey":11000, "DisplayName":"Jon V. Yang" Verwenden des Tabellen-Speichers - Implementierung Es werden wiederum zwei Properties verwendet, der ConnectionString hält den Verbindungsstring zum Storage-Account. Da der Storage-Account vom Blob-Beispiel verwendet wird bleibt dieser gleich, der Container ist allerdings nun eine CloudTable. Um auf diese jederzeit in den weiteren Methoden Zugriff zu haben wird diese ebenfalls in einem Property in der Klasse gespeichert. Die Methode GetTableClient setzt diese auf die Azure- Tabelle, bei Bedarf wird die Tabelle auch sofort erzeugt. Code für den Zugriff einer Azure Table und dem Anlegen using Microsoft.WindowsAzure.Storage; using Microsoft.WindowsAzure.Storage.Table; using System.Collections.Generic; using System.Linq; using System.Threading.Tasks; namespace AzureStorageDemo

134 130 Hamboeck / Azure für Entwickler class SvobiStorageTable public static string ConnectionString get; set; public static string TableName get; set; private static CloudTable _currenttable; private static async Task<CloudTable> GetTableClient() // Retrieve the storage account from the connection string. CloudStorageAccount storageaccount = CloudStorageAccount.Parse(ConnectionString); // Create the table client. CloudTableClient tableclient = storageaccount.createcloudtableclient(); // Create the table if it doesn't exist. _currenttable = tableclient.gettablereference(tablename); await _currenttable.createifnotexistsasync(); return _currenttable; Damit zum Einfügen, bzw. Löschen einer Entität in eine Tabelle. Für das Einfügen stehen die Methoden zur Verfügung: TableOperation.Insert, TableOperation.InsertOrMerge und TableOperation.InsertOrReplace. Gelöscht werden kann eine Entität mit der TableOperation.Delete(entity) Methode. Code für das Einfügen einer Entität zu einer Azure-Table public static async Task<TableResult> InsertTableEntity(TableEntity entity) if (_currenttable == null) await GetTableClient(); // Create the TableOperation that inserts the entity. TableOperation insertoperation = TableOperation.Insert(entity); //TableOperation insertoperation = TableOperation.InsertOrMerge(entity); //TableOperation insertoperation = TableOperation.InsertOrReplace(entity); // Execute the insert operation. TableResult result = await _currenttable.executeasync(insertoperation); return result;

135 Hamboeck / Azure für Entwickler 131 Sollen mehrere Entitäten eingefügt werden, so empfiehlt es sich, dies im Batch-Betrieb durchzuführen, da jeder Batch nur als eine einzelne Transaktion bei der Berechnung der Kosten gilt. Dabei ist allerdings folgendes zu beachten: Alle Entitäten müssen in einem Batch den gleichen Partition Key haben. Es können nicht mehr als 100 Entitäten in einem Batch verschickt werden. Der Payload in einem Batch darf nicht mehr als 4MB sein. Diese Vorgaben resultieren in folgendem Code, der den Batch-Vorgang durhführt. Code für das Einfügen als Batch zu einer Azure-Table public static async Task InsertTableEntityBatch(List<CustomerEntity> entities) if (_currenttable == null) await GetTableClient(); TableBatchOperation batchoperations = new TableBatchOperation(); foreach (var group in entities.groupby(x => x.partitionkey)) foreach (var entity in group) if (batchoperations.count < 100) batchoperations.add( TableOperation.InsertOrReplace(entity)); else await _currenttable.executebatchasync(batchoperations); batchoperations = new TableBatchOperation TableOperation.InsertOrReplace(entity) ; if (batchoperations.count > 0) await _currenttable.executebatchasync(batchoperations); batchoperations = new TableBatchOperation(); Das Entfernen einer Table ist keine große Sache. Zu beachten ist möglicherweise, dass ein sofortiges Anlegen einer Tabelle mit dem gleichen Namen sehr wahrscheinlich nicht sofort klappt, da die Tabelle zuerst nur zum Löschen markiert wird und von einem Hintergrundprozess später entfernt wird, sowie die Tabelle drei Mal gelöscht werden muss.

136 132 Hamboeck / Azure für Entwickler Das bedeutet, dass der Vorgang noch aktiv sein kann, auch wenn die Methode schon beendet ist. Code für das Löschen einer Azure-Table public static async Task DeleteTable() if (_currenttable == null) await GetTableClient(); await _currenttable.deleteifexistsasync(); Jetzt fehlt noch die Definition der Entität, die in der Azure-Table gespeichert werden soll. In der Datei sind 3 Felder pro Kunde zu finden "Country, "CustomerKey", und der "DisplayName. Durch das Vererben der Klasse von TableEntity werden die Properties PartitionKey und RowKey zur Verfügung gestellt. Wir benötigen zwingend einen Konstruktor ohne Parameter (optional habe ich einen weiteren Konstruktor hinzugefügt, der alle Felder übernimmt). Da die Daten aus einer Datei kommen, welche am einfachsten mittels NewtonSoft.Json deserialisiert wird, werden alle drei Felder benötigt. Das Feld Country wird dabei als PartitionKey verwendet, das Feld CustomerKey als RowKey. Um die Felder nicht doppelt in der Azure Table aufscheinen zu lassen, werden diese mit dem [IgnoreProperty] Attribut versehen. Customer Klasse für den Table-Storage using Microsoft.WindowsAzure.Storage.Table; namespace AzureStorageDemo public class CustomerEntity : TableEntity public CustomerEntity(string country, string key, string displayname) this.partitionkey = country; this.rowkey = key; this.displayname = displayname; public CustomerEntity() [IgnoreProperty] public string Country get return this.partitionkey; set this.partitionkey = value;

137 Hamboeck / Azure für Entwickler 133 [IgnoreProperty] public string CustomerKey get return RowKey; set RowKey = value; public string DisplayName get; set; Jetzt kann es auch schon richtig zur Sache gehen, zuerst muss die Hilfsklasse mit dem ConnectionString und dem Namen des Azure-Table-Storage-Containers befüllt werden, das geschieht im Konstruktor für das MainWindow. Client-Initialisierung des ConnectionStrings und des Azure Table Namens public MainWindow() InitializeComponent(); SvobiStorageTable.ConnectionString = Properties.Settings.Default.AzureStorageConnectionString; SvobiStorageTable.TableName = "svobicustomers"; Der erste Button liest die Datei ein, erstellt ein Liste von CustomerEntity Objekten und geht diese in einer Schleife durch. Jede einzelne Customer-Entität wird dabei einzeln wegeschrieben, was als einzelne Transaktion für die Berechnung der Azure-Kosten gilt. Client Aufruf für das Senden einer Message in eine Azure-Table private async void SaveTableEntryButton_Click(object sender, RoutedEventArgs e) var json = File.ReadAllText(TableFileNameTextBox.Text); var customers = JsonConvert.DeserializeObject<List<CustomerEntity>>(json); foreach (var customer in customers) try var result = await SvobiStorageTable.InsertTableEntity(customer); TableInfoListBox.Items.Insert(0, result.etag); catch (Exception ex) TableInfoListBox.Items.Insert(0, ex.message);

138 134 Hamboeck / Azure für Entwickler Die Batch-Sepicherung ist hier vermutlich die bessere Wahl, diese ruft die zuvor beschriebene Methode zur Verarbeitung im Batch-Modus auf. Client Aufruf für die Batch-Speicherung in eine Azure-Table private async void SaveTableEntryBatchButton_Click(object sender, RoutedEventArgs e) var json = File.ReadAllText(TableFileNameTextBox.Text); var customers = JsonConvert.DeserializeObject<List<CustomerEntity>>(json); try TableInfoListBox.Items.Insert(0, DateTime.Now.ToLongTimeString() + " - Batch gestartet"); await SvobiStorageTable.InsertTableEntityBatch(customers); TableInfoListBox.Items.Insert(0, DateTime.Now.ToLongTimeString() + " - Batch beendet"); catch (Exception ex) TableInfoListBox.Items.Insert(0, ex.message); Das Löschen einer gesamten Tabelle ist zum Testen ebenfalls hilfreich. Client Aufruf für das Löschen einer Azure-Table private async void DeleteTableEntryButton_Click( object sender, RoutedEventArgs e) try await SvobiStorageTable.DeleteTable(); TableInfoListBox.Items.Insert(0, DateTime.Now.ToLongTimeString() + " - Löschen abgeschlossen"); catch (Exception ex) TableInfoListBox.Items.Insert(0, ex.message); Zur sofortigen Kontrolle der Azure-Table und ob der Upload geklappt hat, bietet sich der Server Explorer an.

139 Hamboeck / Azure für Entwickler 135 Abbildung 4.17: Ansicht der Azure-table in Visual Studio mit dem Server Explorer Die Daten sind erfolgreich in der Azure-Table gespeichert. Kommen wir nun zu den Abfragemöglichkeiten. Eine einzelne Entität mit der Angabe des Partiton-Keys und des Row-Keys ist am performantesten. Abfrage einer Azure-Table mit dem PartitionKey und dem RowKey public static async Task<CustomerEntity> GetTableEntityByPartitionAndRowKey(string partitionkey, string rowkey) TableOperation query = TableOperation.Retrieve<CustomerEntity>(partitionKey, rowkey); TableResult result = await _currenttable.executeasync(query); return (CustomerEntity)result.Result; Dicht gefolgt von einer Abfrage, die alle Entitäten einer Partition zurückgibt. Abfrage einer Azure-Table mit dem PartitionKey public static async Task<List<CustomerEntity>> GetTableEntitiesByPartition(string partitionkey) IQueryable<CustomerEntity> query =

140 136 Hamboeck / Azure für Entwickler _currenttable.createquery<customerentity>().where(x => x.partitionkey == partitionkey); return query.tolist(); Wiederum etwas mühsamer für den Azure-Table-Storage ist die Abfrage über den Row- Key, bzw. die Abfrage mehrerer Row-Keys. Abfrage einer Azure-Table mit dem RowKey public static async Task<List<CustomerEntity>> GetTableEntitiesByRowKey(string rowkey) IQueryable<CustomerEntity> query = _currenttable.createquery<customerentity>().where(x => x.rowkey == rowkey); return query.tolist(); Womit wir beim Table-Scan angelangt sind, es empfiehlt sich aus Gründen der Performance möglichst den Partition-Key bei solchen Abfragen mitzugeben. Abfrage einer Azure-Table über ein beliebiges Attribut public static async Task<List<CustomerEntity>> GetTableEntitiesByName(string displayname) IQueryable<CustomerEntity> query = _currenttable.createquery<customerentity>().where(x => x.displayname == displayname); return query.tolist(); Kommen wir nach dem Table-Storage nun zum Queue-Speicher Verwenden des Queue-Speichers Eine Queue ist eine Ansammlung von Messages, die nach dem FIFO (First In-First Out) Prinzip abgearbeitet werden, also z. B. genauso wie im wirklichen Leben vor einem Supermarktkassa. Als braver Kunde stellt man sich immer hinten an in der Warteschlange, derjenige der ganz vorne steht wird von der Kassiererin als Erster abgefertigt und die Warteschlange rückt nach. Genauso wie in einem Supermarkt, wo die Kunden aus allen Richtungen zur Kassa strömen, genauso können Messages von überall her, also auch von verschiedenen Applikationen, in die Queue gestellt werden. Diese Applikationen wissen möglicherweise auch nichts voneinander und auch der Inhalt kann verschieden sein. Wenn die Schlange im Supermarkt zu lange wird, dann wird häufig eine weitere Kassa geöffnet und die Warteschlange teilt sich auch auf die zweite Kassa auf. Auch das

141 Hamboeck / Azure für Entwickler 137 funktioniert im Prinzip genauso unter Azure Queues, es kann sowohl die Anzahl der Message- Consumer definiert werden, als auch die Anzahl von Messages, die abgearbeitet werden. Also, wenn man so will, handelt es sich bei Azure Queues um einen großen Supermarkt. Eine einzelne Queue-Message kann bis zu 64 KB an Daten mitsenden (Größe des Einkaufswagens), in einer Azure Queue können sich mehrere Millionen Messages ansammeln (da würde jedem Supermarkt-Chef der Schweiss ausbrechen bei so vielen Kunden), bis das Limit eines Storage-Accounts erreicht ist. Ein Storage Account kann insgesamt bis zu 200 TB an Daten (Blob, Queue, und Table gemeinsam) vorhalten, was wiederum eine Menge an Artikeln eines Supermarkts entspricht wobei die Daten, wie erwähnt, immer drei Mal vorgehalten werden, also jeder Artikel ist im Supermarkt drei Mal verfügbar. Ein möglicher Anwendungsfall unter Azure ist das Senden von s. Wenn sich beispielsweise ein neuer Kunde auf der Webseite registriert, dann wird die Information der Registrierung in eine Queue gestellt, das Bestätigungs wird dann von einem anderen Task gesendet, der periodisch die Queue ausliest. Somit müssen die Anwender nicht warten, bis die zugestellt wurde, was durchaus auch etwas länger dauern kann. Wir sehen uns ein ganz einfaches Beispiel an, um die Funktionsweise der Azure Queues kennenzulernen Verwenden des Queue-Speichers Übersicht Ich habe die Beispiel-Applikation, die bereits für den Azure-Blob-Storage verwendet wurde erweitert, um folgende Funktionalität für den Test der Azure Queues bereit zu stellen: Es ist möglich, verschiedene Messages in eine Azure Queue zu stellen. Das Beispiel soll Befehle übergeben (Gehen, Laufen, Stehen bleiben, Links drehen, Rechts drehen), die dann von einem Client aus der Queue ausgelesen werden. Der Message-Client wird durch einen Timer simuliert, der sich immer 1 Message holt und den Inhalt im Bereich Informationen/Resultate ausgibt. Die GUI für diese Desktop Applikation sieht wie folgt aus - das komplette Beispiel ist ebenfalls im Software-Download für dieses Buch zu finden:

142 138 Hamboeck / Azure für Entwickler Abbildung 4.18: WPF Azure Queue Beispiel-Applikation Um diese Applikation zu bauen, sind folgende Schritte notwendig: Erstellen der GUI Hinzufügen des NuGet Packages (WindowsAzure.Storage) Konfigurieren des Connection-Strings zum Blob-Storage Erstellen einer Klasse zur Kommunikation mit einer Azure Queue in einem Azure Blob- Storage Simulation eines Message-Clients durch einen Timer, der die Messages ausliest, den Inhalt ausgibt und die Message aus der Queue löscht. Die Beispielapplikation könnte beispielsweise zur Steuerung eines Roboters genutzt werden Verwenden des Queue -Speichers - Implementierung Das Erstellen der GUI lasse ich in diesem Kapitel wiederum außen vor, diese ist in der Abbildung sehr gut zu erkennen. Das Anlegen des ConnectionStrings wurde ebenfalls schon beschrieben und das Hinzufügen des NuGet Packages WindowsAzure.Storage ist auch schon erledigt. Kommen wir also gleich zum Anlegen der Klasse, in der die Kommunikation mit der Azure Queue abgehandelt wird. Wie schon beim Azure Blob-Storage benötigt man wieder den ConnectionString und dieses Mal den gewünschten Namen der Queue, dieser wird in zwei Properties vorgehalten.

143 Hamboeck / Azure für Entwickler 139 Desweiteren wird die Queue ebenfalls über die gesamte Laufzeit in einem Property vorgehalten, nachdem diese einmal angelegt, bzw. ein Zugriff darauf erfolgt ist. Code für den Zugriff einer Azure Queue und dem Anlegen using System; using System.Diagnostics; using System.Threading.Tasks; using Microsoft.WindowsAzure.Storage; using Microsoft.WindowsAzure.Storage.Queue; namespace AzureStorageDemo class SvobiStorageQueue public static string ConnectionString get; set; public static string QueueName get; set; private static CloudQueue _currentqueue; private static async Task<CloudQueue> GetCloudQueue() CloudStorageAccount storageaccount = CloudStorageAccount.Parse(ConnectionString); // Create the queue client CloudQueueClient queueclient = storageaccount.createcloudqueueclient(); // Retrieve a reference to a queue _currentqueue = queueclient.getqueuereference(queuename); // Create the queue if it doesn't already exist await _currentqueue.createifnotexistsasync(); return _currentqueue; Für etwaige spätere Aufräumarbeiten ist eine Methode zum Löschen der Queue bestimmt hilfreich. Code für das Löschen einer Azure Queue public static async Task DeleteQueue() // Delete the queue await _currentqueue.deleteasync();

144 140 Hamboeck / Azure für Entwickler Das Hinzufügen einer neuen Message klappt einfach, wenn man schon Zugriff auf die Queue hat. Es genügt das Instanziieren der Klasse CloudQueueMessage mit dem Inhalt der Message und danach das Hinzufügen des CloudQueueMessage-Objektes zu der Queue. Die Größe der Message darf 64KB nicht überschreiten, darauf ist zu achten, wenn z. B. ein JSON String erzeugt wird und dieser der Message übergeben wird und dieser muss im UTF-8 Format vorliegen. Code für das Senden einer neunen Message in eine Azure Queue public static async Task NewQueueMessage(string content) CloudQueueMessage message = new CloudQueueMessage(content); if (_currentqueue == null) await GetCloudQueue(); await _currentqueue.addmessageasync(message); Eine Meldung zurückzulesen ist über die Queue mit einem Methodenaufruf möglich. Der folgende Code liest die Message von der Queue, diese Message ist vom Zeitpunkt des Auslesens für 30 Sekunden für andere Clients nicht sichtbar. D. h. innerhalb dieser Zeitspanne sollte die Message auch aus der Queue gelöscht werden ansonsten wird nach dieser Zeitspanne die Message wieder sichtbar (sollte kein Löschen erfolgt sein). Dieses Vorgehen ist sinnvoll, da es durchaus vorkommen kann, dass der Client ein Problem hat (Software, Netzwerk,..) und ein erneuter Versuch des Auslesens, z. B. nach dem Neustart der Client-Applikation wiederum diese Message zur Verfügung stellt. Code für das Lesen einer Message in eine Azure Queue public static async Task<CloudQueueMessage> DeQueueMessage() // Get the next message CloudQueueMessage retrievedmessage = await _currentqueue.getmessageasync(); return retrievedmessage; Das Löschen der Message aus der Queue erfolgt durch Senden des CloudQueueMessage- Objektes, welches zuvor gelesen wurde. Code für das Löschen einer Message aus einer Azure Queue public static async Task DeleteMessage(CloudQueueMessage deletemessage) await _currentqueue.deletemessageasync(deletemessage);

145 Hamboeck / Azure für Entwickler 141 Es kann durchaus vorkommen, dass man eine Message nur ansehen möchte, ohne diese für 30 Sekunden von der Queue herunterzunehmen, dafür gibt es die PeekMessage Methode. Die Message bleibt dabei auch für andere Clients sichtbar. Code für das Senden einer neunen Message in eine Azure Queue public static async Task<CloudQueueMessage> PeekQueueMessage() CloudQueueMessage peekedmessage = await _currentqueue.peekmessageasync(); // Display message. Debug.WriteLine(peekedMessage.AsString); return peekedmessage; Ein Szenario mit Message in Queues kann auch sein, dass eine Message gelesen wird, der Content angepasst wird und die Meldung wieder zur Verfügung gestellt wird, das kann mit der UpdateMessage-Methode abgebildet. Code für das Senden einer neunen Message in eine Azure Queue public static async Task UpdateMassage(CloudQueueMessage message, string content) message.setmessagecontent(content); await _currentqueue.updatemessageasync(message, TimeSpan.FromSeconds(0.0), MessageUpdateFields.Content MessageUpdateFields.Visibility); Möglicherweise möchte man gerne die Anzahl der Messages in der Queue wissen. Code für das Abfragen der Anzahl an Messages in eine Azure Queue public static async Task<int?> GetQueueLength() await _currentqueue.fetchattributesasync(); int? cachedmessagecount = _currentqueue.approximatemessagecount; Debug.WriteLine("Number of messages in queue: " + cachedmessagecount); return cachedmessagecount; Kommen wir nun zur Nutzung der Klasse. Im ersten Schritt muss wiederum der ConnectionString aus unserem Application-Setting gesetzt werden. Da es sich um den

146 142 Hamboeck / Azure für Entwickler gleichen Azure-Storage-Account handelt, wie auch schon beim Blob-Storage-Beispiel kann hier der gleiche Wert verwendet werden. Des Weiteren der Name der Queue, ich habe mich für svobiqueue entschieden. Client-Initialisierung des ConnectionStrings und des Azure Queue Namens public MainWindow() InitializeComponent(); SvobiStorageQueue.ConnectionString = Properties.Settings.Default.AzureStorageConnectionString; SvobiStorageQueue.QueueName = "svobiqueue"; Der Button, der die Message in die Queue sendet, liest den ausgewählten Wert aus der ComboBox aus und schickt diese über die zuvor erstellte NewQueueMessage-Methode in der SvobiStorageQueue-Klasse an die Azure Queue. Client Aufruf für das Senden einer Message in eine Azure Queue private async void SendQueueButton_Click(object sender, RoutedEventArgs e) string content = ((ComboBoxItem)CommandComboBox.SelectedItem).Content.ToString(); await SvobiStorageQueue.NewQueueMessage(content); Der Button zum Pollen der Azure Queue verwendet einen DispatcherTimer, der jede Sekunde die Queue um eine Message bittet und sofern diese vorhanden ist, wird diese auch retourniert und im Informationsbereich ausgegeben. Client Aufrufe für das Auslesen einer Azure Queue DispatcherTimer _timer = null; private void StartReadingQueueButton_Click(object sender, RoutedEventArgs e) StartReadingQueueButton.IsEnabled = false; StopReadingQueueButton.IsEnabled = true; if (_timer == null) _timer = new DispatcherTimer(); _timer.interval = TimeSpan.FromSeconds(1); _timer.tick += timer_tick; _timer.start(); async void timer_tick(object sender, EventArgs e) var message = await SvobiStorageQueue.DeQueueMessage();

147 Hamboeck / Azure für Entwickler 143 if (message!= null) string infotext = string.format("0 - command: 1", DateTime.Now.ToLongTimeString(), message.asstring); QueueInfoListBox.Items.Insert(0,infoText); SvobiStorageQueue.DeleteMessage(message); private void StopReadingQueueButton_Click(object sender, RoutedEventArgs e) StartReadingQueueButton.IsEnabled = true; StopReadingQueueButton.IsEnabled = false; _timer.stop(); Kommen wir nun zu den Kosten dess Azure-Storage. 4.6 Kosten des Azure Storage Die Berechnung der Kosten erfolgt mit dem Azure Preisrechner Bei der Berechnung der Kosten sollte man sich vorab folgende Kennzahlen überlegen: Die Menge der Daten Anzahl der Transaktionen Ausgehender Datenverkehr Anfallender Datenverkehr zwischen den Datacentern Mit diesen Werten lässt sich ein ungefährer Preis mit dem Azure Preisrechner errechnen. Ich habe beispielhaft eine Berechnung mit GB an Speicher und 10 Millionen Transaktionen für alle Replikationsvarianten durchgeführt.

148 144 Hamboeck / Azure für Entwickler Abbildung 4.19: Preiskalkulation Dezember 2014 für 1TB an Speicher mit 10 Millionen Transaktionen, DocumentDB und 1TB ausgehende Bandbreite Bei einem Preis von ca. 2-5 Euro-Cent pro GB, ist der Azure Storage um einiges günstiger als Azure SQL, stellt also bestimmt eine interessant Variante der Datenspeicherung in der Cloud dar. 4.7 Zusammenfassung Die Datenhaltung mittels NoSQL-Technologien bietet bei sehr großen Datenmengen Vorteile gegenüber einer Datenspeicherung durch SQL. Unter Azure stehen uns verschiedene NoSQL- Speichermöglichkeiten zur Verfügung, eine Auswahl wurde in diesem Kapitel gezeigt und mittels einer Beispiel-Applikation wurden diese anprogrammiert. Dabei zeigt sich, dass der BLOB-Storage sich zur Speicherung von Dateien eignet, die Azure-Tables für strukturierte, nicht (unbedingt) relationale Daten geeignet sind, und sich anbieten, wenn man die Daten partitionieren kann, und Azure-Queues zum speichern von Messages dienen, die später abgearbeitet werden können um beispielsweise länger laufende Tasks zu erledigen.

149 Hamboeck / Azure für Entwickler Azure Virtuelle Maschinen In diesem Kapitel wird ein virtueller Computer aus der Azure Galerie mit Visual Studio erstellt der Remotezugriff auf diese VM gezeigt die Kosten einer VM erläutert Da ich noch auf mein Gehäuse für meinen neuen Hyper-V PC warte, ich aber unbedingt Visual Studio 2015 ausprobieren wollt, stand ich kurzfristig vor einem Dilemma. Ich könnte natürlich mein Arbeits-Notebook missbrauchen, aber für eine CTP möchte ich mir die Arbeit, die dann vermutlich auf mich wartet um wieder produktiv zu sein, nicht wirklich antun. Tja, was tun, eine kleine Ewigkeit hat sich Ratlosigkeit breit gemacht.bis ja, bis mir eine Erleuchtung gekommen ist, da gibt es ja noch die Azure VMs, die bereits fix und fertig zur Verfügung stehen und auf eine Verwendung unsererseits nur warten. Und genau das wäre die Lösung all meiner momentanen Probleme: Das risikolose Testen der neuen Visual Studio Version, ohne eine bestehende Maschine zu opfern, bzw. selbst eine VM zu erstellen. Also, nichts wie ran an das Aufsetzen eines virtuellen Computers.

150 146 Hamboeck / Azure für Entwickler 5.1 Einrichten der VM mit VS 2015 Mit einer bestehenden Azure Subscription sind die Schritte überschaubar, um an eine VM mit VS 2015 zu gelangen. Die Schritte, die notwendig sind kurz zusammengefasst: 1. Anmelden am Management Portal unter 2. Anlegen eines virtuellen Computers 3. Konfiguration des virtuellen Computers 4. Start des virtuellen Computers 5. Verbinden mit Remote Desktop Klingt relative einfach, wie wir gleich sehen werden, ist es das auch. 5.2 Anmelden im Portal Nehmt den Browser eurer Wahl und navigiert zu Dort meldet Ihr euch mit eurer Microsoft ID und dem Passwort an, danach landet Ihr (wie gewohnt) im Management Portal. Abbildung 5.1: Nach der Anmeldung wollen wir den virtuellen Computer mit Visual Studio 2015 anlegen.

151 Hamboeck / Azure für Entwickler Virtuellen Computer anlegen Wählt nun auf der linken Seite virtuelle Computer an und klickt auf virtuellen Computer erstellen. Abbildung 5.2: In dem neuen Fenster wählt Ihr nun aus Katalog aus. Abbildung 5.3: Azure VM Katalog auswählen Es öffnet sich ein Fenster, wo alle vorhandenen virtuellen Maschinen aufgelistet sind, die Ihr installieren könnt. Wir sind auf der Suche nach dem Visual Studio 2015 Image, dazu habe ich in der Suchleiste das Suchkriterium visual studio eingegeben, dementsprechend wird die Liste der verfügbaren Images eingeschränkt. Voila, Visual Studio Professional 2015 steht da an dritter Stelle.

152 148 Hamboeck / Azure für Entwickler Abbildung 5.4: Auswahl aus dem Azure VM-Katalog Dieses habe ich angewählt und danach den Button gedrückt um die VM zu konfigurieren. 5.4 Konfiguration des virtuellen Computers Die Konfiguration ist eine recht einfache Sache, diese geschieht mit drei einfachen Schritten. Im ersten Schritt sollte man vorsichtig sein, hier ist folgendes einzugeben: Der Name des virtuellen Computers. Unter diesem Namen (plus der Erweiterung.cloudapp.net) ist derselbe später über Remote Desktop erreichbar. Der Name muss weltweit eindeutig sein und ist später nicht mehr änderbar. Die zweite Auswahl betrifft die Art und Größe der zugrunde liegenden Hardware. Je stärker, umso mehr kosten fallen pro Monat an. Ich habe den Vorschlag von A2 auf A1 zurück gesetzt, das bedeutet 1 Core mit 1.75 GB Ram und (maximale) Kosten von 45,-- pro Monat (dazu aber später noch etwas mehr)

153 Hamboeck / Azure für Entwickler 149 Im zweiten Schritt kann die Region des virtuellen Computers angepasst werden. Diesen habe ich auf Westeuropa geändert. Besondere Beachtung sollte man den Ports widmen, diese werden später zur Herstellung der Verbindung benötigt. Abbildung 5.5: Name, Größe und Benutzerangaben für die VM und die Speicher-Informationen Im abschließenden dritten Schritt erkennt ihr die rechtlichen Bedingungen von Microsoft an, danach kann es auch schon losgehen.

154 150 Hamboeck / Azure für Entwickler Abbildung 5.6: Am Ende die rechtlichen Bedingungen Unser Job ist getan, jetzt kann es losgehen, wir sind nur noch wenige Minuten davon entfernt unseren virtuellen Computer auszuführen. 5.5 Start des virtuellen Computers Nach dem Klick auf sehr schön ersichtlich ist. wird der virtuelle Computer angelegt, was in der Statusanzeige Abbildung 5.7: Anlegen der VM

155 Hamboeck / Azure für Entwickler 151 Nach einigen Minuten ist der virtuelle Computer bereit, die Statusanzeige wechselt auf wird ausgeführt, der DNS-Name ist rechts daneben zu sehen und kann in den Clipboard übernommen werden. Abbildung 5.8: VM wird ausgeführt Die frei geschalteten Ports sind unter dem Punkt ENDPUNKTE im Azure Management Portal an der VM einzusehen. Abbildung 5.9: Endpunkte für die VM Mit diesen Informationen kann man sich jetzt mittels Remote Desktop an dem soeben erstellten virtuellen Computer verbinden. 5.6 Verbinden mit Remote Desktop Auf meinem lokalen Notebook starte ich Remote Desktop und verbinde mich zu dem soeben angelegten virtuellen Computer (vs2015hambo.cloudapp.net und der Port 57149).

156 152 Hamboeck / Azure für Entwickler Abbildung 5.10: Remote Desktop Verbindung zur VM Das dauert ein paar Sekunden, danach kann ich Visual Studio 2015 starten und gleich einmal auf meine Person aktivieren. Abbildung 5.11: Visual Studio in der VM

157 Hamboeck / Azure für Entwickler 153 Voila, einem ersten Test von Visual Studio 2015 steht nun nichts mehr im Wege und das ganz ohne eigenes Risiko eine (bestehende) Installation durch den Test unbrauchbar zu machen. 5.7 Stoppen der virtuellen Maschine Mittlerweile wird von Microsoft eine minutengenaue Abrechnung durchgeführt und gestoppte VMs produzieren keinerlei Kosten. Das Herunterfahren ist mit dem Button im Management Portal zu bewerkstelligen ACHTUNG - ein Herunterfahren im Remote Desktop alleine ist nicht ausreichend, um die laufenden Kosten zu minimieren. Abbildung 5.12: Herunterfahren der VM, um Kosten zu sparen Das bedeutet, dass es sich durchaus lohnt die virtuellen Maschinen im Azure Management Portal herunterzufahren, wenn diese nicht benötigt werden. So müssen viele Server nur während der regulären Bürozeiten im Betrieb sein und können über Nacht beendet (und morgens wieder gestartet) werden. Ähnlich verhält es sich natürlich mit der hier vorgestellten Entwickler VM, diese kann zu Zeiten, wo der Entwickler seinen wohl verdienten Schlaf verbringt, heruntergefahren werden, womit sich im gesamten die Kosten für die Infrastruktur verringern lassen. 5.8 Azure SDK und Azure VMs in lokalem Visual Studio Seit der Version 2.4 des Azure SDKs (und dem Update 3 von Visual Studio 2013) ist es möglich den virtuellen Computer direkt in Visual Studio 2013, bzw zu konfigurieren. Die zuvor erstellte VM taucht im Server Explorer im Azure/Virtual Machines Knoten auf.

158 154 Hamboeck / Azure für Entwickler Abbildung 5.13: Visual Studio Server Explorer mit installiertem Azure SDK Starten, Stoppen, Konfigurieren und sogar Debuggen ist schon länger möglich, der Configure Menüeintrag war neu in der Version 2.4 des Azure SDKs und öffnet ein neues Fenster mit den Einstellungsmöglichkeiten. Abbildung 5.14: Konfiguration der VM in Visual Studio Perfekt, so muss man nicht in das Azure Portal wechseln, wenn man Einstellungen kontrollieren, oder anpassen möchte. Ich frage mich gerade ernsthaft, ob ich meinen neuen, gerade bestellten, physikalischen Server nicht gleich wieder zurück schicken soll..

159 Hamboeck / Azure für Entwickler Anfügen eines neuen Datenträgers Möglicherweise möchte man ein eigenes Laufwerk zu der virtuellen Maschine hinzufügen, um Daten auf diesem zu speichern und dieses Laufwerk auch an einer anderen virtuellen Maschine weiter verwenden, da darauf z. B. Dokumentation, oder Source Code abgelegt wurde. Dazu ist an der VM der Link ANFÜGEN vorhanden. Wenn dieser angewählt wird, öffnet sich ein Dialog, wo der Storage Container und die Größe der Hard Disc anzugeben ist. Abbildung 5.15: Anlegen eines neuen Datenträgers Es wird in dem Storage Container eine weitere.vhd Datei mit fixer Größe als Page Blob angelegt. Das VHDX-Format für virtuelle Maschinen, sowie expandierende Dateien werden derzeit noch nicht unterstützt. Abbildung 5.16: VHD-Datei für die Disk

160 156 Hamboeck / Azure für Entwickler In der VM ist die Disk allerdings noch unbekannt, d. h. es muss in der VM noch der Server Manager gestartet werden, der Bereich File and Storage Services angewählt werden. Abbildung 5.17: Server Manager starten und File and Storage Services anwählen Im Bereich Disks sind die System-Disks zu sehen, sowie die neue 5 GB Disk, welche noch initialisiert werden muss. Abbildung 5.18: Initialisieren der neuen Disk Das System warnt uns, dass alle eventuell vorhandenen Daten bei diesem Vorgang verloren gehe - da unsere Disk aber keinen Inhalt hat, stellt das kein Problem dar. Abbildung 5.19: Warnung vor dem Initialisieren

161 Hamboeck / Azure für Entwickler 157 Abschließend kann der Wizard zum Erstellen des Laufwerks innerhalb der VM gestartet werden. Abbildung 5.20: New Volume, um das Laufwerk anzulegen Es öffnet sich ein Wizard, wo die Größe (Schritt 1), der Laufwerksbuchstabe (Schritt 2) und das File System (Schritt 3) angegeben werden kann, bzw. angepasst werden kann. Nach dem Abschließen des Wizards steht das Laufwerk zur Verfügung. Abbildung 5.21: Das eingebundene Laufwerk im File-Explorer Somit stehen die Daten auch nach dem Löschen der VM weiterhin als VHD-Datei zur Verfügung. Diese kann aus dem Storage-Container heruntergeladen werden, oder für eine andere VM wieder verwendet werden Kosten der VM Das Ganze hat natürlich auch seinen Preis. Ich habe das einmal herausgesucht, Ihr könnt das gerne selbst kontrollieren unter:

162 158 Hamboeck / Azure für Entwickler Abbildung 5.22: Kosten einer Azure VM Die Kosten von 50,-- pro Monat für eine Standard A1 Instanz sind durchaus eine feine Sache. Wie bereits erwähnt, lassen sich die Kosten aber noch reduzieren, da ich diesen virtuellen Computer im Management Portal herunterfahren kann, wenn ich ihn gerade nicht benötige Zusammenfassung Ich denke, Microsoft hat eine sehr elegante und auch kostengünstige Lösung für Entwicklungsteams geschaffen, um schnell einmal etwas auszuprobieren wie etwa Beta Versionen, neue Major Releases, oder einfach nur vorgefertigte virtuelle Computer, die ein bestimmtes Thema abdecken, das man sich genauer ansehen möchte (z. B. BI mit dem SQLServer 2014). Als kleine Randnotiz möchte ich noch anfügen, dass ich parallel zur Erstellung des oben beschriebenen virtuellen Computers auf meinem Notebook das Update 4 für Visual Studio 2013 installiert habe. Es war ein knappes Rennen, der virtuelle Computer mit Visual Studio 2015 war aber um einige Minuten schneller verfügbar.

163 Hamboeck / Azure für Entwickler Azure Powershell In diesem Kapitel wird die Azure PowerShell installiert, die PowerShell mit der Azure Subscription verbunden, die Verwendung derselben mit Azure Diensten gezeigt. Das Azure Management Portal ist durchaus eine tolle Oberfläche, um Azure Dienste zu konfigurieren, aber häufig ist es von Vorteil, administrative Aktionen per Script auszuführen. Dafür stellt Microsoft für die PowerShell Commandlets (cmdlets) zur Verfügung. Für Administratoren, aber auch für Entwickler eine feine Sache, da man auf diese Art Skripte erstellen kann, um diese während der Entwicklung immer wieder verwenden kann, um Dienste anzulegen oder wieder zu löschen.

164 160 Hamboeck / Azure für Entwickler 6.1 PowerShell und Azure Nahezu alle Aktionen, die im Management Portal ausgeführt werden können, können auch durch die Rest API (auch die anderen SDKs, wie für C# oder JavaScript setzen darauf auf) und PowerShell durchgeführt werden. Windows Azure PowerShell Releases sind derzeit auch noch sehr häufig und Erweiterungen immer wieder verfügbar. Die Azure PowerShell Module können durch den Microsoft Web Platform Installer heruntergeladen und installiert werden, dieser ist hier zu finden: Abbildung 6.1: Web Platform Installer und die Installation der PowerShell Nach dem Herunterladen und Installieren aller Abhängigkeiten durch den Web Platform Installer ist das System bereit.

165 Hamboeck / Azure für Entwickler 161 Abbildung 6.2: Installation der PowerShell beendet Unter Windows 8.1 und höher wird die Azure PowerShell vom Start-Screen aus aufgerufen, im Suchfenster kann danach gesucht werden. Abbildung 6.3: Starten der PowerShell Zum Testen eignet sich gleich einmal folgendes Kommando, um Hilfe zu allen Azure cmdlets zu erhalten: Get-Help Azure. Das Resultat ist eine lange Liste von Kommandos. Abbildung 6.4: Auflistung aller Azure CmdLets mit Get-Help Azure

166 162 Hamboeck / Azure für Entwickler Die Azure PowerShell ist somit am System installiert, nun muss die Azure Subscription konfiguriert werden. 6.2 Einrichten der Azure-Subscription Die Azure cmdlets benötigen den Zugriff auf eine active Azure Subscription, um die Dienste managen, bzw. konfigurieren zu können. Dafür gibt es mehrere Methoden; es genügt hier aber, eine zu kennen. Ich möchte die Methode mit dem Kommando Get-AzurePublishSettingsFile vorstellen. Wird dieses Kommando abgesetzt, dann öffnet sich der Browser und man wird aufgefordert das publishing profile herunterzuladen und zu speichern. Bitte sich den Pfad der publishsettings Datei merken, diese wird im nächsten Schritt benötigt. Abbildung 6.5: Herunterladen der.publishsettings Datei Diese Datei muss nun importiert werden, d. h., zurück in der PowerShell, empfiehlt sich folgendes Kommando, dadurch wird diese Subscription für das Bearbeiten der Dienste durch die CmdLets in der Azure PowerShell verwendet: Import-AzurePublishSettingsFile yourpublishsettings.publishsettings Abbildung 6.6: Importieren der.publishsettings Datei

167 Hamboeck / Azure für Entwickler 163 Um die momentan installierten Subscriptions einzusehen, eignet sich Get- AzureSubscription, dies liefert eine detaillierte Liste derselben: Abbildung 6.7: Alle Subscriptions auflisten Falls man mehrere Subscriptions zur Verfügung hat, möchte man die aktive Subscription in der Azure PowerShell möglicherweise wechseln, um eben die Dienste in der anderen Subscription zu bearbeiten. Dafür wird Select-AzureSubscription <subscription_name> verwendet werden. Abbildung 6.8: Wechseln der Subscription Versuchen wir nun, einen neuen Dienst anzulegen, die Änderungen zu kontrollieren und den Dienst wieder zu löschen 6.3 Verwenden der cmdlets In den vorherigen Kapiteln haben wir folgende Azure Dienste kennen gelernt: Azure Webseiten Azure SQL

168 164 Hamboeck / Azure für Entwickler Azure Storage Bisher wurde zumeist immer das Azure Management Portal verwendet, um diese Dienste zu bearbeiten. Darum bietet es sich hier nun geradezu an, dies mit der Azure PowerShell und den zugehörigen cmdlets zu versuchen Bearbeiten einer Azure Website Testen wir also das Anlegen einer Azure Webseite. Dazu benötigen wir einen Namen, der noch nicht verwendet wurde und der den DNS-Richtlinien entspricht. Also ein Name, der nur Buchstaben (von 'a' bis 'z'), Zahlen ('0' bis'9'), und möglicherweise auch noch ein Hyphen ('- ') enthält. In diesem Beispiel verwende ich "svobiwebps" - wie bereits erwähnt muss der Name weltweit unter Azure eindeutig sein und auch noch nicht in Verwendung mit einer Azure Webseite sein. Es empfiehlt sich eine Variable anzulegen, dann kann der Name jederzeit geändert werden, für die Verwendung in der Zukunft als Script. PS C:\> $websitename = "svobiwebps" PS C:\> New-AzureWebsite $websitename Die Webseite wird erzeugt und retourniert ein Objekt, welches alle Informationen über die neue Azure Website enthält. Um das Anlegen zu kontrollieren, kann man entweder in das Azure Management Portal wechseln, oder das cmdlet für die Auflistung aller Webseiten in der Subscription verwenden, optional mit dem Namen der Webseite als Parameter, dann erhält man nur Informationen zu dieser: PS C:\> Get-AzureWebsite PS C:\> Get-AzureWebsite -Name $websitename Um die Webseite im Browser anzuzeigen, kann folgendes Kommando abgesetzt werden: PS C:\> Show-AzureWebsite $websitename Um die Webseite zu löschen: PS C:\> Remove-AzureWebsite -Name $websitename Und wiederum die Überprüfung, ob die Webseite wirklich gelöscht wurde: PS C:\> Get-AzureWebsite -Name $websitename

169 Hamboeck / Azure für Entwickler Bearbeiten von Azure SQL Zum Anlegen eines Storage-Accounts benötigt man die Region - dazu ist eine Liste aller Regionen hilfreich - diese erhält man: PS C:\> Get-AzureLocation Jetzt sind ein paar Variablen hilfreich, die Region, der Username und das Passwort für die Administration des Azure Sql Serververs und der Name der Datenbank die dann angelegt werden soll. PS C:\> $location = "North Europe" PS C:\> $login = "svobi" PS C:\> $password = "Pa$$w0rd" PS C:\> $dbname = "sqldbps" Losgehen kann es mit dem Anlegen des virtuellen Azure Sql Servers, das Resultat wird aufgehoben: PS C:\> $sqlserver = New-AzureSqlDatabaseServer -AdministratorLogin $login -AdministratorLoginPassword $password -Location $location Der Name des Servers könnte durchaus von Interesse sein, dieser kann durch Zugriff auf die Eigenschaft ServerName des Rückgabeobjektes ausgegeben werden: PS C:\> $sqlserver.servername Die Firewall-Rule legen wir auch gleich mit an, in diesem Falle wird diese quasi disabled, da jede IP darauf zugreifen kann, dies sollte im Idealfall nur die eigene sein. PS C:\> New-AzureSqlDatabaseServerFirewallRule -ServerName $sqlserver.servername -RuleName "everyone" -StartIpAddress EndIpAddress Jetzt brauchen wir Credentials, wobei das Passwort verschlüsselt sein muss, d. h. zuerst muss ein verschlüsselter String aus dem originalen Passwort erzeugt werden: PS C:\> $securepassword = ConvertTo-SecureString $password

170 166 Hamboeck / Azure für Entwickler -AsPlainText -Force Nun können die Credentials erzeugt werden: PS C:\> $servercreds = New-Object System.Management.Automation.PSCredential -ArgumentList $login, $securepassword Somit ist der Weg frei, um sich Zugriff auf den virtuellen Azure Sql-Server zu verschaffen: PS C:\> $ctx = New-AzureSqlDatabaseServerContext -ServerName $sqlserver.servername -Credential $servercreds Jetzt kann die Datenbank angelegt werden: PS C:\> New-AzureSqlDatabase $ctx -DatabaseName $dbname -MaxSizeGB 1 -Edition Basic Löschen der Datenbank ist natürlich auch möglich: PS C:\> Remove-AzureSqlDatabase $ctx $dbname Force Nun noch das Löschend des virtuellen Azure Sql-Servers und der Urzustand ist wieder hergerichtet: PS C:\> Remove-AzureSqlDatabaseServer $sqlserver.servername -Force Bearbeiten des Azure Storage Zum Anlegen eines Storage-Accounts benötigt man, wie schon beim Azure SQL Beispiel, die Region - dazu ist eine Liste aller Regionen hilfreich - diese erhält man: PS C:\> Get-AzureLocation Anlegen des Storage-Accounts mit 2 Variablen (Name und Region): PS C:\> $storagename = "svobistoreps" PS C:\> $location = "North Europe" PS C:\> New-AzureStorageAccount StorageAccountName $storagename -Location $location Informationen über den Storage-Account:

171 Hamboeck / Azure für Entwickler 167 PS C:\> Get-AzureStorageAccount $storagename Löschen des Storage-Accounts: PS C:\> Remove-AzureStorageAccount $storagename 6.1 Zusammenfassung Der Zugriff über die Azure Powershell ist eine weitere Möglichkeit die komplette Administration der Azure Dienste durchzuführen. Obwohl wir in diesem Kapitel nur an der Oberfläche des Möglichen gekratzt haben, ist durchaus das Potential ersichtlich. Jeder Administrator und Entwickler wird über diese Möglichkeiten der Administration von Azure Diensten seine Freude haben und voller Inbrunst und Begeisterung seine eigenen Skripte schreiben. Das Microsoft Script Center ist auch ein guter Start, um sich bestehende Skripte einzusehen, dieses ist hier zu finden:

172 168 Hamboeck / Azure für Entwickler 7 Visual Studio Online In diesem Kapitel wird eine allgemeine Einführung in VS Online gegeben, werden die Features aufgezeigt, wird die Anwendung in einer Entwicklungsumgebung beschrieben und sind die Kosten dargestellt. Möglicherweise habt Ihr schon den Microsoft Team Foundation Server (TFS) in einem eurer Projekte eingesetzt. Möglicherweise als reines Source-Code Verwaltungstool, oder ihr habt auch mehr davon verwendet. Zum Beispiel die Prozessvorlagen für die agile Softwareentwicklung, oder Scrum. Vermutlich habt ihr auch Work-Items zugewiesen oder Bug Tracking und Builds automatisiert. Diesen TFS habt ihr vermutlich in einem Windows Server in eurem (Firmen-)Netzwerk installiert. Das Entwicklungsteam verwendet Visual Studio, um sich an den TFS anzuhängen. Das bedeutet, dass die Hardware angeschafft, das Server OS lizenziert und installiert werden musste (bzw. eine VM zur Verfügung gestellt werden musste) und jemand eine bestimmte Version des TFS installiert hat. Kurz gesagt, es fallen Kosten für die Hardware, Software und die Wartung des (eigenen) Systems an (z. B. Updates des Server OS, bzw. des TFS müssen selbst eingespielt werden). Falls Ihr den TFS überhaupt noch nicht im Einsatz hattet, so ist möglicherweise ein anderes Source-Code Verwaltungstool, wie z. B. Git, Tortoise, oder Jira im Einsatz. Alle aufgezählten Varianten haben Vorteile, aber auch verschiedene Nachteile. In einem meiner Entwicklungsteams haben wir eine Menge Source-Code und Zeit verloren, da das Infrastruktur-Team geschlampt hat. Wie? Nun ja, trotz mehrmaliger Rückfragen meinerseits, ob es ein funktionierendes Backup unseres Servers gibt, war im

173 Hamboeck / Azure für Entwickler 169 Ernstfall leider keines vorhanden. Obwohl diese Anfrage natürlich mehrmals positiv beantwortet wurde.. Nun.ja.seither verlasse ich mich äußerst ungern auf Infrastruktur-Teams und sehe mich gerne nach alternativen Lösungen zu dem In-House Hosting unseres Source-Codes um. Als erste Variante gib es natürlich den gehosteten TFS. Mehr Informationen findet Ihr z. B. hier: Ihr entscheidet euch für eine Version des TFS (2010, 2012, oder 2013) und für die Basic- Variante (Source Control und Work Item Tracking) oder die Full Variante (Basic Features und mit Sharepoint und Reporting). Diese Variante hat bestimmt Ihren Reiz, ich möchte euch aber eine weitere Möglichkeit hier vorstellen: Visual Studio Online (VS Online). 7.1 VS Online Allgemein Wieder ein neues Produkt werdet ihr euch jetzt möglicherweise denken, das ist aber so nicht ganz korrekt. Mit beiden Produkten könnt ihr: Euren Source Code in verschiedenen Versionen verwalten, Work Items verwalten, Bugs tracken und Backlogs verwalten. Also im Großen und Ganzen all das, was ein gutes Application Lifecycle Management (ALM) Produkt können sollte. Wie man anhand dieser Auflistung sehen kann, sind die Core-Funktionalitäten von TFS und VS Online gleich. Eigentlich ist es das gleiche Produkt, allerdings mit unterschiedlichen Versionssprüngen und der zugehörigen Updates (VS Online hieß früher auch Team Foundation Service). TFS wird in eigenständigen Versionen ausgeliefert, aktuell 2013, davor 2012 und Dies kennt ihr z. B. von Visual Studio selbst, oder auch vom SQLServer, oder Office her. Immer, wenn ein neues Release am Markt ist, entscheidet ihr euch, diese zu installieren und eure bestehende Software upzugraden (oder eben auch nicht). VS Online kennt diesen Produktzyklus in dieser Form nicht. Es gibt keine Version 2013, 2012, oder 2010, stattdessen wird VS Online automatisch auf den neuesten Stand gebracht. Schön und gut, aber wer macht dann die Updates? VS Online steht in der Cloud zur Verfügung. Microsoft s Cloud Lösung heißt Azure und bietet mittlerweile eine Menge an Diensten, einer davon ist eben VS Online. 7.2 VS Online Features Es gibt 2 verschiedene Varianten von VS Online: Basic und Professional. Gemeinsam ist den beiden, dass keine eigene Infrastruktur, wie z. B. ein eigener Server zur Verfügung gestellt werden muss. Der Source Code liegt in der Cloud und ist von überall von

174 170 Hamboeck / Azure für Entwickler berechtigten Personen abrufbar (ohne lästiger VPN Clients auf den Entwickler-Notebooks). Sehen wir uns einmal die beiden Versionen an. Ich möchte euch einmal die Features vorstellen, die mich überzeugt haben mit meinem Entwicklungsteam auf VS Online umzusteigen. Jeder VS Online Zugang verfügt über fünf kostenlose Benutzer (weitere Benutzer sind dann allerdings kostenpflichtig). Unbegrenzte Anzahl von Projekten (Team oder privat) Gehostete Code-Repositories mit der Team Foundation-Versionskontrolle oder Git in unbegrenzter Größe. Somit ist sichergestellt, dass unser Source Code von allen Entwicklern erreicht werden kann und diese jederzeit Source Code einchecken können, und das mit einer unbegrenzten Anzahl von Projekten mit einer unbegrenzten Größe der Projekte! Weitere Vorteile sind die Features für die gemeinsame Entwicklung innerhalb des Teams: Über sogenannte Teamräume wird jeder Entwickler über den aktuellen Projektstand informiert. Aufgliedern und Planen komplexer Projekte mit den Features der agilen Portfolioverwaltung: o o o o Erfassen von Product-Backlogs. Definition und Verfolgung von Sprints. Zuweisen und Tracken von Work-Items. Einholen und Nachverfolgen von Feedback für Projektbeteiligte (mit dem Microsoft Feedback Client). Erstellen von Testplänen und Test Cases. Integriertes Bug-Tracking. Verwenden der Auslastungstests (bis zu virtuelle Benutzerminuten pro Monat). All diese Punkte sind in der VS Online Basic Version enthalten und frei. Solltet ihr euch mehr Features punkto Projektplanung wünschen, dann solltet Ihr einen Blick auf die VS Online Advanced Variante legen, diese kostet allerdings $60,-- pro Benutzer im Monat. Eine VS Online Professional Variante ist ebenfalls erhältlich, diese umfasst ein monatliches Abonnement für die Visual Studio Professional IDE und schlägt mit $ 45,-- zu Buche. Aber zu Beginn sollte die VS Online Basic Variante durchaus ausreichen, möglicherweise benötigt Ihr mehr Benutzer, jeder weitere Benutzer über die inkludierten 5 schlägt sich mit $ 20,-- im Monat nieder. Kommen wir aber nun zur Anwendung von VS Online und legen ein Beispielprojekt an und checken vorhandenen Source Code ein. Dazu sind folgende Schritte notwendig:

175 Hamboeck / Azure für Entwickler 171 Anlegen des VS Online Kontos. Anlegen eines neuen Projektes. Einchecken des lokalen Source Codes. 3 kleine Schritte, mal sehen, ob es wirklich so einfach ist. In circa 10 Minuten könnt ihr selbst darüber urteilen legen wir also los, die Zeit läuft! 7.3 VS Online Anwendung Das VO Online - Konto Zur Verwendung von VS Online wird ein VS Online-Konto benötigt, dieses wird im Azure Management Portal angelegt. Abbildung 7.1: Anwählen des Visual Studio Online-Bereichs im Portal und der Neu-Button Es öffnet sich das - mittlerweile schon altbekannte - Konfigurationsfenster für das Anlegen eines neuen Azure Dienstes. Benötigt werden folgende Informationen: Der gewünschte Name des VS Online Kontos, dieser darf noch nicht vergeben sein. Das Active-Directory Verzeichnis in Microsoft Azure. Die Region - derzeit steht nur West-Europe und South Central US zur Verfügung. Das Abonnement, auf welches der Dienst gebucht wird. Abbildung 7.2: Konfiguration des Visual Studio Online-Dienstes

176 172 Hamboeck / Azure für Entwickler Nach erfolgreicher Anmeldung, ist euer Konto dann unter folgender Adresse im Browser erreichbar: Error! Hyperlink reference not valid. Des Weiteren inkludiert VS Online eine Version von Visual Studio Express für das Web, Windows oder Windows Desktop, aber als eingefleischte Entwickler habt ihr vermutlich schon eine der höherwertigeren Desktop Varianten der Visual Studio Editionen installiert. VS Online funktioniert allerdings auch mit Eclipse, oder XCode, ist also nicht an Visual Studio gebunden. Das Anlegen eines Visual Studio Online Kontos benötigt übrigens nicht zwingend eine Azure Subscription, das klappt auch schnell und problemlos mit dem Browser und folgendem Link: Nach erfolgreicher Anmeldung werdet ihr aufgefordert, ein neues Projekt anzulegen. Es ist der Name des Projektes einzutragen, optional dazu eine Beschreibung. Als Versions- Kontrolle setze ich auf die Team Foundation Version Control, da ich damit jahrelange Erfahrungen habe, die andere Option wäre Git, SVN wird leider nicht unterstützt. Als Scrum Master kommt mir das Microsoft Visual Studio Scrum Template gerade recht (andere Optionen sind: MSF for Agile Software Development und MSF for CMMI Process Improvement ). Abbildung 7.3: Anlegen des ersten Projektes

177 Hamboeck / Azure für Entwickler 173 Mit dem Create Project -Button ist dieser Schritt auch schon so gut wie abgeschlossen. Den Rest der Arbeit erledigt VS Online, welches das Projekt und den zugehörigen Team Room anlegt und zur Verfügung stellt, was später im Dashboard sehr schön zu sehen ist. Das VS Online-Konto ist nun vorhanden. Kommen wir zum nächsten Schritt Öffnen von Visual Studio 2013 und der Team Explorer Wir wollen gleich einmal dieses Projekt mit Visual Studio 2013 bearbeiten das ist die bisher einzige Version von Visual Studio, die unterstützt wird. Abbildung 7.4: Öffnen des angelegen Projektes in Visual Studio Beim Klicken des Buttons Open with Visual Studio to connect erfolgt folgende Sicherheitsabfrage vom Browser, welche ganz einfach bestätigt werden muss. Damit öffnet sich euer installiertes Visual Studio. Falls dieses noch nicht mit eurem Windows Live Account korrekt verbunden ist, erscheint folgende Fehlermeldung: Abbildung 7.5: Warnung im Browser und Visual Studio im Offline-Modus

178 174 Hamboeck / Azure für Entwickler Um den Fehler zu beheben, ganz einfach VS starten und es mit eurem Windows Live Account wieder verbinden. Danach nochmal im Browser den Button Open with Visual Studio to connect klicken. Dann startet euer Visual Studio ohne Fehlermeldungen und mit dem geöffneten Team Explorer. Abbildung 7.6: Team-Explorer Dieser wartet nun darauf, von uns konfiguriert zu werden, um den lokalen Source Code einchecken zu können. Zuvor sollte in Visual Studio 2013 kontrolliert werden, ob Team Foundation Server als momentanes Source Control plug-in verwendet wird. Dazu ist das Menü Tools -> Options -> Source Control aufzurufen.

179 Hamboeck / Azure für Entwickler 175 Abbildung 7.7: Source Control Plug-In konfigurieren Kommen wir abschließend zum Einchecken des Source-Codes Mappen und Einchecken des lokalen Source Codes Nun ist es an der Zeit, den VS Online Account mit einem (lokalen) Projekt zu verbinden. Dazu ist der Link configure your workspace zu drücken. Die Ansicht wechselt und nun muss das VS Online Projekt ($/Azure Informer) auf das lokale Verzeichnis gemappt werde. Bei mir liegt der Source Code unter C:\Development\Mobile\AzureInformer. Nachdem der Map & Get -Button gedrückt wurde, ist VS Online mit dem lokalen Projekt verbunden. Abbildung 7.8: Angeben des lokalen Verzeichnisses und erfolgreiches Mapping

180 176 Hamboeck / Azure für Entwickler Jetzt kann das Projekt unter Source Code-Verwaltung gestellt werden. Das gelingt mit der rechten Maustaste an der Solution im Solution Explorer und der Auswahl von Add Solution to Source Control. Das gleiche Spielchen noch einmal, allerdings wird nun Check In angewählt. Abbildung 7.9: Die Ansicht wechselt wieder auf den Team Explorer. Jetzt noch schnell ein Kommentar für das Einchecken des Source Codes eingeben, den Check-In Button drücken und der Source Code ist in guten Händen, immer und überall für mein Team und mich erreichbar.

181 Hamboeck / Azure für Entwickler 177 Geschafft, der Source Code ist bei VS Online hinterlegt. Die nächsten Schritte sind nun, weitere Team Mitglieder einzutragen, danach Work Items zu erfassen und an das Team zu verteilen. Die faszinierende Reise mit VS Online für mein Team und mich kann beginnen! 7.4 Kosten von Visual Studio Online Um die Kosten für Visual Studio Online berechnen zu können, ist wiederum der Azure Preisrechner sehr hilfreich, diesen findet man unter: DE/pricing/calculator/ Ich habe hier eine Preiskalkulation vorgenommen - diese umfasst 6 Visual Studio Online Anwender, 5 Anwender sind gratis, der nächste und jeder weitere schlägt dann jedes Monat mit Zusatzkosten zu Buche ( 14,90). Wird die Professional Variante benötigt, kostet diese für jeden Anwender extra, auch wie die erweiterte Variante. Ich habe mir 400 Minuten Build- Time herausgesucht und Lasttests.

182 178 Hamboeck / Azure für Entwickler Abbildung 7.10: Preiskalkulation Visual Studio Online (Januar 2015) Für kleinere Entwicklungsteams ist das sicherlich eine sehr interessante Variante, um den Source-Code verwalten zu lassen. 7.5 Zusammenfassung Ich durfte in meinem Arbeitsleben bisher 3 Entwicklungsteams leiten und ich hätte mir jedes Mal die unproblematische Möglichkeit der Kollaboration innerhalb des Teams, sowie die jederzeitige Verfügbarkeit des Source-Codes an jedem Ort der Welt gewünscht. VS Online macht es möglich eine unlimitierte Anzahl von Projekten mit unlimitierter Größe zu verwalten. Für Entwicklerteams mit bis zu 5 Leuten ohne jeglicher Kosten. Microsoft ist hier wieder ein hervorragendes Stück Software gelungen, einfach verpackt, ready to use for everyone!

183 Hamboeck / Azure für Entwickler Azure Beispielprojekt In diesem Kapitel habt ihr die Möglichkeit mit mir etwas interessantes zu bauen: Ein Security-System mit dem Surface, Windows Phone und Azure. Beim lesen meiner Twitter Feeds ist mir vor ein paar Wochen ein interessanter Eintrag in die Hände gefallen, den ich sogleich umsetzen wollte. Man nehme: Ein paar Netzwerk-Kameras Ein SurfaceRT Ein Windows Phone und Windows Azure..und schon ist das eigene Heim mir nichts dir nichts eine sichere Festung.

184 180 Hamboeck / Azure für Entwickler Abbildung 8.1: Neugierig geworden? Nun dann lest doch bitte weiter, wenn ihr an der Umsetzung interessiert seid. 8.1 Das Projekt - Übersicht Im Originalartikel wurden relativ teure Netzwerkkameras verwendet, ich war auf der Suche nach einer billigeren Lösung, dabei hatte ich folgendes kleines Kästchen im Auge:

185 Hamboeck / Azure für Entwickler 181 Abbildung 8.2: Links zu sehen ist das ist das SUNLUXY 8 Kanal CCTV H.264 DVR Wasserdicht IR Nachtsicht Sicherheit Kamera Video Überwachungssystem Set, gibt es bei dem Händler meines Vertrauens, nämlich Amazon um ca. 175, oder auch mit nur 4 Kameras um ca Es ist natürlich nicht unbedingt diese Lösung notwendig, ich habe mir auch noch folgende WLAN-Kamera bestellt (im Bild rechts): Eine D-Link DCS-932L Wireless N Tag/Nacht Home IP Kamera. Diese kostet momentan ca. 55,--, kommt also in Summe teurer, als die zuvor vorgestellte Lösung. Das Kästchen, welches bei der Sunluxy-Lösung mit dabei ist, ist an und für sich schon recht mächtig, man schließt es an einen Monitor an und schon sind alle Kamers sichtbar, eine Web-Oberfläche ist ebenfalls verfügbar, diese sieht dann so aus:

186 182 Hamboeck / Azure für Entwickler Abbildung 8.3: Soweit so gut, das reichte mir aber nicht, ich wollte gerne mein vorhandenes Surface RT für die Kameras verwenden. Warum? Erstens liegt es bei mir ebenfalls nur noch herum, seit ich das Surface Pro mein Eigen nennen darf und zweitens fand ich es durchaus schick das Surface RT bei meiner Eingangstüre, bzw. bei der Terrasse zu platzieren und z. B. zu sehen, wer denn da von meinen lieben Verwandten, oder Freunde gleich wieder vor unserem Haus auftaucht meist ist es sowieso meine Schwägerin, diese ist immer herzlich willkommen, da ich dann ungestört mich meinem Source Code widmen darf, da die beiden Schwestern ja immer richtig viel zu besprechen haben. Noch besser wäre mein Windows Phone zu verwenden, da klappt das dann ja komplett ortsunabhängig, da kommt jetzt Windows Azure in s Spiel. 8.2 Das Projekt Umsetzung Die Idee war die Bilder von den Kameras in den Azure Blob Storage zu stellen, die Namen der aktuellen Blobs im Azure Table Storage zu hinterlegen. Damit wären die Bilder der Kameras weltweit mit nahezu jedem beliebigen Client zugänglich Ansprechen der Kameras Alle WLAN-Kameras bieten die Möglichkeit die momentanen Bilder mit dem Browser abzufragen. Falls ihr noch eine Kamera herumliegen habt, könnt ihr unter diesem Link vermutlich die Adresse finden:

187 Hamboeck / Azure für Entwickler 183 Abbildung 8.4: Das Ergebnis war bei mir: In meinem Fall wären die Adressen für die Sunluxy-Lösung laut und für die D-Link-Kamera: Für die Sunluxy-Lösung konnte ich das auch durch die Web-Oberfläche ermitteln, die Anzeige der Kameras ist zwar eine Flash-Applikation, das Speichern des Snapshots ist allerdings außerhalb - im HTML Dokument - implementiert: Soweit so gut, das bedeutet egal welche Lösung man wählt, dem Zugriff über den Browser, bzw. einem http-request steht nichts mehr im Wege. Ich möchte nun mit euch den kompletten Code entwicklen, um eine Kamera abzubilden. Die Applikation zu erweitern, um 4, 8, oder gar 16 Kameras zu verwalten ist relativ einfach, der zusätzliche notwendige Code würde aber diesen Blog-eintrag zu unübersichtlich machen. Folgende Schritte sind notwendig: Die Windows Store App für den Surface RT entwickeln, um die Bilder abzuholen

188 184 Hamboeck / Azure für Entwickler Den Azure Storage Account anlegen Die Windows Store App erweitern, um die Bilder in Azure zu laden Die Windows Phone 8/8.1 entwickeln, um die Bilder von Azure darzustellen. Lasst uns also loslegen! Ach ja, eines noch vorweg: Der gezeigte Code ist hier als Prototyp anzusehen und soll nur zeigen, wie das gestellte Problem gelöst werden kann. In den nächsten Wochen wird dieser noch gehörig aufpoliert Der Surface RT Client Der Surface RT Client, soll im ersten Schritt folgende Anforderungen erfüllen: Anzeige des Bildes der Kamera Aktualisieren des Bildes in einem Intervall Anzeige des Datums und der Uhrzeit des Bildes. Wir beginnen mit einer neuen Windows Store App, das Blank App Template erfüllt unseren Zweck. Ich habe für das Projekt den Namen SecureHome.WinStore und für die Solution den Namen SecureHome gewählt. Abbildung 8.5: Fügen wir im nächsten Schritt gleich folgendes NuGet Package hinzu, die vereinfacht unser Entwickler-Leben für ds Handling des Azure-Storage allgemein: Windows Azure Storage

189 Hamboeck / Azure für Entwickler 185 Abbildung 8.6: Das Windows Azure Storage Package unterstützt seit der Version 4.2 auch Windows Phone 8 Silverlight Clients, d. h. der Code, den wir schreiben wird sowohl in der Windows Store App, als auch in der Windows Phone 8 App funktionieren. Erweitern wir die MainPage.xaml um folgende Controls: Ein Image, wo das Bild der Kamera dargestellt werden soll Ein TextBlock, der das momentane Datum und die Uhr anzeigt. <Grid Background="ThemeResource ApplicationPageBackgroundThemeBrush"> <Image Name="WebView0x1" Stretch="UniformToFill"></Image> <TextBlock Name="CurrentDateTextBlock4" HorizontalAlignment="Center " VerticalAlignment="Bottom"> :10:22</TextBlock> </Grid> Jetzt können wir schon ans implementieren gehen, folgendes ist zu tun: Einen DispatcherTimer erzeugen und alle 2 Sekunden aufrufen Im Timer Tick Event soll die Methode RefreshCams aufgerufen werden Die Methode RefreshCams holt das Bild von der Kamera ab und stellt es dar Das sieht dann erst einmal so aus: using System; using System.Diagnostics; using System.Net.Http; using Windows.Storage.Streams; using Windows.UI.Popups; using Windows.UI.Xaml; using Windows.UI.Xaml.Controls; using Windows.UI.Xaml.Media.Imaging; using SecureHome.WinStore.DataModel; namespace SecureHome.WinStore public sealed partial class MainPage : Page //Camera uri private string _uri = " private DispatcherTimer _dispatchertimer; //Get the images from Azure, or from HTTP?

190 186 Hamboeck / Azure für Entwickler private bool _azurereadmode = false; //Store the image in Azure? private bool _storeinazure = true; public MainPage() this.initializecomponent(); this.loaded += Page_Loaded; private void Page_Loaded(object sender, RoutedEventArgs e) DispatcherTimerSetup(); public void DispatcherTimerSetup() _dispatchertimer = new DispatcherTimer(); _dispatchertimer.tick += dispatchertimer_tick; _dispatchertimer.interval = new TimeSpan(0, 0, 0, 1); _dispatchertimer.start(); void dispatchertimer_tick(object sender, object e) RefreshCams(); private async void RefreshCams() var handler = new HttpClientHandler(); handler.allowautoredirect = true; var httpclient = new HttpClient(handler); int currentcam = 1; _picturedatasource.clearimages(); try InMemoryRandomAccessStream ims = null; if (_azurereadmode) //TODO: Read byte[] from Azure else HttpResponseMessage reponse = await httpclient.getasync (new Uri(_uri, UriKind.Absolute)); byte[] contentbytes = reponse.content.readasbytearrayas ync().result; ims = new InMemoryRandomAccessStream(); var datawriter = new DataWriter(ims); datawriter.writebytes(contentbytes); await datawriter.storeasync();

191 Hamboeck / Azure für Entwickler 187 AddToAzureSaveList(currentCam, contentbytes); ims.seek(0); //if(ims.size == 1081) // continue; var bitmap = new BitmapImage(); bitmap.setsource(ims); WebView0x1.Source = bitmap; catch (Exception ex) Debug.WriteLine("*ERROR: " + ex.message); if (!_azurereadmode && _storeinazure) //TODO: Upload picture to Azure if (!await _picturedatasource.uploadpicturestocloud()) CurrentDateTextBlock.Text = DateTime.Now.ToString(); private async void AddToAzureSaveList(int camnum, byte[] image) //TODO: Remember byte[] to upload more cam pics in the future Wie unschwer zu erkennen ist, habe ich eine andere Adresse für die Kamera eingesetzt: private string _uri = " Das Sunluxy-Kamera-System verwendet nach außen hin den Port 60001, wie ich in meinen Einstellungen meines Routers sehen konnte:

192 188 Hamboeck / Azure für Entwickler Abbildung 8.7: Wenn Ihr diesen Code laufen lässt, dann müsste das Bild der ersten Kamera sichtbar sein, sollte es klappen, dann sieht es bei euch aber vermutlich trotzdem anders aus: Abbildung 8.8: Der erste Schritt ist getan, jetzt gilt es das Bild in Azure hochzuladen, als Vorbereitung öffnet bitte die App.xaml.cs Datei und erweitert diese um drei Properties: sealed partial class App : Application public static StorageCredentials credentials = new StorageCredentials("SPEICHERNAME", "ZUGRIFFSCHLÜSSEL");

193 Hamboeck / Azure für Entwickler 189 public static CloudStorageAccount account = new CloudStorageAccount(credentials, false); public static string tablename = "pictures", contianername = "pictures"; 8.3 Azure Konfiguration In Azure benötige ich einen Blob Storage, um die Bilder der Kamera hochzuladen. Der Name des aktuellen Blobs pro Kamerabild soll im Azure Table-Storage hinterlegt werden. Damit etwas gespeichert werden kann muss man einen Cloud-Storage in Anzure anlegen. Dazu meldet euch mit eurem Account im Azure-Management-Portal an unter Klickt nach erfolgreicher Anmeldung auf den Link. Wie man sehen kann, habe ich bereits zwei Storage-Accounts, solltet ihr noch keinen Azure Storage angelegt haben, drückt auf den links unten. Abbildung 8.9: Es öffnet sich ein neues Fenster und ihr müsst einen Namen für euren Speicher-Account angeben. Der Speicher ist dann unter <euername>.core.windows.net erreichbar. Drückt am Ende den -Button und euer Speicher-Account ist angelegt.

194 190 Hamboeck / Azure für Entwickler Abbildung 8.10: Jetzt benötigen wir die Zugriffschlüssel, um mit der Applikation auf den Storage Account zugreifen zu können, dazu drückt ihr den Button. Abbildung 8.11: Es öffnet sich ein neues Fenster, wir benötigen davon zwei Einträge, den Speicherkontoname und den primären Zugriffsschlüssel:

195 Hamboeck / Azure für Entwickler 191 Abbildung 8.12: Diese beiden Werte kommen in die App.xaml.cs-Datei: public static StorageCredentials credentials = new StorageCredentials("SPEICHERNAME", "ZUGRIFFSCHLÜSSEL"); das müsste dann ungefähr so aussehen: public static StorageCredentials credentials = new StorageCredentials("hambostore", "rxyuyrriozhhn==nggziasw "); Damit wären wir fertig mit dem Azure Portal, kehren wir zu unser Windows Store App zurück Speichern im Azure-Storage Den Speichername und Jetzt gilt es unser byte[] im Azure Blob-Storage zu speichern und ein paar Informationen zu dem Bild im Azure Table Storage. Dafür gibt es ein hervorragendes Beispiel, welches bereits fix und fertig implementiert ist: Wenn ihr euch dafür den Code herunterladet, dann werdet ihr zwei Klassen finden, die wir gerne übernehmen wollen: C#\CSAzureWin8WithAzureStorage\DataModel\PictureDataSource.cs C#\CSAzureWin8WithAzureStorage\DataModel\PictureViewModel.cs aus: Ich habe die Dateien ein wenig für meine Bedürfnisse angepasst und diese sehen nun so PictureViewModel.cs using System; using System.Collections.Generic; using Microsoft.WindowsAzure.Storage.Table; und

196 192 Hamboeck / Azure für Entwickler namespace SecureHome.WinStore.DataModel public class PictureViewModel private DynamicTableEntity entity; public PictureViewModel() this.entity = new DynamicTableEntity() PartitionKey = "cam", RowKey; public string Name get return entity.rowkey; set entity.rowkey = value; public string PictureUrl get return entity.properties["imageurl"].stringvalue; set entity.properties.add(new KeyValuePair<string, EntityProper ty>("imageurl", new EntityProperty(value))); ); public DateTime CreationDate get return DateTime.FromFileTime(Convert.ToInt64(entity.RowKey) set entity.rowkey = value.tofiletime().tostring(); public string Description get return entity.properties["description"].stringvalue; set entity.properties.add(new KeyValuePair<string, EntityProper ty>("description", new EntityProperty(value)));

197 Hamboeck / Azure für Entwickler 193 public DynamicTableEntity PictureTableEntity get return entity; set entity = value; public byte[] PictureFile get; set; PictureDataSource.cs using System; using System.Collections.ObjectModel; using System.IO; using System.Threading.Tasks; using Windows.Storage.Streams; using Microsoft.WindowsAzure.Storage.Blob; using Microsoft.WindowsAzure.Storage.Table; namespace SecureHome.WinStore.DataModel public class PictureDataSource private ObservableCollection<PictureViewModel> allimages = new Obse rvablecollection<pictureviewmodel>(); public PictureDataSource() //GetPictureInfoFromTableStorage(); public ObservableCollection<PictureViewModel> AllImages get return allimages; public static async Task<bool> UploadPictureToCloud(PictureViewMode l pictureviewmodel, byte[] image) try ontianername); obreference); var blockblobclient = App.account.CreateCloudBlobClient(); var contianer = blockblobclient.getcontainerreference(app.c await contianer.createifnotexistsasync(); string blobreference = Guid.NewGuid().ToString(); CloudBlockBlob picture = contianer.getblockblobreference(bl th); await picture.uploadfrombytearrayasync(image, 0, image.leng //await picture.uploadfromstreamasync(image);

198 194 Hamboeck / Azure für Entwickler pictureviewmodel.pictureurl = picture.uri.tostring(); var tableclient = App.account.CreateCloudTableClient(); var table = tableclient.gettablereference(app.tablename); await table.createifnotexistsasync(); var operation = TableOperation.Insert(pictureViewModel.Pict uretableentity); await table.executeasync(operation); return true; catch (Exception) throw; internal async Task<bool> UploadPicturesToCloud() try var blockblobclient = App.account.CreateCloudBlobClient(); var contianer = blockblobclient.getcontainerreference(app.c ontianername); await contianer.createifnotexistsasync(); var tableclient = App.account.CreateCloudTableClient(); var table = tableclient.gettablereference(app.tablename); await table.createifnotexistsasync(); foreach (var pictureviewmodel in allimages) string blobreference = pictureviewmodel.name + "_" + Gu id.newguid().tostring(); CloudBlockBlob picture = contianer.getblockblobreferenc e(blobreference); var image = pictureviewmodel.picturefile; await picture.uploadfrombytearrayasync(image, 0, image. Length); //await picture.uploadfromstreamasync(image); pictureviewmodel.pictureurl = picture.uri.tostring(); var operation = TableOperation.InsertOrReplace(pictureV iewmodel.picturetableentity); await table.executeasync(operation); catch (Exception ex) throw;

199 Hamboeck / Azure für Entwickler 195 return true; public async Task GetPictureInfoFromTableStorage() var client = App.account.CreateCloudTableClient(); var table = client.gettablereference(app.tablename); await table.createifnotexistsasync(); var results = await table.executequerysegmentedasync(new TableQ uery(), null); foreach (var item in results) allimages.add(new PictureViewModel() PictureTableEntity = item ); public void ClearImages() if (allimages!= null) allimages.clear(); public ObservableCollection<PictureViewModel> GetAllImages() return allimages; public async Task<bool> DeletePictureFormCloud(PictureViewModel pic tureviewmodel) try var blob = new CloudBlockBlob(new Uri(pictureViewModel.Pict ureurl), App.credentials); await blob.deleteasync(); var tableclient = App.account.CreateCloudTableClient(); var table = tableclient.gettablereference(app.tablename); var operation = TableOperation.Delete(pictureViewModel.Pict uretableentity); await table.executeasync(operation); allimages.remove(pictureviewmodel); return true; catch (Exception) throw;

200 196 Hamboeck / Azure für Entwickler #if WINDOWS_APP public async Task<InMemoryRandomAccessStream> DownloadPictureFromCl oud(pictureviewmodel pictureviewmodel) try var blob = new CloudBlockBlob(new Uri(pictureViewModel.Pict ureurl), App.credentials); var ims = new InMemoryRandomAccessStream(); await blob.downloadtostreamasync(ims); return ims; catch (Exception) throw; #else public async Task<MemoryStream> DownloadPictureFromCloud(PictureVie wmodel pictureviewmodel) try var blob = new CloudBlockBlob(new Uri(pictureViewModel.Pict ureurl), App.credentials); var ims = new MemoryStream(); await blob.downloadtostreamasync(ims); return ims; catch (Exception) throw; #endif internal void AddImage(PictureViewModel uploadform) allimages.add(uploadform); Jetzt geht es darum die fehlenden TODOs mit Code zu befüllen und am Besten auch gleich in eine neue Klassendatei auslagern, ich habe diese Refresh.cs genannt. Das sieht am Ende so aus: using System; using System.Collections.Generic; using System.Diagnostics; using System.Linq; using System.Net.Http; using System.Text; using System.Threading.Tasks; using Windows.Storage.Streams;

201 Hamboeck / Azure für Entwickler 197 using Windows.UI.Popups; #if WINDOWS_APP using Windows.UI.Xaml; using Windows.UI.Xaml.Controls; using Windows.UI.Xaml.Media.Imaging; #elif WINDOWS_PHONE using System.IO; using System.Windows.Threading; using System.Windows.Controls; using System.Windows.Media.Imaging; #endif using SecureHome.WinStore.DataModel; namespace SecureHome.WinStore class Refresh //Camera uri private string _uri = " private DispatcherTimer _dispatchertimer; //Get the images from Azure, or from HTTP? private bool _azurereadmode = false; //Store the image in Azure? private bool _storeinazure = true; (); public PictureDataSource _picturedatasource = new PictureDataSource private bool _uploadinprogress; private TextBlock CurrentDateTextBlock; private Image WebView0x1; public Refresh(Image image, TextBlock info) CurrentDateTextBlock = info; WebView0x1 = image; public void DispatcherTimerSetup() _dispatchertimer = new DispatcherTimer(); _dispatchertimer.tick += dispatchertimer_tick; _dispatchertimer.interval = new TimeSpan(0, 0, 0, 1); _dispatchertimer.start(); public void Start() DispatcherTimerSetup(); void dispatchertimer_tick(object sender, object e) RefreshCams();

202 198 Hamboeck / Azure für Entwickler internal async void RefreshCams() var handler = new HttpClientHandler(); handler.allowautoredirect = true; var httpclient = new HttpClient(handler); int currentcam = 1; try #if WINDOWS_APP InMemoryRandomAccessStream ims = null; #elif WINDOWS_PHONE MemoryStream ims = null; #endif if (_azurereadmode) //Read byte[] from Azure await _picturedatasource.getpictureinfofromtablestorage (); var pictures = _picturedatasource.getallimages(); if (pictures.count > 0) ims = await _picturedatasource.downloadpicturefromc loud(pictures[0]); else HttpResponseMessage reponse = await httpclient.getasync (new Uri(_uri, UriKind.Absolute)); byte[] contentbytes = reponse.content.readasbytearrayas ync().result; #if WINDOWS_APP ims = new InMemoryRandomAccessStream(); var datawriter = new DataWriter(ims); datawriter.writebytes(contentbytes); await datawriter.storeasync(); #elif WINDOWS_PHONE ims = new MemoryStream(contentBytes); #endif if (!_uploadinprogress) AddToAzureSaveList(currentCam, contentbytes); #if WINDOWS_APP ims.seek(0); #elif WINDOWS_PHONE ims.seek(0, SeekOrigin.Begin); #endif //if(ims.size == 1081) // continue;

203 Hamboeck / Azure für Entwickler 199 var bitmap = new BitmapImage(); bitmap.setsource(ims); WebView0x1.Source = bitmap; if (!_azurereadmode && _storeinazure &&!_uploadinprogress) _uploadinprogress = true; //Upload picture to Azure if (!await _picturedatasource.uploadpicturestocloud()) CurrentDateTextBlock.Text = "Failed to upload, plea se try it again later."; _picturedatasource.clearimages(); _uploadinprogress = false; return; _picturedatasource.clearimages(); _uploadinprogress = false; CurrentDateTextBlock.Text = DateTime.Now.ToString(); catch (Exception ex) Debug.WriteLine("*ERROR: " + ex.message); private async void AddToAzureSaveList(int camnum, byte[] image) //Remember byte[] to upload more cam pics in the future var uploadform = new PictureViewModel(); uploadform.name = camnum.tostring(); uploadform.picturefile = image; _picturedatasource.addimage(uploadform); Die Mainpage.xaml.cs wird dadurch auch um einiges kleiner: using Windows.UI.Xaml; using Windows.UI.Xaml.Controls; namespace SecureHome.WinStore public sealed partial class MainPage : Page private Refresh _refresh; public MainPage() this.initializecomponent();

204 200 Hamboeck / Azure für Entwickler this.loaded += Page_Loaded; private void Page_Loaded(object sender, RoutedEventArgs e) _refresh = new Refresh(WebView0x1, CurrentDateTextBlock); _refresh.start(); Wenn Ihr die Applikation einige Sekunden laufen lässt, dann könnt Ihr die gespeicherten Blobs in Visual Studio sehen: Abbildung 8.13: Der Eintrag im Table-Storage ist ebenfalls zu sehen:

205 Hamboeck / Azure für Entwickler 201 Abbildung 8.14: Der Windows Phone Client Dieser ist beinahe nur noch Formsache. Wichtig ist, dass das Nuget Package für den Windows Azure Storage nur das Windows Phone Silverlight SDK allerdings kappt dann auch schon Windows Phone 8.1. Fügen wir also zu unserem Projekt eine Windows Phone App hinzu. Die Blank App (Windows Phone Silverlight) ist perfekt für unsere Zwecke. Abbildung 8.15: Wir fügen gleich die notwendigen NuGet-Packages hinzu: Wie gehabt das Package für den Windows Azure Storage. Abbildung 8.16: Zusätzlich die Http Client Libraries.

206 202 Hamboeck / Azure für Entwickler Abbildung 8.17: Soweit so gut, beginnen wir mit dem User Interface. Die MainPage.xaml ist nahezu ein Abbild unserer Store App: <Grid x:name="contentpanel" Grid.Row="1" Margin="12,0,12,0"> <Image Name="WebView0x1" Stretch="UniformToFill"></Image > <TextBlock Grid.Row="0" Grid.Column="0">CAM1</TextBlock> <TextBlock Name="CurrentDateTextBlock" HorizontalAlignme nt="center" VerticalAlignment="Bottom"> :10:22</TextBlock > </Grid> Als nächstes müssen folgende Schritte durchgeführt werden: Die drei Zeilen für die Zugangsdaten zu eurem Storage in die App.xaml.cs Die beiden Dateien PictureDataSource.cs und PictureViewModel.cs müssen hinzugefügt werden (als Link reicht vollkommen aus) Die Datei Refresh.cs kommt ebenfalls mit in das neue Projekt (wiederum als Link). Abbildung 8.18: Die MainPage.xaml.cs sieht nahezu identisch zur Windows Store App aus: using System.Windows; using Microsoft.Phone.Controls;