KAPITEL 3

Infrastruktur-Plattformen

Es gibt sehr viele Tools, die auf die eine oder andere Art und Weise mit moderner Cloud-Infrastruktur in einer Verbindung stehen. Man kann von der Frage überwältigt sein, welche Technologien man auswählen soll und wie diese zusammenpassen. Dieses Kapitel stellt Ihnen ein Modell vor, wie Sie über die übergeordneten Belange Ihrer Plattform, die von ihr gebotenen Fähigkeiten und die Infrastrukturressourcen, die Sie zur Bereitstellung dieser Fähigkeiten einsetzen können, nachdenken können.

Das ist kein verbindliches Modell und auch keine strenge Architektur. Sie werden Ihren eigenen Weg finden, um die Teile Ihres Systems beschreiben zu können. Es ist weniger wichtig, sich auf den richtigen Platz all Ihrer Tools und Technologien im Diagramm zu einigen, als überhaupt darüber zu sprechen.

Ziel dieses Modells ist, in diesem Buch einen Rahmen für Diskussionen über Konzepte, Praktiken und Vorgehensweisen zu schaffen. Besonders wichtig ist mir, sicherzustellen, dass diese Diskussionen für Sie von Relevanz sind – egal welchen Technologie-Stack, welche Werkzeuge oder Plattformen Sie nutzen. Dieses Modell definiert daher Gruppen und Terminologie, mit denen in späteren Kapiteln beschrieben wird, wie man beispielsweise Server auf einer Virtualisierungsplattform wie VMware oder einer IaaS-Cloud wie AWS provisioniert.

Die Elemente eines Infrastruktur-Systems

Es gibt in einer modernen Cloud-Infrastruktur viele verschiedene Elemente und viele unterschiedliche Arten von Elementen. Ich finde es hilfreich, diese in drei Plattformschichten aufzuteilen (Abbildung 3-1):

Anwendungen

Anwendungen und Services stellen Ihrer Organisation und deren Benutzerinnen und Benutzern bestimmte Fähigkeiten oder Möglichkeiten zur Verfügung. Alles andere in diesem Modell dient dazu, diese Schicht möglich zu machen.

Anwendungs-Laufzeitumgebungen

Anwendungs-Laufzeitumgebungen stellen Services und Fertigkeiten für die Anwendungsschicht bereit. Beispiele für Services und Konstrukte in einer Anwendungs-Laufzeitplattform sind Container-Cluster, Serverless-Umgebungen, Anwendungsserver, Betriebssysteme und Datenbanken. Diese Schicht kann auch als Platform as a Service (PaaS) bezeichnet werden.

Infrastruktur-Plattformen

Die Infrastruktur-Plattform besteht aus den Infrastruktur-Ressourcen und den Tools und Services, die sie managen. Cloud- und Virtualisierungsplattformen stellen Infrastruktur-Ressourcen bereit, unter anderem Computing-, Storage- und Networking-Komponenten. Dies wird auch als Infrastructure as a Service (IaaS) bezeichnet. Ich werde auf die Ressourcen aus dieser Schicht genauer in »Infrastruktur-Ressourcen« auf Seite 57 eingehen.

Abbildung 3-1: Schichten der Systemelemente

Prämisse in diesem Buch ist, dass die Infrastruktur-Plattformschicht genutzt wird, um Infrastruktur-Ressourcen zusammenzufügen, damit die Anwendungs-Laufzeitschicht erstellt werden kann.

Kapitel 5 und die anderen Kapitel in »Teil II« beschreiben, wie Sie Code nutzen können, um Infrastruktur-Stacks aufzubauen. Ein Infrastruktur-Stack ist eine Sammlung von Ressourcen, die zusammen von Tools wie Ansible, CloudFormation, Pulumi oder Terraform definiert und gemanagt werden.

In Kapitel 10 und den anderen Kapiteln aus »Teil III« geht es darum, wie Sie Code nutzen, um Anwendungs-Laufzeitumgebungen zu definieren und zu managen. Dazu gehören Server, Cluster und Serverless-Ausführungsumgebungen.

Dynamische Infrastruktur-Plattform

Für Infrastructure as Code ist eine dynamische Infrastruktur-Plattform erforderlich – etwas, bei dem Sie Ressourcen auf Anforderung hin über eine API provisionieren und ändern können. In Abbildung 3-2 ist die Infrastruktur-Plattformschicht im Plattform-Modell hervorgehoben. Das ist im Prinzip die Definition einer Cloud.¹ Wenn ich in diesem Buch von einer »Infrastruktur-Plattform« spreche, können Sie davon ausgehen, dass ich eine dynamische IaaS-artige Plattform meine.²

Abbildung 3-2: Die Infrastruktur-Plattform ist die grundlegende Schicht des Plattform-Modells.

Früher – in der Eisenzeit des Computings – bestand die Infrastruktur aus Hardware. Mit der Virtualisierung wurden Systeme von der Hardware, auf der sie liefen, entkoppelt, und durch die Cloud kamen APIs zum Managen dieser virtualisierten Ressourcen hinzu.1 Damit begann das Cloud-Zeitalter.

Es gibt verschiedene Arten von Infrastruktur-Plattformen – von ausgewachsenen Public Clouds bis zu privaten Clouds, von kommerziellen Anbietern bis zu Open-Source-Plattformen. In diesem Kapitel gebe ich einen Überblick über diese Varianten und beschreibe dann die verschiedenen Arten von Infrastruktur-Ressourcen, die dort angeboten werden. In Tabelle 3-1 finden Sie Beispiele für Anbieter, Produkte und Tools für jede Art von Cloud-Infrastruktur-Plattform.

Tabelle 3-1: Beispiele für dynamische Infrastruktur-Plattformen

Art der Plattform	Anbieter oder Produkte
Public IaaS Cloud-Services	AWS, Azure, Digital Ocean, GCE, Linode, Oracle Cloud, OVH, Scaleway und Vultr
Private IaaS Cloud-Produkte	CloudStack, OpenStack und VMware vCloud
Bare-Metal Cloud Tools	Cobbler, FAI und Foreman

Ganz allgemein bieten Infrastruktur-Plattformen Computing-, Storage- und Networking-Ressourcen. Die Plattformen bieten diese in unterschiedlichen Formaten an. So können Sie Computing-Ressourcen beispielsweise als virtuelle Server, als Container-Runtimes oder als Serverless Code betreiben.

PaaS Die meisten Anbieter für Public Clouds stellen Ressourcen oder Ressourcen-Bundles bereit, die gemeinsam Services auf einem höheren Level anbieten, um Anwendungen zu deployen und zu managen. Beispiele für gehostete PaaS-Services sind Heroku (https://www.heroku.com), AWS Elastic BeanStalk (https://oreil.ly/rbFTp) und Azure DevOps (https://oreil.ly/r0mPZ).2

Unterschiedliche Anbieter bieten die gleichen Ressourcen eventuell unterschiedlich kombiniert an – oder zumindest mit unterschiedlichen Namen. So sind beispielsweise AWS Object Storage, Azure Blob Storage und GCP Cloud Storage alle mehr oder weniger das Gleiche. Dieses Buch versucht, generische Namen zu verwenden, die für verschiedene Plattformen passen. Statt VPC und Subnet nutze ich Netzwerk-Adressblock und VLAN.

Multicloud

Viele Organisationen hosten irgendwann auf mehreren Plattformen. In dieser Situation gibt es auch ein paar typische Begriffe:

Hybride Cloud

Anwendungen und Services für ein System werden sowohl auf privater Infrastruktur als auch über einen Public-Cloud-Service gehostet. Das wird oft genutzt, weil sich Altsysteme nicht so einfach in eine Public Cloud migrieren lassen (wie zum Beispiel Services, die auf Mainframes laufen). In anderen Fällen haben Organisationen Anforderungen, die Public-Cloud-Anbieter momentan nicht erfüllen können, wie zum Beispiel rechtliche Anforderungen, Daten in einem Land zu hosten, in dem der Anbieter nicht präsent ist.

Cloud-agnostisch

Systeme werden so gebaut, dass sie auf unterschiedlichen Public-Cloud-Plattformen laufen können. Das wird häufig gemacht, um nicht auf einen Anbieter angewiesen zu sein (Lock-in). In der Praxis führt das zu Lock-ins gegenüber Software, die verspricht, die Unterschiede zwischen den Clouds zu verbergen, zum Bauen und Warten großer Mengen angepassten Codes – oder zu beidem.

Polycloud

Verschiedene Anwendungen, Services und Systeme laufen auf mehr als einer Public-Cloud-Plattform. Das geschieht normalerweise, um die verschiedenen Stärken der unterschiedlichen Plattformen ausnutzen zu können.

Infrastruktur-Ressourcen

Es gibt im Prinzip drei grundlegende Ressourcen, die von einer Infrastruktur-Plattform angeboten werden: Computing, Storage und Networking. Die verschiedenen Plattformen kombinieren und verpacken diese Ressourcen auf unterschiedliche Art und Weise. So können Sie auf Ihrer Plattform vielleicht virtuelle Maschinen und Container-Instanzen provisionieren. Oder Sie können eine Datenbankinstanz provisionieren, die Computing, Storage und Networking kombiniert.

Ich nenne die eher grundlegenden Infrastruktur-Ressourcen Primitive. Jede der in den folgenden Abschnitten beschriebenen Computing-, Networking- und Storage-Ressourcen sind ein Primitiv. Cloud-Plattformen kombinieren Infrastruktur-Primitive in Ressourcen-Kombinationen, wie zum Beispiel:

• Database as a Service (DBaaS)
• Load Balancing
• DNS
• Identity Management
• Secrets Management

Die Grenze zwischen einer Primitiv- und einer zusammengesetzten Ressource ist willkürlich gewählt, wie auch die zwischen einer zusammengesetzten Infrastruktur-Ressource und einem Anwendungs-Laufzeitservice. Selbst ein grundlegender Storage-Service wie ein Object Storage (denken Sie an AWS S3 Buckets) beinhaltet Computing- und Networking-Ressourcen, um Daten lesen und schreiben zu können. Aber es ist eine nützliche Unterscheidung, die ich nun verwenden werde, um gebräuchliche Formen von Infrastruktur-Primitiven aufzuführen. Diese fallen in eine der drei zentralen Ressourcen-Typen: Computing, Storage und Networking.

Computing-Ressourcen

Computing-Ressourcen führen Code aus. Ganz grundlegend handelt es sich beim Computing um Ausführungszeit auf einem physischen Server-CPU-Core. Aber Plattformen bieten Rechenleistung auf nützlichere Art und Weise an. Meist gehören zu solchen Ressourcen:

Virtuelle Maschinen (VMs)

Die Infrastruktur-Plattform verwaltet einen Pool physischer Host-Server und lässt Instanzen von virtuellen Maschinen auf Hypervisoren über diese Hosts verteilt laufen. Kapitel 11 geht genauer darauf ein, wie man Server provisioniert, konfiguriert und managt.

Physische Server

Auch als Bare Metal bezeichnet. Die Plattform provisioniert dynamisch auf Anforderung physische Server. »Einen Server mit einem Network-Provisioning-Tool erstellen« auf Seite 220 beschreibt einen Mechanismus zum automatischen Provisionieren physischer Server als Bare-Metal Cloud.

Server-Cluster

Ein Server-Cluster ist ein Pool mit Server-Instanzen – entweder virtuelle Maschinen oder physische Server – die die Infrastruktur-Plattform als Gruppe provisioniert und verwaltet. Dazu gehören beispielsweise AWS Auto Scaling Group (ASG), Azure Virtual Machine Scale Set und Google Managed Instance Groups (MIGs).

Container

Die meisten Cloud-Plattformen bieten Containers as a Service (CaaS) an, um Container-Instanzen zu deployen und auszuführen. Häufig bauen Sie ein Container-Image in einem Standardformat (zum Beispiel Docker), und die Plattform nutzt dieses dann, um Instanzen laufen zu lassen. Viele Anwendungs-Laufzeitplattformen bauen auf Containerisierung auf. Kapitel 10 behandelt das genauer. Container brauchen Host-Server, auf denen sie laufen können. Manche Plattformen stellen diese Hosts transparent zur Verfügung, aber bei vielen müssen Sie ein Cluster und dessen Hosts selbst definieren.

Anwendungshosting-Cluster

Ein Anwendungshosting-Cluster ist ein Pool mit Servern, auf denen die Plattform mehrere Anwendungen deployt und hostet.1 Dazu gehören beispielsweise Amazon Elastic Container Services (ECS), Amazon Elastic Container Services for Kubernetes (EKS), Azure Kubernetes Service (AKS) und Google Kubernetes Engine (GKE). Sie können auch ein Anwendungshosting-Paket auf einer Infrastruktur-Plattform deployen und managen. Mehr dazu finden Sie in »Lösungen für Anwendungs-Cluster« auf Seite 270.

FaaS Serverless Code Runtimes

Eine Infrastruktur-Plattform führt als Reaktion auf ein Event oder einen Zeitplan Function-as-a-Service-(FaaS-)Code aus und beendet ihn, nachdem die Aktivität erledigt ist. In »Infrastruktur für FaaS Serverless« auf Seite 286 gehe ich darauf genauer ein. Zu Serverless-Angeboten von Infrastruktur-Plattformen gehören unter anderem AWS Lambda, Azure Functions und Google Cloud Functions.

Serverless geht über Code hinaus Das Serverless-Konzept geht über das Ausführen von Code hinaus. Amazon DynamoDB und Azure Cosmos DB sind Serverless-Datenbanken: Die zum Hosten der Datenbank genutzten Server sind für Sie transparent – anders als klassischere DBaaS-Angebote wie AWS RDS. Manche Cloud-Plattformen bieten auch spezialisierte On-Demand-Anwendungs-Ausführungsumgebungen an. So können Sie beispielsweise AWS SageMaker, Azure ML Services oder Google ML Engine verwenden, um Modelle zum maschinellen Lernen zu deployen und auszuführen.

Storage-Ressourcen

Viele dynamische Systeme benötigen Storage, wie zum Beispiel Disk Volumes, Datenbanken oder zentrale Repositories für Dateien. Selbst wenn Ihre Anwendung nicht direkt Storage braucht, werden viele der eingesetzten Services welchen benötigen – und wenn es nur für das Sichern von Computing-Images ist (zum Beispiel Snapshots von virtuellen Maschinen oder Container-Images).

Eine wirklich dynamische Plattform bietet den Anwendungen Storage transparent an und managt ihn auch entsprechend. Dieses Feature ist anders als bei klassischen Virtualisierungssystemen, bei denen Sie explizit angeben müssen, welcher physische Storage angefordert und mit jeder Computing-Instanz verbunden werden soll.

Typische Storage-Ressourcen auf Infrastruktur-Plattformen sind:

Block Storage (Virtual Disk Volumes)

Sie können ein Block Storage Volume mit einer einzelnen Server- oder Container-Instanz so verbinden, dass es als lokale Festplatte behandelt werden kann. Beispiel für Block Storage Services für Cloud-Plattformen sind AWS EBS, Azure Page Blobs, OpenStack Cinder und GCE Persistent Disk.

Object Storage

Sie können Object Storage nutzen, um Dateien von mehreren Orten aus zu lesen und zu schreiben. S3 von Amazon, Azure Block Blobs, Google Cloud Storage und OpenStack Swift sind Beispiele dafür. Object Storage ist meist günstiger und zuverlässiger als Block Storage, hat aber eine höhere Latenz.

Netzwerk-Dateisysteme (Shared Network Volumes)

Viele Cloud-Plattformen bieten Shared Storage Volumes an, die über Standardprotokolle auf vielen Computing-Instanzen gemountet werden können, wie zum Beispiel per NFS, AFS oder SMB/CIFS.1

Structured Data Storage

Die meisten Infrastruktur-Plattformen bieten eine gemanagte Database as a Service (DBaaS), die Sie als Code definieren und verwalten können. Dabei kann es sich um eine kommerzielle oder Open-Source-Standard-Datenbankanwendung handeln, wie zum Beispiel mySQL, Postgres oder SQL Server. Oder es ist ein eigener Structured Data Storage Service – beispielsweise ein Key/Value-Store oder Document Stores für JSON- oder XML-Inhalte. Bei den großen Cloud-Anbietern sind auch Data-Storage- und Verarbeitungs-Services für das Verwalten, Umwandeln und Analysieren großer Datenmengen nutzbar. Dazu gehören Services für Batch-Datenverarbeitung, Map-Reduce, Streaming, Indexierung und Suchen und vieles mehr.

Secrets-Management

Jede Storage-Ressource kann verschlüsselt werden, sodass Passwörter, Schlüssel und andere Informationen gespeichert werden können, die Angreifer nutzen könnten, um privilegierten Zugriff auf Systeme und Ressourcen zu erhalten. Ein Secrets-Management-Service bietet zusätzliche Funktionalität, die spezifisch dafür gedacht ist, diese Art von Ressourcen zu managen. In »Secrets als Parameter nutzen« auf Seite 133 sind Techniken zum Verwalten von Secrets und Infrastruktur-Code beschrieben.

Networking-Ressourcen

Wie bei den anderen Arten von Infrastruktur-Ressourcen bieten die Fähigkeiten dynamischer Plattformen zum Provisionieren und Ändern von Networking-Elementen per Code viele Möglichkeiten. Diese gehen darüber hinaus, schnell etwas am Netzwerk ändern zu können – sie lassen sich auch sicherer verwenden.

Ein Teil der Sicherheit entsteht durch die Möglichkeit, schnell und exakt die Änderung einer Netzwerkkonfiguration zu testen, bevor man sie auf eine kritische Umgebung anwendet. Darüber hinaus ermöglicht es Software Defined Networking (SDN), feingranularere Netzwerksicherheits-Konstruktionen aufzusetzen, als das manuell möglich wäre. Das gilt besonders für Systeme, bei denen Sie Elemente dynamisch erstellen und zerstören.

Zero-Trust-Sicherheitsmodell mit SDN

Ein Zero-Trust-Sicherheitsmodell schützt jeden Service, jede Anwendung und andere Ressourcen in einem System auf niedrigster Ebene.1 Das ist der Unterschied zu einem klassischen perimeterbasierten Sicherheitsmodell, bei dem davon ausgegangen wird, dass jedem Device innerhalb eines sicheren Netzwerks vertraut werden kann.

Solch ein Zero-Trust-Modell lässt sich für nichttriviale Systeme überhaupt nur sinnvoll als Code implementieren. Die manuelle Arbeit zum Managen der Kontrollelemente für jeden Prozess im System wäre sonst überwältigend.

Bei einem Zero-Trust-Modell wird jede neue Anwendung mit Anmerkungen versehen, um anzuzeigen, welche Anwendungen und Services sie erreichen können muss. Die Plattform ermöglicht damit automatisch den erforderlichen Zugriff und stellt sicher, dass alles andere blockiert wird.

Zu den Vorteilen solch eines Vorgehens gehören:

• Jede Anwendung und jeder Service besitzt nur die Privilegien und Zugriffe, die er explizit benötigt – ganz im Sinne des Prinzips der geringsten Privilegien (https://oreil.ly/0Zonv).
• Bei Zero-Trust oder perimeterloser Sicherheit werden Hürden und Kontrollelemente für die spezifischen zu schützenden Ressourcen feingranularer aufgebaut. Dieser Ansatz vermeidet es, großräumige Trust-Zonen einrichten zu müssen – zum Beispiel jedem Device zu vertrauen, das mit einem physischen Netzwerk verbunden ist.
• Die Sicherheitsbeziehungen zwischen Elementen des Systems sind sichtbar, womit Validierung, Auditierung und Reporting möglich werden.

Zu den typischen Networking-Elementen und Services einer Infrastruktur-Plattform gehören:

Netzwerk-Adressblöcke

Netzwerk-Adressblöcke sind eine grundlegende Struktur für das Gruppieren von Ressourcen, um das Routing von Traffic zwischen ihnen zu steuern. Der Top-Level-Block in AWS ist eine VPC (Virtual Private Cloud). In Azure, GCP und anderen ist es ein Virtual Network. Der Top-Level-Block wird oft in kleinere Blöcke unterteilt, wie zum Beispiel Subnets oder VLANs. Eine bestimmte Networking-Struktur wie AWS Subnets kann mit physischen Standorten verbunden werden, beispielsweise einem Data Center, das Sie nutzen können, um die Verfügbarkeit zu managen.

Namen (zum Beispiel DNS-Einträge)

Namen werden auf Lower-Level-Netzwerk-Adressen gemappt – normalerweise auf IP-Adressen.

Routen

Hier wird konfiguriert, welcher Traffic zwischen und innerhalb von Adressblöcken erlaubt ist.

Gateways

Können erforderlich sein, um Traffic in Blöcke hinein und aus ihnen hinaus zu leiten.

Load-Balancing-Regeln

Leitet an eine einzelne Adresse eintreffende Verbindungen an einen Ressourcen-Pool weiter.

Proxies

Akzeptiert Verbindungen und nutzt Regeln, um sie umzuwandeln oder weiterzuleiten.

API-Gateways

Ein Proxy – meist für HTTP/S-Verbindungen –, der Aktivitäten ausführen kann, um nichtzentrale Aspekte von APIs zu behandeln, wie zum Beispiel die Authentifizierung und das Rate Limiting. Siehe auch »Service Mesh« auf Seite 284.

VPNs (Virtual Private Networks)

Verbindet unterschiedliche Adressblöcke über Standorte hinweg, sodass sie als Teil eines einzelnen Netzwerks erscheinen.

Direkte Verbindung

Eine dedizierte Verbindung, die zwischen einem Cloud-Netzwerk und einem anderen Standort eingerichtet ist – meist ein Data Center oder ein Firmennetzwerk.

Netzwerk-Zugriffsregeln (Firewall-Regeln)

Regeln, die Traffic zwischen Standorten beschränken oder zulassen.

Asynchrones Messaging

Queues für Prozesse, mit denen Nachrichten verschickt und empfangen werden.

Cache

Ein Cache verteilt Daten über Netzwerk-Standorte, um die Latenz zu verbessern. Ein CDN (Content Distribute Network) ist ein Service, der statische Inhalte (und in manchen Fällen auch ausführenden Code) auf mehrere geografische Standorte verteilt – meist für Inhalte, die per HTTP/S ausgeliefert werden.

Service Mesh

Ein dezentralisiertes Service-Netzwerk, das die Verbindung zwischen Teilen eines verteilten Systems dynamisch managt. Es zieht Networking-Fähigkeiten in dem Modell, das ich in »Die Elemente eines Infrastruktur-Systems« auf Seite 53 beschreibe, aus der Infrastruktur-Schicht in die Anwendungslaufzeit-Schicht.

Die Details des Networking würden den Rahmen dieses Buchs sprengen. Schauen Sie sich dazu die Dokumentation Ihres Plattform-Anbieters und vielleicht auch eine Referenz wie Craig Hunts TCP/IP Netzwerk-Administration (https://oreil.ly/2JlVeYe, O’Reilly) an.

Zusammenfassung

Die verschiedenen Arten an Infrastruktur-Ressourcen und -Services, die in diesem Kapitel behandelt wurden, sind die Elemente, die Sie zu nützlichen Systemen zusammenstellen – der »Infrastruktur«-Anteil von Infrastructure as Code.