Das Citrix C3 Lab der Amazon Web Services als SBC Lösung für kleine und mittelständische Unternehmen unter Berücksichtigung wirtschaftlicher Aspekte

Aus Winfwiki

Name des Autors / der Autoren:	Jörn Rusch
Titel der Arbeit:	Das Citrix C3 Lab der Amazon Web Services als SBC Lösung für kleine und mittelständische Unternehmen unter Berücksichtigung wirtschaftlicher Aspekte
Hochschule und Studienort:	FOM Duisburg

Inhaltsverzeichnis 1 Einleitung 2 Grundlagen 2.1 Server Based Computing 2.2 Cloud Computing 2.3 Amazon AWS 2.4 Citrix C3 3 Soll-Konzept 3.1 Methodik 3.2 Betrachtungsumgebung 3.2.1 Anzahl Benutzer 3.2.2 Anzahl Server 3.2.3 Infrastruktur und Lizenzen 3.2.4 Datenvolumen und Verwendungsdauer 3.2.5 Zusammenfassung 4 Berechnungen 4.1 Amazon EC2 4.2 Co-Location 4.3 On-Site 5 Ergebnisanalyse 5.1 Monetäre Aspekte 5.2 Nicht-Monetäre Aspekte 6 Fazit 7 Abkürzungsverzeichnis 8 Abbildungsverzeichnis 9 Tabellenverzeichnis 10 Fußnoten 11 Literaturverzeichnis

1 Einleitung

"Over the next three years, CIOs will have an "a-ha moment" as the gap between the web and enterprise computing will no longer be defensible. We are at the epicenter of this IT revolution" - Mark Templeton, CEO Citrix Systems, Inc.

Aktuelle Presseankündigungen des Beratungsunternehmens Gartner besagen, dass bis 2012 ca. 50% aller Dienste und IT-Services (Workloads) mittels virtueller Maschinen bereitgestellt werden. Dies entspricht einer Anzahl von 58 Millionen virtueller Server und Desktops. Bereits im Mai 2007 kündigte Gartner für das Jahr 2015 die Ausweitung von Virtualisierungs-Aspekten, auf fast jeden relevanten Bereich der IT an^[1]. Unternehmen wie Citrix und VMware tragen mit der kontinuierlichen Weiterentwicklung ihrer Technologien in den Bereichen der Virtualisierung und Konsolidierung maßgeblich dazu bei. Ein weiterer entscheidender Aspekt ist die zunehmende Verbreitung und Akzeptanz von Cloud Computing Services, die als Plattform für SaaS (Software as a Service), IaaS (Infrastructure as a Service) oder DaaS (Desktop as a Service) Programme dienen. Immer mehr Anwendungen überschreiten die Grenzen des Unternehmens-Rechenzentrums und werden in Form von SaaS-Applikationen über das Internet bereitgestellt. Ein populäres Beispiel dafür, sind die von dem Unternehmen Salesforce.com^[2] bereitgestellten CRM (Customer Relationship Management), ERP (Enterprise Ressource Planning) und SCM (Supply Chain Management) Applikationen. Salesforce hat weltweit über 67000 Kunden mit insgesamt 1,5 Millionen Nutzern^[3]. Zu den führenden Betreibern und Entwicklern von Cloud Computing Plattformen (Cloud Provider) gehören die Unternehmen Microsoft (Microsoft Azure), Google (Google App Engine) und Amazon (Amazon Web Services). Wie lassen sich solche Dienste für Unternehmen vorteilhaft nutzen? Diese Arbeit betrachtet einen Ausschnitt der auf dem Markt verfügbaren Cloud Computing Dienste hinsichtlich der Anwendbarkeit und Wirtschaftlichkeit für kleine und mittelständische Unternehmen am Beispiel der Amazon Web Services.

2 Grundlagen

2.1 Server Based Computing

Das Konzept des SBC (Server Based Computing) ist nicht neu und geht aus dem Ansatz der Großrechner und Mainframes hervor. Anfang der 1960er Jahre wurden Ressourcen wie Rechenleistung und Speicher zentral mittels weniger Großrechner bereitgestellt. Die Eingabe der Befehle und Daten erfolgte zunächst mit Lochkarten und später über seriell angeschlossene Terminals, die damit eine direkte Verbindung zum Großrechnersystem besaßen (Sterntopologie). Die verwendeten Terminals^[4] verfügten über keine eigene Rechenleistung und waren lediglich für die Eingabe sowie die Anzeige der Rückgaben vom Großrechner zuständig. Diese Architektur war weitaus günstiger, als für jeden Anwender einen eigenen Computer bereitzustellen. Die Mainframe-Systeme waren in ihrer Hard- und Software-Architektur so aufgebaut, dass ein Multi-User- als auch Multi-Tasking Betrieb möglich war. Unter Verwendung des Timesharing-Verfahrens, erfolgte die zeitweise Zuteilung von Rechenleistung an die einzelnen Benutzersitzungen. Somit hatte jeder Benutzer den Eindruck, als stünde die gesamte Rechenleistung ihm allein zur Verfügung. Die Markteinführung des IBM PCs (Personal Computer) im August 1981 machte das Konzept dezentraler Rechenleistung bezahlbar. Dies führte dazu, dass in vielen Bereichen eine Umorientierung vom Mainframe zum PC erfolgt. Die damit einhergehenden Vorteile brachten jedoch gleichzeitig Nachteile, hauptsächlich in Form eines erhöhten TCO (Total Cost of Ownership) mit sich. Dieser resultiert vor allem aus den Kosten hinsichtlich der Administration, des Managements und der Wartung der PCs^[5]. Aus diesem Grund wurde das SBC-Konzept als zentrale Plattform zur Datenverarbeitung wieder aufgegriffen. "Sämtliche Anwendungskomponenten laufen dabei ausschließlich auf dem Server ab. Der Zugriff darauf erfolgt über ein Netzwerk und Clients, die nur über Basisfunktionalität verfügen und möglichst einfach zu verwalten sind."^[6] Zunächst stellten zentrale UNIX-Systeme den über Ethernet und TCP/IP (Transmission Control Protocol/Internet Protocol) angebundenen Clients eine grafische Oberfläche^[7] zur Datenverarbeitung zur Verfügung. Die in diesem Zusammenhang häufig verwendeten (Thin) Clients verfügen weder über eigene Rechenleistung, noch eine Festplatte. Ähnlich der Clients beim Mainframe-Konzept, dienen diese der Verbindung zum Server, der Benutzereingabe sowie der Anzeige der Serverrückgaben^[8]. Mit der Veröffentlichung des Microsoft Windows Terminalservers erfuhr SBC eine weite Verbreitung auf dem Markt. Anwendern war es nun möglich, mittels einer bereits vom PC bekannten Windows GUI (ähnlich Microsoft Windows NT) Applikationen auf dem Terminalserver auszuführen. Dabei wurden Standard-Applikationen wie bspw. Textverarbeitung, Tabellenkalkulation, E-Mail- und ERP-Programme sowie ganzen Benutzer-Desktops (Windows Desktops) bereitgestellt. Ergänzend zu den Microsoft Windows Terminal Services stellt das Unternehmen Citrix mit der Produktreihe "XenApp", derzeit in der Version 5 verfügbar, weitere, unternehmenskritische Funktionalitäten bereit und ist damit Marktführer im Bereich der Applikations-Bereitstellung bzw. Anwendungs-Virtualisierung^[9].

2.2 Cloud Computing

In der Literatur und im Internet finden sich unzählige Definitionen für den Begriff Cloud Computing, der einen großen Schritt in der Evolution der Informationstechnologie beschreibt. Allgemein lässt sich Cloud Computing als eine konsequent Service-orientierte Weiterentwicklung des Grid und Utility Computing beschreiben. Spezifischer wird Cloud Computing wie folgt definiert: "Unter Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner Web-Technologien stellt Cloud Computing skalierbare, netzwerk-zentrierte, abstrahierte IT-Infrastrukturen, Plattformen und Anwendungen als on-demand Dienste zur Verfügung. Die Abrechnung dieser Dienste erfolgt nutzungsabhängig."^[11] Die Basis des Cloud Computing wird durch (Server-)Virtualisierungs-Technologien geschaffen, die die Hardwareressourcen abstrahieren und aggregieren, sowie diese beliebig skalierbar machen. Dadurch lässt sich die verfügbare Rechenleistung flexibel unterteilen und den Nutzern der Cloud in einer wunschgemäßen Ansicht präsentieren^[12]. Dieser kann wiederum individuell und anhand der aktuellen Bedürfnisse den Umfang der genutzten Dienste steuern und dynamisch abrufen. Ebenso flexibel werden die bezogenen Dienste abgerechnet. In der Regel erfolgt keine vertragliche Bindung an den Cloud Provider, der die Nutzung anhand der Dauer, des übertragenen oder des gespeicherten Datenvolumens abrechnet. Da die Services eines Cloud Providers häufig auf sehr umfangreichen Hardware-Ressourcen (Rechenleistung, Massenspeicher) basieren und ein hohes Maß an Standardisierung aufweisen, kann dieser Economy of Scale nutzen und zu sehr günstige Preis/Leistungsverhältnissen anbieten^[13]. Fundamentale Voraussetzung für die vorteilhafte Ausnutzung dieser Skaleneffekte des Cloud Computing sind SOA (Service-orientierte Architekturen) und Web Services^[14]. Komponenten innerhalb einer SOA sind als unabhängige Dienste realisiert und können ebenso wie Anwender auf die Dienste und Applikationen anderer Komponenten zugreifen bzw. diese verwenden. Dadurch lassen sich verschiedene Dienste dynamische zu einem Prozess zusammenfassen und als neue Applikation, die wiederum als Dienst bereitgestellt werden kann, nutzen (siehe Abbildung 2). In öffentlichen Cloud Umgebungen werden die Dienste häufig über das Internet unter Verwendung standardisierter Web Services als Kommunikationsbasis angeboten^[15]. "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstelle als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Softwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden."^[16] Diesen Technologien und Architekturen zugrundeliegend ist es daher möglich, wie bereits angesprochen, Cloud Dienste über das Internet anzubieten und zu nutzen. Daraus ergeben sich die folgenden Cloud Architekturen:

Public Cloud

Im Fall einer Public Cloud sind Anbieter und Nutzer nicht Teil derselben Organisation. Die Dienste der Cloud sind öffentlich über das Internet zugänglich und ermöglichen dem Nutzer die Art und den Umfang der Verwendung selbst zu gestalten^[17].

Private Cloud

Im Gegensatz zur Public Cloud sind bei einer Private Cloud Anbieter und Nutzer Teil derselben Organisation. Häufig sprechen Sicherheitsaspekte für den Einsatz einer privaten Cloud, da so sensible Daten innerhalb des Unternehmens bleiben und kein Zugriff von außen möglich ist. Services und Prozesse werden jedoch auf die gleiche Weise wie bei einer Public Cloud realisiert, um Applikationen nahtlos zwischen der privaten und der öffentlichen Cloud transferieren zu können^[18].

Hybrid Cloud

Die Hybrid Cloud vereint die Eigenschaften der Public und der Private Cloud. Die Anwender sind somit Teil der anbietenden Organisation, als auch externe dritte. Beispielhaft für ein solches Einsatzscenario ist die Auslagerung von Lastspitzen in die Public Cloud, wohingegen der Regelbetrieb mit den normalen Ressourcen erfolgt^[19].

Die somit über das Web angebotenen Cloud Services, lassen sich anhand ihrer Art und Beschaffenheit (Infrastruktur, Plattform, Software) in Kategorien einordnen und klassifizieren. Diese Kategorien folgen dabei dem everything-as-a-service-Paradigma (XaaS) und setzen sich zu IaaS (Infrastructure as a Service), PaaS (Platform as a Service) und SaaS (Software as a Server) zusammen^[20]. Dabei lassen sich beliebig weitere Kategorien bilden, je nach dem, was der jeweilige Service abbildet, bspw. DaaS (Desktop as a Service) oder VaaS (VoIP as a Service).

IaaS

Im Rahmen eines IaaS Dienstes werden dem Anwender verschiedene Komponenten einer IT-Infrastruktur (Rechenleistung, Massenspeicher, Netzwerke etc.) weitestgehend beliebig skalierbar und konfigurierbar bereitgestellt. Benutzern einer solchen Infrastruktur-Lösung ist es damit möglich, eigene IT-Services zu implementieren und innerhalb des Unternehmens zu nutzen oder an dritte anzubieten. Beispiele für IaaS-Provider: Amazon Web Services^[21], GoGrid^[22], Joyent^[23]

PaaS

Eine als Service angebotene Plattform setzt meist auf ein IaaS Angebot auf und dient Entwicklern als PE (Programming Environment) oder EE (Execution Environment), d.h. Entwichlung oder Ausführung von Software in verschiedenen Programmiersprachen und Umgebungen. Die unterstützten Programmiersprachen sind häufig vorgegeben, begrenzt und unterscheiden sich von Anbieter zu Anbieter^[24]. Beispiele für PaaS-Provider: Facebook^[25], Google App Engine^[26], Microsoft Azure^[27]

SaaS

Ein SaaS Angebot bedient sich der durch IaaS und PaaS bereitgestellten Ressourcen und Umgebungen, um selbst eine Anwendung als Service zu offerieren. Der BITKOM (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.) definiert SaaS als "ein Geschäftsmodell für zentrale Bereitstellung und Ausführung von vor konfigurierten, serverbasierten Softwarelösungen und den damit verbundenen Dienstleistungen für eine Vielzahl von Kunden über öffentliche oder private Netze".^[28]. Beispiele für SaaS-Provider: Google Text & Tabellen^[29], Microsoft Office Live^[30], Salesforce^[31]

2.3 Amazon AWS

Das Unternehmen Amazon.com wurde 1994 von Jeff Bezos gegründet und ist heute Marktführer im Bereich des Internethandels. Das Online-Versandhaus mit Sitz in Seattle ermöglicht es Kunden weltweit über das Internet aus diversen Kategorien Artikel zu bestellen sowie eigene anzubieten und zu verkaufen. Zu Spitzenzeiten werden über die Amazon Webseiten bis zu 110 Produkte pro Sekunde verkauft, abgerechnet und an die Käufer versendet^[32]. Um ein solches Transaktions- und Datenaufkommen bewältigen zu können, betreibt Amazon eine mehrere Millionen Dollar teure, dezentrale Cloud Computing Infrastruktur, welche die Käufe und Verkäufe abwickelt^[33]. Da der überwiegende Teil dieser Infrastruktur nur zu saisonalen Ereignissen wie Thanksgiving oder in der Weihnachtszeit ausgelastet wird und im weiteren Verlauf des Jahres meist brach liegt, ist die Geschäftsidee der AWS (Amazon Web Services) entstanden. Im Rahmen der AWS stellt das Unternehmen externen Kunden einen Teil seiner freien Ressourcen in Form von IaaS gegen Entgelt zur Verfügung^[34]. Zu den angebotenen Diensten gehören u.a.:

Amazon EC2

Die Amazon Elastic Compute Cloud ist ein Web Service, welcher Rechenleistung in Form verschiedener Instanz-Typen (Standard, High-Memory, High-CPU etc.) und Betriebssysteme (Red Hat Enterprise Linux, Oracle Enterprise Linux, Windows Server etc.) bereitstellt. Mit Hilfe der vorkonfigurierten AMIs (Amazon Machine Images) ist es möglich, innerhalb von wenigen Minuten mehrere Server in der AWS Cloud zu erstellen^[35].

Amazon S3

Der für eine IT-Infrastruktur benötigte Speicherplatz wird in Form des Amazon Simple Storage Service angeboten. Der Simple Storage Service ermöglicht die Speicherung und Bereitstellung unendlich vieler, bis zu je 5 GB großer Objekte. Authentifizierungsmechanismen sowie die Attribute "public" und "private" lassen sich für jedes Objekt konfigurieren, um Zugriffsrechte zu wahren^[36].

Amazon VPC

Die Amazon Virtual Private Cloud lässt sich sicher via IPsec VPN (Virtual Private Network) Verbindungen in die unternehmenseigene IT-Infrastruktur integrieren. Die VPC ist dabei ein vollkommen isolierter Teil der Amazon Web Services (private Cloud) und bietet weitere Sicherheitsmechanismen, wie bspw. Firewalls und Intrusion Detection Systeme. Derzeit lässt sich die VPC nur mit der über die Amazon EC2 bereitgestellte Rechenleistung kombinieren^[37].

Amazon RDS

Vielfach setzen Services innerhalb einer IT-Infrastruktur Datenbanken zur Speicherung und Verwaltung großer Datenmengen voraus. Hierzu bietet Amazon den Relational Database Service, der es ermöglicht, SQL Datenbanken innerhalb der Cloud zu nutzen. Der Relational Database Service setzt dabei auf MySQL auf und bietet neben den Funktionen eines DBMS (Datenbank Management System) automatische Backups, Datenbank-Snapshots und ein Ressourcen Monitoring Amazon CloudWatch^[38].

Amazon SQS

Der Amazon Simple Queue Service ist ein hochverfügbarer und skalierbarer Dienst zum sicheren und gezielten Datenaustausch zwischen verteilten Komponenten. Durch den SQS lassen sich Workflows zwischen den verschiedenen Infrastruktur-Komponenten (einer SOA) der AWS, aber auch außerhalb der Cloud, automatisieren. Eine durch den SQS versendete "Message" enthält bis zu 8 KB textorientierter Daten, bspw. in XML-Form (Extended Markup Language)^[39].

Neben diesen vorgestellten Diensten stellt Amazon eine Reihe weiterer Funktionalitäten bereit, die die angebotene Infrastruktur vervollständigen und eine Vielzahl von Anwendungsmöglichkeiten abdecken. Dabei folgt Amazon immer den folgenden Prinzipien und Strategien^[40]:

• Flexible (Flexibilität hinsichtlich Entwicklungssprache, Betriebssystem, Datenbank etc.)
• Cost-effective (Kosteneffizienz bei der Bezahlung und der Vertragsgestaltung)
• Scalable and elastic (Skalierbarkeit und Elastizität bei der bedarfsgerechten Bereitstellung von Rechenleistung und Speicher)
• Secure (Alle angebotenen Dienste sind nach Security Best Practices konzipiert und weisen unternehmenskritische Sicherheitsfunktionalitäten auf)
• Experienced (Amazon weißt 15 Jahre Erfahrung im Betrieb und Management einer derart großen und globalen Infrastruktur auf)

Auf Basis dieser Strategie greifen immer mehr Unternehmen, im Rahmen des AWS Solution Provider Programs die angebotenen Services auf, und entwickeln maßgeschneiderte Lösungen mit und für die Cloud. Zu diesen Unternehmen zählen u.a. IBM, Oracle, Sybase, Salesforce, Facebook und Citrix. Salesforce und Facebook nutzen die Ressourcen der Amazon Web Services zur Bereitstellung von Entwicklungsumgebungen für SaaS-Applikationen. IBM, Oracle, Sybase und Citrix bieten innerhalb der Cloud für ihre Produkte angepasste und bereits vorinstallierte AMIs. Entwicklungs-, Test- und Disaster-Recovery-Umgebungen sind somit schnell und flexibel verfügbar^[41].

2.4 Citrix C3

Das Unternehmen Citrix Systems, Inc. wurde 1989 ursprünglich als Citrus Systems, Inc. von Edward Iacobucci in Richardson, Texas gegründet. Der Name Citrix folgte kurze Zeit später und setzt sich aus Citrus und UNIX zusammen^[42]. Citrix verfolgt mit seiner Strategie der Zentralisierung, Optimierung und Virtualisierung die Vision einer vereinfachten Bereitstellung von Anwendungen und Desktops, sodass die Arbeit für jeden von überall aus möglich wird^[43]. Realisiert wird dies durch das Produktportfolio, welches die folgenden Technologien abdeckt:

• Desktop-Virtualisierung (Citrix XenDesktop)
• Anwendungs-Virtualisierung (Citrix XenApp)
• Server-Virtualisierung (Citrix XenServer)

Das Wort "Xen" steht dabei als Synonym für Virtualisierung und setzt sich konsequent durch die Produkte von Citrix fort. Das Portfolio wird durch eine Reihe weiterer Produkte aus den Bereichen Networking (Citrix NetScaler), Cloud Computing (Citrix Cloud Center) und SaaS (GoToMeeting, GoToWebinar, GoView) sinnvoll ergänzt. Eine zentrale Komponente der Citrix Produkte zur Bereitstellung von Applikationen und Desktops ist das ICA-Protokoll (Independent Computing Architecture). Mit Hilfe des ICA-Protokolls werden Bilder und multimediale Inhalte vom Terminalserver bzw. vom virtuellen Desktop zum Client transferiert. Dabei ist das Protokoll dank einer bandbreitenabhängigen Kompression sogar für Modem- und ISDN-Verbindungen geeignet. Die konsequente Weiterentwicklung des ICA-Protokolls und Bestandteil der Citrix Produkte zur Desktop- und Anwendungs-Virtualisierung ist die HDX Technologie (High-Definition User Experience). HDX wurde entwickelt, um Benutzern beim Zugriff auf multimediale Inhalte, wie bspw. Sprache, Video, 3D-Grafiken, mehr Komfort, Performance und Flexibilität bieten zu können^[44]. Die Kombination der verwendeten Technologien und Produkte vermarktet Citrix u.a. als Citrix Cloud Center (C3). Das Cloud Center umfasst neben den bereits angesprochenen Technologien das Citrix Workflow Studio (Scripting-Umgebung zur Automatisierung von Workflows) sowie den Citrix Repeater (WAN-Strecken Optimierung) und fasst diese zu einer Cloud Infrastruktur zusammen (siehe Abbildung 4). Die Architektur des Cloud Centers lässt sich den folgenden Funktionen zuordnen^[45]:

Platform

Der Citrix XenServer dient der Implementierung einer Virtualisierungs-Schicht (Hypervisor) und ist somit die Grundlage des Cloud Centers. Die Infrastruktur der Amazon Web Services und der XenServer basieren beide auf dem Open Source Hypervisor "Xen".

Application and Desktop Services

Citrix XenDesktop und XenApp realisieren die Desktop- und Anwendungs-Virtualisierung. Dies ermöglicht im Rahmen eines Service-Provider Angebotes Microsoft Windows Desktops (DaaS, Desktop as a Service) und Windows Anwendungen (SaaS) als Dienst aus der Cloud bereitzustellen.

Delivery

Der Citrix NetScaler stellt Sicherheit und Performance der Services sicher, indem Zugriffe verteilt und die Ressourcen passgenau und permanent skaliert werden. Die durch die Cloud bezogene Rechenleistung wird so optimal ausgeglichen und effizient ausgenutzt. Dabei werden die Server innerhalb der Cloud durch den NetScaler u.a. hinsichtlich Protocol Offloading und Transaktionsverarbeitung entlastet.

Bridge

Bei der Verwendung externer Clouds als Infrastruktur für Service-Provider Dienste ist eine hochverfügbare und schnelle Anbindung an das eigene Rechenzentrum unternehmenskritisch. Der Citrix Repeater optimiert und beschleunigt Datentransfers zwischen der Cloud und dem Rechenzentrum durch Caching und De-Duplication einzelner Datenpakete.

Orchestration

Typische Workflows innerhalb der Cloud und das Management der jeweiligen Infrastruktur-Komponenten lassen sich durch das Citrix Worklow Studio automatisieren. Dabei greift das Workflow Studio u.a. auf die Microsoft PowerShell zurück. Die PowerShell ist eine objektorientierte Ergänzung zu den bisherigen Microsoft Scripting Umgebungen (cmd.exe)^[46].

Das Citrix Cloud Center wird im Rahmen einer Solution Provider Partnerschaft zwischen Citrix und Amazon als Dienst für die Amazon Web Services angeboten. Vorinstallierte und angepasste Amazon Machine Images für Citrix XenApp, Citrix Access Gateway und Citrix Repeater nutzen die Rechenleistung der Amazon EC2 und werden innerhalb der isolierten Umgebung der Amazon VPC gehostet. Dies ermöglicht die sichere Anbindung an die unternehmenseigene IT-Infrastruktur und die Integration der Citrix Ressourcen^[47]. Große Unternehmen können so flexibel und zeitnah auf steigende Anforderungen reagieren, wenn die Erweiterung der eigenen Citrix Farmen aus Performance Gründen erforderlich wird. Für kleine und mittle Unternehmen ist eine solche Lösung ebenfalls interessant, da keine Investitionen für die benötigte Infrastruktur anfallen und somit die Nutzung der Citrix Technologien innerhalb und außerhalb des Unternehmens möglich wird.

3 Soll-Konzept

Im Rahmen des Soll-Konzepts wird die Methodik der Vorgehensweise unter Berücksichtigung wirtschaftlicher Aspekte beschrieben, sowie eine Betrachtungsumgebung definiert. Anhand der beschriebenen Vorgehensweise werden verschiedene SBC-Konzepte bewertet und nachfolgend hinsichtlich ihrer Kosten verglichen. Das Soll-Konzept umschreibt welche Anforderungen im Rahmen einer SBC-Lösung für die Betrachtungsumgebung erfüllt werden sollen, welche Gegebenheiten das Design der Lösung beeinflussen, sowie welche Annahmen getroffen werden bzw. was sich als Vorausgesetzt betrachten lässt.

3.1 Methodik

Mit Hilfe des Amazon EC2 Cost Comparison Calculators^[48] wird die Basis für einen monetären Vergleich verschiedener Lösungen geschaffen. Der Amazon EC2 Cost Comparison Calculator basiert auf Microsoft Excel und berechnet anhand von Industriedaten, AWS Nachforschungen und durch den Anwender spezifizierte Parameter, jährliche Kosten für die folgenden IT-Infrastruktur Alternativen:

• Amazon EC2 (Infrastruktur auf Basis der Amazon Web Services Elastic Compute Cloud)
• Co-Location (Rechenzentrumsbetrieb, Managed IT-Services)
• On-Site (Eigenlösung am Unternehmensstandort)

Die Berechnung bezieht sich dabei auf die direkten Kosten, welche durch die Investition, den Betrieb und die Wartung der jeweiligen Infrastruktur entstehen. Vergleichsweise dazu zeigt das Tool die Kosten einer nach Nutzungsdauer und Datenvolumen abgerechneten AWS-Lösung auf. Um die Übersichtlichkeit der Berechnungen zu gewährleisten, werden lediglich die ausschlaggebendsten Faktoren für die Ermittlung der Kosten berücksichtigt (Server Hardware, Netzwerk Hardware, Wartung, Betriebssystem, Datentransfer etc.). Weitere Aspekte, wie bspw. Dienstleistung, Verkabelung, Mieten und Kapitalkosten bleiben unberücksichtigt^[49]. Für die Berechnung sind die folgenden, individuellen Parameter maßgeblich:

• Anzahl und Typ der EC2 Instanzen im Basisbetrieb (Baseline)
• Anzahl und Typ der EC2 Instanzen während Lastspitzen (Peak)
• Verwendungsdauer der EC2 Instanzen (Basisbetrieb und Lastspitzen)
• Übertragenes Datenvolumen (In, Out)

Innerhalb der im nächsten Abschnitt beschriebenen Betrachtungsumgebung, werden diese notwendigen Parameter ermittelt und festgelegt. Anschließend erfolgt die Berechnung sowie die Auswertung und Interpretation aus monetärer Sicht im Rahmen der Ergebnisanalyse. Des Weiteren erfolgt die Bewertung zusätzlicher Entscheidungskriterien, die nur schwer monetär quantifizierbar sind (Verfügbarkeit, Skalierbarkeit, Flexibilität, Sicherheit).

3.2 Betrachtungsumgebung

Damit die Berechnung mit Hilfe des Amazon EC2 Cost Comparison Calculators vergleichbare Ergebnisse zurückliefert, wird eine einheitliche Betrachtungsumgebung definiert. Zum Einen werden die notwendigen Eingabeparameter ermittelt, zum Anderen wird festgelegt, welche Voraussetzungen und Annahmen getroffen werden.

3.2.1 Anzahl Benutzer

Diese Arbeit bezieht sich auf die Verwendung der Amazon Web Services im Umfeld kleiner und mittelständischer (mittlerer) Unternehmen. Die EU (Europäische Union) definiert Kleinstunternehmen, kleine Unternehmen und mittlere Unternehmen wie folgt^[50]:

• Kleinstunternehmen < 10 Mitarbeiter
• Kleine Unternehmen < 50 Mitarbeiter
• Mittlere Unternehmen < 250 Mitarbeiter

Daher werden bei der Skalierung der SBC-Lösung drei Szenarien mit jeweils 10, 50 und 250 Benutzern berücksichtigt.

3.2.2 Anzahl Server

Für diese Benutzer werden zentral Applikationen und Desktops mittels Microsoft Windows Terminal Services und Citrix XenApp bereitgestellt. Das Betriebssystem der Server ist daher auf Microsoft Windows 2003/2008 sowie 32-bit Architektur festgelegt^[51]. Eine Citrix Studie über die Skalierbarkeit von Amazon EC2 Instanzen als Terminalserver mit Citrix XenApp ergab hinsichtlich Benutzeranzahl pro Server folgendes Ergebnis (siehe Abbildung 5). Im Rahmen der Studie wurden die verschiedenen Instanz Typen, unter Verwendung von Citrix EdgeSight, Lasttests unterzogen, um so auf die maximal mögliche Anzahl von Benutzer pro EC2 Instanz schließen zu können^[52].

Ausschlaggebend ist demnach nicht der verfügbare Arbeitsspeicher, sondern die verfügbare Rechenleistung des Systems. Der zu verwendende Instanz-Typ wird daher auf "High-CPU Medium" festgelegt. Pro 21 Benutzer ist daher 1 EC2 Instanz notwendig. Um einen kontinuierlichen Betrieb der Arbeitsumgebung zu gewährleisten, empfiehlt es sich, die SBC-Lösung redundant (min. 2 Systeme) aufzubauen. Bei Ausfall eines Systems können die Benutzer so nach erneuter Anmeldung auf dem redundanten System weiter arbeiten. Die Anzahl der Instanzen im Basisbetrieb (Baseline) muss demnach 100% der Benutzer (Workload) verarbeiten können. Im Lastbetrieb (Peak) wird ein Workload von 200% angenommen. Dementsprechend ist die SBC-Lösung zu skalieren. Für die drei Benutzer-Szenarien lässt sich somit die Anzahl der benötigten EC2 Instanzen berechnen:

Users	Baseline		Peak
	Anzahl	Workload	Anzahl	Workload
10	2	420%	0	420%
50	3	126%	2	210%
250	12	101%	12	202%

Tabelle 1: Anzahl der benötigten EC2 Instanzen

Amazon bietet das Hosting der EC2 Instanzen in verschiedenen Zonen bzw. Regionen an. Derzeit stehen die Regionen US-East (Northern Virginia), US-West (Northern California) und Europe (Ireland) zur Verfügung. Um Latenzzeiten zu minimieren, bietet sich die Wahl der Region Europe (Ireland) an. Bestimmte Services der AWS sind jedoch nicht in allen Regionen verfügbar, dazu gehört u.a. auch die Amazon VPC. Damit die Dienste der VPC dennoch genutzt werden können, fällt die Auswahl der Region auf US-East (Northern Virginia). Da das Citrix ICA-Protokoll für WAN-Verbindung mit teilweise hohen Latenzzeiten optimiert ist, beeinflusst diese Einschränkung nicht die Performance der SBC-Lösung.

3.2.3 Infrastruktur und Lizenzen

Die für eine derartige SBC-Lösung benötigten Serverrollen und des Weiteren im Unternehmensumfeld benötigten IuK-Infrastrukturen (Informations und Kommunikationstechnik) werden als gegeben betrachtet und innerhalb der Kalkulation nicht berücksichtigt. Dazu gehören:

• Domain Controller (Microsoft Windows Active Directory)
• Mail Server (Bspw. Microsoft Exchange)
• Datenbank Server (Bspw. Microsoft SQL-Server)
• File Server (Konsolidierte Speicherlösung, bspw. NetApp)
• Netzwerkinfrastruktur (Bspw. Gigabit Ethernet Netzwerk, Switche, Router)
• Internetanbindung (Bspw. synchrones DSL)
• VPN-fähige Firewall (Bspw. Cisco, Astaro)
• Citrix Lizenz Server (Reine Softwarekomponente, bspw. Bereitstellung über Domain Controller)

Außerdem benötigte Lizenzen für Microsoft Windows Betriebssysteme, Microsoft Windows Terminalserver CALs (Client Access License) und Citrix Produkte haben ebenfalls keinen Einfluss auf die Berechnung. Amazon ermöglicht, im Rahmen der Partnerschaft mit Citrix, die eigenen Lizenzen für die Nutzung des C3 Labs zu verwenden (Bringing Your Own Licenses)^[53].

3.2.4 Datenvolumen und Verwendungsdauer

Zu berücksichtigende Aspekte sind zum Einen das übertragene Datenvolumen (in die AWS Cloud und heraus) und zum Anderen die Verwendungsdauer (Utilization) der Amazon EC2 Instanzen. Da das Datenvolumen nur sehr schwer einzuschätzen ist und stark vom Aufgabenbereich des Unternehmens abhängt, werden 3 verschiedene Szenarien (Low, Average, High) entwickelt, um den Einfluss des Datenvolumens aufzuzeigen. Beispielsweise wird ein Ingenieurbüro mit vielen umfangreichen CAD-Zeichnungen (Computer Aided Design) ein höheres Datenvolumen, als vergleichsweise eine Anwaltskanzlei, aufweisen. Die drei Szenarien basieren daher auf den folgenden Annahmen:

• Low: 2 GB pro Benutzer, pro Monat
• Average: 4 GB pro Benutzer, pro Monat
• High: 8 GB pro Benutzer, pro Monat

Unter Berücksichtigung der drei Benutzer- und Datenvolumina-Szenarien ergibt sich daraus die folgende Tabelle:

Users	Data Transfer (GB) "In"			Data Transfer (GB) "Out"
	Low	Average	High	Low	Average	High
10	20	40	80	20	40	80
50	100	200	400	100	200	400
250	500	1000	2000	500	1000	2000

Tabelle 2: Übersicht der monatlichen Datenvolumina

Da der Amazon EC2 Cost Comparison Calculator lediglich die Eingabe des Datenvolumens pro EC2 Instanz ermöglicht, werden die ermittelten Werte auf die Anzahl der benötigten Systeme umgelegt:

Anzahl EC2 Instanzen	Data Transfer (GB) "In" p. Instanz			Data Transfer (GB) "Out" p. Instanz
	Low	Average	High	Low	Average	High
2	10	20	40	10	20	40
5	20	40	80	20	40	80
24	21	42	84	21	42	84

Tabelle 3: Übersicht der monatlichen Datenvolumina pro EC2 Instanz

Die bereits angesprochene Verwendungsdauer der EC2 Instanzen ist ein weiterer, einflussreicher Faktor bei der Berechnung der resultierenden Kosten. Da die SBC-Lösung als vollwertige EDV-Lösung für das Unternehmen und Arbeitsgrundlage für die Mitarbeiter dienen soll, ist mit einer Nutzung von 100% pro Jahr zu rechnen. Dieser Wert wird lediglich um 2% reduziert, da dies monatlichen Wartungsarbeiten von ca. 14,5 Std. entspricht. In dieser Zeit können Arbeiten am Netzwerk oder der Internetverbindung vorgenommen und somit die Amazon EC2 Instanzen deaktiviert werden. Daher wird die Verwendungsdauer (Utilization) auf 98% im Basisbetrieb (Baseline) festgelegt. Gerade morgens und nach der Mittagszeit treten häufig Lastspitzen auf, da viele Benutzer gleichzeitig eine Anmeldung an den Terminalserver vornehmen. Um Lastspitzen abzufangen, ist es möglich, zusätzliche EC2 Instanzen bereitzustellen. Die Verwendungsdauer dieser Instanzen wird auf 10%, was 2,4 Std. täglich entspricht, festgelegt.

3.2.5 Zusammenfassung

Anhand dieser Eingabeparameter wird nachfolgend die Berechnung mit dem Amazon EC2 Cost Comparison Calculator durchgeführt:

Parameter	Wert
Region	US-East (Northern Virginia)
Operating System	Windows
Amazon EC2 Instance Type	High-CPU Medium
Anzahl Baseline Instances	siehe Tabelle 1
Annual Utilization	98%
Amazon EC2 Instance Type	High-CPU Medium
Anzahl Peak Instances	siehe Tabelle 1
Annual Utilization	10%
Avg. Monthly Data Transfer "In"	siehe Tabelle 3
Avg. Monthly Data Transfer "Out"	siehe Tabelle 3

Tabelle 4: Zusammenfassung der Eingabeparameter

4 Berechnungen

Der Amazon EC2 Cost Comparison Calculator berechnet für jede Lösung die jährlichen Gesamtkosten. Diese werden auf 12 Monate umgelegt, um die monatlichen Werte zu erhalten. Für Unternehmen außerhalb des US-Dollar Raums ist ebenfalls der korrespondierende Wechselkurs ausschlaggebend. Der Wechselkurs zwischen EUR (Euro) und USD (US-Dollar) wird auf $1,4391 je 1 € festgelegt. Im Folgenden wird aufgezeigt, wie sich die monatlichen Kosten zusammensetzen und welche Bestandteile für die jeweilige Lösung charakteristisch sind.

4.1 Amazon EC2

Die monatlichen Kosten der Amazon EC2 Lösung setzen sich hauptsächlich aus der auf Stundenbasis abgerechneten Verwendungsdauer (Utilization) der betriebenen EC2 Instanzen, als auch aus dem übertragenen Datenvolumen zusammen. Der Betrieb einer im Modell verwendeten "On-Demand" EC2 Instanz "High-CPU Medium" kostet $0.29 pro Stunde. Amazon bietet alternativ die Reservierung einer festgelegten Anzahl von EC2 Instanzen für 1 oder 3 Jahre an. Diese "Reserved" Instanzen sind nach einer einmaligen Gebühr zu günstigeren Konditionen verwendbar. Der Typ "High-CPU Medium" kostet bei vorzeitigen Reservierung mit Linux Betriebssystem lediglich $0.06 pro Stunde (im Vergleich zu $0.17 als "On-Demand" Variante). "Reserved" Instanzen stehen jedoch derzeit nur mit Linux und nicht mit Windows Betriebssystemen zur Verfügung. Ein weiteres Kostenmodell stellen die sog. "Spot" Instanzen dar. In diesem Fall werden freie Kapazitäten zu günstigen Konditionen versteigert. Der Preis pro Stunde ist dabei mit Abhängig von der aktuellen Nachfrage^[54]. Das übertragene Datenvolumen in die AWS Cloud ist derzeit kostenlos (bis Juni 2010) und wird dementsprechend nicht berechnet. Nach diesem Zeitraum beträgt der Preis $0.10 pro GB in die Cloud. Daten, die aus der Cloud ins Internet bzw. Unternehmensnetz transferiert werden, rechnet Amazon in Intervallschritten ab. Die Ersten 10 TB pro Monat kosten $0.17 pro GB. Hinzu kommen die Gebühren für die VPN-Verbindung zur Amazon VPC. Auch hier rechnet Amazon stundenbasiert mit einem Preis von $0.05 pro Stunde ab. Da der Amazon EC2 Cost Comparison Calculator die Kosten für die VPN-Verbindung zur VPC nicht berücksichtigt, wurden die entsprechenden Werte mit dem AWS Simple Monthly Calculator^[55] ermittelt und nachträglich addiert.

4.2 Co-Location

Mit den angegebenen Parametern berechnet der Amazon EC2 Cost Comparison Calculator eine gleichwertige Rechenzentrums-Lösung. Neben den Kosten, die allgemein für den Betrieb einer IT-Infrastruktur anfallen (Server Hardware, Netzwerk Hardware, Wartung, Betriebssystem und Datentransfer), erfasst das Tool spezifische Komponenten der jeweiligen Lösung. Beim Rechenzentrumsbetrieb fallen daher zusätzlich die folgenden Kosten an:

• Rechenzentrumsgebühren (Co-Location Expense)
• Fernwartung (Remote Hands Support)

Die monatlichen Gebühren für das Rechenzentrum und die damit zur Verfügung gestellte Infrastrukturen richten sich nach der Anzahl der benötigten HEs (Höheneinheiten). Standard Rack-Server sind für den Einsatz in einem 19'' Rack vorgesehen und verfügen über ein oder mehrere HEs. Das Tool ermittelt zunächst die Anzahl der benötigten HEs für die Systeme, die im Rechenzentrum untergebracht werden sollen und berechnet anschließend pro Höheneinheit $80^[56]. Im Vergleich dazu kostet eine HE im Düsseldorfer Rechenzentrum der myLoc managed IT AG 49,00 € pro Monat^[57]. Der monatliche Preis für Fernwartungen durch Rechenzentrumspersonal ergibt sich aus der Server-Fehlerrate (bspw. Konfiguration, Neustarts, Fehlersuch), der Zeit, die das Service-Personal zum Beheben eines solchen Fehlers benötigt und der Kosten für solch einen Einsatz. Amazon nimmt dabei eine Fehlerrate von 10% pro Jahr und 1 Stunde zu je $150 pro Fehler an^[58].

4.3 On-Site

Die dritte Alternative ist der Betrieb eines eigenen Unternehmens-Rechenzentrums mit der notwendigen Infrastruktur und dem für die Administration benötigtem Personal. Folgende Aspekte werden hierzu bei der Berechnung kalkuliert:

• Strom und Klimatisierung (Power and Cooling)
• Aufbau eines Rechenzentrums (Data Center Construction)
• Verwaltung und Management (Administration)

Der Ansatz zur Ermittlung der Strom- und Klimatisierungskosten beruht auf einer Studie der Organisation "The Green Grid", welche sich u.a. mit der Energieeffizienz von Rechenzentren beschäftigt^[59]. Auf Basis der Angaben zur Leistungsaufnahme der Server-Hersteller und der innerhalb der Studie ermittelten Werte, berechnet das Tool die korrespondierenden Kosten. Bei der Berechnung der Kosten für den Aufbau eines Rechenzentrums nach einer Studie der Organisation "Uptime Institute" vor. Die Studie entwickelt ein Kosten-Modell, welches, über die Kosten pro Quadratmeter hinaus, die ausschlaggebenden Faktoren bei der Konstruktion und beim Bau eines Rechenzentrums mit einbezieht^[60]. Ausgehend von einer Kapazität von 50 Servern pro Administrator und einem jährlichen Gehalt von $105.000 berechnet der Calculator die Personalkosten für das Management und den Support der Serversysteme. Diese Werte beruhen dabei auf Amazon-Schätzungen und sind als durchschnittlich für entsprechende Rechenzentren anzusehen^[61].

5 Ergebnisanalyse

5.1 Monetäre Aspekte

Die folgende Tabelle zeigt die monatlichen Kosten für die jeweiligen Benutzer- und Datenvolumina-Szenarien auf.

Users	Amazon EC2			Co-Location			On-Site
	Low	Average	High	Low	Average	High	Low	Average	High
10	329,15 €	342,19 €	353,56 €	452,71 €	461,17 €	478,13 €	6300,76 €	6302,84 €	6307,07 €
50	528,25 €	552,66 €	601,48 €	1166,35 €	1193,45 €	1226,06 €	6633,37 €	6640,15 €	6653,70 €
250	2061,63 €	2178,77 €	2413,05 €	5368,00 €	5462,09 €	5626,66 €	8730,17 €	8759,58 €	8818,36 €

Tabelle 5: Übersicht der monatlichen Kosten

Das Spektrum der monatlichen Kosten reicht von 329,15 € für das Szenario mit 10 Benutzern und einem niedrigen Datenaufkommen bei Verwendung der Amazon Web Services, bis 8818,36 € pro Monat für das Szenario mit 250 Benutzern und einem hohen Datenaufkommen beim Betrieb eines eigenen Rechenzentrums. Insgesamt sind die Anzahl der Benutzer und damit die resultierende Anzahl der benötigten Systeme ausschlaggebend für die monatlichen Kosten. Die in den verschiedenen Szenarien betrachteten Datenvolumina fallen nur wenig ins Gewicht und beeinflussen die resultierenden Kosten kaum. Für die AWS Lösung ist dies ist zum Teil darauf zurückzuführen, dass bis Juni 2010 eingehende Datenübertragungen kostenlos sind und somit durch Amazon nicht berechnet werden. Die nachfolgenden Abbildungen zeigen die Kosten für die drei Benutzer-Szenarien und jeweils für die Amazon EC2 Lösung, die Co-Location Lösung und die On-Site Lösung mit Berücksichtigung der drei Datenvolumina-Szenarien auf (siehe Abbildung 6, 7, 8).

Abbildung 6: Vergleich der monatlichen Kosten bei 10 Benutzern

Abbildung 7: Vergleich der monatlichen Kosten bei 50 Benutzern

Abbildung 8: Vergleich der monatlichen Kosten bei 250 Benutzern

5.2 Nicht-Monetäre Aspekte

Neben den resultierenden Kosten für die Installation, das Management und den Betrieb einer der im Vorfeld beschriebenen Lösungen, gibt es weitere Aspekte, die bei einer Entscheidung zu berücksichtigen sind. Der Einfluss, dieser häufig nur schwer quantifizierbaren Faktoren, hängt vom Unternehmensumfeld, der zukünftigen Entwicklung oder gültigen Bestimmungen und Gesetzen ab. Nachfolgend werden einige dieser Faktoren, bezüglich ihrer Vor- und Nachteile im Hinblick auf Cloud Computing, beleuchtet.

Verfügbarkeit

Dient die SBC Plattform der Bereitstellung einer vollwertigen Arbeitsumgebung für die Mitarbeiter des Unternehmens, sollte das Konzept eine höchstmögliche Verfügbarkeit realisieren. Dies erfordert, über die redundante Auslegung von Services hinaus, zusätzlich eine abgesicherte Infrastruktur für den Betrieb der Server- und Netzwerkhardware. Moderne Rechenzentren (Co-Location) garantieren durch verschiedenste Vorkehrungen (Redundante Energieversorgung, 24-stündige Betriebsüberwachung, Gaslöscheinrichtungen, Zugangssicherheit) annähernd 100%-tige Verfügbarkeit für die dort betriebene Hardware. Amazon garantiert für die Elastic Compute Cloud eine Verfügbarkeit von 99,95%^[62]. Um eine solche Verfügbarkeit für das eigene Rechenzentrum (On-Site) zu gewährleisten, sind häufig hohe Investitionen notwendig.

Flexibilität

Die Flexibilität im Bezug auf die Rechenleistung, die Betriebssysteme oder die unterstützte Software, ist bei einem Cloud-Provider auf die angebotenen Services begrenzt. Die Amazon Web Services bieten ein sehr umfangreiches Angebot an Infrastruktur- und Plattform-Diensten. Es mag jedoch Einsatzszenarien geben, die sich nicht mit diesem Angebot abdecken lassen. Durch genaue Planungsarbeiten im Vorfeld, ist mit einem eigenen Rechenzentrum ein höchstmöglicher Grad an Flexibilität realisierbar, da dieses keinen Beschränkungen bezüglich Netzwerk- und Serverhardware oder der gewählten Architektur unterliegt.

Sicherheit

Bei der Entwicklung und Implementierung von Services setzt Amazon aktuelle Sicherheitstechnologien, Standards und Best Practices ein, um die Sicherheit und Vertraulichkeit der Daten zu gewährleisten. Des Weiteren ermöglicht die Dokumentation dieser Funktionalitäten den richtigen Einsatz und die Verwendung durch die Nutzer der Cloud^[63]. Kommerzielle Rechenzentren, als auch die der Amazon Web Services, sind durch Sicherheitsfirmen, Protokollierte Zugangssysteme und Videoüberwachung vor unbefugten Zugriffen geschützt. Falls nicht schon vorhanden, entstehen durch Maßnahmen der Zugangssicherheit am eigenen Standort, weitere Aufwendungen, die zu berücksichtigen sind.

Skalierbarkeit

Die Skalierbarkeit eines Services ist Voraussetzung, um im Nachhinein auf wachsende Anforderungen, ohne hohe Folgeinvestitionen reagieren zu können. Durch Virtualisierungs-Technologien lässt sich ein gewisser Umfang an Skalierbarkeit leicht erreichen. Ein eigener Serverraum oder der angemietete Platz in einem Rechenzentrum sind jedoch im Vergleich zu Cloud Computing als nur bedingt skalierbar und statisch zu betrachten (siehe Abbildung 9). Mit Hilfe der Amazon Web Services lässt sich zu jeder Zeit der exakte Bedarf an Rechenleistung und Speicher decken, unabhängig welchen Fluktuationen dieser unterliegt (siehe Abbildung 10).

Abbildung 9: Skalierbarkeit eines traditionellen Rechenzentrums (Quelle: http://aws.amazon.com/economics/)

Abbildung 10: Skalierbarkeit der Amazon Web Services (Quelle: http://aws.amazon.com/economics/)

6 Fazit

Insgesamt lässt sich eine SBC-Lösung auf Basis der Amazon Web Services für kleine und mittlere Unternehmen in Betracht ziehen. Die angebotenen Infrastruktur-Dienste (IaaS) stellen gerade im Bezug auf die Skalierbarkeit, im Gegensatz zu konventioneller Hardware, eine wirtschaftliche Alternative dar. Da keine großen Initialinvestitionen getätigt werden müssen, können IT-Services flexibel und bedarfsgerecht im Unternehmen implementiert werden. Ob die Lösung eines Cloud Computing Providers immer eine günstigere Variante darstellt, hängt jedoch von vielen Faktoren ab. Einflussreich sind dabei die gewählte Betriebssystem-Architektur (32-bit oder 64-bit) und insbesondere die Verwendungsdauer (Utilization) der virtuellen Infrastruktur. Zu diesem Ergebnis kam ebenfalls eine Studie des Lehrstuhls für Wirtschaftsinformatik an der Universität Bayreuth. Demnach ist bei einem niedrigen Auslastungsgrad (Verwendungsdauer) der benötigten Serversysteme in jedem Fall die Rechenleistung der AWS einer Eigenbereitstellung vorzuziehen^[64]. Als Entscheidungsgrundlage sollte im Vorfeld immer eine genauere Untersuchung des Verwendungszwecks und der möglichen Alternativen durchgeführt werden. Abschließend lässt sich sagen, dass Cloud Computing und die daraus resultierenden Business-Modelle die zukünftige Marktentwicklung maßgeblich beeinflussen werden.

7 Abkürzungsverzeichnis

Abkürzung	Bedeutung
AMI	Amazon Machine Image
AWS	Amazon Web Services
BITKOM	Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.
CAD	Computer Aided Design
CAL	Client Access License
C3	Citrix Cloud Center
CRM	Customer Relationship Management
DaaS	Desktop as a Service
DBMS	Datenbank Management System
EC2	Elastic Compute Cloud
EDV	Elektronische Datenverarbeitung
EE	Execution Environment
ERP	Enterprise Ressource Planning
EUR	Euro
GUI	Graphical User Interface
HDX	High-Definition User Experience
HE	Höheneinheit
IaaS	Infrastructure as a Service
ICA	Independent Computing Architecture
IP	Internet Protocol
IPsec	Internet Protocol Security
ISDN	Integrated Services Digital Network
IuK	Informations und Kommunikationstechnik
PaaS	Platform as a Service
PE	Programming Environment
RDS	Relational Database Service
S3	Simple Storage Service
SaaS	Software as a Service
SBC	Server Based Computing
SCM	Supply Chain Management
SOA	Service-orientierte Architekturen
SQL	Structured Query Language
SQS	Simple Queue Service
TCO	Total Cost of Ownership
TCP/IP	Transmission Control Protocol/Internet Protocol
URI	Uniform Resource Identifier
USD	US-Dollar
VaaS	VoIP as a Service
VoIP	Voice over IP
VPC	Virtual Private Cloud
VPN	Virtual Private Network
WAN	Wide Area Network
XaaS	Everything as a Service
XML	Extensible Markup Language

8 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
Abbildung 1	Thin Clients des Herstellers IGEL
Abbildung 2	Kombination der verschiedenen Amazon Web Services für die Anwendung GrepTheWeb
Abbildung 3	Architektur des Citrix Cloud Centers (C3)
Abbildung 4	Netzwerkarchitektur der Anbindung des C3 Labs der AWS
Abbildung 5	Ergebnis der Citrix Amazon EC2 Scalability Analysis
Abbildung 6	Vergleich der monatlichen Kosten bei 10 Benutzern
Abbildung 7	Vergleich der monatlichen Kosten bei 50 Benutzern
Abbildung 8	Vergleich der monatlichen Kosten bei 250 Benutzern
Abbildung 9	Skalierbarkeit eines traditionellen Rechenzentrums
Abbildung 10	Skalierbarkeit der Amazon Web Services

9 Tabellenverzeichnis

Tab.-Nr.	Tabelle
Tabelle 1	Anzahl der benötigten EC2 Instanzen
Tabelle 2	Übersicht der monatlichen Datenvolumina
Tabelle 3	Übersicht der monatlichen Datenvolumina pro EC2 Instanz
Tabelle 4	Zusammenfassung der Eingabeparameter
Tabelle 5	Übersicht der monatlichen Kosten

10 Fußnoten

1. ↑ Vgl. Virtualization.info (2009)
2. ↑ http://www.salesforce.com
3. ↑ Vgl. Salesforce.com (2010)
4. ↑ häufig auch "Dumb Terminals" oder "Dumb Clients" genannt
5. ↑ Vgl. Jutzi-Blank (2004), S. 2f.
6. ↑ Tritsch (2003), S. 6
7. ↑ GUI (Graphical User Interface)
8. ↑ Vgl. Nieh (2000), S. 1
9. ↑ Vgl. Citrix (2003)
10. ↑ Vgl. Baun et al. (2010), S. 50f.
11. ↑ Baun et al. (2010), S. 4
12. ↑ Vgl. Baun et al. (2010), S. 2
13. ↑ Vgl. Baun et al. (2010), S. 2
14. ↑ Vgl. Baun et al. (2010), S. 16
15. ↑ Vgl. Baun et al. (2010), S. 17
16. ↑ Austin (2002)
17. ↑ Vgl. Baun et al. (2010), S. 25
18. ↑ Vgl. Baun et al. (2010), S. 26f.
19. ↑ Vgl. Baun et al. (2010), S. 27
20. ↑ Vgl. Baun et al. (2010), S. 29
21. ↑ http://aws.amazon.com/
22. ↑ http://www.gogrid.com/
23. ↑ http://www.joyent.com/
24. ↑ Vgl. Baun et al. (2010), S. 33
25. ↑ http://developers.facebook.com/
26. ↑ http://code.google.com/intl/de/appengine/
27. ↑ http://www.microsoft.com/windowsazure/
28. ↑ BITKOM (2009), S. 10
29. ↑ https://www.google.com/accounts/ServiceLogin?service=writely&passive=true&nui=1&continue=http%3A%2F%2Fdocs.google.com%2F%3Fhl%3Dde%26tab%3Dwo&followup=http%3A%2F%2Fdocs.google.com%2F%3Fhl%3Dde%26tab%3Dwo&ltmpl=homepage&rm=false
30. ↑ http://www.officelive.com/de-DE/
31. ↑ http://www.salesforce.com/de/
32. ↑ Vgl. Amazon (2009c)
33. ↑ Vgl. Amazon (2009a), S. 3
34. ↑ Vgl. Baun et al. (2010), S. 40
35. ↑ Vgl. Amazon (2009d)
36. ↑ Vgl. Amazon (2009e)
37. ↑ Vgl. Amazon (2009f)
38. ↑ Vgl. Amazon (2009g)
39. ↑ Vgl. Amazon (2009h)
40. ↑ Vgl. Amazon (2009i)
41. ↑ Vgl. Amazon (2009j)
42. ↑ Vgl. Citrix (2009a)
43. ↑ Vgl. Citrix (2009b)
44. ↑ Vgl. Citrix (2009c)
45. ↑ Vgl. Citrix (2009d)
46. ↑ Vgl. Wölfer (2006)
47. ↑ Vgl. Amazon (2009k)
48. ↑ http://media.amazonwebservices.com/Amazon_EC2_Cost_Comparison_Calculator.xls
49. ↑ Vgl. Amazon (2009b), S. 2
50. ↑ Vgl. KfW (2008)
51. ↑ Eine 64-bit Architektur ist ebenfalls realisierbar, jedoch nicht Betrachtungsgegenstand
52. ↑ Vgl. Citrix (2009e), S. 3
53. ↑ Vgl. Amazon (2009k)
54. ↑ Vgl. Amazon (2009d)
55. ↑ http://aws.amazon.com/calculator
56. ↑ Vgl. Amazon (2009b), S. 10f.
57. ↑ Vgl. myLoc (2010)
58. ↑ Vgl. Amazon (2009b), S. 11f.
59. ↑ Vgl. Belady (2008), S. 2
60. ↑ Vgl. Turner (2008), S. 1
61. ↑ Vgl. Amazon (2009b), S. 15ff.
62. ↑ Vgl. Amazon (2009d)
63. ↑ Vgl. Amazon (2009l)
64. ↑ Vgl. Matros (2009), S. 15f.

11 Literaturverzeichnis

Bezeichnung	Quelle
Amazon (2009a)	o.V.: Overview of Amazon Web Services, Amazon, o.O. 2009, http://awsmedia.s3.amazonaws.com/AWS_Overview_Whitepaper_120809.pdf (03.01.2010, 10:32)
Amazon (2009b)	o.V.: User Guide: Amazon EC2 Cost Comparison Calculator, Amazon, o.O. 2009, http://media.amazonwebservices.com/User_Guide_Amazon_EC2_Cost_Comparison_Calculator.pdf (10.01.2010, 16:56)
Amazon (2009c)	o.V.: Über uns - Kunden bestellten über 110 Produkte pro Sekunde auf Amazons weltweiten Websites – mehr als 9,5 Millionen Artikel am Spitzentag, dem 14. Dezember, Amazon, o.O. 2009, http://www.amazon.de/gp/press/pr/20091226/ref=amb_link_82934453_1?pf_rd_m=A3JWKAKR8XB7XF&pf_rd_s=center-1&pf_rd_r=0J7WFRRP27FKPEA5FHZH&pf_rd_t=2701&pf_rd_p=479062853&pf_rd_i=home-2009 (03.01.2010, 08:17)
Amazon (2009d)	o.V.: Amazon Elastic Compute Cloud (Amazon EC2), Amazon, o.O. 2009, http://aws.amazon.com/ec2/ (03.01.2010, 07:42)
Amazon (2009e)	o.V.: Amazon Simple Storage Service (Amazon S3), Amazon, o.O. 2009, http://aws.amazon.com/s3/ (03.01.2010, 08:46)
Amazon (2009f)	o.V.: Amazon Virtual Private Cloud (Amazon VPC), Amazon, o.O. 2009, http://aws.amazon.com/vpc/ (03.01.2010, 09:01)
Amazon (2009g)	o.V.: Amazon Relational Database Service (Amazon RDS), Amazon, o.O. 2009, http://aws.amazon.com/rds/ (03.01.2010, 09:27)
Amazon (2009h)	o.V.: Amazon Simple Queue Service (Amazon SQS), Amazon, o.O. 2009, http://aws.amazon.com/sqs/ (03.01.2010, 09:48)
Amazon (2009i)	o.V.: What is AWS?, Amazon, o.O. 2009, http://aws.amazon.com/what-is-aws/ (04.01.2010, 07:02)
Amazon (2009j)	o.V.: Solution Providers Program, Amazon, o.O. 2009, http://aws.amazon.com/solutions/solution-providers/program/ (04.01.2010, 08:30)
Amazon (2009k)	o.V.: Citrix and AWS, Amazon, o.O. 2009, http://aws.amazon.com/solutions/global-solution-providers/citrix/ (04.01.2010, 10:21)
Amazon (2009l)	o.V.: AWS Security Center, Amazon, o.O. 2009, http://aws.amazon.com/security/ (12.01.2010, 21:48)
Austin (2002)	Austin, Daniel; Barbir, Abbie; Garg, Sharad: Web Services Architecture Requirements, W3C, o.O. 2002, http://www.w3.org/TR/2002/WD-wsa-reqs-20020429.html (07.01.2010, 14:03)
Baun et al. (2010)	Baun, Christian; Kunze, Marcel; Nimis, Jens; Tai, Stefan; Günther, O.; Karl, W.; Lienhart, R.; Zeppenfeld, K. (Hrsg.): Cloud Computing. Web-basierte dynamische IT-Services, Springer, Berlin Heidelberg 2010
Belady (2008)	o.V., Belady, Christian (Hrsg.): GREEN GRID DATA CENTER POWER EFFICIENCY METRICS: PUE AND DCIE, The Green Grid, o.O. 2008, http://www.thegreengrid.org/~/media/WhitePapers/White_Paper_6_-_PUE_and_DCiE_Eff_Metrics_30_December_2008.ashx?lang=en (11.01.2010, 22:08)
BITKOM (2009)	o.V., BITKOM Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (Hrsg.): Leitfaden für SaaS-Anbieter, BITKOM, Berlin 2009, http://www.bitkom.org/files/documents/Leitfaden_SaaS_20090310_web_neu(1).pdf (08.01.2010, 17:59)
Citrix (2003)	o.V.: News - Now 99% of Fortune 500, 95% of Financial Times European 100 and 95% of Fortune Global 100 Use Citrix Software, Citrix, o.O. 2003, http://www.citrix.com/site/NE/news/news.asp?newsID=10042 (05.01.2010, 20:19)
Citrix (2009a)	o.V.: 20 Years of Citrix History, Citrix, o.O. 2009, http://www.citrix.com/lang/English/lp/lp_1689476.asp (05.01.2010, 20:24)
Citrix (2009b)	o.V.: About Citrix Systems, Inc., Citrix, o.O. 2009, http://www.citrix.com/lang/English/aboutCitrix.asp (05.01.2010, 20:45)
Citrix (2009c)	o.V.: Citrix HDX Technologien, Citrix, o.O. 2009, http://www.citrix.de/produkte/schnellsuche/xendesktop/hdx/ (05.01.2010, 22:28)
Citrix (2009d)	o.V.: Citrix Cloud Center, Citrix, o.O. 2009, http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=1857312 (05.01.2010, 22:52)
Citrix (2009e)	o.V.: Amazon EC2 XenApp Scalability Analysis, Citrix, o.O. 2009, http://support.citrix.com/servlet/KbServlet/download/22295-102-641971/AmazonEC2XenAppScalabilityNew.pdf (10.01.2010, 10:34)
Jutzi-Blank (2004)	Jutzi-Blank, Gerda; Leister, Jürgen; Steenweg, Helge: Rezentralisierung: Server-Based Computing in der Praxis einer Universitätsbibliothek, Informationsmanagement UB Kassel, Kassel 2004 http://kobra.bibliothek.uni-kassel.de/bitstream/urn:nbn:de:hebis:34-200603027127/6/abi2004-3preprint.pdf (18.11.2009, 17:29)
KfW (2008)	o.V.: KMU-Definition, KfW, o.O. 2008, http://www.kfw-mittelstandsbank.de/DE_Home/Service/Kreditantrag_und_Formulare/142291_Selbsterklaerung_KMU.pdf (28.12.2009, 13:20)
Matros (2009)	Matros, Raimund; Stute, Philipp; von Zuydtwyck, Nicolaus H.; Eymann, Torsten (Hrsg.): Make-or-Buy im Cloud-Computing – Ein entscheidungsorientiertes Modell für den Bezug von Amazon Web Services, Universität Bayreuth, Bayreuth 2009 http://opus.ub.uni-bayreuth.de/volltexte/2009/552/pdf/Paper_45.pdf (02.12.2009, 19:41)
myLoc (2010)	o.V.: Serverhousing Tower oder 1 HE Stellplatz mieten, myLoc managed IT AG, o.O. 2010, http://www.myloc.de/products-serverhousing.html (11.01.2010, 22:42)
Nieh (2000)	Nieh, Jason; Yang, S. Jae: Measuring the Multimedia Performance of Server-Based Computing, Department of Computer Science Columbia University, o.O 2000 http://www.ncl.cs.columbia.edu/publications/nossdav2000_fordist.pdf (18.11.2009, 17:11)
Salesforce.com (2010)	o.V.: Unternehmen - Über salesforce.com, o.O. 2010, http://www.salesforce.com/de/company/ (06.01.2010, 06:31)
Tritsch (2003)	Tritsch, Bernhard: Windows Server 2003 Terminaldienste. Die praktische Anleitung für Administratoren: Architektur, Installation, Administration, Betrieb, Add-Ons und Troubleshooting, Microsoft Press, Unterschleißheim 2003
Turner (2008)	Turner, Pitt; Brill, Kenneth: Cost Model: Dollars per kW plus Dollars per Square Foot of Computer Floor, Uptime Institute, Inc., Santa Fe 2008, http://uptimeinstitute.org/wp_pdf/(TUI3029A)CostModelDollarsperkWPlusDollars.pdf (11.01.2010, 22:37)
Virtualization.info (2009)	Perilli, Alessandro: 50% of workloads will run inside virtual machines by 2012 says Gartner, Virtualization.info, o.O. 2009, http://www.virtualization.info/2009/10/50-of-workloads-will-run-inside-virtual.html(15.12.2009, 18:17)
Wölfer (2006)	Wölfer, Thomas: Cmd-Nachfolger – Scripting mit der Windows PowerShell, Microsoft TechNet, o.O. 2006, http://www.microsoft.com/germany/technet/scriptcenter/topics/msh/scripting-mit-windows-power-shell.mspx (05.01.2010, 11:28)