Kostentransparenz als Entscheidungsgrundlage für Cloud Computing

Unternehmen sehen sich früher oder später mit der Herausforderung konfrontiert, dass bestehende On-Premises-Applikationen oder -Umgebungen entweder den Businessanforderungen nicht mehr genügen oder das Ende des Lifecycle erreicht ist und wieder neu investiert werden muss. Es besteht dann die Möglichkeit, die Applikation zu modernisieren, zu ersetzen – hierunter fällt auch ein Anbieterwechsel – oder als Ganzes zuerst in die Cloud zu verlagern, bevor sie zu einem späteren Zeitpunkt gegebenenfalls modernisiert wird. Letzteres wird auch unter dem Begriff «Lift and Shift» zusammengefasst und gehört zu den zurzeit am häufigsten diskutierten Ansätzen bei Cloud-Vorhaben.

Bei der Frage, ob eine Applikation in die Cloud verlagert werden soll, kann es helfen, Kostentransparenz zu schaffen. Diese bildet zusammen mit anderen Faktoren eine solide Entscheidungsgrundlage. Hierbei empfiehlt sich ein Vorgehen in vier Schritten: 1) Analyse des Ist-Zustandes, 2) Entwicklung von möglichen Cloud-Sourcing-Szenarien, 3) Berechnung der TCOs (Total Costs of Ownership) und 4) Vergleich und Handlungsempfehlung.

Bei der Analyse des Ist-Zustands müssen in einem ersten Schritt die Kennzahlen der On-Premises-Applikation analysiert werden. Diese dienen nicht nur dazu, die Anforderungen für die Cloud-Sourcing-Szenarien zu entwickeln, sondern auch festzustellen, was der Betrieb der On-Premises-Applikation insgesamt kostet. Zu den Kennzahlen, die ermittelt werden sollen, gehören unter anderem die Daten, die benötigten Speicher- und Rechenkapazitäten, aber auch die Anzahl der Nutzer und der benötigten Lizenzen. Diese Parameter lassen sich von traditionellen Monitoring-Tools relativ einfach ermitteln. Was Standard-Monitoring-Tools jedoch häufig nicht zu messen vermögen und was in einem traditionellen Rechenzentrumsbetrieb oft auch keine Anforderung darstellt, sind die Abhängigkeiten der Applikation mit anderen Systemen. Wichtige Faktoren hierbei sind etwa die Bandbreiten oder die Anzahl (paralleler) Zugriffe auf die Applikation.

Abhängigkeiten zum Business klären

Hat man die Abhängigkeit der Applikation zu den anderen Systemen geklärt, gilt es, die Abhängigkeit zum Business zu betrachten. Sprich: Welche und wie viele Businessprozesse hängen mit der Applikation zusammen? Wie ist demzufolge der Stellenwert der Applikation einzuschätzen? Aus der Beantwortung dieser und ähnlicher Fragen lassen sich wiede­rum Anforderungen ableiten, etwa hinsichtlich der Ausfallsicherheit der Applikation. Wertvolle Hinweise auf die Abhängigkeiten einer Applikation mit anderen Systemen und dem Business kann das Application Performance Monitoring (APM) liefern, das schon länger zum Standard gehört. Das APM stellt detaillierte Performance-Metriken der Applikation zur Verfügung, die bei einem Cloud-Transition-Projekt im Hinblick auf die Bewertung sehr hilfreich sein können.

Nach der Analyse der Ist-Situation gilt es, auf der Basis der ermittelten Kennzahlen verschiedene Szenarien für die Auslagerung der Applikation in die Cloud zu entwickeln. Hierbei müssen Fragen geklärt werden wie: Soll nur ein IaaS-Service verwendet oder sollen IaaS- und PaaS-Services kombiniert werden? Sollen Services von nur einem Provider oder von mehreren Anbietern berücksichtigt werden?

Bei der Entwicklung von Cloud-Sourcing-Szenarien müssen ausserdem die Anforderungen an den Cloud-Service-Provider und die technische Lösung definiert und gewichtet werden. Auch was den Datenschutz sowie die Datensicherheit angeht, gilt es, die entsprechenden Anforderungen festzuhalten. Wurden mögliche Sourcing-Szenarien zusammengestellt, werden zwei bis drei ausgewählt, die dem eingangs festgelegten Ziel am ehesten entsprechen.

Capital und Operational Expenses unterscheiden

In einem nächsten Schritt berechnet man die TCOs (Total Costs of Ownership) der On-Premises-Applikation sowie der verschiedenen Cloud-Sourcing-Szenarien. Ein TCO gibt an, was eine Investition tatsächlich kostet, das heisst, er berücksichtigt idealerweise sämtliche Kosten, die über den kompletten Lebenszyklus einer Applikation hinweg entstehen. Geht man vom Szenario aus, die Applikation weiter on-premises zu betreiben und zu modernisieren, fallen vor allem sogenannte Capital Expenses an, also Investitionen in Hard- oder Software. Diese sind zu Beginn immer «überdimensioniert», da sie ein Wachstum mitberücksichtigen – sei dies x-mal mehr User pro Jahr, x-mal mehr Datenvolumen pro Jahr, x-mal mehr Kunden pro Jahr. Braucht man beispielsweise heute 500 TB Speicher pro Jahr und rechnet ein Wachstum von 30 TB jährlich hinzu, benötigt man auf fünf Jahre gerechnet insgesamt 650 TB. Die Hardware, die neu dazugekauft wird, muss diese Annahme bereits berücksichtigen.

Zu den Kosten, die durch die Anschaffung von Hardware entstehen, kommen Kosten für die Pflege, die Wartung und den Betrieb der Hardware. Bei Letzterem gehen oft Ausgaben für Strom und Kühlung vergessen, obwohl diese einen nicht unerheblichen Bestandteil ausmachen. Zu guter Letzt fallen beim Weiterbetrieb der Applikation on-premises Lizenzkosten an. Meistens hat man es hier mit Lizenzmodellen inklusive Support zu tun, die über Jahre ausgerichtet sind.

Bei der Berechnung der TCOs der Cloud-Sourcing-Szenarien werden die Capital Expenses weitgehend ersetzt durch Operational Expenses: Da Hard- und Software als Dienstleistung bei einem Anbieter eingekauft werden, wird diese Kostenkategorie durch eine neue ersetzt, und zwar diejenige der fortlaufenden Kosten für die Beanspruchung der Cloud-Dienste. Hier ist vor allem das Verhalten der Applikation von Relevanz. Weiss man zum Beispiel, dass eine Applikation während zweier Monate im Jahr Volllast zu tragen hat und sonst mehr oder weniger inaktiv ist, kann man dies bei der Ermittlung des TCOs berücksichtigen und somit dedizierter auf das Business eingehen.

Lizenzkosten nicht unterschätzen

Ein wichtiger Kostenfaktor bei Cloud-Sourcing-Szenarien sind die Lizenzen. Dies gilt vor allem bei IaaS-Szenarien, bei denen es dem Kunden obliegt, die genutzten Applikationen zu lizenzieren (man spricht in diesem Kontext auch von BYOL – Bring your own License). Hier muss genau hingeschaut werden, denn je nach angebotenem Lizenzmodell können die Kosten schnell stark von einem klassischen On-Premises-Deployment abweichen, so etwa, wenn sich Lizenzmodelle nicht auf Nutzer, sondern auf Cores (CPUs) beziehen. Je nach Cloud-Szenario und Anforderung kann es sein, dass man bei einem zum On-Premises äquivalentem Set-up im IaaS-Umfeld unter Umständen mehr unterliegende CPUs verwendet – was in einen Anstieg der Lizenzkosten resultiert. Ein klassisches Beispiel: On-Premises wird eine Applikation auf 10 CPUs betrieben und lizenziert. Im Sourcing-Szenario können aber nur 8 oder 16 CPUs gewählt werden. Somit müssen 6 CPU-Lizenzen mehr eingerechnet werden. Dies kann einen grossen Impact auf die Kosten haben.

Hat man die TCOs der On-Premises-Lösung und der verschiedenen Cloud-Sourcing-Szenarien berechnet, kann man diese miteinander vergleichen. Zusammen mit den Vor- und Nachteilen, die sich in funktionaler Hinsicht bei einer Verlagerung der Applikation in die Cloud ergeben, ist die Aufstellung der Kosten eine wertvolle Entscheidungsbasis. Es ist nämlich nicht zwingend so, dass die Verlagerung in die Cloud günstiger kommt als der Weiterbetrieb on-premises. Gerade aufgrund des Umstandes, dass Lizenzkosten häufig falsch eingeschätzt werden, können sich Cloud-Transitionen als sehr kostspielige Varianten entpuppen. Es lohnt sich in jedem Fall, einen kompetenten Partner beizuziehen, der einen auf die Fallstricke auf dem Weg in die Cloud hinweisen kann.