Azul vs Oracle: náklady, update politika a migrační scénář

Tento článek je určen pro IT manažery, architekty a compliance role, kteří potřebují udělat informované rozhodnutí: ponechat Oracle Java (a případně platit subscription) nebo standardizovat na OpenJDK distribuci (např. Azul Zulu / Azul Platform Prime, Temurin apod.) a snížit licenční i auditní rizika.

Poznámka: Konkrétní ceny a licenční metriky se mohou měnit a závisí na smluvních podmínkách a regionu. Níže je praktický rámec, jak náklady počítat a co porovnávat.

1) Co ve skutečnosti tvoří „náklady na Javu“

Když firma řekne „Java je drahá“, obvykle tím myslí kombinaci:

Licenční/subscription náklady (pokud jsou potřeba)
Náklady na aktualizace a bezpečnost (čas, procesy, testování)
Auditní riziko (právní/finanční dopad, interní kapacity)
Provozní riziko (zranitelnosti, výpadky, incidenty)
Inženýrská práce (standardizace runtime, CI/CD, image governance)
Vendor management (smlouvy, support, SLA, komunikace)

Dobré rozhodnutí vyžaduje posoudit TCO (Total Cost of Ownership), ne jen cenu licencí.

2) Oracle Java: typický nákladový „spouštěč“

U Oracle Java je nejčastější rozpočetový problém, že firma:

historicky používala Oracle JDK (8/11),
rozšířila instalace napříč servery, build agenty, desktopy,
a později zjistila, že pro určité použití je potřeba subscription (nebo že bez subscription není dlouhodobě zajištěný update stream a support).

Hlavní praktický dopad

licenční metrika (např. „employee-based“ model v některých scénářích) umí v některých organizacích dramaticky navýšit náklady oproti očekávání, protože je „svázaná“ s velikostí firmy, nikoliv s počtem JVM.

3) OpenJDK/Azul: kde vzniká úspora a kde jsou hranice

OpenJDK (včetně vendor buildů) typicky přináší:

nižší licenční tlak (v závislosti na zvolené distribuci a support modelu),
jednodušší standardizaci (když firma přejde na jednotný runtime),
nižší auditní stres (zejména pokud eliminujete Oracle JDK v produkci a CI).

Kde je potřeba být realistický:

i při „bezplatném runtime“ máte náklady na governance, patchování, testy a rollout,
a pokud chcete enterprise support, bude to placené (ale často s předvídatelnější strukturou).

4) Update politika: proč je to klíčové pro security a compliance

V praxi rozhoduje odpověď na otázku:

„Dostanu bezpečnostní aktualizace pro verzi, kterou provozuji, a jak dlouho?“

Doporučený přístup:

vybrat LTS verzi (např. 17 nebo 21 dle vašeho stacku),
vybrat distribuci, která má jasný model patchování,
nastavit patch management (měsíční/kvartální rytmus, testovací pipeline).

Co porovnávat u dodavatelů

dostupnost security patchů pro LTS
délka podpory (horizont)
SLA pro support (reakční doby, eskalace)
dostupnost buildů pro vaše platformy (Linux/Windows/macOS, ARM/x86, kontejnery)
dokumentace a auditovatelnost (SBOM, release notes, CVE komunikace)

5) Jak srovnat náklady: jednoduchý TCO model (šablona)

Krok A: inventarizace rozsahu

Sečti:

počet serverů / VM / kontejnerových workloadů, kde běží Java
počet CI/build agentů
počet desktopů s JDK/JRE (pokud relevantní)
kritičnost aplikací (tier 1/2/3)

Krok B: cost drivers (proměnné)

Použij proměnné:

E = počet zaměstnanců (nebo relevantní licenční metrika)
J = počet JVM/instancí v produkci
B = počet build agentů
T = počet technologických domén / aplikačních týmů
H = hodinová cena interních kapacit

Krok C: TCO (orientačně)

Subscription: SUB_ORACLE(E) nebo SUB_VENDOR(J/B)
Patch management: PATCH = (T * hodiny_na_release * H)
Governance: GOV = (čas na standardizaci + CI hardening + image policy) * H
Riziko: RISK = (pravděpodobnost incidentu/auditu * očekávaný dopad)
(tady nejde o exaktní číslo, ale o srovnání scénářů)

Výstupem je srovnávací tabulka scénářů, ne „jedno magické číslo“.

6) Doporučené scénáře pro rozhodnutí (prakticky)

Scénář 1: „Oracle-only“ (subscription + governance)

Vhodné, když:

máte silnou smluvní pozici u Oracle,
chcete jednotného vendora napříč stackem,
vyžadujete konkrétní Oracle support režim.

Rizika:

nákladová citlivost na licenční metriku,
vendor lock-in.

Scénář 2: „OpenJDK standard“ (Azul/Temurin/… + jasná pravidla)

Vhodné, když:

chcete snížit licenční tlak a auditní stres,
chcete předvídatelnou politiku aktualizací,
chcete standardizovat runtime napříč firmou.

Rizika:

vyžaduje řízenou migraci a governance (jinak vznikne “JDK zoo”).

Scénář 3: „Hybrid“ (Oracle jen tam, kde má smysl; jinak OpenJDK)

Vhodné, když:

část aplikací je z historických důvodů navázaná na Oracle stack,
ale většina workloadů může běžet na standardním OpenJDK.

Rizika:

governance musí být ještě přísnější (jinak chaos).

7) Migrační scénář (end-to-end) pro firmu

Fáze 1: Discovery a klasifikace (1–3 týdny)

detekce runtime (vendor, verze, path)
mapování na aplikace a týmy
klasifikace: produkce / dev / test / build / desktop

Výstup: inventář + riziková mapa (kde je Oracle JDK a proč)

Fáze 2: Standardizace cílové platformy (1–2 týdny)

volba LTS (např. 17/21)
volba distribuce (např. Azul Zulu/Prime, Temurin…)
definice policy: “approved JDK list”, release cadence, image policy

Výstup: „Java Runtime Standard“ (krátký interní standard)

Fáze 3: Pilot (2–6 týdnů)

1–3 aplikace různých typů (web, batch, integrace)
otestovat: performance, TLS, crypto policy, container base images, monitoring

Výstup: pilotní report + checklist pro rollout

Fáze 4: Rollout (iterativně)

migrační vlny (tier 3 → tier 2 → tier 1)
CI/CD standard: build image, runtime image, pinned digests, SBOM, scanning

Výstup: stabilní provoz, jednotné aktualizace, auditní připravenost

Fáze 5: Stabilizace a průběžná compliance

měsíční/kvartální patch okna
metriky: % standardizovaných runtime, age of runtime, CVE exposure
periodické interní audity (např. kvartálně)

8) Co obvykle přinese největší „rychlou“ úsporu

Eliminace Oracle JDK v CI/build (často skryté množství instalací)
Standardizace kontejnerových image (jedna runtime base image)
Sjednocení na jednu LTS verzi (méně testování, méně incidentů)
Zákaz ad-hoc instalací (repo, policy, schvalování)

9) Doporučení na závěr

Pokud chceš udělat rozhodnutí rychle a profesionálně:

udělej inventarizaci a klasifikaci (produkce vs build vs dev),
sestav 2–3 scénáře TCO (Oracle-only vs OpenJDK standard vs Hybrid),
vyber cílovou LTS a zaveď „Java Runtime Standard“,
spusť pilot a pak rollout ve vlnách.