Apache Kafka se odvaja od diska, ali račun za cloud tek postaje vidljiv

Apache Kafka je dugo bila arhitektonska konstanta: distribuirani commit log, lokalni disk, replike, particije i dovoljno discipline da se ne pretvori u skupi prometni čvor. No cloud je taj model pogurnuo u drugom smjeru. U analizi za InfoQ, Viquar Khan opisuje Kafkin prijelaz prema cloud-native arhitekturi u kojoj više nije dovoljno samo dodavati brokere i diskove. Sada se mora mjeriti tko troši, gdje se podaci hlade, kako se consumeri šire i koliko izolacije tenant zaista dobiva.

Prvi važan pomak je tiered storage u Apache Kafki. Ideja je jednostavna, ali posljedice su velike: broker više ne mora čuvati sav povijesni log na lokalnom disku. Vrući podaci ostaju blizu computea, dok se stariji segmenti mogu preseliti u jeftiniju objektnu pohranu. Time se retencija prestaje računati isključivo kroz lokalni SSD kapacitet i broj brokera. Za organizacije koje drže duge tokove događaja zbog audita, replaya ili analitike, to mijenja ekonomiku platforme.

Drugi sloj je manje glamurozan, ali operativno presudan: FinOps telemetrija. Kafka u cloudu ne košta samo kroz storage. Račun dolazi iz compute instanci, mrežnog prometa, replikacije, cross-zone kretanja podataka, consumer lagova i loše dimenzioniranih workloadova. Zato cloud-native Kafka mora izlagati upotrebljive metrike po timu, topicu, tenant prostoru ili aplikacijskom toku. Bez toga platforma izgleda kao zajednički servis, ali se ponaša kao neprozirni troškovni centar.

Khanov tekst posebno naglašava da elastičnost nije samo pitanje broja brokera. Consumeri često određuju stvarnu korisnost event streaminga: ako zaostaju, sustav tehnički radi, ali poslovni proces kasni. Elastično skaliranje consumera zato postaje dio arhitekture, ne dodatak. U istoj logici, virtualni klasteri pokušavaju dati tenantima osjećaj odvojenog Kafka okruženja bez fizičkog umnažanja cijele infrastrukture. To je privlačno za platform timove, ali traži preciznu kontrolu kvota, izolacije i prava pristupa.

Najsvježiji dio rasprave odnosi se na Share Groups, mehanizam koji se u Kafkinoj zajednici razvija kroz KIP-932. Cilj je približiti Kafku queue obrascima u kojima više consumera dijeli obradu bez klasične krutosti consumer group particioniranja. Ako takav model sazrije, Kafka bi mogla bolje pokrivati radne redove i event streaming bez stalnog preslagivanja aplikacijske logike.

Diskless budućnost je najradikalnija točka. Umjesto da se Kafka broker i lokalni disk tretiraju kao nerazdvojni par, diskless prijedlozi guraju logiku prema modelu u kojem je trajna pohrana izdvojena, a brokeri postaju elastičniji compute sloj. To zvuči prirodno za cloud, ali nije besplatan ručak: svaka ovisnost o udaljenoj pohrani otvara pitanja latencije, dostupnosti, oporavka i ponašanja pod velikim replay opterećenjem. Drugim riječima, Kafka se može udaljiti od diska, ali ne može pobjeći od fizike distribuiranih sustava.

Zato je stvarni zaključak trezveniji od slogana o “diskless” budućnosti. Cloud-native Kafka nije jedna značajka, nego paket odluka: Apache Kafka mora zadržati pouzdanost loga, dodati bolju ekonomiku pohrane, otvoriti troškove kroz telemetriju i istodobno dati tenantima više izolacije. To je ozbiljan infrastrukturni zaokret, ne kozmetička modernizacija.