Cloud-Computing
Was bei einer Migration zu beachten ist
Was bedeutet es für ein Unternehmen die IT-Services in der Cloud zu betreiben? Wie sollte ein Sizing von bestehenden Systemen nach einer Migration in die Cloud aussehen? Und ändern sich bestehende Prozesse nach einer Migration? Diesen und anderen Fragen geht Kolja Henckel von Arvato nach.
Die Cloud bietet in erster Linie Rechenleistung. Diese Rechenleistung, meist in Form von virtuellen Maschinen (VM), ist auf Knopfdruck abrufbar und wird nur für die tatsächlich genutzte Zeit gezahlt. Eine Stunde, oder in manchen Fällen auf eine Sekunde heruntergebrochen, wird per Kreditkarte abgerechnet. Dabei gibt es bei allen Anbietern verschiedene Maschinentypen und T-Shirt-Sizings. Welche Art von virtualisierter Maschine und welches Sizing das Richtige für eine Migration ist, hängt von der zu migrierenden Applikation und deren Anforderungen ab. So gibt es spezielle VMs mit GPU-Unterstützung, breiterer Netzwerkanbindung oder mit 4+TB RAM, um dort In-Memory-Datenbanken zu betreiben. Die Auswahl an Typen wächst immer weiter. Netzwerk- und Internetanbindungs-Geschwindigkeiten, die im regulären Datacenter-Betrieb durchaus zu Engpässen führen können, werden hierbei dynamisch an die Anforderungen des Kunden angepasst. Durch die regelmäßige Erneuerung der Serverhardware ist auch im Cloudumfeld eine Nutzung von aktuellen Prozessorgenerationen möglich. Durch die von den Cloudanbietern angebotenen Plattform-Dienste (PaaS) werden zudem immer neue Möglichkeiten in der Bereitstellung von neuen Funktionalitäten geschaffen.
Monolith oder mehrere kleine virtuelle Server?
Bei einer Eins-zu-eins-Migration eines Servers in die Cloud ist die Geschwindigkeit und die Auslastung nach der Migration theoretisch erst einmal genauso hoch wie vorher. Allerdings werden bei einer solchen Migration auch keine der cloud-spezifischen Vorteile wie Flexibilität und Elastizität berücksichtigt.
Durch die Preisgestaltung der Cloudanbieter und die Möglichkeit zur automatischen Skalierung ist es meist interessanter mehrere kleine virtuelle Server zu nutzen, die die gleiche Applikation bereitstellen, als einen großen Monolithen. Das bietet am Ende ein ausfallsicheres Szenario mit mehreren VMs, die sich über mehrere Rechenzentren verteilen können, zu den gleichen Kosten des bisherigen Monolithen. Dabei sind natürlich seitens der Applikation einige Voraussetzungen zu erfüllen.
Der Vorteil einer solchen Aufteilung liegt darin, dass es möglich ist, bei hoher Last weitere Server mit der gleichen Applikation und der gleichen Konfiguration in den Verbund aufzunehmen. Bei sinkender Last können einzelne Server wieder abgeschaltet werden, um so die Kosten gering zu halten.
Natürlich muss für eine dynamische Anpassung der Server im Voraus vieles bedacht und automatisiert werden. Infrastructure-as-Code ist die Grundlage für eine automatisierte Serverlandschaft, die Hand in Hand mit einem Configuration Management Tool geht, um die Konfiguration aller Applikationen und Tools auf allen Servern einheitlich zu verwalten. Als letzte Zutat kommt nun noch ein Applikationsrepository hinzu, das den aktuellen Softwarestand auf den Server ausrollen kann.
- Was bei einer Migration zu beachten ist
- Rückbesinnung auf "nachhaltige" Softwareentwicklung
Lesen Sie mehr zum Thema
