Programmieren für die Cloud

5 Minuten

Für das Entwerfen von Programmen, die für die Cloud bestimmt sind, müssen besondere Aspekte beachtet werden. Je nach Typ der Anwendung und der erwarteten Last können Entwickler einige der von Cloudanbietern bereitgestellten Features nutzen, um die Skalierbarkeit und Verwaltbarkeit von Programmen zu verbessern. Die Verwendung von automatischen Skalierungssystemen und Lastenausgleichen ermöglicht es Entwicklern, die Infrastruktur basierend auf der Hardwarenutzung oder einem vom Programm berechneten Faktor für die Auslastung dynamisch zu vergrößern oder zu verkleinern.

Es gibt mehrere Überlegungen, die ein Entwickler berücksichtigen muss, wenn eine Anwendung in die Cloud entwickelt oder migriert werden soll, insbesondere solche, die sich auf die Leistung und Sicherheit beziehen.

Leistungsfaktoren für Anwendungen in der Cloud

Die Umgebung in einem cloudorientierten Rechenzentrum unterscheidet sich von dem, was Entwickler beim Entwerfen und Bereitstellen von Anwendungen in einer eigenen Infrastruktur gewohnt sind. Einige Entwickler finden es schwierig, die Leistung ihrer Anwendungen zu optimieren oder zu verbessern, da sie keinen Zugriff auf das Layout der physischen Hardware oder Spezifikationen in öffentlichen Clouds haben. Wir versuchen, einige der am häufigsten auftretenden Probleme aufzulisten und legen besonderen Schwerpunkt auf Faktoren, die die Anwendungsleistung in der Cloud beeinflussen:

Ressourcenbandweite und Latenz

Ein Hauptproblem beim Entwickeln und Bereitstellen von Cloudanwendungen ist die Latenzzeit. Entwickler müssen ihre Anwendungen mit strengen Latenzanforderungen planen. Ein Ansatz besteht darin, die Verteilung von Clientstandorten zu kompilieren. Auf diese Weise können Entwickler die optimalen Rechenzentrumsstandorte finden, die zum Optimieren der Leistung und Reaktionsfähigkeit für Endbenutzer verwendet werden können. Dies gilt insbesondere für Webanwendungen, bei denen einzelne HTTP-Anforderungen für statische Webinhalte einen wichtigen Bruchteil der Ladezeiten einer Webseite darstellen können.

Abgesehen von der Latenzzeit haben Anwendungen möglicherweise auch strikte Bandbreitenanforderungen, insbesondere solche, die mit umfangreichen Multimediainhalten wie Audio und Video arbeiten. Viele Cloudanbieter ermöglichen Cloudentwicklern die Angabe von Leistungsparametern in Form von IOPS-Anforderungen für Compute- und Speicherressourcen während der Bereitstellung. Zusätzlich lassen viele Cloudanbieter zu, dass Entwickler virtuelle Netzwerke einrichten. Die Implementierung und Übernahme von softwaredefinierten Netzwerk- und Speicherinstanzen (wird in späteren Modulen behandelt) bieten zusätzliche Einblicke in neuere Techniken, die von Rechenzentren zum Verwalten von Datenverkehr von mehreren Clients verwendet werden, während einzelne Anforderungen wie in den Client-SLOs angegeben verwaltet werden.

Die oben erwähnten Techniken richten sich hauptsächlich an statische Inhalte. Ein weitaus schwierigeres Problem besteht darin, die Latenz des Zugriffs auf verteilte Datenspeichersysteme zu optimieren, insbesondere solche, die Schreib- und Aktualisierungsvorgänge verarbeiten müssen. Weitere Informationen zu diesen Bedenken finden Sie in späteren Modulen.

Mehrinstanzenfähigkeit

Anwendungen in öffentlichen Rechenzentren werden in der Regel in einer gemeinsam genutzten Infrastruktur ausgeführt. Dieser Clouddienstaspekt lässt einige wichtige Fragen aufkommen. Moderne Virtualisierungstechnologien bieten zwar eine isolierte Umgebung in Bezug auf die Anwendungsumgebung und -Sicherheit, sie können jedoch die Leistungsisolation in der Regel nicht garantieren. Daher können virtualisierte Ressourcen in Clouds nicht immer eine konsistente Leistung garantieren. Die Leistung einer Ressource zu einem beliebigen Zeitpunkt ist eine Funktion der Gesamtlast auf Ressourcen aller Mandanten, auch bekannt als die Interferenz (Störung), die von anderen Mandanten wahrgenommen wird, die dieselbe Hardware verwenden.

Einige Cloudanbieter (z. B. Azure) bieten Clients die Möglichkeit, bestimmte Ressourcentypen (wie VMs) auf dedizierter Hardware bereitzustellen. Dies bietet Schutz vor hohen Schwankungen der Ressourcenleistung und gewährleistet so eine relativ konsistente Leistung für die Ressourcen. Die dedizierten Hardwareinstanzen kosten jedoch deutlich mehr als normale bedarfsgesteuerte Instanzen, da Azure exklusiv für die Ressourcen einen Server zuweisen muss.

Ein verwandter Aspekt der Mehrinstanzenfähigkeit ist das Problem der Bereitstellungsvariation, bei der identische Anforderungen für virtuelle Ressourcen in öffentlichen Clouds nicht identisch auf physische Ressourcen zugeordnet werden, wodurch Leistungsschwankungen auftreten.¹ Beispielsweise können zwei identische Anforderungen für virtuelle Computer (VM1 und VM2) an zwei verschiedene physische Computer (A und B) weitergeleitet werden. Der physische Computer A hat vielleicht vier Mandanten, die um Ressourcen auf demselben Computer konkurrieren, wobei Computer B nur zwei Mandanten hat. Dem Client wird für die virtuellen Computer VM1 und VM2 der gleiche Betrag in Rechnung gestellt, jedoch kann sich die Leistung auf beiden Computern voneinander unterscheiden.

Sicherheitseinstellungen

Öffentliche Clouds unterliegen vermehrten Angriffsvektoren, wie wir bereits in Lerneinheit 1 gesehen haben. Entwickler müssen bei der Bereitstellung und Verwalten von Anwendungen in der Cloud äußerst vorsichtig sein, um sicherzustellen, dass Best Practices, Protokolle und Prozeduren befolgt werden. Folglich können zusätzliche Leistungseinbußen durch die Verwendung von Sicherheitsprotokollen auftreten, die von öffentlichen Clouds vorgeschrieben sind.

Da diese Protokolle in einem früheren Modul behandelt wurden, werden diese nicht mehr ausführlicher erörtert. Jeder in einer öffentlichen Cloud bereitgestellter Code muss einen strengen Prozess manueller und automatisierter Quellcodeüberprüfungen und statische Analysen sowie eine dynamische Analyse zu Sicherheitsrisiken sowie Penetrationstests durchlaufen. Richtlinien für die sichere Bereitstellung von Anwendungen werden auf der nächsten Seite erläutert.

Literatur