Azul vs Oracle Java: náklady, rizika a reálné scénáře ve firmách

Pokud ve firmě provozujete Java aplikace, dříve nebo později narazíte na otázku: zůstat u Oracle JDK, nebo přejít na alternativu typu Azul (Zulu / Platform Core)?
Rozhodnutí obvykle není o „technologické chuti“, ale o nákladech (TCO), compliance, auditní expozici a podpoře.

Tento článek shrnuje, jak se na srovnání dívat prakticky a jaké scénáře v praxi vídáme nejčastěji.

1) Co přesně porovnáváme

Aby srovnání dávalo smysl, ujasněte si tyto dimenze:

• Distribuce JDK/JRE: Oracle JDK vs Azul (Zulu / Platform Core) vs jiné OpenJDK distribuce
• Způsob použití: produkce / vývoj / test / CI / build farmy / kontejnery
• Topologie: on-prem / cloud / hybrid / VDI / desktop fleet
• Požadovaná podpora: SLA, reakční doby, LTS údržba, bezpečnostní backporty
• Rizikový profil: auditní expozice, interní governance, regulatorní požadavky

2) TCO: z čeho se skládá „cena Java“

Když firmy říkají „Oracle je drahý“, často tím myslí více věcí najednou. Praktické TCO se typicky skládá z:

1. Licenční poplatek / subscription
   Nejen „kolik to stojí“, ale i jak se to počítá (metrika) a jak rychle to roste při rozšiřování infrastruktury.

2. Náklady na compliance
   Evidence instalací, klasifikace prostředí, interní procesy, kontroly, právní výklady, schvalování výjimek.

3. Auditní riziko a dopady
   Čas lidí, externí konzultace, potenciální doplatky, reputační dopady, tlak na rychlá rozhodnutí.

4. Provozní dopady
   Patching cadence, stabilita, kompatibilita, incidenty, dlouhodobá udržitelnost.

5. Migrace a změnové řízení
   Testy, release okna, komunikace s vlastníky aplikací, případné výjimky a dlouhodobé výluky.

3) Proč firmy přecházejí na Azul (nebo jiné OpenJDK)

3.1 Předvídatelnost a nižší „compliance overhead“

U alternativních OpenJDK distribucí (včetně Azul) firmy často získají:

• jednodušší licenční „story“ pro typické enterprise scénáře,
• snížení auditního stresu (zejména pokud interně přepnete standard na non-Oracle JDK),
• lepší možnost standardizace napříč týmy a platformami.

3.2 Podpora a dlouhodobá údržba

Klíčové je, aby distribuce nabízela:

• bezpečnostní aktualizace,
• backporty pro LTS verze,
• transparentní support model a jasně definované SLA.

3.3 Minimální zásah do aplikací

V typických případech je migrace:

• bez změny kódu,
• s důrazem na testování a ověření kompatibility (TLS, kryptografie, specifické knihovny, certifikáty, runtime flags).

4) Kdy dává Oracle JDK smysl

Existují situace, kdy je Oracle JDK legitimní volba, například pokud:

• máte konkrétní komerční závazky, které Oracle JDK vyžadují,
• potřebujete specifické podmínky podpory nebo kompatibility v rámci ekosystému,
• máte „vyčištěnou“ evidenci a jasný licenční rámec, který je pro vás akceptovatelný.

Prakticky ale platí: pokud nedokážete s vysokou jistotou říct, kde všude Oracle Java běží (včetně CI a kontejnerů), roste vám riziková složka TCO.

5) Typické scénáře ve firmách

Scénář A: „Neviditelná Java“ (nejčastější)

• Java je na serverech, desktopech, v CI, v kontejnerech i v toolingu.
• Nikdo nemá kompletní inventory.
• Objevují se různé verze a mix vendorů.

Doporučení: inventarizace + klasifikace + standardizace runtime (často na non-Oracle JDK).

Scénář B: „Audit readiness“

• Firma chce snížit riziko a mít jasný příběh pro management a právní tým.
• Potřebuje podklady, které ustojí kontrolu (interní i externí).

Doporučení: licenční vyhodnocení, riziková mapa, akční plán, governance a kontrolní mechanismy.

Scénář C: „Cloud cost pressure“

• Java workload v cloudu roste (počty instancí i CI agentů).
• Každá změna metriky/licencování se násobí.

Doporučení: runtime strategie, sjednocení LTS verze, proces patchingu, cost model a standardizace build image.

6) Praktický rámec rozhodnutí (krok za krokem)

1. Scope & cíle
   Co chcete vyřešit: auditní riziko, náklady, standardizaci, bezpečnost, nebo kombinaci?

2. Discovery (inventarizace)
   Servery, desktopy, kontejnery, CI/build, image registry, runtime v toolingu.

3. Normalizace a deduplikace
   Odstranit duplicity, sjednotit pojmy (aplikace, instance, prostředí) a rozpadnout to na „spravovatelné celky“.

4. Vyhodnocení dopadů
   Rizika, compliance, nákladový model, scénáře a doporučená roadmapa.

5. Pilot migrace
   Vybrat reprezentativní aplikace a ověřit kompatibilitu na cílové distribuci.

6. Rollout + governance
   Standard runtime, pravidla výjimek, patching cadence, CI hardening, reporting a kontrola.

7) Co si odnést

• „Cena Java“ není jen licence: TCO = licence + compliance + audit + provoz + změny.
• Pokud dnes nemáte inventory, první krok je discovery a normalizace.
• Přechod na Azul/OpenJDK bývá v praxi cesta k:
  • nižšímu riziku,
  • vyšší předvídatelnosti,
  • lepší standardizaci.

Chcete rychlý odhad dopadů ve vaší firmě?

Typicky během 1–2 týdnů podle rozsahu připravíme:

• inventarizaci Java prostředí,
• licenční a rizikovou mapu,
• doporučení a roadmapu (včetně migrace),
• podklady pro management a auditní připravenost.

Pokračujte na stránku Java Assessment nebo nám napište přes kontakt.