Microservices mit luftigen Maschen

Eine Einführung in Azure Service Fabric
Keine Kommentare

Azure Service Fabric ist das Resultat der langjährigen Erfahrung von Microsoft mit der Bereitstellung von Cloud-Diensten und hat sich seit dem Jahr 2010 bewährt. Dabei handelt es sich um das „Fundament“, auf dem Microsoft seine Azure-Kerninfrastruktur und diverse Dienste wie beispielsweise Skype for Business, Cortana oder die Azure SQL-Datenbank aufbaut.

Diese langjährige Erfahrung hat Microsoft in die Lage versetzt, eine Plattform zur zu erstellen, mit der hoch verfügbare und beständige Dienste zur Verfügung gestellt werden können. Kurz gesagt, die Azure Service Fabric ermöglicht die Bereitstellung und Verwaltung hoch skalierbarer Microservices.

Azure Service Fabric wurde für die Erstellung Cloud-basierter Dienste konzipiert, die zunächst klein ausfallen, dann aber je nach Anforderung und Bedarf auf hunderte oder tausende Computer skaliert werden können. Entwickler können sich ganz auf die Erstellung der Anwendung konzentrieren, ohne sich dabei Gedanken im Hinblick auf Skalierbarkeit und Zuverlässigkeit machen zu müssen.

Als Microservice wird ein Architekturmuster bezeichnet, durch das komplexe Anwendungssoftware erstellt werden kann, die aus einer Vielzahl von kleinen und unabhängigen Prozessen besteht, die untereinander mithilfe programmiersprachenunabhängiger Schnittstellen kommunizieren. Dabei sind diese Dienste klein und nach Möglichkeit vollkommen entkoppelt, sodass ein modularer Aufbau der Anwendung möglich wird. Auf diese Weise lassen sich komplexe Infrastrukturprobleme von vornherein vermeiden. In der Azure Service Fabric werden diese Microservices in einem gemeinsam verwendeten Computerpool (sogenannte Cluster) ausgeführt. Dabei bietet die Plattform die Möglichkeit, sowohl zustandslose als auch zustandsbehaftete Services bereitzustellen. Zusätzlich wird eine Vielzahl an Verwaltungs- und Controllingfunktionen bereitgestellt. Da Microsoft sich laut eigener Aussage dazu verpflichtet hat, seinen Kunden eine größtmögliche Flexibilität zu bieten, kann Service Fabric Anwendungen in Azure lokal (als kostenloser Download für Windows Server) oder sogar in einer anderen Cloud-Lösung ausführen.

Einrichten eines Azure-Abonnements

Microsoft stellt allen Benutzern eine einmonatige Azure-Testversion zur Verfügung, mit der sie derzeit 170 Euro „verspielen“ können. Dies soll Microsoft-Azure-Neulingen die Möglichkeit geben, sich mit der Microsoft Cloud Computing Platform zu befassen und einen ersten Überblick über den Umfang des bereitgestellten Angebots zu erlangen. Um sich anmelden zu können, müssen Sie einfach auf die Seite des Azure-Portals gehen und dort den Link KOSTENLOS STARTEN auswählen. Bevor die eigentliche Anmeldung erfolgt, werden Sie zunächst umfangreich über die Bedingungen und Möglichkeiten der Testversion aufgeklärt. Zur Anmeldung benötigen Sie einen Microsoft-Account, der zur Verwaltung des Kontos dient. Nach dem erfolgreichen Anmelden im Azure-Portal kann mit der Einrichtung der benötigten Ressourcen begonnen werden.

Erstellen von Clustern

Zunächst einmal sollte kurz erläutert werden, was ein Cluster überhaupt ist. Ein Cluster ist eine Menge per Netzwerk verbundener Computer (egal, ob virtuell oder physikalisch) – auch als Knoten bezeichnet –, auf denen Microservices bereitgestellt und verwaltet werden können. Grundsätzlich können diese Cluster auf einer Vielzahl von Umgebungen erstellt werden. So können diese neben Azure auch lokal unter Windows oder unter Linux laufen. Im folgenden Abschnitt wird auf die Erstellung eines Service-Fabric-Clusters in Azure detaillierter eingegangen. Als erster Schritt erfolgt die Anmeldung auf dem Azure-Portal. Dort kann unter RESSOURCE ERSTELLEN | COMPUTE | SERVICE FABRIC-CLUSTER (Abb. 1) ein neuer Service-Fabric-Cluster angelegt werden.

Abb. 1: Erstellen von Clustern

Zunächst ist ein Clustername zu vergeben sowie das Betriebssystem der Knoten auszuwählen. Hier wird eine immer größer werdende Liste von unterstützten Betriebssystemen angeboten. Direkt im Anschluss können die Anmeldedaten für die VMs (Knoten) des Clusters festlegt werden (Abb. 2). Sie sollten sorgfältig gewählt werden, denn damit erfolgt später die Anmeldung auf den verschiedenen Knoten.

Abb. 2: Festlegen von Namen und Basisinformationen

Weiter unten ist eine Ressourcengruppe festzulegen. Hier besteht ganz klar die Empfehlung, dass für jede angelegte Service Fabric eine eigene Ressourcengruppe angelegt werden sollte. Beim Erstellen einer Azure Service Fabric werden viele Komponenten mit teilweise kryptischen Namen angelegt. Soll diese Service Fabric später wieder gelöscht werden und wurde sie nicht einer eigenen Ressourcengruppe hinzugefügt, wird es nahezu unmöglich, alle zugehörigen Komponenten zu löschen. Wurde eine eigene Ressourcengruppe angelegt, die nur die zu löschende Service Fabric enthält, so kann man diese löschen und alle zugehörigen Komponenten werden automatisch mit entfernt. Die Ressourcengruppe sollte dabei einen erklärenden Namen bekommen.

Als Standort, in dem der Cluster läuft, empfehle ich immer, ein Datacenter in Europa auszuwählen. Anschließend können die Grundeinstellungen mit OK übernommen werden. Nun kann die Konfiguration des Clusters erfolgen (Abb. 3). Hier ist zunächst die Anzahl der Knotentypen auszuwählen.

Abb. 3: Auswahl der Knotentypen

Anschließend erfolgt die Konfiguration der Knoten (Abb. 4). Dort ist für jeden Knoten ein passender Name sowie die Dauerhaftigkeitsstufe festzulegen. Über diese wird dem System angezeigt, über welche Berechtigungen Ihre VMs für die zugrunde liegende Azure-Infrastruktur verfügt. Für diese Berechtigung können die folgenden Werte festgelegt werden:

  • Gold: Die Infrastrukturaufträge können für eine Dauer von 2 Stunden angehalten werden.
  • Silber: Die Infrastrukturaufträge können für eine Dauer von 30 Minuten angehalten werden.
  • Bronze: Keine Berechtigungen; dies ist die Standardoption.

Zusätzlich ist die Größe der VM festzulegen. Hier empfehle ich für unsere Spielwiese die kleinste und somit preiswerteste Konfigurationsmöglichkeit.

Abb. 4: Festlegen von Namen und Dauerhaftigkeit von Knoten

Durch klicken auf OK geht es zurück zur Clusterkonfiguration, wo noch weitere optionale Einstellungen vorgenommen werden können. Anschließend geht es mit der Konfiguration der Sicherheitseinstellungen weiter. Hierbei ist zwischen zwei Konfigurationstypen auszuwählen. Für unsere Zwecke ist „Basic“ vollkommen ausreichend. Hierbei wird in einem Schlüsseltresor ein Zertifikat erstellt. Wenn ein vorhandenes Zertifikat verwendet werden soll oder zusätzliche Zertifikatoptionen eingestellt werden sollen, ist der Typ „benutzerdefiniert“ der richtige.

Anschließend wird eine kurze Zusammenfassung der ausgewählten Konfiguration des Clusters angezeigt. Mit ERSTELLEN wird die Service Fabric (Abb. 5) endgültig angelegt.

Abb. 5: Zusammenfassung der Einstellungen

Beachten Sie, dass unter VORLAGE UND PARAMETER HERUNTERLADEN die Möglichkeit angeboten wird, sich ein Erstellungsskript zu kopieren. Dies ermöglicht beispielsweise eine Automatisierung des Erstellungsprozesses. Ebenfalls sollten Sie den Hinweis berücksichtigen, dass Sie das erstellte Zertifikat auf Ihrem Rechner installieren müssen. Dieses können Sie an der in Abbildung 5 markierten Stelle herunterladen und installieren. Nachdem die Erstellung erfolgreich abgeschlossen wurde, steht die Azure Service Fabric zur Verfügung. Dies nimmt allerdings mehrere Minuten in Anspruch.

Zustandslose und zustandsbehaftete Microservices

An dieser Stelle möchte ich nicht genauer auf die Definition eines Microservice eingehen. Ich denke, dass diese durchaus spannende Thematik derzeit ausführlich genug diskutiert wird. Allerdings möchte ich kurz die Unterschiede zwischen einem zustandslosen und einem zustandsbehafteten Service näher erläutern. Dabei behalten zustandslose Microservices über die Anforderung und der entsprechenden Antwort vom Dienst hinaus keine veränderbaren Zustände. Zustandslose Dienste sind z. B. die klassischen REST-Services oder die Worker-Rolle in den Azure Cloud Services. Zustandsbehaftete Microservices verfügen hingegen über einen veränderbaren Zustand der über die Antwort des Service hinaus erhalten bleibt. Durch die Verwendung von zustandsbehafteten Microservices kann beispielsweise auf zusätzliche Caches oder Queues verzichtet werden.

Architektur der Azure Service Fabric

Die Azure Service Fabric besteht aus mehreren Bestandteilen, die sich auf mehrere Ebenen aufteilen. Das Schaubild in Abbildung 6 zeigt die wichtigsten Teile der Service Fabric auf.

Abb. 6: Azure-Service-Fabric-Architektur

In einem verteilten System ist die Gewährleistung einer sicheren Kommunikation zwischen den verschiedenen Knoten innerhalb eines Clusters eine der Kernkomponenten. An der Basis befindet sich das Transportsubsystem. Es stellt eine sichere und somit verlustfreie Kommunikation zwischen den verschiedenen Knoten eines Clusters her.

Unmittelbar über der Transportebene befindet sich das Federation-Subsystem (Verbundsystem). Es gewährleistet die Verbindung zwischen den verschiedenen Knoten des Clusters, sodass die Service Fabric beim Erkennen eines Fehlers eine übergeordnete Instanz auswählt (Leader Election) und ggf. die Daten konsistent an diese weiterleiten kann.

Über dem Federation-Subsystem ist unter anderem das Reliability-Subsystem (Zuverlässigkeits-subsystem), das für die Zuverlässigkeit der Service-Fabric-Dienste verantwortlich ist, angesiedelt. Hier kommen Mechanismen wie Replikation, Ressourcenverwaltung und Failover zum Einsatz. Ebenfalls direkt über dem Verbundsystem liegt das Hosting- und Activation-Subsystem, das die Lebenszyklen einer Applikation auf den einzelnen Knoten verwaltet. Das auf der gleichen Ebene befindliche Communication-Subsystem gewährleistet die Kommunikation des Clients mit allen Knoten des Clusters. Das Managementsubsystem verwaltet den Lebenszyklus von Anwendungen und Diensten. Das Testability-Subsystem dient der Unterstützung des Entwicklers beim Testen der Dienste.

Die Service Fabric bietet zusätzlich die Möglichkeit, die Dienstspeicherorte über das Kommunikationssubsystem aufzulösen. Die für Entwickler verfügbaren Anwendungsprogrammiermodelle (Application Model und APIs) liegen zusammen mit dem Anwendungsmodell über diesen Subsystemen. Für den interessierten Leser beschreibe ich im Folgenden die verschiedenen Bestandsteile etwas detaillierter:

Das Transportsubsystem: In der Transportebene erfolgt die Implementierung einer klassischen Ende-zu-Ende-Verbindung, die die Kommunikation zwischen verschiedenen Endpunkten steuert. Dadurch wird die Kommunikation innerhalb eines Clusters, aber auch zwischen mehreren Clustern gewährleistet. Die Kommunikation wird dabei entweder durch ein X.509-Zertifikat oder durch Windows Security gesichert.

Das Federation-Subsystem: Um die „Bedeutung“ einer Gruppe von Knoten in einem verteilten System bewerten zu können, muss das gesamte System als eine Einheit gesehen werden. Diese Aufgabe übernimmt die Federation-Ebene. Sie verwendet die von der Transportebene bereitgestellten Kommunikationsmittel, fügt die verschiedenen Knoten zu einem einzelnen einheitlichen Cluster zusammen und betrachtet das Ergebnis als ganze Einheit. Auf dieser Ebene werden die eigentlichen Stammfunktionen eines verteilten Systems zur Verfügung gestellt. Diese können von den anderen Elementen (z. B. Fehlererkennung, Leader Election, Weiterleitung) verwendet werden. Dabei kommt eine verteilte Hashtabelle mit einem 128-Bit-Tokenbereich zum Einsatz. Es wird eine Ringtopologie über allen Knoten erzeugt und dabei jedem Knoten eine Teilmenge des Tokenspeichers zugewiesen.

Zur Fehlererkennung verwendet das Federation-Subsystem einen sogenannten Leasing-Mechanismus. Mittels diverser komplexer Protokolle wird gewährleistet, dass jeweils nur ein Benutzer im Besitz eines Tokens sein kann. Dies ist die Voraussetzung für Leader Election und einer konsistenten Weiterleitung.

Das Reliability-Subsystem: Im Reliability-Subsystem erfolgt die Bereitstellung der Hochverfügbarkeit der Azure Service Fabric. Dies erfolgt im Wesentlichen durch die Bereitstellung von drei Komponenten:

  • Der Replicator stellt sicher, dass alle Statusänderungen in einem primären Replikanten automatisch in den sekundären Replikanten gespiegelt werden. So wird die Konsistenz der beiden Replikatorgruppen garantiert. Der Replicator agiert mit dem Failover-Manager, um die Liste der zu replizierenden Vorgänge abzurufen.
  • Der Failover-Manager stellt sicher, dass die Last vollkommen automatisch auf die verfügbaren Knoten verteilt wird. Fällt ein Knoten aus oder wird ein neuer Knoten hinzugefügt, so konfiguriert der Cluster die Dienstreplikate automatisch neu.
  • Der Ressourcenmanager organisiert die Dienstreplikate und stellt sicher, dass alle Failover-Einheiten betriebsbereit sind. Weiterhin ist er für die Verteilung der Dienstressourcen über den gesamten Pool der Knoten zuständig, um so eine optimale Lastverteilung zu erhalten.

Das Managementsubsystem: Die Managementebene stellt die Ende-zu-Ende-Verbindung sowie die Lebenszyklusverwaltung für die Applikationen bereit. Auch dazu werden im Wesentlichen drei Systeme verwendet:

  • Der Clustermanager ist ein Dienst, der mit dem Failover-Manager kommuniziert, um die Anwendungen – je nach Einschränkung – auf den entsprechenden Knoten zu platzieren. Er ist ebenfalls für die Verwaltung des Lebenszyklus der Anwendung verantwortlich.
  • Der Health-Manager ermöglicht die Überwachung der Integrität von Anwendungen, Diensten und Clusterelementen (z. B. Knoten, Dienstpartitionen, Replikate).
  • Der Image-Speicher ist ein Dienst, der für das Verteilen und Speichern der binären Anwendungsdaten zuständig ist. Er beinhaltet einen einfachen Speicher, in dem die Anwendung hochgeladen bzw. heruntergeladen werden kann.

Hosting-and-Activation-Subsystem: Diese Ebene verwaltet den Lebenszyklus der Anwendung auf einem Knoten. Dazu bekommt diese vom Clustermanager diejenigen Dienste mitgeteilt, die für die Verwaltung des Knotens benötigt werden. Um die korrekte Platzierung der Replikate zu gewährleisten, kommuniziert dieser Bereich ebenfalls mit den Reliability-Komponenten und dem Health-Manager.

Communication-Subsystem: Dieses Subsystem sorgt mithilfe des Naming-Services für ein zuverlässiges Messaging sowie Diensterkennung. Der Naming-Dienst speichert die Namen des Diensts im Cluster und ermöglicht es den Benutzern, Dienstnamen und -eigenschaften zu verwalten. Durch die Verwendung des Naming-Diensts können die Clients vollkommen sicher mit allen Knoten im Cluster kommunizieren.

Testability-Subsystem: Diese Ebene besteht aus mehreren Tools, die speziell zum Testen von Diensten entwickelt worden sind. Mit diesen Tools können Entwickler auf einfache Art und Weise aussagekräftige Fehler hervorrufen und diverse Testszenarien ausführen. So kann eine Vielzahl an Zuständen und Übergängen simuliert und überprüft werden. Dabei ist die volle Kontrolle und Sicherheit zu jedem Zeitpunkt gewährleistet.

Einrichten der Entwicklungsumgebung

Sofern Visual Studio 2015 verwendet wird, benötigen Sie zum Entwickeln und Ausführen von Azure-Service-Fabric-Anwendungen auf dem Entwicklungsrechner folgende Erweiterungen: Service Fabric SDK und Tools für Visual Studio 2015. Bei der Verwendung von VS 2017 sind die Service Fabric Tools Bestandteil des Azure Development Workload. Dieser kann einfach als Bestandteil von Visual Studio eingeschaltet werden. Zusätzlich ist die folgende Erweiterung zu installieren: Visual Studio 2017 Service Fabric SDK. Alle benötigten Komponenten finden Sie auf den Azure-Downloadseiten von Microsoft.

Weiterhin ist die PowerShell-Skriptausführung zu aktivieren, da zum Erstellen eines lokalen Entwicklungsclusters die Service Fabric im Hintergrund PowerShell-Skripte ausführt. Diese ist jedoch in Windows als Default geblockt. Um die Skripte zu aktivieren, sind die Ausführungsrichtlinien der PowerShell zu ändern. Dazu ist in PowerShell (im Administratormodus) der folgende Befehl auszuführen: Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser. Nachdem alle Erweiterungen eingerichtet wurden, kann mit dem Erstellen einer Service-Fabric-Anwendung begonnen werden.

Erstellen und Debuggen des Service

Grundsätzlich kann eine Service-Fabric-App einen oder mehrere Dienste (oder besser Microservices) enthalten. Die Erstellung eines neuen Projekts erfolgt mithilfe des Assistenten und stellt, wie von Microsoft gewohnt, keinerlei Probleme dar. Hierzu sind lediglich folgende Schritte durchzuführen:

  • Starten von Visual Studios als Administrator.
  • Unter der Registerkarte DATEI auf NEUES PROJEKT => CLOUD => SERVICE FABRIC ANWENDUNG klicken.
  • Der Anwendung einen sinnvollen Namen geben und OK auswählen.
  • Anschließend ist auszuwählen, welche Dienstvorlage erstellt werden soll (für den Einstieg sollte ein zustandsloser Dienst gewählt werden).

Nachdem der Dienst einen sinnvollen Namen bekommen hat, wird wie gewohnt alles, was für einen (lokalen) Dienst, der in der Service Fabric läuft und benötigt wird, vollkommen automatisch installiert. Die erstellte Solution enthält zwei Projekte: das Anwendungsprojekt und das Serviceprojekt, in dem der Service implementiert wird. Das Anwendungsprojekt unterteilt sich in drei verschiedene Bereiche:

  • PublishProfiles: Diese werden zum Verwalten von Tooleinstellungen für die unterschiedlichen Umgebungen verwendet.
  • Scripts: Hier sind PowerShell-Skripte zur Bereitstellung bzw. Upgrade der Anwendung zu finden. Diese Skripte werden – wie bereits oben erwähnt – von Visual Studio im Hintergrund ausgeführt. Diese Skripte können auch direkt in der Kommandozeile aufgerufen werden.
  • Anwendungsdefinition: ApplicationPackageRoot: Dieser Ordner enthält das Application-Manifest. Die zugehörigen Anwendungsparameterdateien befinden sich unter ApplicationParameters. Sie definieren die Anwendung und ermöglichen es, eine bestimmte Umgebung konfigurieren zu können.

Nun kann das Projekt durch Drücken der F5-Taste erstellt werden. Die erste Bereitstellung nimmt etwas mehr Zeit in Anspruch (die eine oder andere Minute kann dabei schon vergehen), da von Visual Studio (für die Entwicklung) ein lokaler Cluster erstellt wird. Sobald dieser Cluster zur Verfügung steht, wird der Entwickler darüber in der Taskleiste informiert. Anschließend wird der Dienst gestartet.

Der von Visual Studio beim Einrichten erstellte Dienst ist voll lauffähig, was an der Ausgabe (Erhöhung des Counters) in der automatisch geöffneten Diagnoseereignisanzeige deutlich zu erkennen ist. Wenn eines der Ereignisse „aufgeklappt“ wird, kann unter anderem eingesehen werden, auf welchem Knoten der Code ausgeführt wird.

Mithilfe des Service Fabric Explorer wird eine Möglichkeit geboten, einen Cluster, wie in Abbildung 7 dargestellt, visuell darzustellen. Dazu wird lediglich ein Browser benötigt. Zu finden ist der Explorer unter dem URL http://:19080/Explorer. Für den Fall, dass eine sichere Verbindung besteht, wird HTTPS verwendet. Alternativ kann der Cloud Explorer von Visual Studio verwendet werden.

Abb. 7: Service Fabric Explorer

Um den Ausfallknoten zu simulieren, ist der Knoten, auf dem der Code aktuell ausgeführt wird, zu suchen. Er kann durch AKTIONEN > DEAKTIVIEREN (NEUSTARTEN) neu gestartet werden. Dies simuliert einen Ausfall des Knotens. Bei der Betrachtung der Diagnoseereignisanzeige ist an den Meldungen zu erkennen, dass der Zähler weiter erhöht wird, obwohl die Ereignisse tatsächlich von einem anderen Knoten ausgeführt werden.

Wechseln des Clustermodus

Der lokale Entwicklungscluster verfügt standardmäßig über fünf Knoten. Die Bereitstellung einer Anwendung im Entwicklungscluster mit fünf Knoten nimmt dabei einige Zeit in Anspruch. Für den Fall, dass die Codeänderungen schnell durchlaufen werden sollen, kann die Anzahl der Knoten jederzeit angepasst werden. Dies erfolgt über das Kontextmenü (rechte Maustaste) in der Taskleiste (Abb. 8). Dabei ist zu berücksichtigen, dass beim Ändern des Clustermodus der Entwicklungscluster zurücksetzt wird und somit alle Apps, die im Cluster bereitgestellt oder ausgeführt werden, entfernt werden.

Abb. 8: Anzahl der Knoten anpassen

Bereinigen

Wenn Sie den Debugger beenden, wird Ihre Anwendungsinstanz entfernt und die Registrierung des Anwendungstyps aufgehoben. Der Cluster wird weiterhin im Hintergrund ausgeführt. Um den Cluster zu „verwalten“, gibt es zwei Möglichkeiten:

  • Zum Beenden des Clusters – bei Beibehaltung der Anwendungsdaten und Ablaufverfolgungen – klicken Sie in der Infobereichs-App auf LOKALEN CLUSTER BEENDEN.
  • Zum vollständigen Entfernen des Clusters klicken Sie in der Infobereichs-App auf LOKALEN CLUSTER ENTFERNEN. Löschen Sie den Cluster jedoch nur, wenn Sie beabsichtigen, den Cluster für eine Weile nicht zu verwenden, oder wenn zwingend Ressourcen freigegeben werden sollen.

Veröffentlichen des Service in Azure

Das Veröffentlichen der Anwendung erfolgt in der für Azure bekannten einfachen Form. Dazu ist in Visual Studio über das Kontextmenü einfach die Option VERÖFFENTLICHEN auszuwählen. Nachdem das Veröffentlichungsziel MICROSOFT AZURE APP SERVICE ausgewählt wurde, erfolgt eine Weiterleitung auf den in Abbildung 9 dargestellten Wizard.

Abb. 9: Veröffentlichung mit dem Wizard

Nachdem als Verbindungspunkt die oben erstellte Azure Service Fabric ausgewählt wurde, kann mittels „Veröffentlichen“ der Service in die Fabric geschoben werden. Zuvor sollte natürlich das erstellte Zertifikat auf dem Entwicklungsrechner installiert worden sein, sonst gibt es eine Fehlermeldung. Der Fortschritt der Veröffentlichung kann in der Ausgabe von Visual Studio jederzeit eingesehen werden.

Fazit

Azure Service Fabric bietet die Möglichkeit, sich auf das Erstellen von Anwendungen und deren Geschäftslogik zu konzentrieren. Die mit dem Erstellen von verteilten Anwendungen entstehenden Probleme – beispielsweise Skalierbarkeit, Verwaltung und Latenz, werden dabei vollständig Microsoft überlassen, die dies hervorragend beherrschen. Die Verwaltung erfolgt in der von Azure gewohnten übersichtlichen Form.

Da Azure Service Fabric die Technologiegrundlage ist, auf der die gesamte Microsoft-Azure-Infrastruktur sowie viele weitere Microsoft-Dienste, wie etwa Skype for Business, Intune, Azure Event Hubs, Azure Data Factory, Azure-SQL-Datenbank, Dynamics 365 und Cortana aufgebaut ist, können wir uns sicher sein, dass diese Dienstleistung äußerst zuverlässig funktioniert. Die Kosten, die für die Bereitstellung von Azure Service Fabric entstehen, sind ebenfalls überschaubar.

Die Service Fabric ist mit allen Standardgrößen von Windows-Server- oder Linux-VMs verfügbar. Es werden lediglich die gewählten Compute-Instanzen sowie die erforderlichen Speicher- und Netzwerkressourcen für die Erstellung eines Service-Fabric-Clusters in Rechnung gestellt. Für den Service-Fabric-Dienst selbst fallen keinerlei Kosten an.

Die Einsparmöglichkeiten bei den Wartungskosten machen die Mietkosten meines Erachtens schnell wieder wett. Grundsätzlich sprechen die Möglichkeiten, Systeme zu skalieren und jederzeit zu starten und zu beenden, eindeutig dafür, den Weg in die Cloud – sofern nicht schon geschehen – in Angriff zu nehmen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -