🛠️ Nejdůležitější backend novinky 24.05.-31.05.2026
Backend vývoj novinky 🛠️
24.05.-31.05.2026
AWS zpřístupnilo MCP Server v ostrém provozu s plným pokrytím API a řízením přes IAM
AWS uvedlo svůj spravovaný MCP Server do režimu GA, takže AI agenti pro programování mohou standardizovaně a kontrolovaně přistupovat k AWS API, dokumentaci i provozním workflow. Novinka staví na IAM oprávněních, metrikách v CloudWatch a auditních záznamech v CloudTrail, takže firmy mají nad činností agentů lepší dohled bez rozdávání širokých přístupových údajů. Oproti preview verzi teď služba pokrývá všechna AWS API, včetně dlouhotrvajících operací a nahrávání souborů, a přidává sandbox pro běh Pythonu. Služba je zatím dostupná jen v regionech Northern Virginia a Frankfurt a samotné použití je zdarma, platí se jen spotřebované AWS prostředky.
- Pro backend a DevOps týmy je klíčové, že agenti mohou pracovat s aktuální AWS dokumentací a ověřeným přístupem k API, což snižuje chyby způsobené zastaralými znalostmi modelu.
- Bezpečnost stojí na IAM a SigV4, přičemž audit a governance zajišťují CloudTrail a CloudWatch; zároveň ale zaznívají výhrady, že chybí jemnější brány pro omezení některých akcí.
- MCP Server lze napojit na nástroje jako Claude Code, Cursor nebo Codex a přes open source MCP Proxy for AWS funguje i s lokálními AWS přihlašovacími údaji, což usnadňuje nasazení do existujících vývojářských workflow.
JDK 27 míří k uzamčení funkcí: výchozí G1 GC, kompaktní hlavičky objektů a další kolo Vector API
V ekosystému OpenJDK se pro JDK 27 posunulo několik důležitých JEPů do cílového stavu a zároveň byl potvrzen harmonogram vydání, které má dorazit 14. září 2026. Mezi hlavní novinky patří G1 jako výchozí garbage collector ve všech prostředích, kompaktní hlavičky objektů zapnuté standardně a dvanáctá inkubace Vector API. Dále se blíží dokončení podpory PEM pro kryptografické objekty, redakce citlivých dat v JFR a rozšíření jcmd pro analýzu pádů JVM. Sada funkcí se má uzamknout už začátkem června.
- Výchozí nasazení G1 GC ve všech prostředích sjednotí chování JVM bez ohledu na typ běhu, což zjednoduší provoz, ladění i očekávání výkonu mezi vývojem a produkcí.
- Kompaktní hlavičky objektů jako výchozí nastavení v HotSpotu mohou snížit paměťovou režii aplikací, což je praktické hlavně pro služby s velkým počtem objektů a tlakem na heap.
- Pro backend praxi jsou důležité i další změny: Vector API dál cílí na lepší využití SIMD instrukcí, JFR má nově skrývat citlivá data už během záznamu a jcmd má převzít část diagnostiky po pádu JVM bez nutnosti sahat po jhsdb.
OAuth Token Exchange řeší bezpečný přenos identity mezi službami
OAuth Token Exchange je rozšíření OAuth 2.0 podle RFC 8693, které umožňuje službě vyměnit existující token za nový, určený pro další krok v řetězci volání. Hodí se hlavně tam, kde požadavek prochází přes více backendových služeb, agentů nebo různých domén důvěry a původní token už není vhodný kvůli cílové službě, rozsahu oprávnění nebo auditní stopě. Klíčové jsou dva režimy: impersonace, kdy se mezislužba „schová“, a delegace, kdy token nese informaci jak o uživateli, tak o službě, která jedná jeho jménem. Právě delegace je důležitá pro AI agenty a složitější workflow, protože zachovává dohledatelnost i princip nejmenších oprávnění.
- Pro backendy je hlavní přínos v tom, že každá služba může získat token s přesně cíleným publikem a užším rozsahem oprávnění místo přeposílání původního tokenu dál napříč systémem.
- V praxi se to hodí pro mikroslužby, federaci mezi různými poskytovateli identity i pro AI agenty, kteří potřebují volat více navazujících API bez opakovaného přihlašování uživatele.
- Z bezpečnostního hlediska je zásadní ověřovat klienta při výměně tokenu, neeskalovat oprávnění, řídit vícekrokovou delegaci explicitní politikou a počítat s tím, že původní token po výměně nezaniká automaticky.
Kubernetes opraví záznamy CVE: některé starší neopravené chyby nově zasáhnou všechny verze
Projekt Kubernetes 1. června 2026 upraví záznamy několika starších CVE, u nichž bylo chybně uvedeno, že existuje opravená verze. Ve skutečnosti jde o neopravená architektonická omezení, která bez zásahu do základního fungování Kubernetes odstranit nejde. Změna se týká hlavně CVE-2020-8561, CVE-2020-8562 a CVE-2021-25740 a může způsobit, že je bezpečnostní skenery začnou nově hlásit i tam, kde dosud nefigurovaly. Pro administrátory to znamená spoléhat více na konfigurační a provozní mitigace než na čekání na patch.
- Nejdůležitější dopad pro praxi je přesnější výstup skenerů zranitelností: po opravě záznamů už nebudou falešně naznačovat, že některé verze Kubernetes jsou vůči těmto problémům chráněné.
- CVE-2020-8561 a CVE-2020-8562 vyžadují hlavně tvrdší konfiguraci API serveru a DNS vrstvy, například nižší úroveň logování, vypnutí
--profilinga nasazení lokální DNS cache jakodnsmasq. - U CVE-2021-25740 je klíčové zkontrolovat RBAC oprávnění k objektům Endpoints a EndpointSlices, hlavně u clusterů upgradovaných ze starších verzí, kde mohly zůstat příliš široké role.
Kafka míří ke cloudově nativní architektuře bez závislosti na lokálních discích
Apache Kafka prochází posunem od tradičního modelu s lokálními disky k architektuře, která odděluje výpočetní výkon od úložiště a časem může vést až k „bezdiskové“ budoucnosti. Dnes je pro praxi nejdůležitější především tiered storage, které výrazně snižuje cenu dlouhé retence přesunutím studených dat do objektového úložiště, ale zároveň přináší nové FinOps riziko v podobě poplatků za API volání. Kafka 4.0 a 4.2 navíc přidávají zásadní stavební kameny pro cloudový provoz: bezpečnější autoscaling konzumentů a Share Groups pro škálování bez navyšování počtu partition. Úplně bezdiskový provoz je zatím spíš výhled než hotová produkční volba, protože kolem latence, garbage collectu a exactly-once semantics zůstávají otevřené technické otázky.
- Tiered storage dává největší smysl pro clustery s dlouhou retencí a replay scénáři, kde může dramaticky snížit náklady na block storage, ale je nutné hlídat request amplification a ideálně mít metriky pro přiřazení nákladů ke konkrétním klientům.
- Nový rebalance protokol v Kafka 4.0 odstraňuje dřívější „stop-the-world“ chování při změnách v consumer group, takže HPA nebo KEDA podle lagu konečně dávají v Kubernetes reálný provozní smysl.
- Share Groups v Kafka 4.2 umožňují škálovat zpracování nezávisle na počtu partition, což se hodí pro frontové a background job scénáře, ale ne pro datové toky, kde je nutné zachovat striktní pořadí událostí.
LinkedIn odhalil zamrzání databáze pomocí eBPF a našel problém v kernelovém zámku
LinkedIn řešil krátké, opakující se výpadky databáze pro uživatelský feed, které trvaly jen 10 až 15 sekund a nezanechávaly žádné použitelné logy. K průlomu vedlo až off-CPU profilování přes eBPF, spuštěné automaticky ve chvíli, kdy zamrznutí nastalo. Ukázalo se, že příčinou bylo velké přidělení paměti o velikosti asi 3,5 GB, které vyvolalo blokaci na kernelovém zámku mmap_lock a zastavilo ostatní vlákna. Problém nakonec způsobovalo zvětšování velké HashMap v Rustu, které LinkedIn vyřešil jejím předalokováním.
- Pro běžné metriky a monitoring byl problém prakticky neviditelný, protože incidenty byly příliš krátké; v praxi se proto vyplatí mít připravenou automatickou diagnostiku, která se spustí hned při selhání.
- Off-CPU profilování přes eBPF pomohlo zachytit, na čem vlákna čekala, a ukázalo, že zápisový zámek mmap_lock během velké alokace blokoval další paměťové operace i obsluhu page faultů.
- Pro backend systémy citlivé na latenci je důležité hlídat růst velkých datových struktur v paměti; předalokování může zvýšit spotřebu RAM při startu, ale zabrání nečekaným špičkám a zamrzání za provozu.
Adaptivní hedged requests srazily p99 latenci o 74 % bez ručního ladění
Článek ukazuje, že hlavním viníkem špatné p99 latence v distribuovaných systémech často nejsou pády služeb, ale pomalé „stragglers“, na které klasické retry spíš škodí. Řešením jsou adaptivní hedged requests: klient pošle záložní požadavek ještě před timeoutem, ale jen tehdy, když aktuální rozdělení latencí naznačuje, že primární volání je podezřele pomalé. Pro odhad prahů v reálném čase používá DDSketch a proti přetížení při výpadku přidává token bucket rozpočet. V benchmarku pro Go HTTP transport to snížilo p99 z 65 ms na 17,3 ms při režii kolem 8,9 % a bez nutnosti staticky nastavovat timeouty.
- Pro backend praxi je klíčové rozlišit retry a hedge: retry čeká na selhání, zatímco hedge aktivně obchází pomalé odpovědi, což dává smysl hlavně ve fan-out architekturách, kde se i malé procento pomalých downstream volání násobí do špatné systémové p99.
- Statické prahy pro hedging v produkci rychle zastarávají, protože latence se mění podle zátěže, nasazení i denní doby; DDSketch s rotačním oknem umožní průběžně odhadovat třeba p90 na úrovni konkrétního hostu s minimální paměťovou i výpočetní režií.
- Nasazení je praktické jako náhrada HTTP transportu nebo gRPC interceptoru v Go, ale hodí se hlavně pro idempotentní čtení a multi-instance služby; u zápisů, CPU-saturovaných backendů nebo API se sdíleným rate limitem může hedging naopak přinést víc škody než užitku.
Meta přestavěla ingest dat z MySQL pro petabajtový provoz bez výpadků
Meta dokončila migraci platformy pro ingest dat, která denně přenáší několik petabajtů dat ze sociálního grafu v MySQL, na novou centralizovanou architekturu. Cílem bylo zvýšit spolehlivost a zjednodušit provoz bez narušení analytiky, strojového učení a dalších navázaných systémů. Přechod proběhl po etapách s nulovým výpadkem díky shadow režimu, reverse shadowingu, průběžné kontrole checksumů a připraveným rollbackům. Firma tím nahradila roztříštěné pipeline vlastněné jednotlivými týmy za spravovanou službu.
- Pro backend a datové platformy je klíčové, že Meta validovala tisíce pipeline přes porovnání počtu řádků, checksumů, latence a spotřeby prostředků ještě před přepnutím provozu.
- Architektura staví na CDC, kde má každá úloha full dump, delta změny a cílovou tabulku, zatímco metadata o schématech a tabulkách spravuje centrální řídicí služba.
- Praktický přínos migrace spočíval i v omezení drahých snapshotů: Meta minimalizovala zbytečné shadow joby a při přechodu znovu využila snapshot partitiony ze starého systému, čímž snížila zátěž infrastruktury.
Ještě nemáte odběr?
Nenechte si utéct žádnou důležitou novinku. Přidejte se k nám a získejte pravidelný informační přehled čistých faktů přímo do své schránky.