Azure Virtual Datacenter

Hallo zusammen,

es ist schon 1 1/2 Jahre her, da habe ich hier eine Architecture Guidance Studie des Azure CAT Teams, mit dem Titel „Azure Virtual Datacenter – An approach to isolation, security, and trust in the Microsoft Cloud“, vorgestellt (hier).

In der Rückschau stellte sich schnell heraus, dass die Studie die erfolgreichste Veröffentlichung des Teams war und noch heute hohe Aufmerksamkeit von Azure Architekten erhält.

Wie ihr euch bestimmt schon gedacht habt, habe ich einen guten Grund euch das alles zu erzählen, Seit gestern gibt es etwas Neues. Etwas, was das Angebot rund um das Thema Azure Virtual Datacenter erweitert bzw. in den Details ergänzt:

Azure Virtual Datacenter Automation Toolkit Deployment Guide

Das Azure Virtual Datacenter Automation Toolkit Deployment Guide ist ein Open Source Projekt und besteht aus zahlreichen Templates und Scripts. Die meisten Templates und Scripts sind zwar Allgemeinlösungen. Wer Lösungen für hochspezialisierte Workloads (z.B. Deployment von SAP Hana auf Azure) sucht, wird aber auch fündig.

Das Repository des Azure Virtual Datacenter Automation Toolkit Deployment Guide findet ihr hier:

• https://github.com/Azure/vdc

Schöne Grüße

Oliver

[Lesetipp] Build and Deploy a Multi-Container Application…

Hallo zusammen,

hin und wieder lohnt sich der Besuch des Resource Center auf der Microsoft Azure Seite, denn Microsoft überrascht uns regelmäßig mit neuen und interessanten eBooks.  So auch gestern, mit dem neuen eBook Build and Deploy a Multi-Container Application…

Ok, bevor ich jetzt was falsches erzähle. Dieses Buch gibt es je nach Geschmack, in zwei Varianten:

Build and Deploy a Multi-Container Application in Azure Service Fabric

Build and Deploy a Multi-Container Application in Azure Container Service

Autor beider Bücher ist Paolo Salvatori vom Azure Customer Advisory Team (AzureCAT)

Mein Resümee: Unbedingt lesen 🙂 🙂 😉

Download:

• https://azure.microsoft.com/en-us/resources/build-and-deploy-a-multi-container-application-in-azure-service-fabric/en-us/
• https://azure.microsoft.com/en-us/resources/build-and-deploy-a-multi-container-application-in-azure-container-service/en-us/

Ihr wollt den Source Code aus den Büchern?

Kein Problem, schaut einfach auf der GitHub Seite von Paolo vorbei:

• https://github.com/paolosalvatori/service-fabric-acs-kubernetes-multi-container-app

Schöne Grüße

Oliver

[Lesetipp] Azure Virtual Datacenter

Hallo zusammen,

heute habe ich etwas interessantes gefunden, für alle Software Architekten unter euch (oder für alle, die sich für Hybrid Cloud Szenarien interessieren):

Azure Virtual Datacenter –
An approach to isolation, security, and trust in the Microsoft Cloud

Jetzt stellt ihr euch bestimmt die Frage: Worum geht es genau?

Ein kurzer Auszug aus der Einführung gibt glaube ich, die beste Antwort:

„Azure Virtual Datacenter is a way to think about deploying your application estate in a cloud-based architecture while preserving key aspects of your current IT governance and taking advantage of cloud computing’s agility.

There are very real, underlying differences between hosting in the cloud and running in a traditional datacenter. Achieving the level of governance in the cloud environment that you experience in a traditional datacenter requires a sound understanding of why you do what you do today, and how that is achieved in Azure.

Unlike your existing on-premises datacenter environment, the Azure public cloud operates using shared physical infrastructure and a software-defined environment abstraction. The Azure Virtual Datacenter model allows you to structure isolated workloads in the Azure multitenant environment that meet your governance policies.“

Interessiert?

Den kostenlosen Download des eBooks, gibt es hier:

• https://azure.microsoft.com/en-us/resources/azure-virtual-datacenter/en-us/

Schöne Grüße

Oliver

Azure IoT Solution Architecture – Deep Dive #3-3

Hallo zusammen,

heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen.

In der letzten Folge (hier) hatten wir uns mit dem Field Gateway (oder aus der Azure Sichtweise: dem Azure IoT Gateway SDK bzw. Azure IoT Edge) beschäftigt. Da das Thema aber zu umfangreich ist, um in nur einer Folge behandelt zu werden, geht es auch diesmal weiter mit dem Field Gateway.

Bevor wir aber mit unseren Ausführungen starten werden, gibt es auch diesmal, erstmal ein Bild zur Erinnerung:

In unseren heutigen Fokus stehen die Gateway Module (im Bild in grün gemalt) und zwar speziell das mittlere Modul mit der Bezeichnung Filter.

Filter ist dabei eigentlich eine irreführende Bezeichnung, denn der Name Filter ist nur eine grobe Umschreibung der Aufgabe des Moduls.  Ein Filter Modul wartet auf Messages mit speziellen Properties und führt dann eine benutzerdefinierte Transformation aus.

Ändern wir also unser Bild etwas ab:

Aus dem Filter Module ist jetzt das Custom Module geworden. Custom Module bedeutet, dass ihr eure eigene Anwendungslogik in einer Programmiersprache eurer Wahl (zurzeit NET, NET Core, Java, Node.JS) bereitstellt.

Ok, ganz so einfach ist es nicht. Bei einem Custom Module wird zunächst aus einem laufenden Gateway Process, ein sog. Module Host (ein Lademodule) gestartet. Der Module Host sorgt dann z.B. dafür, dass die passende Runtime zur Ausführung des Codes geladen wird. Erst wenn der Module Host vollständig initialisiert ist, kommt auch euer Code ins Spiel.

Der Gateway Process und die Module Host Units sind. wie alle Infrastrukturbestandteile des Field Gateways in ANSI C entwickelt worden. Damit wird sichergestellt, dass die Funktionalität des Gateways, unabhängig vom Betriebssystem (Linux oder Windows), bereitgestellt wird.

Kehren wir noch einmal zum zweiten Bild zurück. Wenn ihr genau hinschaut, sieht ihr neben dem Custom Module ein weiteres Module, mit dem Namen Functions Module (oder etwas genauer Azure Functions Module). Das Functions Module ist eine Sonderform der Custom Module und zugleich ein Out – of – the Box Modul (d.h. ein vorgefertigtes Angebot) des Gateway. Das Functions Module nimmt Messages vom Gateway entgegen und triggert anschließend über ein HTTP Post eine Azure Function in der Cloud.

Ok, genug für heute. Noch mehr zum Thema, gibt es in der nächsten Folge.

Schöne Grüße
Oliver

Azure IoT Solution Architecture – Deep Dive #3-2

Hallo zusammen,

heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen.

In der letzten Folge hatten wir unsere Sicht auf die Architektur etwas erweitert und das Segment Cloud Gateway in die Betrachtungen mit einbezogen. Hier das Gesamtbild noch einmal zur Erinnerung:

Da das Bild sehr komplex ist, hatte ich es für die späteren Betrachtungen noch mehrmals gesplittet. Während ich euch die Erläuterungen für Teilabbildung a + b bereits in der letzten Folge (hier) geliefert hatte, bin ich euch allerdings  die Erläuterungen für Teilabbildung c noch schuldig geblieben.

Das werde ich heute sofort nachholen aber vorher gibt es hier, auch Teilabbildung c noch einmal zum anschauen:

Wie ihr sehen könnt, gibt es in Teilabbildung c keine direkte Kommunikation mehr zwischen den Devices im Segment Field und dem Cloud Gateway. Alle Kommunikation erfolgt stattdessen über ein Field Gateway (gegebenenfalls auch in Kombination mit einem Protocol Gateway).

Stellt sich sofort die Frage: Warum diese Umleitung?

Dafür gibt es mehrere Gründe:

• Ein PAN Device  ist aufgrund seiner Beschaffenheit (niedriges Ressourcenangebot), in der Regel gar nicht in der Lage selbstständig mit der Cloud zu kommunizieren. Ihr müsst zuerst über Bluetooth eine Verbindung zu einem Gateway herstellen, um anschließend die Daten in die Cloud  zu übertragen.
• Legacy Devices benutzen oft komplexe Netzwerk Protokolle (z.B. Modbus). Diese sind für eine direkte Kommunikation auch nicht geeignet.

Neben den Kommunikationsproblemen (davon sind übrigens zirka 85% aller Devices betroffen), kann aber auch die Notwendigkeit oder der Bedarf, den Data Stream einer Vorverarbeitung (Transformation) zu unterziehen, ein Grund für den Einsatz eines Field Gateways sein.

Beispiele für diese Transformationen des Data Streams sind:

• Batching
• Compression
• Message Composition
• Queuing
• Throttling

Kommen wir zum letzten Grund, für den Einsatz eines Field Gateways: die sog. Implementation of Infrastructure Capabilities. Mit dem Field Gateway habt ihr z.B. die Möglichkeit eure Infrastruktur an Sicherheitsbedürfnisse anzupassen oder einen Identity Management Layer (Credential Management Layer) zu realisieren.

Kommen wir nun zur Azure IoT Plattform:

Für die Azure IoT Plattform wurde die Unterstützung für das Field Gateway, bisher als Open Source Projekt „Azure IoT –  Gateway SDK“ auf GitHub  angeboten.

Ok, ihr habt es gelesen: Bisher

Vor knapp drei Wochen fand in Seattle die Microsoft Build Conference 2017 statt (das ist Microsoft größte Entwicklerkonferenz). In der Keynote der Konferenz wurde eine neue Komponente der Azure IoT Platform vorgestellt:

Azure IoT Edge

Azure IoT Edge ist einerseits der Ersatz für das Azure IoT Gateway SDK, mit einer relativ identischen Funktionalität.  Andererseits bekommt ihr aber auch zahlreiche neue Möglichkeiten für die Transformation eures Data Streams geboten (dazu gibt es in einem späteren Artikel mehr).

Betrachten wir nun, das Azure IoT – Gateway SDK (oder auch das Azure IoT Edge) einmal näher:

Wie ihr sehen könnt, besteht der Inhalt eines Field Gateways nur aus zwei unterschiedlichen Elementen, den Modulen und einen Message Broker.

Klären wir nun erstmal die Frage: Was ist ein Gateway Modul?

Ein Gateway Modul empfängt eine Nachricht, führt dann eine Aktion damit aus, transformiert sie optional in eine neue Nachricht und gibt sie dann abschließend zur Verarbeitung an andere Module weiter.

Im Gateway treten Module immer als eine Verkettung von mehreren Modulen auf (auch Data Processing Pipeline genannt). Die Anzahl an unterschiedlichen Modulen hängt von euren individuellen Bedürfnissen ab. Zwei Module findet ihr aber in jeden Szenario:

• Protocol Ingester Modul (als Startpunkt der Pipeline)
• IoT Hub (Send to Cloud) Modul (als Endpunkt der Pipeline)

Zwischen dem Startpunkt und dem Endpunkt der Pipeline, kommen dann weitere vordefinierte Module (zusätzliche Gateway Funktionalitäten) oder benutzerdefiniert Module (eure Business Logic) zum Einsatz (dazu später mehr).

Nächste Frage: Was ist mit dem Message Broker?

Der Message Broker wird von den Modulen dazu verwendet, um miteinander zu kommunizieren. Ihr veröffentlicht eine Nachricht auf dem Broker, die dann schrittweise an alle angebundenen Module weitergegeben werden.

Ein Message Broker basiert je nach eurem Bedarf, auf einer Busarchitektur, dem Pub / Sub Pattern oder jeden anderen Messaging Pattern.

Ok, genug für heute. Sehr viel mehr zum Thema, gibt es in der nächsten Folge.

Schöne Grüße
Oliver

[Praxistipp] Azure Ressource Groups richtig nutzen

Hallo Azure Community,

während meines Vortrags auf der CIM-Lingen kam es zu einigen Rückfragen zur Nutzung von Ressource Groups in Azure. Viele Fragen sich ob es hier ein optimales Vorgehen gibt und wie man seine Ressource Groups aufbaut.
Aus meiner Sicht gibt es hier ein klares Jain. Je nachdem wie ihr Azure nutzt, kann eure Ressource Group Aufteilung anders aussehen.
Heute zeige ich euch ein paar Möglichkeiten, welche Aufteilung ich in Projekten benutze.

Aufteilung nach Abteilungen

Diese Aufteilung sehe ich sehr häufig bei Kunden, deren interne IT als Dienstleister operiert und die ihre Azure Kosten auf die Fachbereiche weiter verteilen.

Hierbei wird eine allgemeine Ressource Group für z.B. Netzwerk und Zugänge angelegt und für jede Abteilung eine zusätzliche Ressource Group.

Hierbei habt ihr folgende Vorteile:

• Ihr könnt die Kosten direkt auf Kostenstellen umschlagen
• Die Automatisierung ist für euch vereinfacht
• Ihr könnt Abteilungsadministratoren ohne größeren Aufwand direkt für die Ressource Groups berechtigen

Aufteilung nach Azure Standorten

Diese Aufteilung sehe ich recht häufig bei Kunden, die mit Azure zusätzliche Rechenzentren abbilden und Azure als klassischen Collocation Provider nutzen.

Hierbei werden alle Ressourcen die in einer Azure Region bereitgestellt werden, in eine Azure Resource Group gelegt.

Diese Aufteilung trifft unser klassisches Verständnis und stellt eine uns bekannte Welt dar. Ich habe gemerkt, dass die meisten IT Abteilungen sich mit dieser Aufteilung am wohlsten fühlen.

Zusätzlich habt ihr folgende Vorteile:

• Dadurch das alle Azure Komponenten in der gleichen Region liegen, habt ihr die beste Performance und es kommt zu keiner Spaltung von z.B. Storage in Region A und zugehörige VM in Region B

Aufteilung nach Kunden

Diese Aufteilung sehe ich häufig bei SaaS Anbietern oder Service Providern die ihre Azure Leistung weiterverkaufen.

Hierbei wird für jeden Kunden eine eigene Resource Group angelegt und jeweils eine für allgemeine Ressourcen. Diese Lösung ist ähnlich der Aufteilung nach Abteilungen.

Diese Aufteilung ermöglich ebenfalls ein sehr gutes Abrechnungs- und Sicherheitsmanagement. Solltet ihr jedoch ein größerer SaaS Anbieter oder ReSaler sein, empfehle ich euch am Microsoft Cloud Solutions Provider Program teilzunehmen und an eure Kunden eigene Subscriptions zu verkaufen.

Aufteilung nach Projekten

Diese Aufteilung verwende ich sehr gerne für Projekte oder Demos für Kunden. Man kann sie aber auch sehr leicht auf Entwicklungsprojekte adaptieren.

Folgende Vorteile ergeben sich für euch daraus:

• Abrechnung der Azure Kosten und direkte Anrechnung an Projekte
• Abtrennung von Ressourcen für Projekte
• Berechtigungsmanagement pro Projekt

Alle Aufteilungen sind natürlich beliebig kombinierbar.

Zusätzlich könnt ihr noch die sogenannten Resource Manager Tags verwenden.

Durch Tags könnt ihr euren Ressourcen noch bis zu 15 weitere Marker hinzufügen und über diese Tags  Filter konstruieren.

Neben der Abrechnung könnt ihr die Resource Tags auch für andere Zwecke verwenden. Zum Beispiel zum Taggen von Zuständigkeiten oder Account Verantwortlichen.

So ich hoffe dieser kleine Post hilft euch etwas Licht in den Resource Group Dschungel zu bringen.

Beste Grüße
Flo

Neues von der Pattern and Practices Group

Hallo zusammen,

heute habe ich nach sechs Monaten Pause mal wieder ein paar Updates, von der Pattern and Practices Group,  für euch. Bevor wir uns aber den Updates widmen, möchte ich noch etwas klären:

Die Pattern and Practices Group ist nicht mehr das frühere Microsoft Team, welches durch die Bereitstellung von Open Source Projekten (z.B. der Enterprise Library) die Arbeit von Entwickler unterstützt, sondern ein Teil des Azure Customer Advisory Team (Azure CAT). Ziel ist es Entwickler, Software Architekten und IT Professionals durch gezielte Guidance, bei ihrem Umgang mit der Microsoft Azure Plattform zu unterstützen.

Einige der Guidance Projekte habe ich hier bereits vorgestellt, den Rest (die aktuellsten Projekte) werde ich heute vorstellen. Fangen wir auch gleich an:

Beginnen möchte mit einem Projekt, das auf den einfachen Namen Blueprints hört. Blueprints ist eine Sammlung von sog. Composable ARM Templates, sowohl für Linux als auch für Windows. Da Windows PowerShell für Linux erst seit dieser Woche verfügbar ist, wird für die Blueprints Sammlung noch das Azure CLI (Command Line Interface) benutzt, um eine Plattformunabhängigkeit zu garantieren.

Das zweite und das dritte Projekt sind direkte Ableger des Blueprint Projekts und hören auf die Namen ARM Building Blocks und Template Building Blocks. Beide Projekte sollen euch bei der Entwicklung eurer eigenen Composable ARM Templates helfen.

Ok, jetzt haben wir die Angebote, für die IT Professionals (Blueprints) und für die Software Entwickler (ARM Building Blocks / Template Building Blocks) unter euch. Was fehlt uns denn jetzt noch?

Richtig, etwas für die Software Architekten, aber keine Angst die bekommen mit dem vierten Projekt (namens Reference Architectures) auch etwas ab. Reference Architectures ist eine Sammlung von ARM Templates (und passender Guidance) für die Bereitstellung von Azure Architekturen. Die Sammlung basiert auf unterschiedlichen Szenarios und ist in Gruppen mit artverwandten Architekturen unterteilt. Für die in einer Gruppe vorhandenen Architekturen gilt: Von der einfachsten bis zur komplexen Architektur ist alles vorhanden.

Wer mehr erfahren will, sollte die folgende Seite besuchen:

• https://azure.microsoft.com/de-de/documentation/articles/guidance-architecture/

Wo finde ich die Projekte?

Alle Projekte werden auf der GitHub Seite der Pattern and Practices Group gehostet:

Blueprints

• https://github.com/mspnp/blueprints

ARM Building Blocks

• https://github.com/mspnp/arm-building-blocks

Template Building Blocks

• https://github.com/mspnp/template-building-blocks

Reference Architectures

• https://github.com/mspnp/reference-architectures

Schöne Grüße

Oliver

Microsoft REST API Guidelines

Hallo zusammen,

über kurz oder lang, muss sich jeder Entwickler auf der Azure Plattform mit dem Thema RESTful HTTP Interfaces (oder kurz REST APIs) beschäftigen. Alle Azure Dienste verfügen über eigene REST APIs und wer mit einem der Dienste arbeiten will, sollte über entsprechende Kenntnisse im Bereich REST verfügen.

Microsoft will euch die Angelegenheit erleichtern und hat dafür ein neues Open Source Projekt ins Leben gerufen:

Microsoft REST API Guidelines

Ok, die Microsoft REST API Guidelines sind eigentlich sog. Design Principles. Da die Guidelines aber auch bei den eigenen Entwicklungen von Microsoft zum Einsatz kamen, gibt es viel zum Lernen.

Das Repository findet ihr hier:

• https://github.com/Microsoft/api-guidelines

Direkt zu den Guidelines geht es hier:

• https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

Resümee: Unbedingt lesen 🙂 🙂 🙂

Schöne Grüße

Oliver

Contoso Shop Keeper

Hallo zusammen,

ich freue mich eigentlich immer, wenn ich euch eine neue Ressource vorstellen kann, die ihr wahrscheinlich noch nicht im Focus habt. Heute habe ich wieder so eine Ressource gefunden:

SaaS App – Contoso Shop Keeper

Was erwartet euch bei diesem Projekt?

Ok, erstmal gibt es natürlich eine SaaS App (eine Lösung aus dem Multi – Tenant Bereich), basierend auf den Azure App Services. Allerdings liegt der Fokus dieses Projektes nicht auf dieser App, sondern auf der Anbindung der App an einen Azure SQL Elastic Pool. Als kleine Zugabe gibt es umfangreiche Monitoring Möglichkeiten, für die Verwendung von Azure SQL Elastic.

Das Projekt ist Open Source und das passende Repository findet ihr hier:

• https://github.com/Microsoft/SaaSApp-ContosoShopkeeper

Schöne Grüße

Oliver

Azure Architecture Guidance – News

Hallo zusammen,

die Software Architekten unter euch, kennen den folgenden Arbeitsprozess: Ihr müsst eine Solution für ein neues Produkt erstellen. Ihr macht euch an die Arbeit und sobald ihr das neue Produkt fertig konzipiert habt, ist es Zeit für die Präsentation der Ergebnisse.

Präsentation der Ergebnisse… Für die meisten von uns, bedeutet das: Microsoft PowerPoint öffnen und zahlreiche, möglichst bunte Slides erstellen.  Das Ergebnis sieht nicht selten so aus:

Dies ist aber nicht wirklich befriedigend – oder? Wie wäre es stattdessen mit einem Architektur Diagramm in 3D. Das Bild von oben, würde dann in etwa so aussehen:

Ok, das ist mein erster Entwurf und noch nicht ganz fertig 😉 Ich denke die Abbildung ist aber sehr viel imposanter und aussagekräftiger.

Wie habe ich das Diagramm erstellt?

Mit Microsoft Visio und dem Microsoft 3d Blueprint Visio Template. Das Template wurde ursprünglich für interne Zwecke entwickelt, um damit z.B. die MSDN Architecture Blueprints zu erstellen. Das Template ist inzwischen als Download erhältlich und somit könnt ihr eure eigenen Architektur Diagramm in 3D erstellen.

Ein kurzer Hinweis zur Verwendung des Templates (Lizenz):

• für den internen Gebrauch: Frei und ohne Einschränkungen
• für den öffentlichen Gebrauch: Frei aber mindestens eine Microsoft Technologie (bzw. ein Microsoft Produkt) muss Bestandteil des Diagramms sein

Ressourcen:

Download des Templates:

• http://www.microsoft.com/en-us/download/48243

Trainingsvideo:

• https://www.youtube.com/watch?v=MXDzcb5HNtM

Schöne Grüße

Oliver