© Ekaphon maneechot/Shutterstock.com
Designherausforderungen von Cloud-Anwendungen

Fantastisch elastisch!


Das häufigste Argument für Cloud-Lösungen in den Medien und auf Entscheiderebene ist, dass man beim Anwendungsbetrieb Kosten sparen kann, weil man nicht mehr durchgängig die Rechenleistung für die Spitzenlast vorhalten muss, sondern nur noch die Rechenleistung bezahlen muss, die man gerade benötigt. Dabei wird aber häufig übersehen, dass es nicht reicht, eine vorhandene Anwendung einfach in eine Cloud-Umgebung zu deployen, um die versprochene Kostenersparnis zu realisieren, sondern dass Anwendungen dafür explizit designt und umgesetzt werden müssen. Dieser Beitrag gibt einen Überblick, was beim Design einer Anwendung zu beachten ist, damit sie „Cloud-ready“ ist.

Video: Interview mit Uwe Friedrichsen

Für den von endlosen Budgetdiskussionen geplagten IT-Entscheider klingt es fast zu schön, um wahr zu sein: Flugs ein paar Anwendungen in die Cloud deployt und schon lassen sich bequem Betriebskosten sparen. Man bezahlt nur noch für die aktuell benötigte Rechenleistung und muss nicht mehr durchgängig die Ressourcen für die Spitzenlast vorhalten, die vielleicht nur einmal im Jahr anfällt. Und es muss ja auch gar nicht gleich alles zum Cloud-Provider verschoben werden. Via Hybrid-Cloud-Angeboten läuft bei Normallast alles wie gewohnt im eigenen Rechenzentrum und nur Lastspitzen werden dynamisch über den Cloud-Provider abgehandelt. Und da es immer mehr deutsche Cloud-Provider gibt, entspannt sich auch die Sicherheitsthematik zusehends, die die Nutzung von Cloud-Angeboten bislang recht schwierig gemacht hat.

Euphorie und Ernüchterung

Die Entscheidung fällt leicht: Es wird „Cloud gemacht“, und endlich kann der IT-Entscheider den nächsten Budgetverhandlungen mit dem CFO wieder gelassen entgegen sehen – denkt er. Denn nach anfänglicher Euphorie setzt in der Umsetzung schnell Ernüchterung ein: Die Anwendungen skalieren nicht richtig. Größer geht zwar halbwegs, aber schrumpfen funktioniert nicht. Der versprochene Business Case löst sich in Luft auf und anstelle von Kosteneinsparungen sitzt der IT-Entscheider plötzlich auf horrenden Kosten für die Cloud-Ressourcen – entspannte Budgetverhandlungen ade.

Was ist schiefgegangen? Das Problem ist, dass Anwendungen elastisch sein müssen, um den beschriebenen Business Case realisieren zu können. „Elastisch“ bedeutet in Kurzform, dass einzelne Anwendungsknoten jederzeit hinzugefügt oder weggenommen werden können, ohne dass es für den Anwender sichtbare Auswirkungen haben darf. Auch den ungewollten Ausfall eines Anwendungsknotens muss die Anwendung transparent für den Anwender kompensieren können.

Eine Anwendung wird aber nicht automatisch elastisch, indem man sie in eine Cloud-Infrastruktur deployt. Man muss eine Anwendung vielmehr explizit elastisch konzipieren und umsetzen. Das gilt grundsätzlich, egal ob man eine private, hybride oder öffentliche Cloud-Lösung einsetzt: Anwendungselastizität ist keine Frage der Laufzeitumgebung, sondern des Anwendungsdesigns.

Herausforderungen von Cloud-Umgebungen

Aber wie designt man eine elastische Anwendung? Um diese Frage zu beantworten, ist es sinnvoll, erst einen kurzen Blick auf die Besonderheiten von Cloud-Umgebungen und die daraus resultierenden Herausforderungen für das Anwendungsdesign zu werfen.

Die Basis von Cloud-Lösungen sind einfache Off-the-shelf-Server, die nach Bedarf hinzugefügt und entfernt werden. Diese Server verfügen über keine Spezialhardware zur Erhöhung der Robustheit wie z. B. redundante Netzteile oder RAID-Controller. Die verwendete Hardware in diesen Servern entspricht in etwa der Hardware, die man in den Desktops beim Discounter um die Ecke findet. Auch auf Betriebssystemebene wird in der Regel auf Speziallösungen zur Erhöhung der Robustheit wie z. B. spezielle HA-Lösungen verzichtet. Stattdessen werden typischerweise einfache Linux- oder Windows-Betriebssysteme ohne spezielle Erweiterungen eingesetzt. Durch den gezielten Verzicht auf spezielle, teure Spezialhardware und -software zur Erhöhung der Robustheit sind diese Server außerordentlich günstig in der Anschaffung.

Der Preis, den man dafür zahlt, ist ein erhöhtes Ausfallrisiko auf Hardwareebene gepaart mit dem Verlust von betriebssystemnahen Mechanismen zur Kompensation von Systemausfällen. Das Risiko, ungewollt einen Knoten zu „verlieren“, ist deutlich höher als bei klassischer Rechenzentrumshardware.

Außerdem hat man ein anderes Skalierungsprinzip. In klassischen Rechenzentrumsanwendungen werden Anwendungen meistens skaliert, indem man zusätzliche Hardware in die Server einbaut, auf denen die Anwendung läuft. Dieses Prinzip, einzelne Server aufzurüsten, nennt man „Scale-up“. Cloud-Lösungen werden anders skaliert. Statt einzelne Server zu skalieren, wenn man mehr Rechenleistung benötigt, wird ein zusätzlicher Knoten „neben“ die vorhandenen Anwendungsknoten gestellt. Dieses Prinzip, über Hinzunahme weiterer Anwendungsknoten zu skalieren, nennt man „Scale-out“.

Es wird ein Stück Individualisierbarkeit der Lösung auf Hardware- und Betriebssystemebene abgegeben. Dafür erhält man auf Basis der hohen Standardisierung deutlich vereinfachte Bereitstellungsprozesse, die sich zusätzlich fast vollständig automatisieren lassen. Das führt zu deutlich reduzierten Bereitstellungs- und Betriebskosten pro (Rechen-)Leistungseinheit. Außerdem steigen die Kosten pro Leistungseinheit bei Scale-up-Lösungen nicht linear. Die Kosten steigen in höheren Ausbaustufen deutlich überproportional, sodass schon die Anschaffungskosten pro Leistungseinheit für hohe Skalierungen bei Scale-up-Lösungen meist weit über denen von Scale-out-Lösungen liegen.

Man zahlt für Scale-out den Preis, dass man es mit echten verteilten Anwendungen zu tun hat. Man kan...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang