Rechnerressourcen sind das Rückgrat der Informatik in den Unternehmen. Doch die Vielfalt an Möglichkeiten, Netze, Server, Speichersysteme, Anwendungen oder Dienste zu beziehen, sie zu managen und für die konkreten Bedürfnisse im Unternehmen optimal zu nutzen, stellt die Verantwortlichen vor grosse Herausforderungen. Denn die Auswahl an Bezugsmodellen für die IT-Infrastruktur ist gross: dediziert oder shared, als Hosted Services oder aus der Cloud. Welches Modell passt für welchen Anwendungsfall?
Beim Dedicated Hosting erhält der Kunde einen ihm zugeordneten Service vom Provider. Dieser Service kann standardisiert oder auch individuell massgeschneidert für den Kunden gestaltet sein. Sein Bezug ist in der Regel mit einer vorab definierten Laufzeit und dementsprechend fixen Kosten verbunden. Dem gegenüber steht das Delivery-Modell von Infrastrukturleistungen aus der Cloud, die Infrastructures as a Service (IaaS). Diese Form der Beschaffung kennt keine Laufzeiten und fixen Kosten mehr. Die Anwender klicken sich ihre Service-Pakete auf den verschiedenen Anbieterportalen selbst zusammen und rechnen nur die Services ab, die sie auch in Anspruch genommen haben. Doch auch in der IT ist die Welt nicht einfach nur schwarz oder weiss: Je nach Mass der Involvierung des Infrastruktur-Dienstleisters beispielsweise gibt es zahlreiche Abstufungen in den Bezugsmodellen.
So unterscheidet man bei der Fertigungstiefe von Dedicated Hosting zwischen managed und unmanaged. Beim Dedicated Managed Hosting geht die Verantwortung für den Betrieb der Services auf den Provider über. Kunde und Provider handeln Service Level Agreements (SLAs) aus, in denen Performance, Verfügbarkeit oder Support-Leistungen definiert werden. Unmanaged Dedicated Hosting Services sind hingegen Roh-Services, die in der Eigenverantwortung des Kunden liegen. Dazu gehört etwa der Bezug eines Root-Servers mit uneingeschränkten Zugriffsrechten. Der Kunde ist für die Verwaltung des Betriebssystems und den Betrieb der Applikationen selbst zuständig.
Sicher, aber träge und teuer
Die Vorteile des herkömmlichen Bezugsmodells «Dedicated Hosting von Rechnerressourcen» liegen in der Zuverlässigkeit und Sicherheit. Die dedizierte IT-Umgebung gehört nur einem Kunden, die Ausfallsicherheit ist dank der professionellen Leistungserbringung hoch und die Daten liegen geschützt an einem eindeutig zugewiesenen Ort. Was auf der einen Seite Zuverlässigkeit und Individualität gewährleistet, schlägt sich auf der anderen in einer relativen Trägheit und in hohen Kosten nieder. Kein Kunde kann zum Bestellzeitpunkt die benötigten Kapazitäten punktgenau abschätzen und kein Business läuft so vorhersagbar und stabil, dass es nicht Irritationen in der Nutzung und Peaks in der Auslastung gäbe. Hinzu kommt, dass die Leistungsverträge mit dem Provider oftmals kein Downgrade zulassen, sondern nur das Hinzubuchen von Leistungen. Werden die dedizierten IT-Umgebungen auf die maximal zu erwartende Auslastung ausgelegt, sind sie in der Regel für das normale Daily Business, – das erfahrungsgemäss mehr als 95 Prozent der Zeit ausmacht – völlig überdimensioniert und damit auch zu teuer. Ein Dedicated Hosting in dieser klassischen Form empfiehlt sich somit für Anwendungsfälle, bei denen regulatorische Anforderungen oder Vorschriften kein anderes Modell erlauben, wenn zum Beispiel aus Compliance-Gründen keine Shared Services und keine Virtualisierung gestattet sind. Des weiteren empfiehlt sich ein Einsatz, wenn aus Kundensicht eine gegenseitige Beeinflussung von verschiedenen Services ausgeschlossen werden muss.
Es ist nicht alles Cloud, was wolkig klingt
Dem dedizierten Modell steht das Shared Hosting gegenüber, das in seiner aktuell modernsten Form Infrastructure as a Service (IaaS) entspricht. Shared Hosting bedeutet in seiner traditionellsten Form, dass sich unterschiedliche Kunden die Rechnerressourcen teilen. Somit werden auch die Kosten für die Service-Kette auf die Teilnehmer aufgeteilt. Shared Hosting in der Form, dass ein Service auf einem physikalischen Rechner für mehrere Kunden bereitgestellt wird, der Service also logisch von Kunde zu Kunde getrennt (Instanzierung) ist, ist für private, semiprofessionelle oder auch einfache professionelle Web-Applikationen sicher die kostengünstigste Variante. Allerdings sind die Standardpakete in vielen Parametern, was etwa Speicherressourcen, garantierte Performance, Traffic oder verfügbare Features betrifft, erheblich eingeschränkt.
Skalierbarkeit im Sinne einer besseren Auslastung bieten Plattformen, bei denen auf einer leistungsstarken Rechnerumgebung respektive in einem Rechnerverbund mehrere Systeme virtualisiert parallel nebeneinander laufen. Beim Shared Virtual Hosting handelt es sich somit um eine multimandantenfähige Infrastruktur mit einer Virtualisierungsschicht. Diese Virtualisierungsschicht ist unmanaged, wenn nur die virtuelle Umgebung bereitgestellt wird und der Kunde sein Betriebssystem und seine Services selbst betreibt, oder managed, wenn der Provider dies übernimmt.
Eine Frage der Cloud-Definition
An dieser Stelle verwischen die technologischen und begrifflichen Grenzen in der Cloud-Computing-Diskussion. Denn Shared Virtual Hosting hat an sich noch nichts mit der Cloud zu tun. Für die Cloud-Computing-Puristen ist die Definition des National Institute of Standards & Technology bindend, die fünf essenzielle Kriterien für echte Cloud-Lösungen beschreibt, welche zwingend alle erfüllt sein müssen, damit auch wirklich von Cloud die Rede sein kann (siehe Kasten). In strikter Auslegung dieser Definition wird Shared Virtual Hosting – also eine multimandantenfähige Infrastruktur mit einer Virtualisierungsschicht – erst dann zur Cloud-Lösung, wenn die Systemumgebung mit einem Self-Service-Portal kombiniert wird. Auf diesem kann der Kunde selbst Ressourcenanpassungen vornehmen und sich etwa den Arbeitsspeicher, Storage und CPU eigenständig zuteilen. Zudem muss das Portal in der Lage sein, transparent die Systemlaufzeit, die genutzten Ressourcen wie Prozessor- oder Speicherleistung sowie die aufgelaufenen Kosten auszuweisen. Denn echte Cloud-Lösungen gehen mit Abrechnungsmodellen nach Nutzungsdauer einher, in denen keine monatlichen Festpreise für die Infrastrukturleistungen mehr gezahlt werden müssen. Dies gilt allerdings nicht für die Netzanbindung, die je nach gewähltem Zugang separat und in der Regel im Abonnement abgerechnet wird.
Reifezeugnis für den Selbstbedienungsladen
Infrastructure as a Service (IaaS) ist also streng genommen die Weiterentwicklung des Shared Virtual Unmanaged Service mit Self Service und nutzergerechter Abrechnung auf Basis verbrauchter, elastisch zugewiesener Ressourcen. Der Kunde greift auf ein reines Deployment und damit nur auf virtualisierte Hardware zu. Dort konfiguriert er seine virtuellen Systeme in Bezug auf die benötigte Rechenleistung und den Speicherausbau und kann zusätzlich Plattenplatz für die Speicherung der Daten in Anspruch nehmen. Dieses Modell eignet sich vor allem für Kunden, die einen hohen Maturitätsgrad im Umgang mit Entwicklungsprojekten aufweisen und ihre Budgets selbst steuern wollen.
Infrastructure as a Service ist ideal für befristete Projekte, insbesondere für Software-Entwicklung und Testumgebungen, wenn Systemleistung, Userzahl, Funktionsspektrum und Services im Projektverlauf flexibel skaliert werden müssen. In Abhängigkeit vom Projektstatus können jederzeit Prozessoren und entsprechender RAM hinzugebucht werden. Das Einrichten eines neuen Systems auf Basis eines bestehenden Templates dauert heutzutage auf einer Plattform nur noch wenige Minuten; das Starten und Stoppen der Systeme in der Regel weniger als eine Minute.
Ein weiteres Einsatzgebiet für dynamische Infrastrukturleistungen aus der Cloud ist jegliche Art von Saisongeschäft, wenn sich der Bedarf an IT-Infrastrukturressourcen durch ein erhöhtes Nutzeraufkommen zu bestimmten Zeiten ändert. Ideal ist IaaS auch für den Fall, dass ein neues Geschäftsmodell möglichst ohne starre Investitionen in die IT-Infrastruktur auf den Weg gebracht werden und die Time-to-market beschleunigt werden soll. Ebenfalls eignet sich IaaS, wenn ein Unternehmen aufgrund von Governance- oder Compliance-Richtlinien bestimmte Vorgaben, beispielsweise die Dokumentenkonvertierung in ein bestimmtes Format, sehr schnell und ohne lange Vorlaufzeiten für Bestell- oder Bereitstellungsprozesse umsetzen muss.
Allen Anwendungsfällen gemeinsam ist, dass der Kunde sich ein System zusammenbaut, welches sich genau an seine nicht funktionalen Anforderungen, wie zum Beispiel die Lastkurve, anpasst und somit keine unnötigen Kosten aufgrund ungenutzter Ressourcen verursacht. Allerdings muss der Kunde einem festgelegten Prozedere folgen und hat kaum Spielraum für individuelle Ansätze. Denn die darunterliegende Architektur, die Technologie, die Komponenten für Server, Storage sowie Netzwerkinfrastruktur und die Prozesse sind hochgradig standardisiert. Zudem muss er über ein gewisses Know-how verfügen, denn im Laufe des Bestellprozesses steht ihm kein Servicemanager oder Techniker zur Seite, mit dem er seine Bedürfnisse besprechen und eine passende Lösung designen könnte. Service Level Agreements, die ihm Performance, Verfügbarkeit oder Support garantieren, gibt es im Fall der Public Cloud oftmals so gut wie gar nicht, während Private-Cloud-Anbieter in der Regel High Performance und 99,5-prozentige Plattformverfügbarkeit sowie Supportleistungen gewährleisten.
Mit den inzwischen marktreifen Angeboten für IaaS befinden wir uns in einem tiefgreifenden Paradigmenwechsel: Es geht nicht in erster Linie um neue Technologien, sondern um neue Service- und Delivery-Modelle, die ein grundlegendes Umdenken in den IT-Abteilungen erfordern. Viele IT-Verantwortliche pflegen noch immer eine Art «Box»-Denken und ordern eine gewisse Anzahl Server mit festgelegten Leistungsparametern. Künftig werden sie sich auf ihren Bedarf konzentrieren müssen und nur noch die Services beziehen, die sie für die konkrete Anforderung benötigen. Ein Vergleich mag diesen Wandel illustrieren: In früheren Autos konnte jeder seine Zündkerzen selbst auswechseln. Heutzutage bringt man sein Auto zum Service und kümmert sich nicht mehr um die technischen Details unter der Motorhaube.
Steven Henzen ist Enterprise Architect bei T-Systems Schweiz.
Definition von Cloud-Lösungen
Die fünf Kriterien für Cloud-Lösungen (Definition gemäss dem National Institute of Standards and Technology NIST):
On Demand Self Service: Die Nutzer müssen die Möglichkeit haben, Ressourcen selbständig und nach eigenem Wunsch zu ordern.
Broad Network Access: Sie müssen Zugriff auf ein Netz haben, welches von verschiedenen Endgeräten aus den Zugriff auf die benötigten Ressourcen ermöglicht.
Resource Pooling: Die Ressourcen werden verknüpft, damit mehrere Kunden gleichzeitig bedient werden können.
Rapid Elasticity: Es muss jederzeit möglich sein, diese Ressourcen automatisiert oder zumindest zeitnah entsprechend dem aktuellen Bedarf nach oben oder unten zu skalieren.
Measured Service: Die bezogenen Ressourcen respektive Services müssen quantitativ erfasst werden können, denn nur so ist der Cloud-Grundsatz «pay as you use» – also die Abrechnung nach tatsächlicher Nutzungsdauer – umsetzbar.
