Infrastructure as Code
Die Zukunft des Backups
Das Infrastructure-as-Code-Prinzip setzt komplette Systeme als Prozess auf, der unendlich dupliziert, modifiziert gelöscht und vor allem voll automatisch ausgeführt werden kann. Was muss ein Backup leisten, um diesem Paradigmenwechsel zu folgen?
Das Service-Modell Infrastructure as Code treibt das Konzept der Virtualisierung und der Cloud bis auf die Spitze. Im Cloud-Modell sind Systeme von der physischen Hardware bereits getrennt, aber jemand muss die Ressourcen und Systeme noch manuell anordnen. Infrastructure as Code will den gesamten Prozess, wie ein neuer Server mit Applikation und Zusatzdiensten aufzusetzen ist, vollkommen automatisieren, und zwar in Form eines Programmcodes, der jederzeit kopiert, modifiziert und automatisch ausgeführt werden kann.
Dank Infrastructure as Code können Entwicklungsteams also Hunderte oder Tausende neue Server automatisch aufsetzen, ihre Entwicklungszyklen beschleunigen und so schneller neue Anwendungen in der Cloud ausrollen. Jede einzelne Konfiguration des Codes kann einfach versioniert, wiederhergestellt und gesichert werden. Ein großer Vorteil, wenn man diesem modernen Ansatz den traditionellen Weg entgegenstellt, eine IT-Applikation aufzusetzen. Für DevOps-Verfahren liefert Infrastructure as Code große Vorteile, schließlich werden alle Ressoucen und Services darin per Code also Software defined geliefert.
Wer es schafft, seine neuen Applikationen und Services mit kurzen Vorlaufzeiten zu konzipieren, aufzusetzen und umzusetzen, hat im Rennen um Anwenderzugriffe und Kunden, gute Chancen und kann beim entscheidenden Schritt schneller sein. Die „Time to market“ ist somit zum entscheidenden Faktor geworden. Nicht nur die Big Five der Cloud-Branche, sondern auch mittlere und große Unternehmen, die selbst bereits Teile ihrer IT-Infrastruktur in Form einer Private-Cloud betreiben, können davon profitieren.
Doppelter Boden
Die völlig virtualisierten Anwendungs-Stacks liefern von sich aus eine hohe Ausfallsicherheit, da automatisch eine neue virtuelle Maschine aufgespielt wird, sollte eine andere in der Produktion abstürzen oder ausfallen. Die Frage ist jedoch, was ist mit den darin bearbeiteten Daten passiert, die auf den DevOps-Systemen und auf der als Infrastructure as Code konzipierten Cloud bearbeitet werden. Schließlich soll es möglich sein, sie klug und skalierbar per Backup zu sichern.
Denn Menschen machen Fehler und korrumpieren Codes, sie müssen oder möchten möglicherweise auf einen alten Systemstand zurückgehen. Das decken Backup-Konzepte von je her ab. Auch essenzielle Teile der Infrastruktur wie die Datenbank, können ausfallen oder gehackt werden. Auch hier möchte man dann gern eine Kopie des Datenstandes von gestern aufspielen, um den Ausfall schnell zu kompensieren.
Allerdings sind die Workloads in einer DevOps-Umgebung sehr dynamisch, die Entwickler setzen virtuelle Maschinen nach Bedarf auf und löschen sie, sobald diese nicht gebraucht werden. Die Entwickler automatisieren die Bereitstellung, deshalb müsste das Backup-Konzept im Idealfall das Infrastructure as Code Paradigma einhalten und Backup als virtuellen Service definieren, der per Code als Bestandteil im Service-Stack eingepflegt werden kann.
Die Strukturen moderner DevOps-Anwendungen sind oft komplex, mehrstufig, auf verschiedenen Standorten verteilt und greifen auf moderne Echtzeit-Datenbanken wie Hadoop oder SAP Hana zurück. Jedes dieser Systeme muss vom Backup abgedeckt und seiner Natur entsprechend gesichert werden, sei es klassisch per Full Backup oder mit Hilfe von Snapshots.
Und zu guter Letzt verändert sich eine moderne DevOps Umgebung recht kurzfristig, denn die Dienste werden konstant an die Anwender und Last angepasst. Es ist sehr wahrscheinlich, dass sich die Applikationslandschaft von heute stark von der in zwei Monaten unterscheidet. Auch dass muss ein Backup-Konzept beherrschen.
- Die Zukunft des Backups
- Das wilde Pferd zähmen
Lesen Sie mehr zum Thema
