WISSEN > CLOUD INFRASTRUKUR > CLOUD INFRASTRUKTUR GRUNDLAGEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Was ist Cloud Infrastruktur?
Warum Compute, Storage und Netzwerk allein noch keine Cloud ergeben
Das sollten Sie mitnehmen:
- Cloud-Infrastruktur umfasst mehr als Server.
Compute, Storage, Netzwerk und die Gebäudeinfrastruktur bilden die unterste Ebene, darüber liegt eine Abstraktions- und Steuerungsebene.
- Virtualisierung ist ein Weg zur Cloud, nicht die Bedingung.
Entscheidend sind Self-Service, Ressourcenpools, Elastizität und messbare Nutzung.
- IaaS verschiebt die Kontrollgrenze, nicht die Physik.
Der Anwender steuert Betriebssysteme, Storage und Anwendungen, nicht die darunterliegende Infrastruktur.
- Hybrid Cloud verbindet Clouds.
Die Kopplung einer Public Cloud an klassische On-Premises-Systeme erfüllt die Definition nicht.
- Bandbreite, Latenz und Datenlokalität bleiben bestehen.
Abstraktion verändert die Bereitstellung, nicht die physikalischen Eigenschaften des Datenpfads.
Was ist ein Cloud Infrastruktur?
Inhaltsverzeichnis
- Cloud-Infrastruktur ist mehr als Hardware im Rechenzentrum
- Fünf Eigenschaften entscheiden über den Cloud-Charakter
- Compute, Storage und Netzwerk bilden nur die unterste Ebene
- Die Abstraktionsebene macht Ressourcen erst zum Cloud Service
- IaaS verlagert den Betrieb, nicht die gesamte Verantwortung
- IaaS, PaaS und SaaS verschieben die Kontrollgrenze
- Public, Private und Community beschreiben nicht den Standort
- Hybrid Cloud verbindet Clouds, nicht Cloud und Altsystem
- Cloud hebt Bandbreite, Latenz und Datenlokalität nicht auf
- Was die Architekturentscheidung tatsächlich bestimmt
- Fazit
- Quellen
Cloud-Infrastruktur bezeichnet die technische Grundlage, auf der Cloud-Services bereitgestellt werden. Dazu gehören zunächst die vertrauten Ressourcen eines Rechenzentrums: Compute, Storage und Netzwerk. Diese Hardware allein bildet jedoch noch keine Cloud.
Entscheidend ist eine zusätzliche Software- und Steuerungsebene, die physische Ressourcen abstrahiert, zu gemeinsam nutzbaren Pools zusammenfasst und deren automatisierte Bereitstellung ermöglicht. Erst das Zusammenspiel dieser Ebenen erzeugt Eigenschaften wie Self-Service, dynamische Zuordnung und elastische Skalierung.
Damit unterscheidet sich Cloud-Infrastruktur von der verbreiteten Vorstellung, Cloud bedeute lediglich, Server oder Storage in das Rechenzentrum eines externen Providers zu verlagern.
Cloud-Infrastruktur ist mehr als Hardware im Rechenzentrum
Das National Institute of Standards and Technology beschreibt Cloud-Infrastruktur als die Gesamtheit aus Hardware und Software, die die wesentlichen Eigenschaften des Cloud Computing ermöglicht. NIST unterscheidet dabei zwei Ebenen.
Der Physical Layer enthält die tatsächlichen Hardware-Ressourcen, die für die Bereitstellung der Services erforderlich sind, typischerweise Server-, Storage- und Netzwerkkomponenten. Der Abstraction Layer besteht aus der Software, die über dieser Hardware betrieben wird und die für Cloud Computing charakteristischen Eigenschaften erzeugt. Konzeptionell liegt der Abstraction Layer über dem Physical Layer.
Diese Unterscheidung ist folgenreich. Ein Rechenzentrum mit Servern, Storage und Netzwerk ist zunächst eine IT-Infrastruktur. Cloud Computing entsteht erst durch die Art, wie diese Ressourcen abstrahiert, zusammengefasst, bereitgestellt und in ihrer Nutzung erfasst werden.
Die ISO/IEC-Systematik ordnet dieselbe Materie anders: ISO/IEC 22123-2 beschreibt die Konzepte des Cloud Computing einschließlich eines eigenen Satzes von Schlüsseleigenschaften, die es von anderen IT-Paradigmen abgrenzen. Die Terminologie ist nicht deckungsgleich mit der NIST-Definition, in den Grundaussagen aber anschlussfähig.
Fünf Eigenschaften entscheiden über den Cloud-Charakter
NIST benennt fünf wesentliche Eigenschaften, die eine Infrastruktur zur Cloud machen. Sie beschreiben nicht die eingesetzte Technik, sondern das Betriebs- und Bereitstellungsmodell.
Beim On-demand self-service stellt der Anwender die benötigten Ressourcen eigenständig bereit, ohne dass für jeden Vorgang eine manuelle Interaktion mit dem Service Provider erforderlich wäre. Der Broad network access bedeutet, dass die Funktionen über das Netzwerk verfügbar sind und über standardisierte Mechanismen von heterogenen Client-Plattformen genutzt werden können.
Das Resource pooling fasst die Ressourcen des Providers in einem Mehrmandantenmodell zusammen. Physische und virtuelle Ressourcen werden dem Bedarf entsprechend dynamisch zugeordnet und neu zugeordnet. NIST nennt an dieser Stelle einen Aspekt, der für datenintensive Architekturen erhebliche Konsequenzen hat: Es besteht eine gewisse Ortsunabhängigkeit, weil der Anwender in der Regel weder Kontrolle noch Kenntnis über den genauen Ort der bereitgestellten Ressourcen hat. Er kann den Ort jedoch auf einer höheren Abstraktionsebene festlegen, etwa auf Ebene eines Landes, einer Region oder eines Rechenzentrums.
Die Rapid elasticity erlaubt es, Ressourcen dem Bedarf entsprechend bereitzustellen und wieder freizugeben, in manchen Fällen automatisiert. Aus Anwendersicht erscheinen die bereitstellbaren Ressourcen dabei häufig als unbegrenzt und in beliebiger Menge zu beliebiger Zeit beziehbar. Diese Wahrnehmung ist Teil der Definition, nicht der physischen Realität. Hinter jeder zugesagten Kapazität stehen weiterhin endliche Hardware-Ressourcen.
Der Measured service schließlich beschreibt mehr als eine Verbrauchsmessung. Cloud-Systeme steuern und optimieren die Ressourcennutzung automatisch über eine Metering-Funktion auf einer dem jeweiligen Service angemessenen Abstraktionsebene. Die Nutzung wird überwacht, gesteuert und berichtet und schafft damit Transparenz für beide Seiten, für den Provider ebenso wie für den Anwender.
Compute, Storage und Netzwerk bilden nur die unterste Ebene
Die NIST Cloud Computing Reference Architecture ordnet die physischen Ressourcen im Physical Resource Layer zusammen, der untersten Ebene des Modells. Er enthält alle physischen Rechenressourcen: Rechner mit CPU und Arbeitsspeicher, Netzwerkkomponenten wie Router, Firewalls, Switches, Netzwerkverbindungen und Interfaces, Storage-Komponenten sowie weitere Elemente der physischen Recheninfrastruktur.
Facility-Ressourcen gehören definitorisch zur Cloud-Infrastruktur
Zu dieser Ebene zählen ausdrücklich auch die Facility-Ressourcen: Klimatisierung, Lüftung, Stromversorgung, Kommunikationsanbindung und die übrigen Aspekte der physischen Anlage. Gebäudetechnik ist damit kein Randthema der Cloud-Architektur, sondern definitorischer Bestandteil der Cloud-Infrastruktur. Bei energieintensiven Workloads wird sie zu einer harten Randbedingung. [QUERVERWEIS: Artikel zu Energieeffizienz und Betriebskosten im Rechenzentrum]
Compute stellt Rechenleistung aus einem gemeinsamen Pool bereit
Compute stellt innerhalb dieser Ebene die Rechenleistung bereit, physisch getragen von Servern mit CPUs, Arbeitsspeicher, lokalen oder angebundenen Ressourcen und Netzwerkinterfaces. Die Abstraktion darüber ermöglicht es, physische Rechenkapazität nicht dauerhaft einer einzelnen Anwendung zuzuordnen, sondern sie aus einem Pool bereitzustellen.
Storage-Konzepte unterscheiden sich in mehr als der Schnittstelle
Storage übernimmt die persistente Datenhaltung. Dabei kommen unterschiedliche Zugriffskonzepte zum Einsatz, die sich nicht nur in ihren Schnittstellen unterscheiden, sondern auch in Datenmodell, Zugriffsmethode und Einsatzbereich. Block Storage stellt adressierbare Blockgeräte bereit und trägt typischerweise Dateisysteme und Datenbanken. File Storage organisiert Daten in einer Datei- und Verzeichnisstruktur und stellt sie über Dateiprotokolle bereit. Object Storage verwaltet Daten als Objekte mit zugehörigen Metadaten und wird über objektbasierte APIs angesprochen. Welche Technologie geeignet ist, ergibt sich aus dem Workload und dessen Zugriffsmuster. Der Begriff Cloud Storage bezeichnet für sich genommen keine bestimmte Storage-Architektur. [QUERVERWEIS: Artikel zu Object Storage als Datenplattform]
Das Netzwerk trägt jeden Zugriff auf Compute und Daten
Das Netzwerk verbindet diese Komponenten und stellt gleichzeitig den Zugang zu den Cloud-Ressourcen her. Ihm kommt in Cloud-Architekturen besondere Bedeutung zu, weil Compute und Storage häufig nicht auf demselben physischen System liegen und Anwender wie angrenzende Systeme ausschließlich über Netzwerkverbindungen zugreifen. Bandbreite und Latenz bleiben damit grundlegende Einflussgrößen der Architektur.
Die Abstraktionsebene macht Ressourcen erst zum Cloud Service
Zwischen den physischen Ressourcen und den bereitgestellten Services liegt die entscheidende mittlere Ebene, die NIST als Resource Abstractionand Control Layer bezeichnet. Sie enthält die Systemkomponenten, mit denen der Cloud Provider den Zugriff auf die physischen Rechenressourcen über Software-Abstraktion bereitstellt und verwaltet.
Auf der Abstraktionsseite nennt NIST typischerweise Software-Elemente wie Hypervisoren, virtuelle Maschinen und virtuellen Storage. Andere Formen der Software-Abstraktion sind ausdrücklich nicht ausgeschlossen. Virtualisierung im klassischen Sinn ist damit ein möglicher Weg, aber keine Voraussetzung: Container-Plattformen und automatisiertes Bare-Metal-Provisioning erfüllen dieselbe Funktion, sofern sie die fünf wesentlichen Eigenschaften erzeugen.
Die Steuerungsseite übernimmt Ressourcenallokation, Zugriffskontrolle, Überwachung der Nutzung und die dynamische Zuordnung von Ressourcen. Erst diese Ebene erzeugt, was NIST als Cloud-Bereitschaft der Infrastruktur beschreibt. Umgekehrt gilt: Eine virtualisierte Umgebung ohne Self-Service, ohne Pooling-Logik und ohne Nutzungsmessung bleibt virtualisierte Infrastruktur.
Über dieser mittleren Ebene liegt der Service Layer, an dem die Schnittstellen der Cloud Services nach außen exponiert werden. Die Anordnung der drei Ebenen impliziert eine Abhängigkeit: Jede obere Ebene setzt auf der darunterliegenden auf.
[BILD: Dreischichtmodell nach NIST SP 500-292. Von unten nach oben: Physical Resource Layer (Hardware: Compute, Storage, Netzwerk; Facility: Strom, Klimatisierung, Kommunikation), Resource Abstraction and Control Layer (Abstraktion und Steuerung), Service Layer (IaaS, PaaS, SaaS). Abhängigkeitspfeile nach oben.]
Die Cloud ist damit keine Alternative zu physischer Infrastruktur, sondern ein Betriebs- und Bereitstellungsmodell, das auf physischer Infrastruktur aufsetzt und diese durch Software abstrahiert und steuert.
IaaS verlagert den Betrieb, nicht die gesamte Verantwortung
nfrastructure as a Service ist eines der drei grundlegenden Servicemodelle. Der Anwender erhält die Möglichkeit, fundamentale Rechenressourcen zu beziehen: Rechenleistung, Storage, Netzwerke und weitere grundlegende Computing-Ressourcen. Auf diesen Ressourcen kann er beliebige Software betreiben, einschließlich Betriebssystemen und Anwendungen.
Die Verantwortungsgrenze ist dabei präzise gezogen. Der Anwender verwaltet und kontrolliert die darunterliegende Cloud-Infrastruktur nicht. Er besitzt jedoch Kontrolle über Betriebssysteme, Storage und die von ihm ausgerollten Anwendungen. Beim Netzwerk ist die Kontrolle enger gefasst: NIST spricht hier von möglicher, begrenzter Kontrolle über ausgewählte Netzwerkkomponenten, etwa Host-Firewalls.
Diese Abgrenzung wird in der Praxis regelmäßig unterschätzt. IaaS bedeutet weder, dass der Anwender die gesamte Infrastruktur selbst betreibt, noch dass er sich um sie nicht mehr kümmern muss. Ein Teil der technischen Verantwortung wandert zum Provider, ein wesentlicher Teil bleibt beim Anwender, insbesondere Betriebssystempflege, Datenhaltung und Anwendungsbetrieb.
IaaS, PaaS und SaaS verschieben die Kontrollgrenze
Cloud-Infrastruktur und IaaS sollten nicht mit Cloud Computing insgesamt gleichgesetzt werden. NIST unterscheidet drei Servicemodelle, die sich vor allem darin unterscheiden, wo die Grenze der technischen Kontrolle verläuft.
Bei Infrastructure as a Service bezieht der Anwender grundlegende Rechenressourcen und betreibt darauf Betriebssysteme und Anwendungen. Bei Platform as a Service stellt der Provider zusätzlich eine Ausführungsumgebung bereit; der Anwender rollt dort eigene oder beschaffte Anwendungen aus, die mit den vom Provider unterstützten Programmiersprachen, Bibliotheken, Services und Werkzeugen erstellt wurden. Er verwaltet die darunterliegende Infrastruktur einschließlich Netzwerk, Servern, Betriebssystemen und Storage nicht, behält aber Kontrolle über die ausgerollten Anwendungen und gegebenenfalls über Konfigurationseinstellungen der Anwendungsumgebung. Bei Software as a Service nutzt der Anwender eine vom Provider betriebene Anwendung; die darunterliegenden Server-, Storage-, Netzwerk- und Plattformkomponenten verwaltet er nicht, allenfalls begrenzte anwenderspezifische Konfigurationseinstellungen.
[BILD: Kontrollgrenze über die drei Servicemodelle. Horizontale Schichtstapel für IaaS, PaaS und SaaS, jeweils farblich getrennt in Verantwortung Anwender und Verantwortung Provider; Schichten von unten: Facility, Hardware, Virtualisierung, Betriebssystem, Middleware, Laufzeitumgebung, Daten, Anwendung.]
Public, Private und Community beschreiben nicht den Standort
Neben den Servicemodellen unterscheidet NIST vier Deployment Models: Private Cloud, Community Cloud, Public Cloud und Hybrid Cloud. Für Infrastrukturarchitekturen im Unternehmenskontext stehen Private, Public und Hybrid im Vordergrund; die Community Cloud, bereitgestellt für eine abgegrenzte Gemeinschaft von Organisationen mit gemeinsamen Anforderungen, spielt vor allem in regulierten Verbünden eine Rolle.
Public beschreibt das Bereitstellungsmodell, nicht die Zugriffskontrolle
Bei einer Public Cloud wird die Infrastruktur für die offene Nutzung durch die Allgemeinheit bereitgestellt. Die physische Infrastruktur befindet sich typischerweise beim Provider. Public bedeutet dabei nicht, dass die dort betriebenen Daten oder Systeme öffentlich zugänglich wären. Der Begriff beschreibt das Bereitstellungsmodell, nicht die Zugriffskontrolle auf einzelne Workloads.
Private Cloud und On-Premises sind zwei verschiedene Aussagen
Eine Private Cloud wird für die exklusive Nutzung durch eine einzelne Organisation bereitgestellt, die dabei durchaus mehrere Nutzergruppen umfasst, etwa unterschiedliche Geschäftsbereiche. Sie kann von der Organisation selbst, von einem Dritten oder in einer Kombination betrieben werden und sich innerhalb oder außerhalb der eigenen Räumlichkeiten befinden. Private Cloud ist damit nicht gleichbedeutend mit On-Premises. Umgekehrt wird eine im eigenen Rechenzentrum betriebene Infrastruktur nicht dadurch zur Private Cloud, dass sie dort steht; sie muss die entsprechenden Eigenschaften und Bereitstellungsmechanismen tatsächlich besitzen.
Standort und Betriebsmodell sind getrennte Achsen
Im allgemeinen Sprachgebrauch wird Cloud häufig mit den Rechenzentren der großen Public-Cloud-Provider gleichgesetzt. Technisch ist diese Verengung nicht haltbar. Cloud Computing beschreibt ein Modell zur Bereitstellung und Nutzung von Rechenressourcen. Wo die zugrunde liegende Hardware betrieben wird und wem sie gehört, ist eine davon getrennte Frage. Eine Cloud-Infrastruktur kann im Rechenzentrum eines Providers realisiert werden, im eigenen Rechenzentrum, bei einem Hosting-Dienstleister oder verteilt über mehrere Umgebungen. Physische Lokation und Betriebsmodell sind zwei Achsen, die getrennt bewertet werden müssen.
[BILD: Zwei-Achsen-Matrix. X-Achse: Betriebsmodell von klassischer IT-Infrastruktur zu Cloud-Betriebsmodell. Y-Achse: Standort von eigenem Rechenzentrum zu Provider-Rechenzentrum. Einordnung der vier Quadranten mit Beispielen; Hervorhebung, dass Private Cloud in beiden Standortquadranten liegen kann.]
Hybrid Cloud verbindet Clouds, nicht Cloud und Altsystem
Eine Hybrid Cloud besteht nach der NIST-Definition aus zwei oder mehr eigenständigen Cloud-Infrastrukturen – privat, community-basiert oder öffentlich –, die eigenständige Einheiten bleiben, jedoch durch standardisierte oder proprietäre Technologie verbunden sind, die Daten- und Anwendungsportabilität ermöglicht.
Zwei Bestandteile dieser Definition werden im Sprachgebrauch regelmäßig übergangen. Erstens verbindet eine Hybrid Cloud Clouds. Die Anbindung einer Public Cloud an klassische, nicht cloud-fähige On-Premises-Systeme ergibt nach dieser Systematik keine Hybrid Cloud, sondern eine gekoppelte Umgebung aus einer Cloud und einer konventionellen Infrastruktur. Das ist kein terminologischer Streitpunkt, sondern hat praktische Folgen: Portabilität von Daten und Anwendungen setzt voraus, dass beide Seiten die dafür erforderlichen Eigenschaften überhaupt besitzen.
Zweitens bleiben die verbundenen Infrastrukturen eigenständig. Eine Hybrid Cloud ist keine übergreifende Einheit, sondern eine Kopplung. Damit wird die Verbindung selbst zum Architekturgegenstand. Datenbewegung, Netzwerkanbindung, Identitäten, Schnittstellen und Betriebsmodelle beider Seiten sind Bestandteile der Gesamtarchitektur und nicht nachgelagerte Integrationsaufgaben. [QUERVERWEIS: Artikel zu Hybrid Cloud Storage]
Cloud hebt Bandbreite, Latenz und Datenlokalität nicht auf
Die Abstraktion von Infrastruktur verändert die Art der Bereitstellung. Sie verändert nicht die physikalischen Zusammenhänge darunter.
Eine virtuelle CPU benötigt physische Rechenkapazität. Ein Storage-Service benötigt physische Speichermedien und Storage-Systeme. Eine Netzwerkverbindung besitzt eine endliche Bandbreite. Die Kommunikation zwischen geografisch getrennten Systemen unterliegt einer Latenz, die sich nicht wegkonfigurieren lässt.
Hier schließt sich der Kreis zur Ortsunabhängigkeit, die NIST beim Resource Pooling beschreibt. Dass der Anwender den genauen Ort seiner Ressourcen in der Regel weder kennt noch kontrolliert, ist definitorisch gewollt und für viele Workloads unproblematisch. Bei datenintensiven Anwendungen kehrt sich das um: Dort ist nicht allein entscheidend, wie viele Ressourcen bereitgestellt werden können, sondern wo sich Compute und Daten befinden und über welchen Datenpfad sie miteinander kommunizieren. Die von NIST vorgesehene Möglichkeit, den Ort auf höherer Abstraktionsebene zu spezifizieren, wird damit von einer Compliance-Frage zu einer Performance-Frage. [QUERVERWEIS: Artikel zu Datenarchitektur für KI-Workloads]
Was die Architekturentscheidung tatsächlich bestimmt
Die Entscheidung für eine Cloud-Infrastruktur ist damit mehr als eine Wahl zwischen eigenem Rechenzentrum und externem Provider. In unseren Projekten zeigt sich, dass tragfähige Architekturen entstehen, wenn mehrere Ebenen getrennt bewertet werden, statt sie zu einer Grundsatzfrage zu bündeln.
Beim Compute geht es um den tatsächlichen Ressourcenbedarf des Workloads und darum, wie dynamisch dieser Bedarf schwankt. Beim Storage sind Kapazität, Zugriffsmethode, Performance, Datenintegrität und Verfügbarkeit zu klären, und zwar getrennt voneinander, weil sie unterschiedliche Konsequenzen für die Plattformwahl haben. Beim Netzwerk stellt sich die Frage, welche Systeme miteinander kommunizieren, welche Datenmengen übertragen werden und welche Bandbreiten und Latenzen dabei entstehen.
Die Datenlokalität betrifft die Orte, an denen persistente Daten liegen, und die Orte, an denen sie verarbeitet werden. Bei der Skalierung ist zu klären, welche Ressourcen unabhängig voneinander wachsen können müssen. Die Betriebsverantwortung entscheidet, welche Komponenten selbst betrieben werden und welche ein Provider übernimmt. Die Integration schließlich umfasst bestehende On-Premises-Systeme, Identitäten, Netzwerke, Anwendungen und Datenquellen, die angebunden werden müssen.
Die geeignete Architektur ergibt sich aus dem Zusammenspiel dieser Ebenen, nicht aus einer Vorabentscheidung für oder gegen Cloud. [QUERVERWEIS: Artikel zu KI-Infrastruktur zwischen On-Premises, Cloud und Hybrid]
Fazit
Cloud-Infrastruktur besteht aus Compute, Storage, Netzwerk und der zugehörigen Gebäudeinfrastruktur sowie den darüberliegenden Abstraktions- und Steuerungsmechanismen, mit denen diese Ressourcen als Cloud Services bereitgestellt werden.
Der Unterschied zu klassischer IT-Infrastruktur liegt nicht darin, wo die Server stehen. Cloud Computing beschreibt ein Modell, in dem Ressourcen im Self-Service bezogen, aus gemeinsamen Pools zugeordnet, elastisch angepasst und in ihrer Nutzung gemessen, gesteuert und berichtet werden.
IaaS stellt die grundlegenden Rechenressourcen als Service bereit und verschiebt dabei die Kontrollgrenze, ohne die Verantwortung des Anwenders aufzuheben. Public, Private, Community und Hybrid beschreiben demgegenüber Deployment Models und sagen für sich genommen nichts über den physischen Standort aus.
Damit bildet Cloud-Infrastruktur die Grundlage für die weiterführenden Fragen: Cloud Storage, die Verbindung von On-Premises-Infrastruktur mit Cloud-Umgebungen und vor allem die Bewegung von Daten zwischen diesen Welten. [QUERVERWEIS: Artikel zu Enterprise Storage]
Quellen
National Institute of Standards and Technology Peter Mell, Timothy Grance: The NIST Definition of Cloud Computing. NIST Special Publication 800-145, September 2011. DOI: 10.6028/NIST.SP.800-145.
National Institute of Standards and Technology Fang Liu, Jin Tong, Jian Mao, Robert Bohn, John Messina, Lee Badger, Dawn Leaf: NIST Cloud Computing Reference Architecture. NIST Special Publication 500-292, September 2011.
ISO/IEC ISO/IEC 22123-2:2023 – Information technology — Cloud computing — Part 2: Concepts. Edition 1, 2023. ISO/IEC JTC 1/SC 38. Ersetzt gemeinsam mit ISO/IEC 22123-1 die Norm ISO/IEC 17788:2014.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
