4.5
Datenstandort... - 41 -
4.6
Verfügbarkeitsbedenken ... - 41 -
5 Fazit ... - 42 -
Anhang ... - 43 -
Literaturverzeichnis ... - 44 -
Abbildung 1: Web-Services-Dreieck
4
Abbildung 2: Privat-, Public-, und Hybrid Cloud
7
Abbildung 3: Service Modelle
8
Abbildung 4: Überblick über die WSDL-Komponenten
13
Abbildung 5: Beschriebene Aspekte von USDL
16
Abbildung 6: Die 9 Module von USDL
16
Abbildung 7: Rollen in einem Servicenetzwerk
17
Abbildung 8: Service Modul
23
Abbildung 9: Function Modul Teil I
24
Abbildung 10: Function Modul Teil II
24
Abbildung 11: Function Modul Teil III
25
Abbildung 12: Tax-Element
25
Abbildung 13: priceMetric-Element
26
Abbildung 14: pricePlan
26
Abbildung 15: priceComponent
27
Abbildung 16: absolutePriceLevel
28
Abbildung 17: Agent
28
Abbildung 18: contactProfile-Element
29
Abbildung 19: Agent:Person
29
Abbildung 20: Work
30
Abbildung 21: usageRight-Element
30
Abbildung 22: license-Element
31
Abbildung 23: Interaction Modul I
32
Abbildung 24: Interaction Modul II
32
Abbildung 25: Service Level Modul
33
Abbildung 26: Service light Editor_Service
34
Abbildung 27: Service light Editor_Pricing
35
Abbildung 28: priceAdjustment-Element
35
Abbildung 29: Participant Modul
36
Abbildung 30: Service Modul_2
37
Abbildung 31: Service Modul_2.1
38
Abbildung 32: targetConsumer-Element
39
Abbildungsverzeichnis
Tabellenverzeichnis
Tabelle 1: Überblick Servicebeschreibungssprachen 15
Abkürzungsverzeichnis
Abb. Abbildung
e.g. exempli gratia (zum Beispiel)
evtl.
eventuell
FTP
File Transport Protocol
GB
Gigabyte
HTTP
Hypertext Transfer Protocol
IaaS
Infrastructure as a Service
Kap.
Kapitel
KMU
kleine und mittelständische Unternehmen
NIST
National Institute for Standards
OWL-S
Ontology Language for Web Services
PaaS
Platform as a Service
RDF
Resource Delivery Framework
SaaS
Software as a Service
SLA
Service Level Agreements
SML
Software Modeling Language
SMTP
Simple Mail Transfer Protocol
SOA
Service orientierte Architektur
SOAP
Simple Object Access Protocol
sog.
so genannt
UDDI
Universal Description, Discovery and Integration
UML
Unified Modeling Language
URI
Unified Resource Identifier
USDL
Unified Service Description Language
VPN
Virtual Personal Network
WADL
Web Application Description Language
W3C
World Wide Web Consortium
WS
Web Service
WSDL
Web Service Description Language
WSMO
Web Service Modeling Ontology
XML
Extensible Markup Language
1 Grundlagen des Cloud Computing
1.1 Definition Cloud Computing
Cloud Computing ist in der IT-Welt allgegenwärtig und nicht mehr wegzudenken. Was steckt
aber wirklich hinter diesem Begriff? Ist es etwa eine neue Technologie, oder doch nur ein
neues, in der IT benutztes Schlagwort, für bereits bestehende Technologien. Eine weltweit
einheitliche standardisierte Definition könnte dabei die Antwort geben, aber diese existiert im
Moment nicht. Dafür finden sich in der Literatur
1
zahlreiche Definitionen zum Thema Cloud
Computing. Eine vielbeachtete und in der Literatur oft zitierte Definition stammt vom
National Institut for Standards and Technology (NIST 2011, 2):
"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access
to a shared pool of configurable computing resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly provisioned and released with minimal
management effort or service provider interaction. This cloud model promotes availability
and is composed of five essential characteristics, three service models, and four deployment
models."
Wie erkenntlich ist, enthält die aufgeführte Definition von NIST, fünf wesentliche
Eigenschaften, drei Service Modelle (SaaS, PaaS und IaaS) und vier Betriebsmodelle. Auf
diese einzelnen Aspekte wird im Folgenden eingegangen, um Cloud Computing zu erklären.
Die fünf wesentlichen Eigenschaften des Cloud Computing nach NIST werden dabei als
erstes aufgezeigt und erklärt (NIST 2011, 2).
Resource pooling: Bestehende IT-Ressourcen werden gebündelt, um von verschiedenen
Nutzern gemeinsam genutzt zu werden. Dabei werden virtuelle und physische Ressourcen
dynamisch einer Vielzahl von Kunden, je nach Bedarf, zur Verfügung gestellt (Metzger,
Reitz, Villar 2011, 13). Dies wird mit Hilfe einer Multi-Tenant-Architektur realisiert. Bei
einer Multi-Tenant-Architektur, arbeiten im Gegensatz zu einer Single-Tenant-Architektur,
alle Nutzer auf derselben Plattform, aber treten als separat voneinander getrennte Kunden auf.
Dadurch, dass diese Kunden als unabhängige Mandanten auf der gleichen Hard- und
Softwareinfrastruktur laufen, können Skaleneffekte, wie auch andere Kosteneinsparungen
realisiert werden (Terplan, Voigt 2011, 22).
Broad network access: Cloud Computing Services sind netzwerkbasiert und können in
Echtzeit abgerufen werden. Der Zugriff ist dabei von jeder standardisierten Plattform
(Laptops, Desktop PCs, Tablet Computer und Mobile Geräte) aus möglich.
1 Vgl. Baun et al. 2011, 4; Foster et al. 2008, 1; Armbrust et al. 2009, 4
1
Measured service: Bei Beanspruchung von Cloud Services kann eine verbrauchsabhängige
Abrechnung erfolgen. Durch Nutzung von Ressourcen, kann sowohl für den Anbieter, als
auch für den Nutzer, durch Beobachtung, Kontrolle und Berichtserstattung eine Transparenz
hergestellt werden. Das Trafficvolumen, die Speichergröße, die Zeit oder auch der Nutzer
sind Beispiele für zu messende Größen, die je nach Typ des Services anders ausfallen können
(Metzger, Reitz, Villar 2011, 15). Diese Transparenz sorgt dafür, dass nur die tatsächlich
genutzten Ressourcen abgerechnet werden und schafft somit eine Basis von Vertrauen und
Sicherheit auf Seiten des Nutzers, sowie auch des Providers.
On-demand self-service: Cloud Services sind zu jedem Zeitpunkt verfügbar und durch den
Nutzer selbstständig skalierbar. Der entscheidende Punkt hierbei ist, die Vereinfachung für
den Nutzer dahingehend, dass der Zugriff auf Cloud Services auch ohne eine menschliche
Interaktion mit dem Anbieter stattfindet (Baun et al. 2011, 5).
Rapid elasticity: Ressourcen von Services können bedarfsgerecht bereitgestellt und
freigegeben werden. Diese sog. elastische Bereitstellung kann entweder manuell durch den
Nutzer oder automatisch ausgeführt werden.
Bevor auf die drei Service Modelle und die vier Betriebsmodelle nach NIST eingegangen
wird, ist es zum Verständnis ratsam, bereits im Vorfeld auf die technologischen Aspekte des
Cloud Computing einzugehen. Hierbei findet keine Unterscheidung oder Abgrenzung
zwischen einzelnen Technologien im Zusammenhang mit Cloud Computing statt. Denn
dieses wurde in der Literatur
2
bereits zu genüge behandelt. Bei dem derzeitigen Hype rund
um das Thema Cloud Computing ist der Gedanke groß, dass dahinter eine neue, innovative
Technologie steckt. Dies ist aber nicht der Fall, denn Cloud Computing steht für keine
neuartige Technologie, sondern für ein neues Geschäftsmodell (Terplan, Voigt 2011, 23).
Cloud Computing bedient sich dabei einer Reihe von bestehenden Technologien, einige
davon werden im nächsten Kapitel vorgestellt, andere wiederum sind in der heutigen Zeit so
selbstverständlich, dass keine Betrachtung mehr notwendig
3
hierfür erscheint.
1.2 Technologien des Cloud Computing
Für die Entwicklung von Cloud Computing und in diesem Zusammenhang auch angebotenen
Cloud Services, sind für den Autor dieser Arbeit, drei Technologien von relevanter
Bedeutung. Bei diesen Technologien, die nun im Folgenden vorgestellt werden, handelt es
sich um die Virtualisierung, die SOA und Web Services.
1.2.1 Virtualisierung
Die Grundlage der meisten Cloud Architekturen besteht aus der Virtualisierung von
Ressourcen (Baun et al. 2011, 9). Eine einheitliche Definition zum generellen Begriff der
2
Vgl. Metzger, Reitz, Villar 2011, 23-24; Chee, Franklin 2010, 38-39
3
Hierbei handelt es sich, um nur einige Beispiele zu nennen, um (Hochleistungs-) Server, Internet, Browser
aber auch andere Webtechnologien die hier nicht näher vorgestellt werden.
2
Virtualisierung existiert nicht, da das Konzept in vielen unterschiedlichen
Technologiedomänen zum Einsatz kommt. Prinzipiell versteht man unter Virtualisierung,
dass dem Nutzer eine Abstraktionsschicht bereitgestellt wird, die ihn von den eigentlichen
physikalischen Ressourcen trennt. Dadurch sollen Ressourcen gemeinsam genutzt werden,
um bestehende Kapazitäten besser auszulasten (BITKOM 2009, 71; Meinel et al. 2011, 10).
Physische Ressourcen, wie Computer, Server und Anwendungssysteme werden dabei in
mehrere, je nach Nutzerzahl, logische Sichten unterteilt. Beispielsweise können mehrere
Betriebssysteme parallel auf einem Server laufen, ohne das zwischen den Betriebssystemen
eine (logische) Verbindung oder gegenseitige Kenntnisnahme existiert. Der ursprüngliche
Gedanke war, einzelne Ressourcen in Pools zusammenzufassen und gemeinsam zu verwalten.
Im Bezug zu Cloud Computing, können aus diesem Pool die Service-Funktionalitäten
bezogen werden, die von den Kunden nachgefragt werden (Baun et al. 2011, 9-10; Metzger,
Reitz, Villar 2011, 15; Beckereit 2011, 70-71).
1.2.2 Service orientierte Architektur
Eine weitere Voraussetzung des Cloud Computing ist die Service orientierte Architektur
(SOA). Unter einer SOA wird keine konkrete Technik, sondern ein abstraktes Konzept einer
Software Architektur verstanden, welches das Anbieten, Suchen und Nutzen von Services
über ein Netzwerk ermöglichen soll (Melzer et al. 2010, 9; TecChannel 2006). Mit der SOA
wird bezweckt, dass nicht mehr Anwendungen an sich, sondern (automatische)
Geschäftsprozesse im Vordergrund stehen. Das ermöglicht IT-Architekturen auf die
Abstraktionsebene von Geschäftsprozessen zu befördern (Baun et al. 2011, 19; TecChannel
2006a). Services sind in einer SOA dabei lose gekoppelt und können bei Bedarf nicht nur
vom Kunden, sondern plattformübergreifend auch von Anwendungen oder anderen Services
dynamisch gesucht und eingebunden werden (Melzer et al. 2010, 11; TecChannel 2006a). Um
dies zu erreichen werden inkompatible Methoden oder Anwendungen als offene
wiederverwendbare Services dargeboten, um somit eine sprachen-, wie auch
plattformunabhängige Nutzung und Wiederverwendung zu ermöglichen (Baun et al. 2011,
20-21).
Damit ein Service von anderen Anwendungen oder Services gefunden und genutzt werden
kann, müssen diese Services, unabhängig von ihrer Programmiersprache, Plattform und
Implementierung offene, frei zugängliche Schnittstellen aufweisen. Dies wird anhand einer
Schnittstellensprache ermöglicht, im Falle von Web Services kommt die Web Service
Description Language zum Einsatz
4
(Melzer et al. 2010, 15). Im Cloud Computing werden
angebotene Anwendungen, Plattformen und Infrastrukturen als Services in der SOA realisiert
und zur Verfügung gestellt. Beispielsweise kann ein Anbieter von Public Cloud Services,
diese mit standardisierten Web-Protokollen und Schnittstellen anbieten
(
Baun et al. 2011,
4
Weitere Informationen dazu im Kapitel 2.2.1
3
19). Hierfür hat sich der Einsatz von Web Services bei den Cloud Service Anbietern zum
großen Teil durchgesetzt
5
.
Beteiligte Rollen die in einer SOA identifiziert werden können, sind der Serviceanbieter, das
verzeichnis und der -nutzer (Melzer et al. 2010, 14; TecChannel 2006a). Jeder dieser drei
Rollen erfüllt einen vorgesehenen Zweck innerhalb der SOA, auf die im nächsten Kapitel, im
Zusammenhang mit Web Services, näher eingegangen wird.
1.2.3 Web Services
Neben den eben vorgestellten Konzepten der Virtualisierung und der SOA sind Web Services
eine wichtige Voraussetzung für das Cloud Computing. Web Services sind eine Möglichkeit
eine SOA technisch zu realisieren. Innerhalb der Interaktion zwischen den Beteiligten der
SOA kommen unterschiedliche Techniken zum Einsatz, welche als Gesamtheit die Web
Services repräsentieren (Krcmar 2011, 183-184; TecChannel 2006b). Es muss von vornherein
klargestellt werden, dass die Nutzung der Technologie von Web Services nicht zwingend für
eine SOA ist, sondern es sich nur um eine Möglichkeit handelt, eine SOA zu realisieren
(Baun et al. 2011, 19).
Das W3C (2002) definiert Web Services wie folgt: ,,A Web service is a software application
identified by a URI, whose interfaces and binding are capable of being defined, described and
discovered by XML artifacts and supports direct interactions with other software applications
using XML based messages via internet-based protocols".
Nach dieser Definition versteht man unter einem Web Service, eine durch URI eindeutig
identifizierte Softwareanwendung, deren Schnittstellen aus einem maschinenlesbaren Format
bestehen. Dadurch wird eine Interaktion und Kommunikation mit anderen Systemen
5
Beispielhaft sei hier Amazon genannt, bei dem zu jedem Web Service eine dazugehörige WSDL-Datei existiert.
4
ermöglicht. Diese maschinenübergreifende Kommunikation vollzieht sich dabei ohne direkte
Beteiligung einer menschlichen Komponente, es handelt sich um eine reine Maschinen-
Kommunikation, die mittels Web Protokollen ermöglicht wird. Den technischen Rahmen von
Web Services bilden Protokolle und Standards wie UDDI, WSDL, SOAP, HTTP und XML.
Wie bereits angedeutet, sind Web Services eine Möglichkeit um eine SOA zu realisieren, mit
dessen Hilfe Services im Internet beschrieben, herausgegeben, gefunden und je nach Bedarf
zugegriffen werden kann (Krcmar 2011, 183-185; TecChannel 2006b).
Die technische Realisierung eines Web Services wird nun unter Einbeziehung der Abb. 1 mit
den Rollen der SOA beschrieben. Im ersten Schritt stellt der Dienstanbieter einen Service zur
Verfügung, in unserem Fall handelt es sich um einen Web Service. Dazu erstellt der
Dienstanbieter eine Schnittstellenbeschreibung des Web Services mit Hilfe von WSDL.
Damit der Servicenutzer einen Service suchen und finden kann, wird dieser, basierend auf
UDDI, in einen Verzeichnisdienst transferiert. Der Dienstnutzer sucht einen bestimmten Web
Service beim Verzeichnis. Zu diesem Zweck verfügt die UDDI über eine SOAP-Schnittstelle.
Nach erfolgreicher Suche des geeigneten Web Service fordert der Nutzer das WSDL-
Dokument an. Dazu liefert das Verzeichnis eine Referenz auf das WSDL-Dokument. Zum
Schluss liefert der Servicenutzer dem Serviceanbieter den Web Service, nachdem eine
Abfrage erfolgte.
Die in der Abb. 1 beschriebene Sicht der SOA wird durch folgende Techniken des Web
Services ermöglicht (Melzer et al. 2010, 63; Krcmar 2011, 184-185):
SOAP ist ein Netzwerkprotokoll das zum Austausch von XML basierten Nachrichten
zwischen Applikationen eingesetzt wird. Zum Senden der Nachricht kann jedes
beliebige Transportprotokoll, wie beispielsweise HTTP, FTP oder SMTP genutzt
werden.
WSDL ist eine auf XML basierende plattform- und protokollunabhängige
Beschreibungssprache, um Web Services zu beschreiben.
UDDI wird benötigt, um Web Services im Internet ausfindig zu machen. Es handelt
sich um ein standardisiertes Verzeichnis von Metadaten aller verfügbaren Web
Services im Repository.
Nachdem ein Blick auf die wesentlichen Eigenschaften, sowie die relevantesten Technologien
des Cloud Computing geworfen wurde, kann nun im Nachfolgenden, auf die in der Definition
von NIST beschriebenen, Service Modelle und Betriebsmodelle eingegangen werden.
1.3 Service- und Betriebsmodelle des Cloud Computing
Nach C. Bau et al. (2009, 27) kann die Betrachtung der Cloud-Architektur aus einer
organisatorischen und einer technischen Sicht erfolgen. Die organisatorische Sicht trennt die
organisatorischen Einheiten, gemeint sind Benutzer und Anbieter, voneinander. Diese Sicht
5
entspricht somit den Betriebsmodellen nach NIST. Daneben orientiert sich die technische
Sicht an den funktionalen Eigenschaften und entspricht somit den Service Modellen.
1.3.1 Betriebsmodelle
Wie bereits erwähnt existieren nach NIST vier verschiedene Betriebsmodelle die sich im
Wesentlichen in ihrer Zugangsform und der Einbettung in bestehende IT-Infrastrukturen
unterscheiden (Meinel et al. 2011, 28). Für den Zugriff und den Konsum von Services aus der
IaaS, PaaS und SaaS spielt die Art des Betriebsmodells keine Rolle.
Die Private Cloud ist für die Verwendung in nur einer einzigen Organisation gedacht. Die
Anwendung erfolgt beispielsweise in Unternehmen, die auf mehreren Standorten verteilt sind,
dessen Mitarbeiter aber gemeinsam auf eine zentrale IT-Komponente zugreifen (NIST 2011,
3). Das wichtigste Unterscheidungsmerkmal der Private Cloud ist hierbei, dass kein weiteres
Unternehmen auf die Services zugreift, wie dies beispielsweise in der Public Cloud der Fall
ist (PROZEUS 2011, 13). Der Zugriff auf die Services erfolgt üblicherweise über ein Intranet
oder einen VPN-Client (Meinel et al. 2011, 28). Für die Nutzung einer Private Cloud
sprechen vor allem vermutete Sicherheitsprobleme des Management im Bereich der
Datensicherheit, aber auch rechtliche Rahmenbedingungen die vom Unternehmen eingehalten
werden müssen (Metzger, Reitz, Villar 2011, 18).
Im Unterschied zur Private Cloud, gehören in der Public Cloud Anbieter und Kunden nicht
zu derselben organisatorischen Einheit an (Baun et al. 2011, 27; PROZEUS 2011, 13). Public
Clouds stehen der ganzen Öffentlichkeit frei zur Verfügung und können somit von beliebigen
Personen, öffentlichen Einrichtungen oder Unternehmen genutzt werden (Metzger, Reitz,
Villar 2011, 19; NIST 2011, 3). Der Zugriff auf die Services erfolgt üblicherweise über das
Internet, wobei die Nutzer in Eigenregie die gewünschten Leistungsumfänge
zusammenstellen können (Baun et al. 2011, 27-28; Meinel 2011, 28; BMWi 2010, 12). Dabei
teilen sich meist mehrere Nutzer eine virtuelle Infrastruktur, ohne eine Kenntnisnahme von
anderen Nutzern zu erlangen (PROZEUS 2011, 13).
Werden die beiden zuvor betrachteten Ansätze kombiniert, entsteht eine dritte Kategorie, die
sog. Hybrid Cloud. Bei dieser Art von Betriebsmodell findet eine kombinierte Nutzung von
Private- und Public Cloud Services statt. Der reguläre Betrieb erfolgt dabei meist im eigenen
Unternehmen, in einer Private Cloud. Bei gelegentlichen, auftretenden, Lastspitzen können
weitere Leistungen in der Public Cloud bezogen werden (Meinel et al. 2011, 28; PROZEUS
2011, 13; BMWi 2010, 12). Ein anderer Zweck, der für den Einsatz einer Hybrid Cloud
spricht, ist im Zusammenhang mit unternehmenskritischen Daten und Datensicherheit
einzuordnen. Unternehmenskritische Daten sowie Funktionen werden in einer Privat Cloud
belassen und unkritische Daten und Funktionen wiederum werden in eine Public Cloud
ausgelagert (Metzger, Reitz, Villar 2011, 19-20; Baun et al. 2011, 29). Um eine reibungslose
Interaktion zwischen einer Private-, und Public Cloud zu ermöglichen, müssen Schnittstellen
6
auf allen Ebenen so integriert werden, dass eine heterogene Landschaft, für den Nutzer
homogen erscheint. (NIST 2011, 3; Terplan, Voigt 2011, 40).
Verbinden oder nutzen mehrere Organisationen, wie beispielsweise Unternehmen ihre Private
Clouds oder Service gemeinsam, so spricht man von einer Community Cloud. Dabei können
es Unternehmen des gleichen Landes, der gleichen Branche oder des gleichen Mutterkonzern
sein. Die Services stehen einem eingeschränkten Nutzerkreis zur Verfügung und zwar den
Mitgliedern, die ihre Services gemeinsam nutzen. Betrieben und verwaltet können die
Services, entweder von den Mitgliedern der Community Cloud oder von einem externen
Anbieter (NIST 2011, 3; Terplan, Voigt 2011, 37). Hierdurch können, durch die geringeren
Skalenerträge, zwar nicht die gleichen Kosteneinsparungen wie bei einer Public Cloud
realisiert werden, ökonomische Vorteile werden trotzdem realisiert (Metzger, Reitz, Villar
2011, 19).
In Abb. 2 werden noch einmal die generellen Unterschiede zwischen den einzelnen
Betriebsmodellen aufgezeigt. Public Clouds stehen weltweit jedem offen zur Verfügung. Bei
Private Clouds ist der Zugang beschränkt, oft findet der Zugang nur von einem Unternehmen
aus statt. Bei der Hybrid Cloud handelt es sich um eine Verbindung zwischen einer Public-,
und einer Private Cloud. Jedes Unternehmen muss für sich die Vor- und Nachteile abwägen
und dann das für sich passende Betriebsmodell auswählen, nach denen die Cloud Umgebung
und die Services betrieben und bezogen werden sollen.
1.3.2 Service Modelle
Die unzählig heterogen existierenden Cloud Services lassen sich nach ihrer Art klassifizieren
und in ein hierarchisches 3 Schichten Modell
6
einordnen, siehe Abb. 3 Dabei können Services
einer höheren, abstrakteren Schicht auf die Services der tieferen Schicht zugreifen und für
ihre eigene Servicerealisierung nutzen (Meinel et al. 2011, 30; Baun et al. 2011, 29-30).
6
In der Literatur tauchen oft weitere Modelle auf, wie z.B. Everything as a Service( XaaS) oder Business as a
Service (BaaS) auf die hier aber nicht näher eingegangen wird.
7
Infrastructure as a Service ermöglicht die Bereitstellung von IT-Infrastrukturen als
virtuelle, frei skalierbare Ressourcen. Bei diesen Ressourcen kann es sich beispielsweise um
Server, Router, Hardware, Archivierungs- und Backup Systeme handeln. Die eben genannten
Ressourcen werden als standardisierte, virtuelle Services über ein Netzwerk bereitgestellt und
bezogen (Metzger, Reitz, Villar 2011, 21; NIST 2011, 3; Meinel et al. 2011, 30). Um die
Ressourcen logisch zu ordnen, erhalten die Nutzer eine abstrakte Sicht. Die Verrechnung der
Services erfolgt nutzungsabhängig, diese kann sich an Datenvolumen, Speichergröße oder
auch Zeiteinheiten orientieren (Baun et al. 2011, 31-32; PROZEUS 2011, 12; Terplan, Voigt
2011, 25).
Platform as a Service richtet sich vornehmlich an Anwendungsentwickler und
Systemarchitekten und ist weiter gefasst, als die einfache Bereitstellung einer Software. Als
Service wird nicht nur eine Standardsoftware angeboten, sondern eine ganze
Entwicklungsumgebung mit Anwendungen wie Middleware, Datenbanken und anderen
Entwicklungstools (PROZEUS 2011, 11; Metzger, Reitz, Villar 2011, 21; Terplan, Voigt
2011, 26). Ein Nutzer greift auf die Komponenten der Plattform zu. Dadurch kann er sich
ganz auf die Entwicklung und Bereitstellung von Anwendungen konzentrieren und muss sich
nicht mit der zugrunde liegenden Infrastruktur befassen (NIST 2011, 2-3).
Software as a Service richtet sich, im Gegensatz zu PaaS, an die Endanwender. Das Konzept
besteht darin, eine bestimmte Softwareanwendung nicht mehr auf jedem Rechner, an dem sie
genutzt werden soll, zu installieren (Metzger, Reitz, Villar 2011, 21). Der Anbieter stellt
einzelne Anwendungen als standardisierte Services zur Verfügung und ist auch für deren
Administration, Wartung und den Betrieb zuständig (Meinel et al. 2011, 34; BMWi 2010, 11).
Die Nutzer beziehen die Services über ein Netzwerk aus verschiedenen Geräten heraus, über
einen Web-Browser oder eine Programm-Schnittstelle. Für die Nutzer entfallen somit die
lokalen Installationen der Software und die Bereitstellung der dafür erforderlichen Ressourcen
(NIST 2011, 2; PROZEUS 2011, 9).
8