Maksym - stock.adobe.com
Java frisst das Cloud-Budget – und kann es auch retten
In fast der Hälfte aller Unternehmen sind Java-Workloads der größte Posten auf der Cloud-Rechnung. Diese Kosten lassen sich allerdings mit einigen Handgriffen senken.
Die Ergebnisse des 2026 State of Java Survey & Report von Azul, für den mehr als 2.000 Java-Professionals weltweit befragt wurden, sind eindeutig: 43 Prozent der Unternehmen weltweit – in Deutschland 35 Prozent – geben an, dass Java-basierte Workloads mehr als die Hälfte ihrer gesamten Cloud-Compute-Kosten ausmachen. Und 74 Prozent der Befragten (Deutschland: 68 Prozent) räumen ein, dass sie mehr als ein Fünftel der gebuchten Public-Cloud-Kapazität schlicht nicht abrufen. Wer diese beiden Zahlen zusammendenkt, erkennt das Ausmaß des Problems – und das Potenzial, das in einer konsequenten Optimierung der Java-Umgebung steckt.
Lizenzwechsel: notwendig, aber nicht ausreichend
Der Wechsel von Oracle Java zu einer alternativen OpenJDK-Distribution ist für viele Unternehmen derzeit ein dringendes Thema. Die Änderungen an Oracles Lizenzbedingungen haben dazu geführt, dass Unternehmen für ehemals kostenfreie Funktionen zahlen müssen – berechnet nicht nach tatsächlichem Verbrauch, sondern nach der Gesamtzahl der Mitarbeitenden, Auftragnehmer eingeschlossen. Das treibt die Kosten in die Höhe, unabhängig davon, wie intensiv Java tatsächlich genutzt wird.
Ein Wechsel auf eine vollkompatible OpenJDK-Distribution ist deshalb ein sinnvoller Schritt. Aber er allein löst das eigentliche Problem nicht: die strukturelle Ineffizienz in der Art, wie Java-Anwendungen betrieben werden. Wer nur die Lizenz tauscht und alles andere beibehält, lässt den größten Teil des Einsparpotenzials auf dem Tisch liegen. Der entscheidende Hebel liegt tiefer – in der Java-Laufzeitumgebung selbst.
Wenn Anwendungen schneller werden, sinken die Kosten automatisch
Die naheliegendste Stellschraube ist die Ausführungsgeschwindigkeit. Java-Anwendungen, die weniger Rechenzeit pro Vorgang benötigen, beanspruchen weniger vCPUs und damit weniger Budget. Der Haken: Viele Unternehmen versuchen, diesen Effekt durch Codeoptimierung zu erreichen. Das ist möglich, aber teuer und zeitaufwendig, weil es Entwicklungskapazitäten bindet, die anderswo fehlen.
Es gibt einen direkteren Weg: den Wechsel auf eine leistungsfähigere JVM (Java Virtual Machine). Unterschiedliche Laufzeitumgebungen führen denselben Code mit erheblich unterschiedlicher Geschwindigkeit aus – ohne dass eine einzige Zeile Anwendungscode angepasst werden muss. Eine modernere JVM mit intelligenteren Kompilierungsverfahren übersetzt Bytecode zur Laufzeit effizienter in Maschinenbefehle und holt so deutlich mehr Leistung aus der vorhandenen Infrastruktur heraus.
Die oben genannte Studie zeigt, dass diese Erkenntnis in der Praxis angekommen ist: 61 Prozent der Unternehmen weltweit (Deutschland: 56 Prozent) setzen eine leistungsoptimierte Java-Plattform primär deshalb ein, um ihre Anwendungsperformance zu steigern. Unter den Unternehmen, die mindestens 90 Prozent ihrer Applikationen auf Java betreiben, liegt dieser Anteil sogar bei 81 Prozent – ein klares Signal, dass intensive Java-Nutzer die JVM längst als strategischen Hebel begreifen.
Das stille Kostenproblem: bezahlte Kapazität, die niemand nutzt
Selbst wer seine Java-Anwendungen beschleunigt hat, steht vor einem zweiten, hartnäckigeren Problem: Überprovisionierung. 74 Prozent der befragten Unternehmen weltweit (Deutschland: 68 Prozent) nutzen mehr als 20 Prozent ihrer gebuchten Cloud-Kapazität nicht. Das klingt nach schlechter Planung, ist aber in Wahrheit ein rationales Verhalten unter den gegebenen Bedingungen.
Der Grund ist Erfahrung: Wer Java-Instanzen stärker auslastet, riskiert höhere Latenzen. Und höhere Latenzen bedeuten SLA-Verletzungen, schlechtere Nutzererlebnisse, im schlimmsten Fall Umsatzausfälle. Also kaufen Unternehmen lieber mehr Kapazität als nötig und lassen einen Großteil davon brach liegen.
Eine Hochleistungs-Java-Plattform verändert diese Gleichung fundamental. Wenn Anwendungen gleichmäßiger und vorhersehbarer ausgeführt werden, verschiebt sich der Punkt, an dem Latenzen ansteigen, nach oben. Jede einzelne Instanz kann mehr Last tragen, bevor die Performance leidet. Das erlaubt es, die Auslastung zu erhöhen, ohne SLA-Grenzen zu riskieren – und in der Konsequenz: weniger Instanzen zu betreiben, die dafür produktiver arbeiten. Die Einsparung entsteht nicht durch Verzicht, sondern durch Effizienz.
Skalierung funktioniert nur, wenn der Start nicht zum Problem wird
Der dritte Ansatz betrifft die zeitliche Dimension des Cloud-Betriebs. Die meisten Unternehmensanwendungen werden nicht gleichmäßig rund um die Uhr belastet. Nachts, an Feiertagen oder außerhalb der Kerngeschäftszeiten liegt der tatsächliche Bedarf weit unter dem bereitgestellten Niveau. Automatisches Skalieren – Instanzen hochfahren, wenn der Bedarf steigt, herunterfahren, wenn er sinkt – wäre die logische Antwort darauf.
In der Praxis scheitert Autoscaling bei Java jedoch häufig an der Warm-up-Problematik: Frisch gestartete Instanzen durchlaufen eine Anlaufphase, in der sie deutlich langsamer reagieren und fehleranfälliger sind. Das Risiko, in dieser Phase Nutzeranfragen zu verarbeiten, ist vielen Teams zu groß. Also laufen die Instanzen lieber permanent durch – auch dann, wenn sie kaum ausgelastet sind.
Moderne Laufzeitumgebungen lösen dieses Problem technisch: Neue Instanzen starten von Beginn an mit vorkompilierten, im Produktivbetrieb bewährten Profilen. Die Anlaufschwächen entfallen, und Autoscaling wird zu einem zuverlässigen Werkzeug, das tatsächlich eingesetzt werden kann, ohne die Servicequalität zu gefährden. Wer Instanzen konsequent hoch- und herunterfährt, zahlt nur für das, was er wirklich braucht – und nicht für Kapazitäten, die aus Vorsicht rund um die Uhr bereitstehen.
Java und KI: eine teure Kombination – oder eine effiziente
Was diese Optimierungsfragen zusätzlich dringlicher macht, ist die wachsende Rolle von Java im KI-Betrieb. Der 2026-Report zeigt: 62 Prozent der befragten Java-Professionals weltweit – in Deutschland sogar 64 Prozent – nutzen Java bereits, um KI-Funktionalität in Anwendungen zu implementieren (siehe Abbildung 1). Damit liegt Java vor JavaScript (57 Prozent) und Python (45 Prozent). Während Python die bevorzugte Sprache für die Entwicklung von KI-Modellen und Experimenten bleibt, setzt sich Java dort durch, wo KI produktiv laufen muss: in skalierbaren, sicherheitskritischen Unternehmensumgebungen.
32 Prozent der Unternehmen weltweit geben bereits an, dass mehr als die Hälfte ihrer Java-Applikationen KI-Funktionalität enthält – in Deutschland sind es 26 Prozent. Nur zwei Prozent weltweit (Deutschland: ein Prozent) arbeiten noch ohne jede KI-Integration in ihren Java-Systemen. KI-Workloads sind rechenhungrig. Wenn Java die Plattform ist, auf der sie produktiv laufen, dann multipliziert jede Ineffizienz in der Java-Umgebung die Kosten. Umgekehrt gilt: Wer seine JVM optimiert, senkt nicht nur die Betriebskosten für bestehende Anwendungen, sondern schafft auch die Grundlage dafür, KI-getriebene Innovation wirtschaftlich tragfähig zu skalieren.
Was Unternehmen bereits tun – und was noch fehlt
Die Bereitschaft zur Kostenoptimierung ist hoch: 97 Prozent der Unternehmen weltweit (Deutschland: 95 Prozent) haben bereits konkrete Maßnahmen ergriffen, um ihre Public-Cloud-Ausgaben zu senken. Zu den wirksamsten Strategien zählt dabei der Einsatz einer hochleistungsfähigen Java-Plattform – 40 Prozent der Unternehmen weltweit setzen darauf. In Deutschland führt dieser Ansatz die Rangliste mit deutlichem Abstand an, vor dem Einsatz von Cloud-Provider-Tools und Best Practices (34 Prozent) sowie KPI-Tracking für Nutzung und Kosten (33 Prozent).
„Wer Java als das begreift, was es ist – die tragende Infrastruktur für einen Großteil der Unternehmens-IT und zunehmend auch für produktiven KI-Betrieb – kommt an einer Frage also nicht vorbei: Ist die Laufzeitumgebung, auf der all das läuft, wirklich so leistungsfähig, wie sie sein könnte?“
James Johnston, Azul
Das zeigt: Die Erkenntnis, dass die JVM ein zentraler Kostenfaktor ist, hat die Praxis erreicht. Was vielerorts noch fehlt, ist der konsequente nächste Schritt – der Wechsel von punktuellen Optimierungsmaßnahmen zu einer ganzheitlichen Java-Strategie, die Lizenzentscheidungen, Laufzeitumgebung und Infrastrukturplanung zusammendenkt.
Der eigentliche Wettbewerbsvorteil liegt in der Ausführung
Schnellere Anwendungen, niedrigere Latenz, stabilerer Betrieb entscheiden darüber, wie Endnutzer eine Anwendung erleben, wie viele Transaktionen pro Sekunde verarbeitet werden können und letztlich darüber, ob ein digitales Produkt seinen Nutzern das liefert, was sie erwarten. Eine optimierte Java-Umgebung schafft also Budgetspielraum und verbessert direkt die Qualität dessen, was Unternehmen ihren Kunden bereitstellen.
Wer Java als das begreift, was es ist – die tragende Infrastruktur für einen Großteil der Unternehmens-IT und zunehmend auch für produktiven KI-Betrieb – kommt an einer Frage also nicht vorbei: Ist die Laufzeitumgebung, auf der all das läuft, wirklich so leistungsfähig, wie sie sein könnte? Die Antwort auf diese Frage hat direkten Einfluss auf die Cloud-Rechnung, die Anwendungsqualität und die Geschwindigkeit, mit der Unternehmen auf veränderte Anforderungen reagieren können.
Über den Autor:
James Johnston ist VP EMEA bei Azul und seit Juli 2023 verantwortlich für das Umsatzwachstum in der EMEA-Region. Azul gilt als führender Anbieter für kommerziell unterstütztes Java und arbeitet mit vielen der weltweit führenden Marken zusammen.
Vor seinem Wechsel zu Azul war Johnston als Group VP bei Cloudera tätig, wo er das Umsatzwachstum in der Region Northern EMEA, Afrika und Israel verantwortete und Kunden bei datengetriebenen Entscheidungen unterstützte. Davor bekleidete er bei Fujitsu UK mehr als acht Jahre lang verschiedene Führungspositionen, zuletzt als VP & Head of Products UKI. Seine Karriere begann Johnston bei Hewlett-Packard, wo er knapp zwölf Jahre in leitenden Funktionen tätig war, unter anderem als Director WW SaaS Sales mit weltweiter Verantwortung.
James Johnston studierte Business Studies an der University of the West of England (UWE) und schloss sein Studium mit einem BA (Hons) ab.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
