---

September 2015

Band 30, Nummer 9

Dieser Artikel wurde maschinell übersetzt.

Microsoft Azure – Fallen bei der Fehlertoleranz und Lösungen in der Cloud

Durch Mario Szpuszta | September 2015

Es gibt mehrere Mechanismen in Microsoft Azure, um sicherzustellen, dass die Dienste bei einem Fehler verfügbar bleiben. Solche Fehler können Hardwarefehler, wie z. B. Festplatte abstürzen oder temporäre Verfügbarkeitsprobleme abhängige Dienste, wie z. B. Speicher oder Netzwerk-Services enthalten. Azure und ihre Infrastruktur Software gesteuert werden, so vorhersehen und verwalten solche Fehler geschrieben.

Bei Auftreten eines Fehlers reagiert die Azure-Infrastruktur (der Fabric Controller) sofort zur Wiederherstellung von Services und Infrastruktur. Wenn eine virtuelle Maschine (VM) aufgrund eines Hardwarefehlers auf dem physischen Host ausfällt, verschiebt der Fabric Controller z. B. basieren, die virtuellen Computer auf einen anderen physischen Knoten auf derselben Festplatte in Azure-Speicher gespeichert. Azure kann auf ähnliche Weise koordinieren, Upgrades und Updates in einer Weise Dienstausfälle zu vermeiden.

Für computing-Ressourcen (z. B. Cloud Services, herkömmliche IaaS-VMs VM Skalierung Sets), sind wichtig und grundlegende Konzepte für hohe Verfügbarkeit Fehlerdomänen und upgradedomänen. Diese wurden seit der Einführung Bestandteil von Azure. Dieser Artikel bietet nicht so gut bekannten Klärung, um diese Konzepte.

Der Azure-Datencenter-Architektur

Um vollständig verstehen Fehlerdomänen und upgradedomänen, ist es hilfreich, eine allgemeine Übersicht über Visualisieren von wie Azure-Datencentern strukturiert sind. Azure-Datencentern verwenden eine Architektur, die innerhalb von Microsoft als 10 Quantum bezeichnet. Höheren Durchsatz im Vergleich zu vorherigen Datacenter-Architekturen unterstützt. Ihre Topologie implementiert eine vollständige, nicht blockierende, vernetzten-Netzwerk mit einer Aggregatfunktion Backplane mit einer hohen Bandbreite für jede Azure-Rechenzentrum, siehe Abbildung 1.

Abbildung 1 Allgemeine Azure Datacenter-Architektur

Die Knoten werden in Racks angeordnet. Eine Gruppe von Racks bildet dann einen Cluster. Jedes Rechenzentrum verfügt über zahlreiche Clustern verschiedener Typen. Einige Cluster sind verantwortlich für die Speicherung, während andere für Compute, SQL usw. verantwortlich sind. Der Top-Of-Rack (TOR)-Switch ist eine einzelne Fehlerquelle des gesamten Racks.

Der Clusters Fabric Controller verwaltet den Computer oder Knoten. Der Fabric Controller orchestriert Bereitstellungen auf Knoten innerhalb eines Clusters. Jeder Cluster verfügt über mehr als ein Fabric Controller für die Fehlertoleranz. Der Fabric Controller muss die Integrität jeder Knoten im Cluster kennen. Dadurch können sie bestimmen, ob der Knoten Bereitstellungen ausführen kann. Darüber hinaus werden der Fabric Controller-Fehler zu erkennen, sodass es Bereitstellungen automatisch reparieren kann, durch die erneute Bereitstellung der betroffenen VMs auf verschiedenen physischen Knoten.

Um der Fabric Controller bei der Bestimmung der Integritäts eines Knotens besser zu unterstützen, hat jeder Computer in einem Cluster verschiedene Agents fortlaufend Knoten-Zustand überwacht und die gleichen wieder zu der Fabric Controller zu kommunizieren. Es ist wichtig zu verstehen, wie die verschiedenen Komponenten zusammenarbeiten, um dies zu erreichen. Wichtigen Komponenten, siehe Abbildung 2, sind:

• Host-Betriebssystem: Das Betriebssystem auf dem physischen Computer ausgeführt wird.
• Host-Agent: Ein Prozess, der zu den einzelnen Knoten ausgeführt, der eine Kommunikation zwischen dem Computer und der Fabric Controller bietet.
• Gastbetriebssystem: Das Betriebssystem auf dem virtuellen Computer ausgeführt wird.
• Gast-Agent: Befindet sich auf dem virtuellen Computer, und kommuniziert mit Host-Agent zum Überwachen und Sicherstellen der Integrität des virtuellen Computers.

Abbildung 2 innerhalb des physischen Computers eines Clusters mit Microsoft Azure

Fehler- und Upgradedomänen

Für die Aufrechterhaltung hoher Verfügbarkeit jeder Anwendung Platform-as-a-Service (PaaS), jede PaaS-Anwendung den Fabric Controller Hosts wäre auf verschiedene Fehlerdomänen verteilt und Domänen zu aktualisieren.

Eine Fehlerdomäne ist eine physische Einheit des Fehlers. Es ist an der physischen Infrastruktur in den Rechenzentren eng miteinander verknüpft. Für Azure entspricht jedes Rack mit Servern eine Fehlerdomäne. Während Azure, dass alle PaaS-Anwendung (mit mehr als eine Instanz gewährleistet) gehostet wird, von der Plattform verfügbaren über mehrere Fehlerdomänen wäre, wird die Gesamtzahl der Fehlerdomänen, über die die Instanzen der Anwendung verteilt werden, von der Fabric Controller basierend auf der Verfügbarkeit der Computer innerhalb des Datencenters bestimmt.

Eine Aktualisierungsdomäne ist eine logische Einheit, die Verfügbarkeit der Anwendung aufrechterhalten, wenn Sie Updates auf dem System übertragen. PaaS-Anwendung ist dies eine konfigurierbare Einstellung. Eine Anwendung in Azure kann seine Instanzen auf maximal fünf upgradedomänen verteilt haben (siehe Abbildung 3).

Abbildung 3 Fehlerdomäne und Aktualisierungsdomäne-Konfiguration

Fehlerdomänen Sie, Domänen, Upgrade und IaaS-VMs

Um Infrastructure-as-a-Service (IaaS) virtuellen Maschinen über Fehlerdomänen verteilt sind, und Aktualisieren von Domänen, Azure, das Konzept der Verfügbarkeit eingeführt. Alle Instanzen innerhalb einer verfügbarkeitsgruppe sind auf mindestens zwei Fehlerdomänen verteilt und separate Aktualisierungsdomäne Werte zugewiesen.

Wenn Sie virtuelle Computer einem verfügbarkeitssatz zuweisen nicht, sind Sie nicht für die Service Level Agreements (SLAs) für diesen virtuellen Computern. Es ist wichtig, dies zu verstehen, da sie definiert, wie hohen Verfügbarkeit für Ihre Dienste und Programme erreichen können, selbst wenn Fehler auftreten oder Upgrades werden an Azure-Datencentern. Nur durch Ihre virtuellen Computer einem verfügbarkeitssatz zuweisen, können Sie vermeiden, durch solche Fehler beeinträchtigt wird.

Um die Bedeutung dieses zu veranschaulichen, betrachten Sie dieses Szenario aus: Das Azure-Produktteam überträgt Betriebssystemupdates auf alle Datencenter in regelmäßigen Abständen. Um Updates für das gesamte Datencenter zu verschieben, müssen das Hostbetriebssystem (physische Computer) und das Gastbetriebssystem (virtuelle Computer hosten PaaS-Anwendung oder Ihren eigenen virtuellen IaaS-Computern) für das aktuelle Betriebssystem aktualisiert werden. Zum Bereitstellen der Updates ohne Auswirkung auf die Verfügbarkeit der Anwendung:

1. Die Host-Betriebssystem-Updates werden über das Datencenter eine Fehlerdomäne als für alle verfügbaren Fehlerdomänen nacheinander ausgeführt.
2. Gast-BS-Updates werden jeweils für die verfügbaren Upgrade-Domänen auf jeder Benutzer ein Upgrade Anwendungsdomäne ausgeführt.

Bei diesen Vorgehensweisen Azure kann drücken Sie Upgrades für eine eigene Infrastruktur unter Aufrechterhaltung der Verfügbarkeit des Service – solange Sie mindestens zwei Instanzen pro Dienst oder mindestens zwei virtuelle Computer als Teil einer verfügbarkeitsgruppe (z. B. ein Lastenausgleich Webdienst, SQL Server AlwaysOn Availability Group-Knoten usw.) ausführen.

Wie viele Fehlerdomänen?

Fehler- und upgradedomänen Gewährleistung der Verfügbarkeit bei PaaS-ähnliche Arbeitslasten, die größtenteils statusfrei sind. Statusfreie ASP.NET-Webanwendungen sind kompatibel mit dieser Ansätze. Auch wenn während der upgradezyklen oder temporäre Ausfallzeiten eine Teilmenge der Knoten ausfällt, bleibt die gesamten Web-Anwendung oder den Dienst verfügbar.

Ruft die Situation schwieriger, bei Infrastruktur mehr statusbehaftete Art, wie z. B. Datenbankservern (z. B. RDBMS oder NoSQL). In diesen Fällen kann das wissen, dass Ihre Server über mehrere Fehlerdomänen verteilt sind nicht ausreichen. Ein Datenbank-Cluster möglicherweise eine minimale Anzahl von Knoten auf alle Zeitangaben für die Cluster Health werden. Betrachten Sie Quorum-basierten Ansätze für die neue master-Knoten bei einem Ausfall Statusmuster.

Für IaaS-VMs garantiert Azure, dass virtuelle Computer in derselben verfügbarkeitsgruppe mindestens zwei Fehlerdomänen (daher zwei Racks) bereitgestellt werden. Es gibt zwar einige Wahrscheinlichkeit die VMs innerhalb einer verfügbarkeitsgruppe auf mehr als zwei Fehlerdomänen bereitgestellt, gibt es keine Garantie. Praktische zum Testen von in den vergangenen Jahren Projekt immer genau zwei Fehlerdomänen beim Bereitstellen in Nordamerika oder Westeuropa sowie mehrere US-Regionen (siehe Abbildung 4).

Abbildung 4 Fehlerdomänen für einen Cluster mit Beispiel SQL AlwaysOn-AG

Abbildung 4 zeigt das Ergebnis einer Get-AzureVM-Befehl durch Azure PowerShell, das dann das Ergebnis in der GridView-Steuerelement anzeigt. Es zeigt, dass die virtuellen Computer im Cluster – das sind alle Teil der gleichen Verfügbarkeit (nicht im Raster angezeigt) – zwei Fehlerdomänen und drei Upgrade domänenübergreifend bereitgestellt werden.

Sql1 und Sqlwitness Knoten von der Bereitstellung des Beispiels befinden sich auf dem gleichen physischen Rack. Die gleichen TOR verbindet, Rack für den Rest des Datencenters. Der Knoten sql2 befindet sich auf einem anderen Rack.

Nur zwei Fehlerdomänen?

Für statusfreie Anwendung, z. B. Web-APIs oder Web Applications sollte nicht auf nur zwei Fehlerdomänen bereitgestellt wird ein Problem mit mindestens hinsichtlich der Konsistenz sein. Statusbehaftete Arbeitslasten wie z. B. Datenbankservern ist es anders, zumindest aus Sicht der Verfügbarkeit.

Je nach Funktionsweise von ein Cluster möglicherweise wichtig zu wissen, wie viele Knoten im Fall eines Fehlers ausfallen können, bevor diese die Cluster Health auswirkt. Wenn ein Cluster quorumstimmen oder Mehrheit basierende stimmen für bestimmte Vorgänge, z. B. Statusmuster neue Master-Shapes oder bestätigt Konsistenz für schreibgeschützte Anforderungen abhängt ist die Frage, wie viele Knoten im ungünstigsten Fall ausfallen können, noch wichtiger.

Obwohl die Fehlerdomäne Ihre virtuellen Computer automatisch wiederhergestellt wird, ist die Frage, wie viele Knoten gleichzeitig ausfallen könnten relevant. Ein Wiederherstellungsvorgang kann je nach der Fabric Controller zum Wiederherstellen des virtuellen Computers selbst und dem Datenbank-Managementsystem, das auf dem virtuellen Computer ausgeführt wird die Dauer der Zeit dauern.

Das gesamte Thema gewinnt an Bedeutung, wenn Sie wissen, dass das interne Verhalten Azure Automatism Upgrades. Bei IaaS-VMs auf alle Upgrades auf das Hostbetriebssystem auf dem Hypervisor auf jedem physischen Knoten, hosten Ihre virtuellen Computer ausführen erfolgt auf Basis Fehlerdomänen – Domänen nicht aktualisiert werden, wie in der Breite Entwicklercommunity ausgegangen. Upgradedomänen werden nur für die Aktualisierung innerhalb PaaS-VMs verwendet. Das bedeutet, dass Sie von Host-BS-Upgrades vierteljährlich betroffen sein werden die normalen Intervall ist. Wenn Ihr Cluster über zwei Fehlerdomänen bereitgestellt wird, hängt jedoch Mehrheit stimmen und ähnliches, könnten Sie zeitweise Ausfälle haben.

Ein allgemeines Beispiel hierfür ist ein MongoDB Replikat in Azure bereitstellen. Jeder Replikatgruppe MongoDB erfordert genau einen Master. Master-Knoten ein Fehler auftritt, wird durch die verbleibenden Knoten ein neuer Master gewählt. Diese Auswahl erfordert die Mehrheit der stimmen für die Wahl des Masters. Nicht genügend Knoten bis zur Abstimmung eines neuen Master, die gesamte Replikatgruppe deklariert einen fehlerhaften Zustand angenommen und kann als "Down" betrachtet werden

Die MongoDB-Dokumentation (bit.ly/1SxKrYI) eine fehlertoleranten pro replikatgröße deutlich erklärt. Nur ein Knoten kann in einer Replikatgruppe drei Knoten fehl. In einem Satz von fünf Knoten, zwei entspricht die maximale Anzahl von Knoten, ohne den gesamten Cluster können wir nach unten, bei, denen in Abbildung 5.

Abbildung 5 Replikatgruppe MongoDB Fehlertoleranz

Anzahl der Mitglieder	Erforderlich, um einen neuen primären wählt Mehrheit	Fehlertoleranz
3	2	1
4	3	1
5	3	2
6	4	2

Wenn die Anzahl der Datenbankknoten, die Sie in einer Replikatgruppe ausführen müssen selbst (z. B. zwei Datenbankknoten für einen Replikatsatz) ist, MongoDB, das Konzept der Arbiter einer eingeführt. Ein Arbiter fungiert als Server für Wahlen Abstimmungsschaltflächen, aber nicht den gesamte Datenbank-Stapel (zum Speichern von Kosten und Ressourcen) ausgeführt. Wenn Sie am Ende eine MongoDB-Replikatgruppe Datenbank zwei Knoten ausreichend sind, benötigen Sie einen dritten Knoten – der Arbiter, wird es nur eine weitere Stimme für die meisten basierende master Wahl bei einem Ausfall zu bieten.

Es ist eine ähnliche Situation mit der SQL Server AlwaysOn-Availability Group, in die Mehrzahl der Knoten an einen neuen primären Knoten erforderlich ist. Das Prinzip der Member nur stimmen ähnelt. Nur ein Zeuge bezeichnet, in der Welt von SQL Server (anstelle von Arbiter, genannt in MongoDB,).

In Betracht ziehen, SQL Server und die Bereitstellung wieder im angezeigten Abbildung 4, es deutlich Zustände sql1 und Sqlwitness auf eine Fehlerdomäne und sql2 ist auf einem anderen. Fällt die Fehlerdomäne "0", der Master- und der Zeuge sind beide nach unten – nur sql2 bleibt. Sql2 allein ist jedoch eine unzureichende Mehrheit für die Wahl eines neuen Masters im Cluster. Das bedeutet Fehlerdomäne "0" ein Fehler auftritt, der gesamte Cluster fehlerhaft ist.

Die Situation wäre noch schlimmer, wenn sql1 und sql2 auf derselben Fehlerdomäne hinzufügten. Dann würden beide Datenbankknoten nicht zur Verfügung, bis der Fabric Controller Knoten aus einem potenzielle Fehler wiederhergestellt oder das Hostbetriebssystem Upgradevorgang abgeschlossen.

Die Situation ist vergleichbar mit einer Replikatgruppe MongoDB. Die Tabelle in Abbildung 5 aus dem offiziellen MongoDB Dokumente deutlich erklärt, dass in einer Replikatgruppe drei Knoten, nur einen Knoten für den gesamten Cluster aktiv und verfügbar bleiben durchgeführt werden kann. Aus diesem Grund ist es wichtig wie die Knoten über eine bestimmte Anzahl von Fehlerdomänen verteilt sind. Sie können es in Azure-Host-BS-Upgrades und potenzielle Fehler beeinflussen.

Hohe Verfügbarkeit in statusbehaftete Services

Eine gültige Frage, dann ist, wie Sie hohen Verfügbarkeit erreichen können, wenn virtuelle Computer von Azure größtenteils auf zwei Fehlerdomänen bereitstellt. Mittelfristige und kurzfristige Antworten auf diese Frage sind vorhanden.

Mittelfristige arbeitet die Azure-Produktgruppe die Situation drastisch verbessern. Wenn Sie Version 2 IaaS-VMs (basierend auf der neuen Azure-Ressourcen-Manager-API) bereitstellen, kann Azure Ihre Arbeitslasten auf mindestens drei Fehlerdomänen bereitstellen. Das ist eine Version 2 verwendet einen guten Grund VM und der Azure-Ressourcen-Manager.

Kurzfristige oder solange Sie immer noch traditionelle Azure Service Management und Version 1 IaaS VMs abhängig sind, ist es nicht so einfach. Zeigen Sie je nach Ihrer SLA Recovery Time Objective (RTO) und Recovery Objective (RPO)-Ziele, die Ihnen zwei Optionen zur Verfügung, die das Risiko von Ausfallzeiten zu verringern. Beide Ansätze zeigt Abbildung 6, und basieren auf einer SQL Server AlwaysOn Availability Group.

Abbildung 6: SQL Server AlwaysOn Availability Group-Bereitstellung

Das Ziel ist immer wirken sich regelmäßig auftreten, dass Host-BS-upgrades und eventuelle Fehler reduzieren. Für einen Cluster mit drei Knoten in einem einzigen Datencenter stellen Sie eine außerhalb der Menge der VM-Verfügbarkeit und zwei Knoten als Teil der gleichen VM Verfügbarkeit bereit.

Die Wirkung des Host-BS-Upgrades sind fast vollständig mit diesem Ansatz verringert. Der Zeitpunkt für die Aktualisierung von virtuellen Computern innerhalb der Verfügbarkeit der unterscheidet sich von den einzelnen VM-Host-BS-Upgrades. Host-Betriebssysteme Einzel-VMs ohne Verfügbarkeit werden in der Regel ungefähr eine Woche vor solchen mit virtuellen Computern in der Verfügbarkeit aktualisiert.

Im Fall von Fehlertoleranz Domäne Fehler können Sie nur die Wahrscheinlichkeit des betroffenen reduzieren. Es ist immer eine Wahrscheinlichkeit der Knoten außerhalb der Verfügbarkeit Satz Antarktisgebiete auf einem Fehlerdomänen VMs innerhalb der Verfügbarkeit. Viel hängt von den Ressourcen verbraucht und in einem Azure-Rechenzentrum verfügbar.

Für eine Active Directory-Domäne wie in Abbildung 6, besteht keine Notwendigkeit für eine solche Lösung. Es ist nur ein Primär- und Domänencontroller für hohe Verfügbarkeit, trotzdem. Zwei Knoten, die perfekt auf zwei Fehlerdomänen verteilt ist was Azure für Version 1 IaaS VMs gewährleistet ist.

Dies dennoch bleibt Ihnen besser vorbereitet wird, für die SQL-Knoten auf der Grundlage der Herausforderung Abbildung 6. Sie können dieses Risiko verringern, indem Sie die Sqlwitness im gleichen Datencenter nicht bereitstellen. Die nicht nur die Wahrscheinlichkeit reduziert. Es entfällt im Wesentlichen das Risiko. Lösung auch ist, ausgedrückt in Abbildung 6: Verteilen Sie die Bereitstellung auf zwei Regionen.

Zwei Optionen

Je nach Ihrer SLA RPO und RTO muss und was für hohe Verfügbarkeit zu bezahlen bereit sind, erneut haben Sie zwei Hauptoptionen: Die voll funktionsfähige backup-Bereitstellung in eine zweite Region oder müssen nur den Arbiter/Zeugen in der sekundären Region.

Eine voll funktionsfähige sekundäre Bereitstellung bedeutet, dass Sie die gesamte Bereitstellung in einer sekundären Region repliziert. Auch zählen, die Ihre Front-End- und Middle-Tier-Anwendung und Dienste. Bei einem schwerwiegenden Fehler in der primären Region könnten Sie Kunden dann an die sekundäre Region umleiten.

Bereitstellungen werden in der Regel für sicheres RPO/RTO-Ziele erstellt. Für Datenbanksysteme wie MongoDB oder SQL-AlwaysOn mit kurzen RPO und RTO führen solche Anforderungen in der Regel umfassen die Replikatgruppe oder AG SQL-Cluster über zwei Regionen mit fortlaufenden Replikation in diesen Regionen aktiviert. Zwar die Replikation zwischen Regionen wahrscheinlich durch Probleme der Wartezeit und asynchrone Replikation in eine beliebige Stelle in Millisekunden auf Minuten, im Gegensatz zu zweistelliges Minuten oder Stunden erfolgt.

Auf der anderen Seite ist nur ein Zeuge oder Arbiter ausgeführt, in der sekundären Region als einzelne VM eine viel kostengünstigere Alternative. Es ist gut genug bei müssen Sie nur den primären Cluster bei einem Ausfall der Fault-Domäne beibehalten werden soll. Es ist die Möglichkeit, sofort einen Failover auf eine sekundäre Region ohne einige ernsthafte zusätzliche Schritte, wie z. B. hochgefahren neue Knoten und virtuellen Computern in der sekundären Region hinzuzufügen.

In dem Beispiel in Abbildung 6, Sie könnte auch einen vollständigen SQL-Knoten ausführen, in der sekundären Region als der einzige Knoten. Da es als einen einzelnen virtuellen Computer ausgeführt wird, müsste andere upgradezyklen. Darüber hinaus, da er in einem anderen Rechenzentrum ausgeführt wird, ist die Wahrscheinlichkeit, dass er aktualisiert wird oder fehlerhafte zur gleichen Zeit wie die Knoten in der primären Verfügbarkeit gering.

Nachbereitung

Erzielen hoher Verfügbarkeit und Fehlertoleranz für Ihre Programme und Dienste ist ein einfacher Prozess nicht. Verstehen und zu grundlegenden Konzepten anpassen muss. Sie müssen verstehen Fehlerdomänen, Domänen und Verfügbarkeit zu aktualisieren. Insbesondere müssen Sie die Fehlertoleranz Anforderungen statusbehaftete Systeme zu verstehen, die Sie in Ihrer Infrastruktur verwenden bei der Umstellung auf Azure. Ordnen Sie diese Anforderungen Fehlertoleranz Verhaltensweisen von Fehlerdomänen, und aktualisieren Sie Domänen in Azure.

Für völlig neue IaaS-Bereitstellungen unbedingt nutzen IaaS-VMs v2 Bestandteil der Azure-Ressourcen-Manager und Ressourcengruppe sind. Auf diese Weise profitieren Sie von der Fehlertoleranz auf mindestens drei Fehlerdomänen bereitgestellt wird. Bereitstellungen mit herkömmlichen Servicemanagement stellen Sie sicher, Sie verstehen, und nutzen die Fakten, die in diesem Artikel beschriebenen. Diese Vorschläge können Auswirkungen der Fehlertoleranz Domäne Ausfallzeiten und Wartungsereignisse wie z. B. Host-BS-Upgrades verringern. Einführung und Anpassen der hier erläuterten Konzepte, werden Sie hohen Verfügbarkeit ohne überraschende unerwünschte Ergebnisse zu erzielen.

---

Mario Szpuszta ist leitender Programmmanager für die DX-Corp. Globale ISV-Team. Er arbeitet mit unabhängigen Softwareanbietern auf der ganzen Welt ihre Lösungen und Dienste auf dem Microsoft Azure zu aktivieren. Sie erreichen ihn über seinen Blog (blog.mszcool.com), auf Twitter (twitter.com/mszcool) oder über marioszp@microsoft.com.

Srikumar Vaitinadin ist als Softwareentwickler für die DX-Corp. Globale ISV-Team. Davor war er beim Migrieren von Microsoft-Eigenschaften in Azure. Erhalten Sie in Kontakt mit Srikumar über srivaiti@microsoft.com.

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels: Guadalupe Casuso und Jeremiah Talkar
Guada Casuso ist ein Technologieexperte für Microsoft Azure arbeiten und in der Cloud und Cross-Plattform Mobile Entwicklung aufgetreten ist. Wenn er nicht funktioniert, ist sie in einem Paddleboard oder fliegenden Drones. Guada teilt ihre Gedanken in seinem Blog unter atomosybitsenlanube.net und auf Twitter unter twitter.com/guadacasuso.