Typický enterprise scénář: TCO porovnání Oracle Java vs OpenJDK (50 zaměstnanců, 5 prod workloadů, 3 CI agenti)

Níže je modelové TCO porovnání pro běžné firemní prostředí:

• 50 zaměstnanců
• 5 produkčních Java workloadů
• 3 CI/build agenti
• převažující Java verze: 8 a 11

Cílem je ukázat metodiku výpočtu a dát managementu srozumitelný rámec pro rozhodnutí. Čísla jsou orientační (nejsou cenovou nabídkou) – reálné subscription ceny se vždy odvíjí od konkrétní nabídky a metriky.

Vstupní parametry

Scénáře, které porovnáme

Scénář A – Oracle-only

Oracle Java subscription pro organizaci + standardní provoz.

Scénář B – OpenJDK standard (Azul/Temurin) + support

Standardizace runtime, enterprise support, sjednocené patchování.

Scénář C – Hybrid

Oracle pouze pro 1–2 legacy aplikace, zbytek OpenJDK + support.

1) Patch management (roční provoz)

I malé prostředí má fixní režii: testování patchů, rollout, ověřování, evidence.

Předpoklad patch programu:

• 20 h / měsíc (příprava, test, rollout, ověření, evidence)
• Koeficient složitosti:
  • standard (A/B): K = 1.0
  • hybrid (C): K = 1.3

Vzorec:

• C_patch = 12 * 20h * H * K

Výsledky:

• A: 12 × 20 × 1 200 × 1.0 = 288 000 Kč/rok
• B: 288 000 Kč/rok
• C: 12 × 20 × 1 200 × 1.3 = 374 400 Kč/rok

2) Governance & compliance režie (roční provoz)

Minimum governance se vyplatí vždy: „approved list“, CI pravidla, evidence, reporting.

Rozpad (model):

• runtime policy + approved list: 20 h/rok
• CI/CD pravidla (base image, pinned digests, SBOM, patch cadence): 30 h/rok
• evidence, reporting, auditní podklady: 20 h/rok
• školení/dev guidelines: 10 h/rok

Celkem: 80 h/rok

Vzorec:

• C_gov = 80h * H

Výsledky:

• A/B: 80 × 1 200 = 96 000 Kč/rok
• C: (hybrid +25 %) = 120 000 Kč/rok

3) Riziko auditu / compliance (Expected Loss model)

Pro ilustraci použijeme „expected loss“:

• impact (interní práce + právník + ad-hoc narovnání): 800 000 Kč
• pravděpodobnost (model):
  • A: 3 %
  • B: 1 %
  • C: 2 %

Vzorec:

• C_risk = P * Impact

Výsledky:

• A: 0.03 × 800 000 = 24 000 Kč/rok
• B: 0.01 × 800 000 = 8 000 Kč/rok
• C: 0.02 × 800 000 = 16 000 Kč/rok

4) Subscription / support (modelové roční částky)

Zde typicky vzniká největší rozdíl. Pro demonstraci použijeme orientační částky:

• A (Oracle subscription): C_support_A = 900 000 Kč/rok
• B (OpenJDK + enterprise support): C_support_B = 180 000 Kč/rok
• C (Hybrid): C_support_C = 420 000 Kč/rok

V praxi se upřesňuje podle metriky (organizace / cores / serverů / distribuce / SLA).

5) Migrace (rok 1, jednorázově)

Pro 5 aplikací je realistický „lean“ program:

• discovery + klasifikace: 16 h
• pilot (1 aplikace): 24 h
• rollout zbývajících 4: 60 h
• runbooky + CI úpravy: 20 h

Celkem: 120 h

Vzorec:

• C_mig = 120h * H

Výsledky:

• A/B: 120 × 1 200 = 144 000 Kč (rok 1)
• C: (hybrid +20 %) ≈ 173 000 Kč

6) TCO výsledky

Rok 1 (včetně migrace)

TCO(rok1) = support + patch + governance + risk + migrace

• A (Oracle-only)
  900 000 + 288 000 + 96 000 + 24 000 + 144 000
  = 1 452 000 Kč

• B (OpenJDK standard)
  180 000 + 288 000 + 96 000 + 8 000 + 144 000
  = 716 000 Kč

• C (Hybrid)
  420 000 + 374 400 + 120 000 + 16 000 + 173 000
  = 1 103 400 Kč

Rok 2+ (bez migrace)

• A: 900 000 + 288 000 + 96 000 + 24 000 = 1 308 000 Kč/rok
• B: 180 000 + 288 000 + 96 000 + 8 000 = 572 000 Kč/rok
• C: 420 000 + 374 400 + 120 000 + 16 000 = 930 400 Kč/rok

Co z toho plyne (pro tento případ)

Nejlogičtější volba pro dané vstupy je obvykle:

• Scénář B (standardizace OpenJDK + support), pokud nemáte tvrdý vendor závazek k Oracle JDK.
• Scénář C (hybrid), pokud existují 1–2 aplikace, kde je přechod rizikový (legacy knihovny, vendor appliance, certifikace).

V modelu vychází rozdíl B vs A v roce 2+:

• 1 308 000 – 572 000 = 736 000 Kč/rok.

Doporučený migrační plán (prakticky)

1) Discovery (1–2 dny)

• inventarizace: kde běží JDK 8/11, jaké image, jaké build kroky, jaký owner
• výběr cílové LTS (typicky 11 stabilizace + 17 roadmap)

2) Pilot (2–5 dnů)

• vybrat 1 aplikaci (nejméně kritickou)
• přepnout runtime na OpenJDK distribuci
• ověřit: TLS, certifikáty, latence, GC, start time, logování

3) Rollout (1–3 týdny)

• přepnout zbývající 4 workloady
• sjednotit CI agenty (toolchain) a base images
• nastavit patch cadence a evidenci

4) Stabilizace + governance (průběžně)

• runtime policy + approved list
• automatická kontrola v CI (kdo tahá Oracle JDK / staré image)
• měsíční reporting verze + EOL

Governance policy (minimum, co se vyplatí)

• Povolené runtime distribuce: OpenJDK vendor X (např. Azul/Temurin)
• Povolené verze v produkci: 11 a 17 LTS
• Zákaz non-LTS v produkci bez výjimky
• Patch pravidlo: security update do 30 dnů
• CI: pinned toolchain, build image s digestem, SBOM, dependency scanning
• Evidence: aplikace → runtime → verze → owner → datum posledního patch