Warum Unternehmen ihre Rechenleistung neu zusammensetzen müssen

Welches Compute-Modell passt zu welchem Workload? Wie Unternehmen GPUs, Serverless und Container heute pragmatisch kombinieren, und warum Observability dabei zur Schlüsselrolle wird.

Cloud-Infrastrukturen werden zunehmend orchestriert. Workloads wandern zwischen Container-Plattformen, Serverless-Angeboten und spezialisierten Instanzen, je nachdem, was für Performance, Kosten und Betriebsaufwand gerade am sinnvollsten ist. Der „State of Containers and Serverless“-Report von Datadog zeichnet das Bild einer Cloud-Nutzung, die pragmatischer und stärker von Optimierungszielen getrieben wird.

Unternehmen bauen nicht auf ein einziges Compute-Modell, stattdessen entsteht eine hybride Praxis, in der GPU-Ressourcen für datenintensive Aufgaben an Bedeutung gewinnen, Autoscaling neu justiert wird und Arm-Architekturen als Effizienzhebel in den Fokus rücken.

Spezialisierter Compute: GPUs werden zum strategischen Baustein

Mit dem Wachstum von KI-Anwendungen verschiebt sich die Compute-Logik. Organisationen beginnen, GPUs für datenintensive Workloads wie KI-Training und Inferenz einzusetzen. Denn gegenüber General-Purpose-CPUs bringen GPUs für bestimmte KI-Workloads deutliche Vorteile bei Performance und Kosten-Effizienz.

Gleichzeitig rückt eine Frage in den Vordergrund, die in vielen IT-Teams lange eher nachrangig war. Wie gut sind teure Spezialressourcen wirklich ausgelastet? GPU-Umgebungen müssen daher eng überwacht und Allokationen nachjustiert werden, um freie Kapazitäten zu reduzieren. Selbst wenn ein Team heute noch keine GPUs nutzt, lohnt es sich, die Angebote der Cloud-Provider für GPUs und weitere Spezialhardware wie FPGAs und ASICs frühzeitig zu kennen, um im Bedarfsfall schnell skalieren zu können.

Praktisch heißt das: KI verändert nicht nur Applikations-Stacks, sondern auch Beschaffungs- und Betriebsentscheidungen, bis hin zur Frage, welche Telemetrie man zwingend braucht, um Kosten und Nutzen in Einklang zu halten.

Autoscaling: Effizienz durch bessere Signale

Autoscaling gilt vielerorts als Standard, dennoch sind weiterhin viele Kubernetes-Cluster überprovisioniert. Obwohl gewisse Reserven für Stabilität nötig sind, können durch die richtige Konfiguration beim Autoscaling Ressourcen noch gezielter an den tatsächlichen Bedarf angepasst werden, ohne die Einhaltung von Performancezielen zu riskieren.

Dafür sind zwei Schritte zentral:

1. Bewusste Toolwahl: Teams sollten prüfen, welche Autoscaling-Werkzeuge zu ihren Anforderungen an Flexibilität, Kontrolle und Einfachheit passen.
2. Signalqualität: Skalierungsregeln auf die Signale stützen, die das Verhalten der Anwendung wirklich abbilden. Oft reichen CPU- und Memory-Auslastung aus. Aber sobald Workloads nicht primär CPU- oder RAM-limitiert sind, können anwendungsnahe Metriken wie Queue-Tiefe oder Request-Rate deutlich bessere Trigger sein, weil sie den tatsächlichen Engpass besser abbilden.

Das passende Compute-Modell: nicht standardisieren, sondern zuordnen

Compute ist heute ein Portfolio und es ist wenig sinnvoll, alles über einen einzigen Ansatz abzubilden, wenn die Cloud längst Alternativen bietet, die für unterschiedliche Profile besser passen. Die Kernfrage ist daher nicht „Serverless oder Container?“, sondern „Welche Umgebung ist für diesen Workload die effizienteste und zuverlässigste?“

• Serverless: Für eventgetriebene oder stark schwankende („spiky“) Workloads sind Serverless-Plattformen attraktiv, weil sie schnell skalieren und eine nutzungsbasierte Abrechnung ermöglichen.
• Managed Container-Plattformen: Für langlebige Services oder Anwendungen mit stärkerem Infrastrukturbezug sind diese die pragmatische Wahl, weil sie viel Betrieb „mitbringen“ und den Overhead reduzieren. 
• Selbst betriebenes Kubernetes: Wenn maximale Kontrolle und Flexibilität gefragt sind, kann ein solches Set-up sinnvoll sein allerdings nur, wenn man bereit ist, den dafür nötigen Betriebsaufwand wirklich zu tragen.

In der Praxis bedeutet das: Workloads regelmäßig neu zu bewerten und dabei auch interne Gewohnheiten zu hinterfragen. Gerade dort, wo ein Unternehmen historisch nur wenige Services nutzt, entstehen schnell implizite Regeln, die sinnvolle Platzierung verhindern.

Arm als Effizienzhebel: Kostenoptimierung über Architektur 

Neben GPUs rücken ARM-Architekturen immer stärker in den Fokus, weil ihre Verwendung bei CPU-basierten Workloads eine Möglichkeit bietet, Kosten zu optimieren, ohne zwangsläufig Performance einzubüßen. ARM steht für hohe Kerndichte und energieeffizientes Design und eignet sich besonders für Serving-Szenarien mit niedriger Latenz oder hohem Durchsatz.

Der Ansatz für eine Bewertung sollte immer “testen, messen, vergleichen” sein. Erst die wichtigsten Workloads auf Arm pilotieren (Kompatibilität, Performance, potenzielle Einsparungen), dann die Adoption über Zeit nachverfolgen und prüfen, ob Migrationen den erwarteten Preis-/Performance-Effekt tatsächlich liefern.

Was moderne Cloudnutzung auszeichnet

Das Monitoring von GPUs, Serverless-Funktionen und Container-Workloads wird immer wichtiger, da es dabei hilft, Unterauslastung zu erkennen, Skalierung zu bewerten und Migrationen zu begleiten. Observability wird hierbei zum Enabler, denn transparente Telemetrie ist eine Grundvoraussetzung, um Cloud-Strategien iterativ zu optimieren.

Am Ende geht es weniger um „die eine richtige Architektur“ als um eine grundlegende Ausrichtung. Cloudnutzung ist ein kontinuierlicher Entscheidungsprozess. Wer seine Workloads beobachtet, die Umgebung bewusst auswählt und Optimierung als laufende Praxis versteht, kann Performance, Kosten und operativen Aufwand deutlich besser ausbalancieren.