Cloudflare satte i gang en ny runde i kampen om strømmedata 1. oktober 2026. Selskapet åpnet offentlig beta for K2, en serverless tjeneste for hendelsesstrømming bygget direkte på R2-lagringen. Produktet skal gjøre det mulig å sende, lagre og lese store mengder hendelser uten å drifte en eneste broker-klynge, og det sikter rett mot Apache Kafka, et system som har dominert sanntidsdata siden tidlig 2010-tall. Lanseringen skjedde under Cloudflares årlige “Birthday Week”, sammen med generell tilgjengelighet for dataplattformen Basin.
For nordiske utviklere og IT-ledere er dette mer enn en produktnyhet. Mange skandinaviske selskaper bygger allerede på Cloudflares Workers og R2, og et serverless alternativ til Kafka kan kutte både driftskostnader og personellbehov. Samtidig reiser det spørsmål om datasuverenitet, prisrisiko ved høy bruk og hvor moden tjenesten faktisk er bak markedsføringen. Denne analysen går gjennom tallene, sammenligner K2 med de etablerte alternativene og vurderer hva lanseringen betyr for skymarkedet fremover.
Hva er Cloudflare K2?
Cloudflare beskriver K2 som en “durable event streaming primitive” på selskapets utviklerplattform. I praksis betyr det at applikasjoner sender hendelser til en K2-strøm, som lagrer dem som en ordnet logg. Konsumenter kan deretter lese dataene på flere måter: de kan dele opp lesingen mellom flere forbrukere i en gruppe, eller la alle meldinger gå til alle konsumenter samtidig. Modellen minner om hvordan Kafka håndterer partisjoner og konsumentgrupper, men uten at kunden selv må sette opp og vedlikeholde brokere.
Den store forskjellen fra tradisjonell Kafka-drift ligger i lagringslaget. K2 bruker Cloudflares objektlagringstjeneste R2 som fundament i stedet for lokale disker knyttet til brokernoder. Det gjør at tjenesten kan skalere lagringen uavhengig av beregningskraften, og Cloudflare hevder dette gir plass til lange retensjonsperioder uten at kostnadene løper løpsk. Selskapet fremhever at selv lange perioder med nede tid hos en konsument ikke fører til tapt data, fordi hendelsene ligger trygt i R2 til de hentes ut. Du finner den offisielle lanseringsomtalen hos Cloudflare og teknisk dokumentasjon hos Cloudflare Developers.
Lanseringen under Birthday Week 2026
Cloudflare bruker tradisjonelt sin årlige “Birthday Week” i slutten av september og starten av oktober til å slippe en bølge med nye produkter. I 2026 inkluderte denne uken generell tilgjengelighet for Basin, dataplattformen bygget på Apache Iceberg og R2 som lar kunder spørre store datasett uten å betale for utgående trafikk. K2 kom ut samtidig, men i offentlig beta heller enn full tilgjengelighet. Det er et bevisst valg fra Cloudflare: selskapet ønsker tilbakemeldinger fra reelle arbeidslaster før det låser prismodellen og garanterer funksjonalitet.
Samme uke fikk Cloudflare Containers en oppdatering som lar brukere velge image og instanstype ved kjøretid, med containere som starter seks ganger raskere enn tidligere, samt filsystem-øyeblikksbilder i offentlig beta. Til sammen tegner dette et bilde av en plattform som prøver å dekke stadig flere lag i applikasjonsstabelen, fra kjøring av kode i Workers til lagring i R2, strømming i K2 og analyse i Basin. Du kan lese mer i Cloudflares egen oppsummering av uken.
Den tekniske arkitekturen: partisjonert logg på R2
Under panseret implementerer K2 det Cloudflare kaller en partisjonert, holdbar logg oppå R2-lagringen. Produsenter og konsumenter er atskilt, slik at en applikasjon kan skrive hendelser uten at noen leser dem med en gang, og en annen tjeneste kan hente dem ut timer eller dager senere. Denne frikoblingen er selve poenget med hendelsesstrømming: systemer som ellers ville vært tett koblet sammen, kan jobbe uavhengig av hverandre og i sitt eget tempo.
Det som foreløpig mangler i den offentlige dokumentasjonen, er detaljer om transaksjoner, nøyaktig-én-gang-semantikk, log-komprimering og et skjemaregister tilsvarende det Kafka-økosystemet har bygget opp over et tiår. Disse manglene betyr ikke at K2 er en dårlig tjeneste. De betyr at selskaper som vurderer å flytte en eksisterende Kafka-arbeidslast, bør sjekke funksjonslisten nøye før de bytter, i stedet for å anta full kompatibilitet fordi Cloudflare bruker ordet “alternativ”.
Et konseptuelt eksempel på hvordan en produsent kan se ut i pseudokode, illustrerer flyten uten å påstå at dette er eksakt offisiell syntaks:
// Konseptuell pseudokode for å illustrere K2-flyten
async function produserHendelse(stream, data) {
await stream.send({
key: data.id,
payload: JSON.stringify(data),
timestamp: Date.now()
});
}
async function konsumerHendelser(stream, gruppeId) {
for await (const hendelse of stream.subscribe(gruppeId)) {
behandle(hendelse.payload);
}
}Poenget med eksempelet er arkitekturen, ikke den nøyaktige API-en. Produsenten skriver til en navngitt strøm, og en eller flere konsumentgrupper leser derfra i sitt eget tempo, akkurat slik Cloudflare beskriver modellen i sin dokumentasjon.
Prising i beta: gratis, men med klare grenser
Under betafasen er K2 gratis å bruke, men tilgangen er begrenset til kontoer med et Workers Paid-abonnement. Lagringen er begrenset til 10 GB per konto, og hver strøm tåler maksimalt 30 MB/s i produksjonstrafikk. Dette er grenser som fungerer fint for prototyper og mindre produksjonsarbeid, men som raskt blir en flaskehals for selskaper med høyt datavolum, for eksempel IoT-flåter, finanstransaksjoner eller sanntids klikkstrøm-analyse.
Cloudflare har vært tydelig på at dette er en betaversjon, og at både grensene og den endelige prisen kan endre seg før allmenn tilgjengelighet. Det er verdt å ta med seg for alle som vurderer å bygge kritisk infrastruktur på toppen av K2 akkurat nå: betaen er et sted å teste konseptet, ikke nødvendigvis stedet å kjøre produksjonstrafikk selskapet er avhengig av i dag.
Forventet prising etter beta: $0,04 per GB
Cloudflares dokumentasjon oppgir foreløpige, ikke endelige, satser for perioden etter beta. Produsert data skal koste 0,04 dollar per GB, konsumert data skal også koste 0,04 dollar per GB, og lagret data skal koste 0,02 dollar per GB per måned. Satt sammen gir det et konkret regnestykke: en arbeidslast som produserer 1 TB, leser den samme 1 TB én gang, og i snitt lagrer 1 TB over en måned, ender på omtrent 100 dollar i bruk, fordelt på 40 dollar for produksjon, 40 dollar for konsum og 20 dollar for lagring.
Modellen er enkel å forstå sammenlignet med konkurrerende tjenester som prissetter etter delte timer, partisjoner eller forespørsler. Den enkelheten er en styrke for mindre team uten en dedikert FinOps-funksjon, men den skjuler samtidig en felle som blir tydelig så snart flere konsumenter kommer inn i bildet.
Fan-out-fellen: når flere konsumenter gir høyere regning
Fordi K2 priser konsum per GB lest, multipliseres kostnaden når flere uavhengige konsumenter leser de samme dataene. Ti separate konsumenter som hver leser den samme 1 TB-strømmen, skaper til sammen 10 TB i fakturerbart konsum. Med de anslåtte satsene betyr det rundt 400 dollar bare i lesekostnader, før produksjon og lagring legges til. Diskusjoner på utviklerforumet Hacker News har pekt nettopp på denne mekanikken: prisingen per GB kan være gunstig for arbeidslaster med mange små meldinger, fordi regningen ikke er knyttet til antall meldinger, men den kan straffe applikasjoner der mange tjenester abonnerer på samme strøm.
For arkitekter som planlegger en migrering betyr dette at fan-out-mønsteret må kartlegges tidlig. En arkitektur med én produsent og én konsument kan bli svært rimelig på K2. En arkitektur med én produsent og ti forskjellige team som hver kjører sin egen kopi av konsumentlogikken, kan fort bli dyrere enn en tilsvarende Kafka-klynge driftet internt, selv om man legger til lønnskostnadene for driftsteamet.
K2 mot Kafka, Confluent, Kinesis, Event Hubs og Pub/Sub
Strømmemarkedet har flere etablerte aktører, og de løser problemet på ulike måter. Apache Kafka er selve referansepunktet: en distribuert, append-only logg som kunden driver selv eller kjøper som administrert tjeneste. Confluent Cloud bygger videre på Kafka-protokollen og legger til skjemaregister, styring og innebygd strømbehandling. Amazon Kinesis Data Streams og Amazon MSK dekker AWS-siden, der MSK er en administrert Kafka-tjeneste mens Kinesis bruker AWS’ egen shard-modell. Azure Event Hubs tilbyr et Kafka-kompatibelt endepunkt for Microsoft-kunder, og Google Cloud Pub/Sub er en global meldingstjeneste som ligner mer på et meldingssystem enn en ordnet logg.
| Tjeneste | Grunnmodell | Krever egen klyngedrift | Kafka-kompatibel | Hovedstyrke |
|---|---|---|---|---|
| Cloudflare K2 | Serverless logg på R2 | Nei | Nei | Ingen broker-drift, tett Workers-integrasjon |
| Apache Kafka | Distribuert append-only logg | Ja (selvdriftet) | Ja (referanse) | Modent økosystem, brede koblinger |
| Confluent Cloud | Administrert Kafka | Nei | Ja | Skjemaregister, styring, strømbehandling |
| Amazon Kinesis | Shard-basert strøm | Delvis | Nei | Dyp AWS-integrasjon |
| Amazon MSK | Administrert Kafka på AWS | Delvis | Ja | Kafka-verktøy med AWS-drift |
| Azure Event Hubs | Administrert hendelsesinntak | Nei | Ja (endepunkt) | Azure-integrasjon, høy inntakskapasitet |
| Google Cloud Pub/Sub | Globalt meldingssystem | Nei | Nei | Global rekkevidde, enkel push/pull-modell |
Tabellen viser hvorfor en direkte prissammenligning er vanskelig. Konkurrentene bruker ulike måleenheter, som delte timer, partisjonsantall, broker-instanser eller forespørsler, mens K2 bruker en ren per-GB-modell. Det gjør K2 lett å forklare for et utviklerteam, men vanskelig å sette opp mot et Kinesis- eller Event Hubs-budsjett uten å regne om til et felles sammenligningsgrunnlag først.
Er K2 egentlig en Kafka-erstatning?
Cloudflare selv omtaler K2 som et alternativ til Kafka, ikke som en implementasjon av Kafka. Det er en viktig nyanse. Kafka-brukere støtter seg typisk på klienter og wire-protokoller, konsumentgrupper med partisjonstildeling, log-komprimering, transaksjoner med idempotente produsenter, et skjemaregister, Kafka Connect-koblinger og verktøy som Kafka Streams eller Flink. Lanseringsmaterialet bekrefter ordnede strømmer, holdbar lagring og flere konsummønstre, men det bekrefter ikke full paritet med alle disse funksjonene.
For et selskap som allerede har bygget store deler av datainfrastrukturen rundt Kafkas økosystem, vil et bytte til K2 trolig kreve betydelig omskriving av koblinger og klientbibliotek, ikke en enkel endepunktsbytte. For et nytt prosjekt uten historisk gjeld er regnestykket et helt annet: her kan den enklere driftsmodellen veie tyngre enn den manglende modenheten.
Fra LinkedIn i 2011 til serverless strømming
Apache Kafka ble opprinnelig utviklet hos LinkedIn og åpnet som åpen kildekode i 2011. Suksessen kom fra en kombinasjon av holdbare append-only-logger, muligheten til å spille av hendelser på nytt, partisjonert horisontal skalering, konsumentgrupper og høy gjennomstrømming via sekvensiell disk-I/O. Kafka ble etter hvert en grunnstein i moderne dataarkitektur, men den operasjonelle modellen krever fortsatt nøye styring av partisjoner, brokere, replikering, lagring, oppgraderinger og lastbalansering.
Markedet har siden beveget seg gjennom flere faser: først selvdriftet Kafka, deretter administrerte Kafka-tjenester som Confluent Cloud og Amazon MSK, så sky-native alternativer som Kinesis, Event Hubs og Pub/Sub, og nå en bølge av serverless hendelsesbusser og meldingstjenester. K2s R2-baserte design følger den samme trenden mot å skille beregning, loggservering og holdbar lagring fra hverandre. Det nye med K2 er ikke selve ideen om en ordnet hendelseslogg, men Cloudflares forsøk på å kombinere den idéen med kanteksekvering, objektlagring og serverless distribusjon i ett og samme produkt.
K2s plass i Cloudflares utviklerplattform
K2 kommer ikke alene. Cloudflare har fra før meldingskøen Queues og dataflytverktøyet Pipelines, og flere av konkurrentens egne skribenter har pekt på at kunder nå må velge mellom tre beslektede produkter avhengig av bruksmønster. Queues passer for enkle, kortvarige meldingskøer. Pipelines passer for å flytte strømmedata rett inn i analyseverktøy. K2 passer når man trenger en holdbar, lesbar-på-nytt logg med lang retensjon og flere konsumentgrupper.
Satt i sammenheng med resten av plattformen fungerer stykkene slik: Workers kjører applikasjonslogikken nær brukeren, Durable Objects holder på tilstand som krever sterk konsistens, K2 flytter hendelser asynkront mellom tjenester, R2 lagrer alt i stor skala, Containers tar imot arbeidslaster som ikke passer Workers-modellen, og Basin gjør dataene tilgjengelige for analyse uten egne kostnader for utgående trafikk. Strategien er tydelig: Cloudflare vil at kundens hele applikasjonsstabel, fra kjøretid til lagring og analyse, skal leve på ett og samme nettverk.
Markedseffekt: utfordrer K2 hyperskalerne?
Strømmedata er i dag spredt over flere overlappende kategorier: hendelsesstrømming, meldingskøer, sanntids dataintegrasjon, strømbehandling og det som ofte kalles “data-in-motion”-infrastruktur. Disse kategoriene gir ulike markedstall avhengig av hvordan analytikerne definerer omfanget, og det finnes foreløpig ingen offentlig, navngitt analytikerrapport som tallfester et samlet 2026-marked spesifikt for denne typen serverless strømmetjenester. Det er derfor mer presist å beskrive effekten kvalitativt enn å sette et tall på den.
Det som derimot er tydelig, er retningen. Ved å flytte strømming inn i et rammeverk der kunden allerede kjører Workers og lagrer data i R2, gjør Cloudflare det vanskeligere å rettferdiggjøre en separat Kafka-klynge eller en frittstående AWS-, Azure- eller GCP-tjeneste for de samme dataene. Dette er den samme mekanismen som har gjort Workers til en reell konkurrent mot Lambda@Edge og Fastly Compute: ikke nødvendigvis bedre rå ytelse på hvert enkelt mål, men lavere total friksjon når alt henger sammen i én plattform. Det finnes heller ingen bekreftet, kilde-attribuert kursbevegelse for Cloudflare-aksjen (NET) direkte knyttet til K2-lanseringen per 7. oktober 2026, og enhver påstand om det bør behandles med forsiktighet gitt hvor mange andre faktorer som påvirker aksjekurser samtidig.
Relevans for Norge og Norden: datasuverenitet og GDPR
For norske og nordiske selskaper kan K2 være attraktivt av flere grunner. Cloudflares kantnettverk kan redusere forsinkelsen mellom applikasjon og hendelsessystem for tjenester med brukere spredt over flere land. Mindre team slipper å bemanne en egen Kafka-driftsfunksjon. Og en serverless strømmetjeneste kan redusere avhengigheten til én enkelt hyperskaler for deler av dataflyten.
Samtidig følger ikke datasuverenitet automatisk med bare fordi man bruker Cloudflare. Nordiske innkjøpere bør konkret avklare hvor hendelsesdataene faktisk lagres fysisk, om R2 og K2 støtter valg av region eller lagring kun i EU/EØS, hvordan replikering og sikkerhetskopier håndteres på tvers av landegrenser, hvilke underleverandører som er involvert, og hvordan ansvarsforholdet mellom behandlingsansvarlig og databehandler er regulert i avtalen. Dette er ikke spesifikt for Cloudflare, men gjelder enhver sky- eller plattformtjeneste underlagt EUs personvernforordning. For selskaper i finans, helse eller offentlig sektor, der kravene til datalokasjon ofte er strengere enn GDPR-minimumet, er dette punktet ikke en formalitet man kan hoppe over.
Risiko og kritikk av den nye tjenesten
Flere svakheter peker seg ut allerede i betafasen. Grensen på 10 GB lagring og 30 MB/s produksjon per strøm passer dårlig for mange produksjonslaster. Prisene på 0,04/0,04/0,02 dollar er merket som foreløpige, ikke endelige. Fan-out-modellen kan gjøre kostnadene uforutsigbare for arkitekturer med mange konsumenter. Økosystemet mangler fortsatt Kafkas etablerte koblinger, klientbibliotek og driftserfaring i bred skala. Og selv om Cloudflare kaller produktet et Kafka-alternativ, er det ikke dokumentert at det støtter Kafkas protokoll eller API.
Legg til dette en økt avhengighet til én enkelt leverandør: jo mer av stabelen som flyttes inn i Workers, R2, K2 og Cloudflares nettverk, desto dyrere og mer komplisert blir det å flytte seg vekk igjen hvis prisene endres eller tjenesten ikke leverer som lovet. Dette er ikke et argument mot å teste K2, men et argument for å bygge inn en reell exit-plan før man setter kritiske data der.
Beta-grenser og veien mot allmenn tilgjengelighet
| Parameter | Status i beta (okt. 2026) | Kommentar |
|---|---|---|
| Bruk | Gratis | Krever Workers Paid-abonnement |
| Lagringsgrense | 10 GB per konto | For lite for mange produksjonslaster |
| Produksjon per strøm | 30 MB/s | Begrenser høyvolum-arbeidslaster |
| Produsert data (etter beta) | ~0,04 USD/GB | Foreløpig, ikke endelig |
| Konsumert data (etter beta) | ~0,04 USD/GB | Multipliseres ved mange konsumenter |
| Lagret data (etter beta) | ~0,02 USD/GB-måned | Billig for lave volum, øker ved lang retensjon |
Tabellen oppsummerer hvorfor K2 i dag er et produkt å teste, ikke nødvendigvis et produkt å migrere kritisk produksjonstrafikk til. Grensene er satt for å samle tilbakemeldinger, og Cloudflare har historisk justert både priser og kvoter betydelig mellom beta og allmenn tilgjengelighet for andre produkter i samme familie, som Workers og R2 selv.
Fem spådommer for strømmemarkedet fremover
- Kafka-kompatibilitet kommer gradvis. Presset fra eksisterende Kafka-brukere vil trolig tvinge Cloudflare til å tilby et Kafka-kompatibelt grensesnitt eller migreringsverktøy innen 2027, selv om K2 i bunn og grunn forblir en egen arkitektur.
- Prisene justeres før allmenn tilgjengelighet. Gitt at Cloudflare selv kaller satsene “anticipated” og ikke endelige, er det sannsynlig at fan-out-prisingen justeres for å dempe de verste utslagene for arkitekturer med mange konsumenter.
- Hyperskalerne svarer med egne forenklinger. AWS, Microsoft og Google vil trolig posisjonere enklere, mer serverless varianter av henholdsvis Kinesis, Event Hubs og Pub/Sub for å møte konkurransen fra en lavterskel-modell som K2.
- Nordiske selskaper tester, men migrerer forsiktig. Forventningen er utstrakt pilotbruk av K2 i mindre, ikke-kritiske arbeidslaster i Norden gjennom 2027, mens større finans- og offentlig sektor-aktører venter på klarere dokumentasjon om datalokasjon og compliance.
- Konsolidering rundt plattformtenkning fortsetter. Flere skyleverandører vil pakke strømming, lagring og analyse tettere sammen, slik Cloudflare nå gjør med K2, R2 og Basin, fremfor å selge dem som separate, frittstående produkter.
Hva betyr dette for norske utviklerteam i praksis?
Konkret bør norske team som allerede bruker Cloudflare Workers eller R2 vurdere en liten, ikke-kritisk pilot på K2 i løpet av de neste månedene, rett og slett fordi betaen er gratis og risikoen er lav. Team som allerede har investert tungt i Kafka eller en administrert Kafka-tjeneste, bør derimot vente til funksjonslisten og den endelige prisingen er klarere, og heller følge med på hvordan tjenesten modnes fram mot allmenn tilgjengelighet.
Den viktigste jobben akkurat nå er å kartlegge eget fan-out-mønster. Hvor mange uavhengige systemer trenger egentlig å lese den samme hendelsesstrømmen? Svaret på det spørsmålet avgjør om K2s prismodell blir en fordel eller en felle for akkurat din arkitektur, og det er et regnestykke som er langt billigere å gjøre på forhånd enn å oppdage via en uventet regning tre måneder inn i produksjon.
Ofte stilte spørsmål om Cloudflare K2
Hva er Cloudflare K2?
K2 er en serverless tjeneste for hendelsesstrømming som Cloudflare lanserte i offentlig beta 1. oktober 2026. Den er bygget på objektlagringstjenesten R2 og lar applikasjoner sende og lese ordnede hendelseslogger uten å drifte egne broker-klynger.
Er K2 gratis å bruke?
Ja, i betafasen er bruken gratis for kontoer med et Workers Paid-abonnement, men begrenset til 10 GB lagring per konto og 30 MB/s produksjon per strøm. Etter beta planlegger Cloudflare en betalt modell rundt 0,04 dollar per GB produsert og konsumert, pluss 0,02 dollar per GB per måned i lagring, selv om disse satsene foreløpig er merket som ikke-endelige.
Kan K2 erstatte Apache Kafka direkte?
Ikke uten videre. Cloudflare omtaler K2 som et alternativ til Kafka, men lanseringsmaterialet bekrefter ikke Kafka-protokollkompatibilitet, transaksjoner, log-komprimering eller et skjemaregister på linje med det modne Kafka-økosystemet tilbyr. En migrering krever trolig tilpasning av klientkode, ikke bare et endepunktsbytte.
Hvorfor kan K2 bli dyrere enn forventet?
Fordi konsum prises per GB lest, multipliseres kostnaden når flere uavhengige konsumenter leser samme strøm. Ti konsumenter som leser den samme 1 TB-strømmen, kan skape rundt 10 TB i fakturerbart konsum, noe som fort blir dyrt sammenlignet med arkitekturer med få, sentraliserte konsumenter.
Hvordan skiller K2 seg fra Cloudflare Queues og Pipelines?
Queues er laget for enkle, kortvarige meldingskøer. Pipelines flytter strømmedata inn i analyseverktøy. K2 er tiltenkt situasjoner som krever en holdbar, lesbar-på-nytt hendelseslogg med lang retensjon og støtte for flere uavhengige konsumentgrupper samtidig.
Er K2 trygt for data underlagt GDPR?
Det avhenger av konfigurasjonen, ikke av leverandørnavnet alene. Selskaper må selv avklare lagringsregion, replikeringsmønster, underleverandører og databehandleravtale før de legger persondata underlagt EUs personvernforordning inn i K2 eller R2.
Når blir Cloudflare K2 allment tilgjengelig?
Cloudflare har ikke publisert en konkret dato for allmenn tilgjengelighet per 7. oktober 2026. Selskapet har historisk brukt betaperioder på flere måneder for tilsvarende produkter som Workers og R2, før priser og kvoter låses endelig.
Bør norske selskaper bytte fra Kafka til K2 nå?
For de fleste etablerte Kafka-arbeidslaster er svaret nei, i hvert fall ikke ennå. Betagrensene, den uavklarte prisingen og mangelen på full funksjonsparitet gjør K2 bedre egnet som et pilotprosjekt for nye, mindre kritiske arbeidslaster enn som en direkte erstatning for produksjonssystemer som allerede kjører stabilt på Kafka.