01. Juli 2019

Der ideale Workload für die Cloud – Buildprozesse mit Spot-Instanzen

cloud_bank_now_aws_blog

Eine der ersten Fragen, die sich im Cloud Kontext stellt, ist: Welche Workloads eignen sich für den ersten Schritt in die Cloud? Lesen Sie im Folgenden, weshalb Build- und Test-Prozesse für Software-Artefakte besonders geeignet sind und was es basierend auf den Erfahrungen aus unserem Projekt mit der BANK-now zu beachten gilt.

Wenn sich ein Unternehmen dafür entschieden hat, Cloud Services zu nutzen, müssen zuerst die zu migrierenden Workloads identifiziert werden. Der entsprechende Workload sollte aus Business-Sicht unkritisch sein, keine Compliance oder Datenschutzprobleme verursachen und halbwegs isoliert von anderen Systemen sein, um die Integration zu vereinfachen.

Ein naheliegender Kandidat für einen solche Workload sind CI/CD-Prozesse, im speziellen Build- und Test-Prozesse für Software-Artefakte. Sie sind aus Compliance-Sicht völlig unproblematisch, da sie keinerlei Daten im Sinne des Datenschutzgesetzes enthalten und ein fehlerhafter Build mag zwar ärgerlich sein, ist aber nur selten Business-kritisch. Diese Prozesse sind auch noch aus einem anderen Grund prädestiniert für ein Cloud Deployment: Sie produzieren hohe Last in einem begrenzten Zeitfenster.

 

Mit Spot-Instanzen lassen sich Kostenvorteile erzielen

Für unseren Kunden BANK-now in Horgen am Zürichsee durften wir in den letzten Monaten ein Projekt realisieren, bei dessen Entwicklung uns Cloud-Dienste sehr von Nutzen waren. Speziell haben wir die Build Prozesse für die Software-Artefakte auf AWS implementiert und konnten so die knappen on-premise Ressourcen deutlich entlasten. Da ausschliesslich Build-Prozesse in der Cloud implementiert und keinerlei Daten dort gespeichert wurden, war die Auslagerung dieser Tasks auch aus Compliance-Sicht unproblematisch. 

Aufgrund der Load-Charakteristik konnten zudem preiswerte Spot-Instanzen genutzt werden, die deutlich billiger sind als on-demand Instanzen. Spot-Instanzen zeichnen sich dadurch aus, dass AWS damit seine nicht genutzten Ressourcen zu Discountpreisen anbietet. Die Preise werden laufend der aktuellen Last im AWS Data Center angepasst. Die Preisfindung funktioniert wie an einer Börse. Als Kunde bietet man einen Maximalpreis und bekommt dann den Zuschlag, wenn der aktuelle Preis unterhalb der definierten Schwelle liegt. Die realisierbaren Preisvorteile liegen typischerweise bei 60 bis 80% im Vergleich mit on-demand Instanzen. Der Haken bei der Sache ist, dass AWS etwa 5 bis 20% der Instanzen eigenständig terminiert, weil die Ressourcen etwa für höherpreisige on-demand Instanzen benötigt werden.

 

Es kommt auf das Design der Workloads an

Um nun trotz des Damoklesschwerts der vorzeitigen Terminierung die Workloads erfolgreich abarbeiten zu können, müssen die Workloads entsprechend konzipiert werden. Im Umfeld von Spot-Instanzen bieten sich dafür folgende Strategien an:

  • Die Workload, in diesem Fall die Build Jobs, müssen so gestaltet sein, dass sie nach einer Terminierung durch AWS selbständig und nur mit geringem Verlust wiederanlaufen können. 
  • Die Build Jobs sind dabei so zu schneiden, dass eine zufällige Terminierung nur wenig bereits geleistete Arbeit vernichtet.
  • Mittels Termination Notice kann AWS Cloud Watch zwei Minuten vor der eigentlichen Terminierung die betroffene Spot-Instanz in einen sicheren, wiederanlauffähigen Zustand versetzen und die bereits geleistete Arbeit sichern.
  • Durch die Definition von Block Durations kann eine Spot-Instanz von vornherein so angefordert werden, dass AWS sie für die spezifizierte Zeitdauer von einer bis sechs Stunden sicher nicht vorzeitig terminieren wird. Eine solche Reservation ist jedoch kostenpflichtig.

AWS bietet so effiziente Mittel, um dafür geeignete Workloads wie Build Jobs sehr kostengünstig abzuwickeln. Da gerade grosse Build Jobs in der Regel hohe CPU- und Memory-Anforderungen haben, sind Spot-Instanzen eine ideale Lösung. Die internen IT Ressourcen werden entlastet, ohne die signifikanten Kosten von grossen Compute-Instanzen in der Cloud tragen zu müssen. 


Bernd  Leinfelder
Bernd Leinfelder

Bernd Leinfelder ist seit 2016 System Architekt bei ti&m. Er verfügt über langjährige Erfahrungen in Softwareentwicklung und System Engineering. Neben seiner Tätigkeit bei ti&m leitet er den Fachbereich Enterprise Computing an der Fernfachhochschule Schweiz und doziert dort zu Robustheit und Wartbarkeit verteilter Software. Er hält diverse Zertifizierungen in den Bereichen Cloud Computing, IT-Security und IT-Audit.

Weitere Beiträge

Glühbirne 750x410
Become a Digital Ambassador

Mehr erfahren
Axpo Agile Workshop Lead Image
Wie man mit dem Bau eines Marsrovers agiles, skaliertes Vorgehen lernt

Wie man agiles Arbeiten auch spielerisch erlernen kann, haben wir bei der Axpo gezeigt. Wir bauten einen Marsrover mit agilen Methoden. Was gar nicht so einfach war, jedoch gut gemeistert wurde.

Mehr erfahren
2017_06_Rimle-Postauto
Autonome Postautos: unterwegs mit der Zukunft

Autonome Fahrzeuge // Die autonomen Postautos haben keinen Fahrer und können dank ihrer leistungsfähigen Sensoren problemlos navigieren. Zum ersten Mal testet ein Unternehmen diese Technologie in der Schweiz im öffentlichen Raum.

Mehr erfahren
Security, die Killer-Applikation des IoT
Security, die Killer-Applikation des IoT

Mehr erfahren
Covid19_closed_2020
Beschleunigt die Corona-Krise die Digitalisierung der Schweizer Banken?

Die Corona-Krise wird auch langfristige Auswirkungen auf die Schweizer Retailbanken haben. Es gilt sich jetzt auf die massiven Veränderungen vorzubereiten. In einer Beitragsserie schauen wir uns Szenarien für den Finanzplatz Schweiz näher an.

Mehr erfahren