Die Cloud-vs-Bare-Metal-Debatte wird meist als alt gegen neu geframed. Dieser Frame ist falsch.
Bare Metal ist keine Legacy-Infrastruktur. Es ist die richtige Wahl für bestimmte Workloads—und die falsche für andere. Der Unterschied liegt in der Physik und der Wirtschaftlichkeit.
Die Storage-Latenz-Hierarchie
Nicht jeder Speicher ist gleich. Die Zahlen beweisen das:
| Speichertyp | Typische Latenz | Anmerkungen |
|---|---|---|
| Lokale NVMe | 0,01–0,1ms | Direktes PCIe, kurze Wege |
| Lokale SATA SSD | 0,1–0,5ms | SATA-Controller-Overhead |
| Lokale HDD | 10–15ms | Mechanische Zugriffszeit |
| FC SAN | 0,2–1ms | Dediziertes Fabric, SCSI-Overhead |
| iSCSI | 0,5–2ms | TCP/IP + SCSI-Overhead |
| NFS | 1–5ms | Dateiprotokoll-Overhead |
| CEPH (HDD) | 5–20ms | Verteilter Konsens + Replikation |
| CEPH (NVMe) | 0,5–3ms | Immer noch ~10× langsamer als lokal |
Quellen: Tom's Hardware, Red Hat Ceph Dokumentation, TechTarget
Lokaler Speicher schlägt Netzwerkspeicher. Immer. Die Physik ist einfach: weniger Hops, weniger Protokoll-Overhead, niedrigere Latenz.
Die Frage ist nicht, ob lokal schneller ist. Die Frage ist, ob Sie diese Geschwindigkeit brauchen—und ob Sie die Trade-offs akzeptieren können.
Wann Bare Metal gewinnt
1. Große Speichervolumen zu niedrigeren Kosten
Netzwerkspeicher hat Overhead: Replikation (CEPH typischerweise 3×), Controller-Redundanz, Netzwerk-Infrastruktur. Sie bezahlen diesen Overhead in Kosten pro TB.
Lokaler Speicher auf Bare Metal umgeht all das. 12× 20TB-Festplatten in einem Server geben Ihnen 240TB Rohkapazität. RAID schützt vor Festplattenausfällen. Keine SAN-Lizenzierung.
Das betrifft vor allem Videoproduktion, Backup-Repositories (Veeam, restic, Borg), Data Lakes und Archivspeicher mit lokalem Zugriffsbedarf.
2. Ultra-niedrige Latenzanforderungen
Lokale NVMe liefert Sub-Millisekunden-Latenz. Nichts Netzwerkbasiertes kommt auch nur annähernd heran—nicht FC SAN, nicht NVMe-oF, nicht Cloud Block Storage.
Wenn Mikrosekunden zählen, ist Bare Metal mit NVMe die einzige Option. Denken Sie an High-Throughput Databases (PostgreSQL, MySQL, Oracle), In-Memory Databases mit Disk-Spillover (Redis, KeyDB), Realtime Analytics (ClickHouse, TimescaleDB) oder Message Queues wie Kafka und Redpanda.
3. High Memory + Local Storage
Manche Workloads brauchen beides: Terabytes an RAM und schnellen lokalen Speicher. VMs auf Shared-Infrastruktur können das nicht liefern—Memory-Contention, Noisy Neighbors, Hypervisor-Overhead.
Bare Metal mit 2–4TB RAM und NVMe-Speicher beseitigt diese Einschränkungen. Typisch: große In-Memory-Datenbanken, Graph-Datenbanken (Neo4j, TigerGraph), Genomsequenzierung oder Financial Risk Modeling.
Wann Cloud/Virtualisierung gewinnt
Bare Metal ist nicht immer die Antwort. Für viele Workloads ist managed Infrastruktur besser.
1. Standard-Compute
Webanwendungen, APIs, Microservices—diese brauchen keine dedizierte Hardware. Sie brauchen Zuverlässigkeit, Skalierung und jemanden, der sich um die Redundanz kümmert.
Managed VMs oder Kubernetes-Cluster erledigen das gut. Sie deployen Code. Infrastrukturausfälle sind das Problem von jemand anderem.
2. GPU-Zugriff ohne Hardware-Management
Für KI-Inferenz, Rendering oder ML-Experimente sind GPU-Instanzen in einer managed Umgebung oft sinnvoller. Sie bekommen GPU-Zugriff ohne Treiber, CUDA-Versionen oder RMA-Prozesse zu managen.
3. Wenn Sie keine Hardware managen wollen
Bare Metal bedeutet, Sie kümmern sich um:
- Festplattenausfälle und Koordination des Austauschs
- RAID-Rebuilds
- Firmware-Updates
- Kapazitätsplanung
Mit managed Infrastruktur sind das die Probleme des Providers.
4. Wenn Verfügbarkeit wichtiger ist als Performance
Verteilte Speichersysteme replizieren Daten über mehrere Nodes. Festplatte fällt aus? System läuft weiter. Node fällt aus? Daten sind noch da.
Lokaler Speicher auf Bare Metal? Festplatte fällt aus, Sie stellen vom Backup wieder her. Server fällt aus, Sie stellen vom Backup wieder her. Falls Sie ein Backup haben.
Der Trade-off: Redundanz
Das ist die Kernentscheidung:
| Bare Metal | Verteilter Speicher | |
|---|---|---|
| Latenz | Am niedrigsten | Höher |
| Kosten pro TB | Niedriger | Höher |
| Redundanz | Ihre Verantwortung | Eingebaut |
| Verfügbarkeit | Single Point of Failure | Multi-Node-Failover |
| Komplexität | Niedriger (einzelnes System) | Höher (verteilt) |
Verteilte Systeme bieten:
- CEPH: 3× Replikation über Nodes
- NetApp: Mehrere Controller, automatisches Failover
Bare Metal bietet:
- Lokales RAID (nur Schutz bei Festplattenausfall)
- Ihre Backup-Strategie
- Ihre Recovery-Prozeduren
Fazit
Wenn Ihr Workload ein Restore-Fenster toleriert, spart Bare Metal Geld. Wenn nicht, brauchen Sie verteilten Speicher oder eine komplexere HA-Architektur.
Entscheidungshilfe
Bare Metal ist sinnvoll wenn:
- Speichervolumen über 100TB liegt
- Latenzanforderungen unter einer Millisekunde liegen
- Speicheranforderungen über 1TB RAM liegen
- Sie solide Backup- und Recovery-Prozesse haben
- Kosten pro TB ein primärer Treiber sind
Managed Cloud ist sinnvoll wenn:
- Workload Standard-Compute ist (Web, API, Container)
- Eingebaute Redundanz wichtiger ist als reine Performance
- Skalierungsflexibilität wichtig ist
- Sie lieber mehr pro TB zahlen als Hardware managen
Die echte Antwort: Hybrid
Die meisten Produktionsumgebungen passen nicht sauber in „Bare Metal" oder „Cloud". Die realistische Antwort ist hybrid—jeden Ansatz dort nutzen, wo er Sinn macht.
Ihr PostgreSQL-Cluster mit 50.000 Transaktionen pro Sekunde braucht lokale NVMe. Ihre Web-Frontends, die diese Abfragen bedienen, nicht. Beides auf der gleichen Infrastruktur zu betreiben bedeutet entweder Geld verschwenden oder unnötige Latenz akzeptieren.
Ein typischer Hybrid-Stack
Was wir bei Mittelständlern mit ernsthaften Workloads gut funktionieren sehen:
- Dedizierte Firewall — OPNsense oder Cisco ASAv auf Hardware, die Sie kontrollieren. Keine Shared-Security-Appliances, keine Multi-Tenant-Routing-Regeln.
- Dedizierte Loadbalancer — HAProxy auf Bare Metal. Vorhersehbare Latenz, keine Cloud-Provider-Rate-Limits für Verbindungen.
- Bare-Metal-Datenbanken — PostgreSQL, MySQL oder Ihr OLAP-System auf NVMe. Sub-Millisekunden-Queries. Keine Noisy Neighbors bei Lastspitzen.
- Kubernetes-Cluster — Ihre Anwendungen und Web-Frontends auf managed Clustern. Horizontal skalieren. Node-Ausfälle sind das Problem von jemand anderem.
Alles verbunden über Ihr privates Netzwerk. VLANs, private Interconnects, kein Traffic-Hairpinning über das öffentliche Internet.
Storage: Wählen Sie Ihren Trade-off
Backup- und Archivspeicher folgt der gleichen Logik. Zwei Optionen, beide mit klaren Trade-offs:
Bare-Metal-Storage-Server für Backup-Repositories, wenn Sie keine unendliche Skalierung brauchen und nichts gegen Hardware-Management haben. Ein 12-Bay-Server mit 20TB-Festplatten gibt Ihnen 240TB Rohkapazität. Veeam, restic, Borg—alles funktioniert gut. Sie kümmern sich um Festplattentausch und Kapazitätsplanung, aber die Kosten pro TB sind unschlagbar.
S3-kompatibler Objektspeicher (ZERO-Z3), wenn Sie wollen, dass jemand anderes sich um Verfügbarkeit kümmert. Repliziert über mehrere Nodes, zugänglich über Standard-S3-API. Höhere Kosten pro TB, aber kein Hardware-Management und eingebaute Redundanz.
Viele Setups nutzen beides: Bare Metal für primäre Backups (schnelle Restores), S3 für Offsite-Kopien (geografische Redundanz).
Warum das funktioniert
Die Datenbank braucht konsistente I/O-Performance. Das ist Physik—lokale NVMe gewinnt. Die Web-Schicht braucht hohe CPU und mittleren bis hohen Speicher, aber keine ultraniedrige Storage-Latenz. Da gewinnt managed Kubernetes.
Ihre High-Transaction-Datenbank auf Kubernetes Persistent Volumes zu betreiben, fügt 5–10ms Latenz pro Query hinzu. Ihre Web-Frontends auf Bare Metal zu betreiben, verschwendet Geld und erhöht den Betriebsaufwand ohne Performance-Gewinn.
Hybrid gibt Ihnen beides: Rohperformance wo es zählt, Betriebseinfachheit wo nicht.
Die Schlüsselanforderung
Hybrid funktioniert nur, wenn alles mit allem über private Infrastruktur kommuniziert. Ihre Bare-Metal-Datenbank braucht einen schnellen, sicheren Pfad zu Ihren Kubernetes-Pods. Roundtrips über das öffentliche Internet killen den Latenzvorteil.
Was wir anbieten
Wir bauen Hybrid-Stacks. Nicht nur „hier ist ein Server, viel Glück"—echte integrierte Infrastruktur.
Bare-Metal-Fundament:
- Dedizierte Firewalls — OPNsense oder Cisco ASAv auf Hardware, die Sie kontrollieren
- Dedizierte Loadbalancer — HAProxy auf Bare Metal für vorhersehbare Performance
- Datenbankserver — NVMe-Storage für PostgreSQL, MySQL, ClickHouse oder Ihr OLAP-System
- Storage Server — 64–576TB, Supermicro Hardware, SATA oder NVMe
- High-Memory Server — bis zu 4TB DDR4 ECC
- GPU Server — dedizierte NVIDIA A2000/A6000
Managed Anwendungsschicht:
- Managed Kubernetes — RKE2-Cluster für Ihre Anwendungen und Web-Frontends
- Managed Containers — ohne Kubernetes-Komplexität
- Managed Proxmox — VM-Cluster wenn Sie klassische Virtualisierung brauchen
Die Verbindung:
- Private VLANs, die alle Komponenten verbinden
- Direkte Interconnects zwischen Bare Metal und managed Clustern
Alles in unserem AS215197 Netzwerk. Ganz ohne Hyperscaler-Preise. Ihre Bare-Metal-Datenbank kommuniziert mit Ihren Kubernetes-Pods über private Infrastruktur, nicht über das öffentliche Internet. So bekommen Sie das Beste aus beiden Welten.