Webservices der Cloud-Anbieter

Niemand vergisst jemals seinen ersten Besuch in einem klassischen Serverraum. Dass es dort einige Computer, reichlich Router und unzählige Netzwerkkabel zu finden gibt, war mir klar. Nicht aber, was sonst noch alles für den zuverlässigen Betrieb „vor Ort“ („on premise“) nötig ist: Grundsolide, oft überfüllte Racks und Schränke, Back-up- und Speichersysteme, Überwachungsterminals, unterbrechungsfreie Stromversorgung.

Mit dem Lärm der Klimaanlage, den unzähligen blinkenden Lichtern und der peniblen Sauberkeit war jedem sofort klar: Dieser Ort ist kompromisslos geschützt. Vom zuverlässigen Betrieb und Back-ups hing und hängt die Arbeitsfähigkeit des Unternehmens ab. Ein Brand oder Wassereinbruch würde Wochen bis Monate für den Wiederaufbau bedeuten.

Serverräume im Unternehmen gibt es heute weiterhin. Vieles daraus ist jedoch oft in externe Data-Center ausgelagert. Sicherheitsaspekte, Platz und Kosten liefern hierfür die Gründe.

Die Cloud ist der nächste Schritt in diesem Mix aus „vor Ort“ und dezentralen Diensten. Etablierte Unternehmen erhoffen sich daraus dieselben Vorteile, die Start-ups (teils aus dem heimischen Wohnzimmer heraus) innerhalb von wenigen Minuten schöpfen. Entwicklungsteams gibt sie die Chance, Neues und Kopien von Bestehendem spontan und ohne größere finanzielle Verpflichtungen aufzusetzen.

verliere ich Geld. Ist er überlastet und fällt aus, passiert dasselbe. Ideal wäre es, wenn ich nur für das zahle, was ich auch nutze. Cloud-Anbieter nennen das „pay as you go“.

Hinzu kommt das Modell der „Verteilten Verantwortung“: Weiß ich als Unternehmen genau, wie ich einen Server aufsetze, betreibe, stets aktuell und abgesichert halte, kann ich diese Verantwortung selbst übernehmen. Fühle ich mich dabei unsicher, leistet der Cloud-Anbieter diese Funktion.

Der unterschiedliche Grad an Verantwortung erklärt, warum Cloud Anbieter häufig Hunderte von Services im Angebot haben. Die gute Nachricht: Zum Einstieg reicht oft die Kenntnis einiger weniger davon. Wir beleuchten diese am Beispiel von AWS.

Die Schlüssel zum virtuellen Serverraum (IAM)

Ein Unternehmen, das AWS nutzen will, legt einen Haupt-Account an. Darüber erhält es via Browser Zugang zur Management-Konsole. Sie bietet Zugriff auf alle AWS Services. Somit halte ich einen Generalschlüssel in meinen Händen.
Für die Aufgabenverteilung im Unternehmen sind weitere Schlüssel sinnvoll. Der AWS-Service, mit dem ich diese verwalte, heißt IAM (Identity & Access Management).
IAM katalogisiert meine Nutzer, ordnet diesen Gruppen zu und erteilt diesen dann über Richtlinien (Policies) ihre Rechte. Für viele Services stellt AWS vorgefertigte Standard-Richtlinien bereit.

Die Spielregeln dabei:

• Zum Start besitzen Nutzer keine Rechte.
• Die Richtlinien aller Gruppen, denen sie zugeordnet werden, kombinieren sich additiv.
• Einzelne Rechte kann ich ihnen danach über ein „DENY“ wieder wegnehmen.

IAM unterscheidet Zugriffstypen für den Zugang zur Konsole bis hin zur Nutzung von AWS-Services in eigenen Programmen.
Hinzu kommen Rollen mit gesonderten Berechtigungen. Nutzer nehmen diese temporär ein, um speziellen Aufgaben nachzugehen.

Der erste eigene Server in der Cloud (EC2)

Einer der populärsten AWS-Services ist EC2 (Elastic Compute Cloud). Mit ihm erstellen wir virtuelle Server. Ich wähle hierzu als AMI (Amazon Machine Image) das gewünschte Betriebssystem (sei es nun Linux, Windows oder macOS) aus, bestimme Größe und Leistung des Geräts und nehme rudimentäre Netzwerk-Einstellungen vor.
Nach Start der Instanz kann ich via SSH beliebige Arbeiten daran vornehmen und Software installieren (ganz so wie bei einem realen Server). Die Verantwortung für das Set-up, den Betrieb, Back-ups und Aktualisierungen liegt dabei vollständig bei mir.
EC2 ist damit extrem flexibel. Ich muss nur genau wissen, was ich tue. (Wir stellen später alternative Services vor, bei denen AWS einen größeren Teil der Verantwortung übernimmt.)

Dateien in der Cloud (EBS, EFS, S3)

EC2 Server Instanzen bringen ihren eigenen Plattenspeicherplatz und über EBS (Elastic Block Store) weitere Festplatten mit. Diese sind als HDD oder SDD konfigurierbar und können dynamisch erweitert werden.
Dateisysteme lassen sich auch unabhängig von Server-Instanzen anfordern. Hierbei spielen die Services EFS und S3 die Hauptrolle.
EFS (Elastic File System) kann in allen AWS Compute-Instanzen integriert werden (also auch in das später erwähnte AWS Lambda). Es skaliert dabei seine Größe vollautomatisch bis in den Petabyte-Bereich hinein. Ein Sonderfeature nennt sich Multi-Attach: Mehrere Compute-Instanzen können dabei das Dateisystem gemeinsam nutzen.
Noch einen Schritt weiter geht S3 (Simple Storage Service). Dieser Dienst setzt den Fokus auf Dateien beliebiger Art und Größe und kann von allen AWS-Services genutzt werden.
Ein spezifisches Dateisystem bietet S3 nicht. Ich erzeuge stattdessen sogenannte Buckets und lege in diesen Dateien und Ordner an. Buckets verfügen dabei über ein ausgefeiltes Berechtigungssystem.
Verschiedene S3 Speicher-Klassen erlauben es mir je nach Anforderung, Geld zu sparen: Müssen meine Dateien jederzeit schnellstmöglich verfügbar sein, kostet das viel. Kann ich (wie zum Beispiel bei Archiven) mit langsamerem Zugriff leben, zahle ich deutlich weniger. Kenne ich die Zugriffsmuster auf meinen Datenbestand nicht, hilft das S3 Feature Intelligent Tiering dabei, die passende Speicherklasse „Datei für Datei“ automatisch zu wählen. Meine Dokumente sind so stets kosteneffizient abgelegt.
S3 unterstützt auf Wunsch die Versionsverwaltung von Dateien, die Replikation von Buckets in andere Zonen der Welt, höchste Anforderungen an Datenschutz und Verschlüsselung und sogar das Hosting von statischen Webseiten.

Cloud Datenbanken (RDS, Aurora, DynamoDB)

Natürlich reichen Dateisysteme allein nicht zur Speicherung meiner Anwendungsdaten. Datenbanken sind hier mindestens genauso wichtig. Theoretisch kann ich dieses Thema durch das Aufsetzen einer EC2 Server Instanz lösen (die Datenbank-Software installiere und warte ich dann selbst), es geht jedoch auch deutlich einfacher.
RDS (Relational Database Service) deckt hierbei relationale Datenbanken wie MySQL, PostgreSQL, Oracle oder Microsoft SQL Server ab. Mit Aurora hat AWS zusätzlich eine eigene SQL-Variante am Start, die MySQL- und PostgreSQL-kompatibel ist und „serverless“ arbeiten kann. Der Vorteil: Der Datenbank Service läuft nicht die ganze Zeit, sondern nur, wenn er auch genutzt wird.
DynamoDB erschließt uns NoSQL Datenbanken. Hierbei ist die Struktur der Tabellen nicht fest: Einzelne Tabellenzeilen verfügen über einen Schlüssel (key) für den Zugriff und Attribute für den Wert (value).
AWS bietet eine Vielzahl weiterer Datenbank Services, die genannten sind für die meisten Aufgaben aber mehr als ausreichend.

Globale Netzwerke (Route 53, CloudFront)

Das Aufsetzen eines virtuellen Netzwerks mit Servern, Dateisystemen und Datenbanken stellt diese noch nicht zuverlässig erreichbar im Internet zur Verfügung. Hier wünschen wir uns den Zugriff über eigene Domainnamen und für den weltweiten Einsatz CDNs (Content Delivery Networks). Auch hierbei unterstützt AWS seine Kunden:

• Route 53 erlaubt es mir, Domains zu registrieren und zu verwalten.
• CloudFront erstellt und betreibt CDNs für mich.

Die Idee dabei: Meine Server-Instanzen sind vielleicht nur in einer oder wenigen Regionen der Welt aktiv. Ein CDN sorgt dafür, dass der Kunde genau mit der verbunden wird, die geografisch am nächsten zu ihm liegt. Es puffert obendrein Inhalte dieser Instanzen für die schnellere Auslieferung.

Serverless Computing (Lambda)

Die Aufstellung der wichtigsten AWS-Services für den Start wäre unvollständig ohne „Serverless Computing“ Dienste. Hier kommen die Vorteile des „pay as you go“ und die Übernahme von Server-Verantwortung durch AWS voll zum Tragen.
Bevor wir in die Services einsteigen, sollten wir über den Begriff „serverless“ sprechen. Wenn wir einen virtuellen Server in Form einer EC2 Instanz aufsetzen, betreuen wir fast alles selbst. Dabei treten Routine-Aufgaben auf, um die wir uns bei unserer Software-Entwicklung eigentlich gar nicht kümmern wollen.
Im „serverless“-Modell übernimmt der Cloud-Anbieter alle lästigen Standardaufgaben und wir konzentrieren uns rein auf den Code, der ausgeführt werden muss, wenn spezielle Ereignisse auftreten.
Ein Beispiel-Ereignis: Ein Benutzer lädt ein Dokument in unser Dateisystem hoch und wir möchten es verarbeiten.
An dieser Stelle setzt AWS Lambda an: Ich wähle eine Programmierumgebung (wie zum Beispiel node.js, Python, Java, …) und entwickle darin nur die Verarbeitung des Dokuments. In vielen Fällen reicht hierfür ein einfacher Codeschnipsel. Das Beste dabei: Kosten entstehen in Lambda rein abhängig von der Anzahl an Anrufen.
Das „serverless“-Modell hat gegenüber EC2 nur einen Nachteil: Es eignet sich rein für kurz laufende Prozesse, jedoch nicht für den Dauerbetrieb (wie beispielsweise eines Webservers). Der Schlüssel zum Erfolg mit AWS liegt also im „Mix & Match“ der eingesetzten Dienste.
Ein perfektes Szenario für die Nutzung von Lambda im Backend sind Web-Apps und Mobile Apps. Diese setzen von Anwender-Geräten aus Anfragen (Requests) ab und erwarten Antworten (Responses) in Form von HTML oder Dateninhalten (JSON oder XML).
AWS hilft uns mit zwei Diensten dabei, diese Anfragen ohne Programmieraufwand auszuwerten und entsprechende Ereignisse für Lambda auszulösen. Diese Gateway Services heißen API Gateway (für REST APIs) und AppSync (für GraphQL APIs). In der Kombination mit Lambda bilden diese Dienste ein perfektes Team.

Ausblick

Damit endet unsere Übersicht über die wichtigsten AWS-Services für den Start. Hunderte weitere spezialisierte Dienste existieren, aber die genannten erlauben einen fokussierten Einstieg in die Welt des Cloud-Computings. Wir freuen uns, wenn dieser für sie so leichter geworden ist.

(Weiterführende Artikel zum Thema AWS-Cloud und vergleichbaren Ansätzen anderer Cloud-Anbieter sind in Vorbereitung)