mirror of
https://gitlab.com/ser-cal/m346.git
synced 2024-11-24 22:51:57 +01:00
KN01 README.md eingefügt
This commit is contained in:
Marcello Calisto
parent
9c9632ac1c
commit
70815d4906
93
KN01/README.md
Normal file
93
KN01/README.md
Normal file
@ -0,0 +1,93 @@
|
||||
[10]: https://git-scm.com/downloads
|
||||
|
||||
|
||||
|
||||
# KN01 Inhaltsverzeichnis
|
||||
|
||||
[TOC]
|
||||
|
||||
<br>
|
||||
|
||||
## Lernziele
|
||||
|
||||
- **Kompetenzband A**: Anforderungen analysieren (Handlungsziele 1,2)
|
||||
- **Kompetenzband C**: Aufwände schätzen (Handlungsziel 1)
|
||||
|
||||
<br>
|
||||
|
||||
## Aufgaben
|
||||
|
||||
### A) Erkunden von AWS On-Demand Pricing und Instanzvergleich in der Management Console
|
||||
|
||||
In dieser Übung werden Sie die AWS Management Console verwenden, um das On-Demand Pricing-Modell von Amazon EC2 kennenzulernen. Sie werden einen Vergleich zwischen den Instanztypen **t2.micro** und **m4.xlarge** für einen Monat durchführen
|
||||
|
||||
|
||||
### B) Evaluation Cloud-Migration für ein Unternehmen mit 50 Mitarbeitern (Einstiegsübung)
|
||||
|
||||
**Ausgangslage:**
|
||||
Ihr Unternehmen mit 50 Mitarbeitern betreibt aktuell die IT on-premises. Die monatlichen IT-Kosten setzen sich aus verschiedenen Faktoren zusammen, darunter ein NAS-Speicher von **20 TB**. Sie sollen herausfinden, ob eine Migration zur AWS-Cloud wirtschaftlich sinnvoll wäre. Diese Übung beschränkt sich nur auf die Services **EC2** und **S3** als Einstieg.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Virtualisierung
|
||||
|
||||
- Sie können den Begriff der "Virtualisierung" erläutern.
|
||||
- Sie können grob erklären welche Rolle ein "[Hypervisor](https://www.redhat.com/en/topics/virtualization/what-is-a-hypervisor)" in der Virtualisierung spielt.
|
||||
- Sie kennen den Unterschied zwischen Typ 1 und Typ 2 Hypervisors und können den auch erklären.
|
||||
- Sie können den Begriff "[Hyperscaler](https://www.redhat.com/en/topics/virtualization/what-is-a-hypervisor)" erklären im Zusammenhang mit Cloud-Systemen.
|
||||
- Sie kennen Schichten von Cloud-Systemen.
|
||||
|
||||
<br>
|
||||
|
||||
## Betriebsmodelle
|
||||
- Sie kennen die drei Betriebsmodelle und können Sie erklären.
|
||||
- Sie kennen die Unterteilung zwischen Public und Private Cloud und können Sie erklären.
|
||||
- Sie können Beispiele zu den Betriebsmodellen nennen (mit Hilfe der unter verlinkten Ressource und des Internets).<br>
|
||||
|
||||
 [Ressource](./x_res/Betriebsmodelle.md)
|
||||
|
||||
<br>
|
||||
|
||||
## Servicemodelle
|
||||
|
||||
- Sie kennen die vier Servicemodelle und können Sie erklären.
|
||||
- Sie wissen welches Servicemodell auf einem anderen aufbaut (z.B. PaaS auf IaaS).
|
||||
- Sie können Beispielprodukte für die Servicemodelle nennen (mit Hilfe der unter verlinkten Ressource und des Internets).<br>
|
||||
|
||||
 [Ressource](./x_res/Servicemodelle.md)
|
||||
|
||||
<br>
|
||||
|
||||
## (Cloud-) Migrationsmodelle
|
||||
|
||||
- Sie kennen die Begriffe der Migrationsmodellen.
|
||||
- Sie kennen die Zielplattform der Migrationsmodellen.
|
||||
- Bei einem gegebenen Szenario können Sie für ein Migrationsmodell argumentieren.
|
||||
|
||||
<br>
|
||||
|
||||
## Speichermodelle
|
||||
|
||||
- Sie kennen die vier Speichermodelle
|
||||
- Sie wissen für welchen Einsatz die Speichermodelle sinnvoll Verwendung finden.
|
||||
- Sie können Beispiele zur Benutzung der Speichermodelle geben.
|
||||
- Sie kennen den Unterschied zwischen persistentem und flüchtigem Speicher und können diesen erklären, speziell im Zusammenhang mit virtuellen Instanzen.
|
||||
- Sie kennen den Unterschied der Lese- und Schreibgeschwindigkeiten der Speichermodelle.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
> [⇧ **Zurück zur Hauptseite**](https://gitlab.com/ser-cal/M346)
|
||||
|
||||
---
|
||||
|
||||
149
KN01/x_res/Betriebsmodelle.md
Normal file
149
KN01/x_res/Betriebsmodelle.md
Normal file
@ -0,0 +1,149 @@
|
||||
[10]: https://git-scm.com/downloads
|
||||
|
||||
|
||||
|
||||
# Betriebsmodelle
|
||||
|
||||
|
||||
[TOC]
|
||||
|
||||
<br>
|
||||
|
||||
## On-Premises, in die Cloud oder doch hybrid?
|
||||
|
||||
Die erste Frage, die uns Unternehmen stellen, wenn es um eine Neu- und
|
||||
Umstrukturierung ihrer IT-Landschaft geht, ist, welches Bereitstellungsmodell
|
||||
sich am besten für sie eignet. Klassisch im eigenen Rechenzentrum On-Premises,
|
||||
ausgelagert in der Cloud oder eher als hybrides Modell? Nun – das kommt darauf
|
||||
an: Welche Anforderungen Sie erfüllen müssen, wie viel Kapital Sie investieren
|
||||
möchten und wie flexibel Sie bei der Skalierung Ihrer Lizenz- und
|
||||
Geschäftsmodelle bleiben möchten.
|
||||
|
||||
Wir stellen Ihnen die verschiedenen Bereitstellungsodelle mit ihren Vor- und
|
||||
Nachteilen vor.
|
||||
|
||||
### On-Premises
|
||||
|
||||
Setzt ein Unternehmen beim Lizenz- und Nutzungsmodell für serverbasierte
|
||||
Software bzw. Computerprogramme auf eine Installation in der eigenen
|
||||
IT-Umgebung, so spricht man von einer On-Premises-Nutzung. Das bedeutet, dass
|
||||
die Verantwortung für Betrieb und Wartung der Software allein beim Lizenznehmer
|
||||
liegt. Dies hat den Vorteil, dass dieser maximale Kontrolle über alle Daten und
|
||||
Zugriffe hat. On-Premises ist das klassische Bereitstellungsmodell, jedoch
|
||||
verliert es in Zeiten von Cloud-Computing und zunehmender Flexibiltät von
|
||||
Märkten und Geschäftsmodellen zunehmend an Bedeutung. Dennoch kann es besonders
|
||||
für Unternehmen, die hohe Datenschutzanforderungen erfüllen müssen, durchaus
|
||||
Vorteile haben.
|
||||
|
||||
#### Vorteile
|
||||
- Maximale Kontrolle über Ihre Daten und Zugriffe
|
||||
- Erfüllung europäischer Datenschutzanforderungen
|
||||
- Einmalige Kosten zur Lizenzierung von Softwareprodukten
|
||||
- Unabhängigkeit von externen Dienstleistern und Lizenzanbietern
|
||||
- Zugriff auf Anwendungen auch ohne Internet gewährleistet
|
||||
- Tiefe Integration in die eigene Infrastruktur
|
||||
|
||||
#### Nachteile
|
||||
- Hohe Ausgaben für Hardware, Wartung und Sicherheit
|
||||
- Hoher zeitlicher und technischer Aufwand für Aktualisierungen, Updates und
|
||||
Backups binden Ressourcen
|
||||
- Laufende Kosten für Software-Updates, Support und ggf. Nachlizenzierungen
|
||||
- Fehlender Support nach Auslauf von Update-Zyklen
|
||||
- Nicht flexibel skalierbar
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
### Private Cloud
|
||||
Eine Private Cloud kann – muss aber nicht – ebenfalls im eigenen Rechenzentrum
|
||||
gehostet werden. Sie unterscheidet sich jedoch dahingehend von einer
|
||||
On-Premises-Nutzung, dass die Software nicht fest auf den eigenen Rechnern
|
||||
installiert ist, sondern durch Cloud-Dienste im Mietmodell bezogen wird. Hierbei
|
||||
ist jedoch entscheidend, dass nur Ihr Unternehmen auf die Ressourcen (Server,
|
||||
Hardware usw.) der gemieteten oder selbstgehosteten Private Cloud Zugriff hat.
|
||||
Die Private Cloud verbindet daher die hohe Sicherheit einer On-Premises-Lösung
|
||||
mit der hohen Skalierbarkeit einer Cloudlösung.
|
||||
|
||||
#### Vorteile
|
||||
- Individuell an Ihr Unternehmen anpassbar
|
||||
- Infrastrukturkapazitäten können flexibel angepasst werden
|
||||
- Hohe Sicherheit
|
||||
- Cloud Features zur hohen Skalierbarkeit
|
||||
|
||||
#### Nachteile:
|
||||
- Bei eigenem Hosting Verwaltungsaufwand vergleichbar mit On-Premise-Nutzung
|
||||
der Systeme
|
||||
- Bei Fremdhosting zumeist teuerer als die Public Cloud
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
### Public Cloud
|
||||
Mit der Public Cloud werden IT-Services über das Internet bereitsgestellt.
|
||||
Firmen können Ressourcen dieser öffentlichen Cloud mieten und auf diesen ihre
|
||||
Anwendungen betreiben. Die Verwaltung und Wartung liegt bei dem Betreiber der
|
||||
Cloud. Dies hat den Vorteil, dass Unternehmen bedarfsgerecht skalieren und so
|
||||
kosteneffizient ihre IT betreiben können. Gleichzeitig profitieren sie von dem
|
||||
Sicherheits-Know-how der Cloudanbieter und müssen sich nicht selbständig um die
|
||||
Sicherheit der eigenen Systeme kümmern.
|
||||
|
||||
#### Vorteile
|
||||
|
||||
- Abonnement-Service kann bedarfsgerecht angepasst werden, sodass Lizenzen
|
||||
jederzeit skaliert werden können
|
||||
- Reduzierung der eigenen Hardware-Ausgaben
|
||||
- Freisetzung interner Ressourcen, da Wartung, Support und Sicherheit der
|
||||
Hardwarekomponenten beim Cloud-Anbieter liegt
|
||||
|
||||
#### Nachteile
|
||||
|
||||
- Keine freie Anbieterwahl, da nicht alle ein DSGVO-konformes Hosting
|
||||
ermöglichen
|
||||
- Verbindung über das öffentliche Internet eröffnet prinzipelle
|
||||
Sicherheitsrisiken
|
||||
- Erreichbarkeit oder Leistung von Cloud-Dienste können durch gemeinsame
|
||||
Nutzung derselbe physische Maschine mit anderen eingeschränkt werden
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
### Hybrid Cloud
|
||||
|
||||
Die Hybrid Cloud verbindet die Vorteile von On-Premise bzw. Private
|
||||
Cloud-Nutzung und Public Cloud: Unternehmen entscheiden sich hierbei, bestimmte
|
||||
Anwendungen auf eigenen Rechnern zu betreiben, andere jedoch in die Public Cloud
|
||||
auszulagern, um Kosten zu sparen. So haben sie volle Kontrolle über sensible
|
||||
Daten, die im eigenen Rechenzentrum liegen, bei gleichzeitig höchster
|
||||
Skalierbarkeit einer Public Cloud-Nutzung.
|
||||
|
||||
#### Vorteile
|
||||
- Flexibel skalierbar, bedarfsgerecht anpassbar
|
||||
- Spart Ressourcen bei Wartung und Sicherheit
|
||||
- Oft günstiger als reine Public Cloud
|
||||
- Sicherheit für sensible Daten und kritische Anwendungen durch Nutzung von
|
||||
On-Premise bzw. Private Cloud-Strukturen.
|
||||
|
||||
#### Nachteile
|
||||
|
||||
- Zusätzlicher Aufwand
|
||||
- Sicherheit kann nur durch klare Regeln garantiert werden
|
||||
|
||||
Welche Form der Bereitstellung letztlich die passendste ist, hängt ganz von den
|
||||
individuellen Bedürfnissen eines Unternehmens ab.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
> [⇧ **Zurück zu KN00**](../README.md)
|
||||
|
||||
---
|
||||
|
||||
> [⇧ **Zurück zur Hauptseite**](https://gitlab.com/ser-cal/M346)
|
||||
|
||||
---
|
||||
|
||||
265
KN01/x_res/Servicemodelle.md
Normal file
265
KN01/x_res/Servicemodelle.md
Normal file
@ -0,0 +1,265 @@
|
||||
[10]: https://git-scm.com/downloads
|
||||
|
||||
|
||||
|
||||
# Servicemodelle
|
||||
|
||||
|
||||
[TOC]
|
||||
|
||||
<br>
|
||||
|
||||
## Servicemodelle in der Cloud
|
||||
|
||||
Der Begriff **Cloud** ist längst in die Alltagssprache eingezogen, doch die
|
||||
wenigsten können im Detail erklären, was genau damit gemeint ist.
|
||||
|
||||
Das US-amerikanische **National Institute of Standards and Technology** (NIST) hat
|
||||
eine [**Definition**](https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp) geschaffen, was unter **Cloud** zu verstehen ist. Darin sind unter anderem **vier Servicemodelle** beschrieben, die sich unter dem Begriff **XaaS** zusammenfassen lassen, was üblicherweise als **Anything as a Service** gelesen wird.
|
||||
|
||||
|
||||
Die Cloud-Service-Modelle IaaS, PaaS und SaaS einfach erklärt anhand des Pizza-Prinzips"
|
||||
|
||||
### Das Pizza-Prinzip
|
||||
Um die Cloud-Service-Modelle **IaaS**, **PaaS** und **SaaS** besser zu verstehen, hier ein Vergleich mit einem Beispiel aus dem Alltag:
|
||||
|
||||
Cloud-Service-Modelle | Pizza as a Service
|
||||
:-------------------------:|:-------------------------:
|
||||
 | 
|
||||
|
||||
|
||||
**IaaS (Infrastructure as a Service):**<br>
|
||||
IaaS ist wie der Kauf von Zutaten für eine Pizza im Supermarkt und das Backen zu Hause. Sie haben die Kontrolle über die Zubereitung, aber müssen sich um die gesamte Vorbereitung selbst kümmern.<br>
|
||||
|
||||
**PaaS (Platform as a Service):**<br>
|
||||
PaaS entspricht dem Erhalt eines vorgefertigten Teigs und einer Auswahl von Belägen in einem Pizzarestaurant. Sie gestalten Ihre Pizza, ohne sich um die Basis oder Infrastruktur zu kümmern.<br>
|
||||
|
||||
**SaaS (Software as a Service):**<br>
|
||||
SaaS ist wie das Bestellen einer fertigen Pizza bei einem Lieferdienst. Sie nutzen die Anwendung, ohne sich um die Details der Installation oder Wartung kümmern zu müssen.<br>
|
||||
|
||||
**Zusammenfassung:**<br>
|
||||
IaaS, PaaS und SaaS bieten verschiedene Ebenen der Kontrolle, ähnlich der Wahl zwischen selbstgemachter Pizza, individueller Gestaltung oder sofortiger Nutzung.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
### Infrastructure as a Service (IaaS)
|
||||
|
||||
Das erste dieser Servicemodelle ist **Infrastructure as a Service** (IaaS). Es
|
||||
beschreibt das Geschäftsmodell, Infrastruktur zu vermieten, statt sie zu
|
||||
verkaufen. Für viele Unternehmen rechnet sich der Betrieb eigener Hardware in
|
||||
einem eigenen Rechenzentrum nämlich nicht, da das teuer und aufwendig ist und
|
||||
dafür in der Regel ein eigenes Team benötigt wird.
|
||||
|
||||
Anders als beim Webhosting in den 90er-Jahren geht es bei IaaS aber nicht mehr
|
||||
darum, Hardware physisch zu buchen, denn auch das ist langsam, aufwendig,
|
||||
umständlich und schlecht skalierbar. Stattdessen werden Server als virtuelle
|
||||
Maschinen angeboten und um andere virtualisierte Ressourcen ergänzt,
|
||||
beispielsweise virtuelle Netzwerke. Die gesamte Infrastruktur wird also
|
||||
softwaredefiniert bereitgestellt.
|
||||
|
||||
Weil das softwaredefiniert erfolgt, lässt sich Infrastruktur auch automatisiert
|
||||
und "on demand" per API aufsetzen. Die Abrechnung erfolgt dabei als
|
||||
Pay-per-Use-Modell, auf lange Vertragslaufzeiten wird verzichtet.
|
||||
|
||||
Bekannt ist dieses Modell unter anderem von Amazon, die mit AWS (Amazon Web
|
||||
Services) einen Dienst anbieten, über den sich Ressourcen aus den Rechenzentren
|
||||
von Amazon buchen lassen. Aber auch andere Anbieter bedienen diesen Markt,
|
||||
beispielsweise Digital Ocean, Microsoft Azure oder die Google Cloud Platform.
|
||||
|
||||
Insgesamt lässt sich sagen, dass IaaS damit die Grundlage für die Cloud
|
||||
darstellt, die sich nun aber in verschiedenen Schritten nach und nach
|
||||
abstrahieren lässt.
|
||||
|
||||
<br>
|
||||
|
||||
 6:39 Min.
|
||||
[](https://youtu.be/I7Oyr_SVJEA)
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
|
||||
### Platform as a Service (PaaS)
|
||||
|
||||
Auch wenn sich IaaS nicht mehr mit physischer Hardware befasst, ist das
|
||||
Servicemodell immer noch weit weg von der Anwendungsentwicklung. In der
|
||||
Entwicklung will man sich nicht zwingend mit Servern, Storage, Load-Balancing &
|
||||
Co. beschäftigen, sondern eher auf der Ebene des Betriebssystems und einer
|
||||
Laufzeitumgebung wie Node.js oder .NET Core arbeiten.
|
||||
|
||||
Genau das adressiert Platform as a Service (PaaS), was letzten Endes eine
|
||||
fertige Softwareumgebung zur Verfügung stellt, auf deren Basis man Anwendungen
|
||||
entwickeln und vor allem ausführen kann. Die Idee dabei ist, sich nicht mehr um
|
||||
die zugrunde liegende Hardware und das Deployment kümmern zu müssen. Auch das
|
||||
Einspielen von Updates für das Betriebssystem oder die Laufzeitumgebung
|
||||
entfällt. Um all diese Aspekte kümmert sich der PaaS-Anbieter.
|
||||
|
||||
Dadurch lässt sich der Fokus auf die eigentliche Anwendungsentwicklung legen,
|
||||
die Bereitstellung erfolgt anschließend automatisiert und transparent. Man legt
|
||||
nur noch fest, auf welcher Plattform die eigene Anwendung laufen soll, muss sich
|
||||
aber nicht mehr um das "wie" der Bereitstellung kümmern. Auch Aspekte wie
|
||||
Storage oder Netzwerk sind abstrahiert und können über APIs angesprochen werden.
|
||||
|
||||
Häufig werden darüber hinaus ergänzende Dienste wie Datenbanken oder Message
|
||||
Queues, die für die Anwendungsentwicklung unerlässlich sind, als Service
|
||||
bereitgestellt. Auch PaaS-Angebote lassen sich über APIs ansteuern, und auch
|
||||
hier erfolgt die Abrechnung On-Demand und als Pay-per-Use.
|
||||
|
||||
Einer der bekanntesten Anbieter in diesem Bereich ist Heroku, es gibt aber wie
|
||||
bei IaaS auch noch zahlreiche weitere Anbieter. Da PaaS auf IaaS basiert, sind
|
||||
häufig die Anbieter von IaaS auch im PaaS-Markt aktiv, beispielsweise Amazon mit
|
||||
AWS Elastic Beanstalk. Damit Anwendungen mit PaaS zusammenpassen, müssen sie
|
||||
allerdings einige Aspekte erfüllen, beispielsweise sollten die [Regeln der 12
|
||||
Factor Apps](https://www.youtube.com/watch?v=UBh8Rp2secQ) berücksichtigt werden.
|
||||
|
||||
<br>
|
||||
|
||||
 5:12 Min.
|
||||
[](https://youtu.be/YqaLnqtj5So)
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
|
||||
### Software as a Service (SaaS)
|
||||
|
||||
Das dritte Servicemodell, Software as a Service (SaaS), beschreibt schließlich
|
||||
die Bereitstellung vollständiger Anwendungen über die Cloud. Als UI wird häufig
|
||||
der Webbrowser genutzt, in nahezu jedem Fall gibt es auch bei SaaS wiederum
|
||||
APIs, über die sich die Anwendungen anbinden und integrieren lassen. Typische
|
||||
Beispiele für Cloud-Software sind unter anderem Office 365, Slack, Dropbox oder
|
||||
auch GitHub.
|
||||
|
||||
Analog zu IaaS und PaaS wird auch bei SaaS die Vermietung als Geschäftsmodell
|
||||
angestrebt: Software wird also nicht mehr gekauft, sondern im Abonnement
|
||||
erworben, wobei in aller Regel pro Anwenderin beziehungsweise pro Anwender
|
||||
monatlich abgerechnet wird.
|
||||
|
||||
Das bietet eine ganze Reihe von Vorteilen, beispielsweise Einfachheit und
|
||||
Flexibilität. Aufwendige und fehleranfällige Vorgänge wie Installation,
|
||||
Konfiguration, das Einspielen von Updates und Sicherheitspatches, oder die
|
||||
Skalierbarkeit entfallen, beziehungsweise werden vollständig in die Hände des
|
||||
Anbieters gelegt. Das ermöglicht es, sich stärker auf das eigene Kerngeschäft zu
|
||||
konzentrieren.
|
||||
|
||||
SaaS hat aber auch Nachteile, allen voran die Abhängigkeit von einem Anbieter
|
||||
(Vendor-Lock-In) und die in aller Regel geringe Anpassbarkeit der Software an
|
||||
die eigenen Bedürfnisse. Um den Vendor-Lock-In zu vermeiden, sind die Verwendung
|
||||
offener Standards und offener Formate essenziell wichtig. Außerdem ist bei SaaS
|
||||
mehr noch als bei IaaS und PaaS der Datenschutz zu beachten, es gilt also, sich
|
||||
mit Themen wie der DSGVO besonders gründlich auseinanderzusetzen.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
 5:00 Min.
|
||||
[](https://youtu.be/olZqZuCXC14)
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
|
||||
### Function as a Service (FaaS)
|
||||
|
||||
Bei Function as a Service (FaaS) wird nochmals eine Abstraktionsschicht
|
||||
eingezogen. Die Infrastruktur, das Betriebssystem, die Laufzeitumgebung und
|
||||
sogar die eigentliche Anwendung sind bereits gegeben – es gilt, nur noch die
|
||||
Geschäftslogik zu ergänzen, quasi als eine Art "Plug-in". Das erfolgt in Form
|
||||
von einzelnen Funktionen, die in einen fertigen Anwendungsrahmen eingebunden
|
||||
werden, beispielsweise als Route in einen vorgefertigten Webserver.
|
||||
|
||||
Als Entwicklerin oder Entwickler muss man sich dann nur noch mit dem Schreiben
|
||||
ebendieser Route beziehungsweise der Funktion befassen, alles andere wird vom
|
||||
Cloud-Anbieter bereitgestellt und kann über APIs angesprochen werden. Da diese
|
||||
Funktionen üblicherweise zustandslos sind, lassen sie sich leicht skalieren.
|
||||
|
||||
Außerdem können sie sehr kostengünstig betrieben werden, da kein dedizierter
|
||||
Server vorgehalten werden muss: Die Funktion wird nach Aufrufen abgerechnet.
|
||||
Finden keine Aufrufe statt, fallen auch keine Kosten an. Das macht FaaS für
|
||||
viele Szenarien zu einer günstigen Alternative, zudem lassen sich die Funktionen
|
||||
auf Grund ihrer einfachen Struktur auch leicht warten und aktualisieren.
|
||||
|
||||
Weil man mit dem eigentlichen Server in diesem Fall nicht mehr in Berührung
|
||||
kommt, hat sich für FaaS auch der Begriff Serverless eingebürgert, was aber
|
||||
letzten Endes falsch ist, da dieser Begriff impliziert, dass es keinen Server
|
||||
mehr gäbe – dem ist aber selbstverständlich nicht so.
|
||||
|
||||
Verwendet wird FaaS häufig, um Anwendungen miteinander zu verbinden, oder als
|
||||
einfaches Backend für Single-Page-Anwendungen (SPA). Bekannte Angebote hierfür
|
||||
sind beispielsweise AWS Lambda von Amazon und Azure Functions von Microsoft. Der
|
||||
größte Nachteil ist auch hier wieder der Vendor-Lock-In, was nochmals die
|
||||
Relevanz von offenen Formaten und offenen Standards unterstreicht.
|
||||
|
||||
<br>
|
||||
|
||||
 5:53 Min.
|
||||
[](https://youtu.be/SR4GhA2sKIU)
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
### X as a Service (XaaS)
|
||||
|
||||
Selbstverständlich ist über diese vier vom NIST definierten Servicemodelle noch
|
||||
mehr möglich. Dementsprechend haben sich zahlreiche Angebote entwickelt, die
|
||||
sich nicht klar einer der vier zuvor genannten Varianten zuordnen lassen. Dabei
|
||||
handelt es sich häufig um Aspekte, die orthogonal zur eigentlichen
|
||||
Anwendungsentwicklung stehen und somit Cross-Cutting-Concerns darstellen,
|
||||
beispielsweise das Bereitstellen von Datenbanken (DBaaS) oder Message-Queues
|
||||
(MQaaS).
|
||||
|
||||
Doch neben produktbezogenen Angeboten gibt es auch servicebasierte Angebote, die
|
||||
einen bestimmten Funktionsbereich übernehmen, zum Beispiel Identity as a
|
||||
Service, Logging as a Service oder Content as a Service. Die Grenze zu SaaS ist
|
||||
dabei allerdings fließend. Eine Hilfe zur Einordnung könnte sein, dass sich
|
||||
diese Angebote eher an Entwicklerinnen und Entwickler richten, wohingegen
|
||||
"echtes" SaaS eher auf nicht in der Entwicklung tätige Anwenderinnen und
|
||||
Anwender abzielt.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
 6:13 Min.
|
||||
[](https://youtu.be/svIDbHriack)
|
||||
|
||||
<br>
|
||||
|
||||
-------
|
||||
|
||||
|
||||
## Fazit
|
||||
|
||||
Die Cloud hat die Art, wie Software entwickelt und vor allem bereitgestellt
|
||||
wird, in den vergangenen zehn Jahren gravierend verändert. Trotzdem hat sie die
|
||||
lokale Ausführung von Software nicht überflüssig gemacht. Es ist daher kein
|
||||
"entweder oder", sondern vielmehr ein "sowohl als auch". Es ist also ratsam, die
|
||||
Cloud als Erweiterung des bisherigen Werkzeugkastens zu sehen und nicht als
|
||||
Ersatz.
|
||||
|
||||
Dabei ist allerdings zu beachten, dass – wie mehrfach betont – offene Formate
|
||||
und offene Standards essenziell sind, um einen Vendor-Lock-In zu vermeiden. Nur
|
||||
wer unabhängig vom jeweiligen Cloud-Anbieter denkt und Lösungen entwickelt, die
|
||||
unabhängig von einem konkreten Angebot funktionieren, behält sich langfristig
|
||||
die Möglichkeit bei, zwischen verschiedenen Anbietern wechseln zu können
|
||||
|
||||
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
> [⇧ **Zurück zu KN00**](../README.md)
|
||||
|
||||
---
|
||||
|
||||
> [⇧ **Zurück zur Hauptseite**](https://gitlab.com/ser-cal/M346)
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user