01. July 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

Evolutionary 750x410
Evolutionary and Disruptive All at Once

There has been a fundamental shift in customer values in the insurance sector, studies and experts tell us. This is being driven by technology. As time goes on, customer opinions will no longer be solely based on brand loyalty and confidence in advisors, but increasingly on digital social networking and self-service.

find more information
murer_lead
An introduction to open banking

Open Banking // Although Swiss banks do not necessarily have to engage with open banking, they would be very wise to do so. Implemented correctly, open banking gives banks the tools to survive and compete in the future. There are also cultural issues to contend with.

find more information
scheidegger_produkte_lead
To get digitalization right, you need the right products

Products // What is it that sets groundbreaking digitalization products apart? There are three key aspects: openness, modularity, and innovation. These three elements need to work together in harmony to create powerful products that can withstand the challenges of the accelerating speed of igitalization and changes in the market.

find more information
Homeoffice_work_business
Banking – made in Swiss Homeoffices

Wandelt sich das Homeoffice nun auch für die Schweizer Bankenwelt zur Normalität? Zumindest ist sicher, dass die Covid-Krise langfristige Auswirkungen auf die Bankenkultur haben wird. Anhand von vier Hypothesen zeigen wir mögliche Veränderungen auf.

find more information
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.

find more information