AI Weekly Malaysia

Cloudflare launched K2 in public beta, a serverless durable event-streaming primitive on its Developer Platform: you write events to a stream that stores them as an ordered log, and consumers can either split reads across a consumer set or receive every message. It is implemented as a partitioned, durable log on top of R2 object storage, and was originally built to serve as the ingestion layer for Cloudflare's Basin Pipelines, which commits to never dropping accepted events. Cloudflare says it could not just deploy Apache Kafka because its edge spans over 335 cities and gives it small machine slices, ephemeral machines, and networking over the public internet.

Why: If you are already on Workers and hand-rolling buffering with queues or Durable Objects, or self-hosting Kafka for an event log, this is a beta alternative with R2-backed retention that survives long consumer downtime. The excerpt gives no pricing, retention limits, throughput numbers, or latency figures, so you cannot cost-compare it against Kafka or your current queue today — the practical move is to prototype a non-critical event path on it and measure, not to plan a migration.

Netlify rebuilt its Edge Functions platform, moving off a hosted V8-isolate execution service to Firecracker MicroVMs running inside its own edge network, in work done with Unikraft. Warm invocation p50 latency dropped from 25–40ms to ~5–6ms, p99 improved 47.4%, edge function log delivery got 5x faster, and Netlify reports 99.998% availability across roughly a billion Edge Functions per day. Cold invocations still occur on about 1.2% of requests (~9ms average to fetch images), and the authoring model is unchanged: URL imports, npm packages, Node built-ins, netlify.toml declarations, and local dev all work as before.

Why: If you run latency-sensitive logic on Netlify Edge Functions, this is a free ~5x median latency win with no code migration — worth re-measuring anything you previously pushed back to an origin server or a regional function because the edge felt too slow. Treat the numbers as vendor self-reported with no third-party replication, and note that cold invocations are still Netlify's own 1.2% figure, not something you can verify from your dashboard. There is no Malaysia or SEA angle in this post.

Cloudflare rearchitected Cloudflare Containers around agent workloads: application code can now pick each sandbox's image and instance type at runtime rather than at deploy time, startup is claimed 6x faster, and filesystem snapshots entered public beta. In ComputeSDK's independent benchmark, median container startup dropped from just over four seconds to 648 milliseconds; Cloudflare's own preliminary burst test created hundreds of thousands of containers in seconds. Every container still gets its own Durable Object, the ctx.container API now controls a container without a wrapper class, and the model carries into Sandbox SDK 1.0.

Why: If you run agent sandboxes — self-hosted or on a competitor — the 4s-to-648ms median startup number is the one to test against your own cold-start budget, because per-task image selection means you no longer pre-bake one image for a whole deployment. Filesystem snapshots in public beta are the piece that makes pause-and-resume viable, but it's beta, so treat it as a design option rather than a guarantee. The post names no pricing, region, or Malaysia-specific detail, so anyone building here still has to verify cost and latency from where their users are.

Cloudflare has taken its Data Platform out of open beta and into general availability, renaming it Cloudflare Basin. The family is now Basin Pipelines (formerly Cloudflare Pipelines, ingesting from Workers, HTTP, or Logpush and writing Apache Iceberg tables or files to R2), Basin Catalog (formerly R2 Data Catalog, managing Iceberg metadata), and Basin SQL (formerly R2 SQL, a serverless distributed SQL engine querying Iceberg tables on Cloudflare). The post cites Anomaly co-founder Dax Raad saying they replaced an AWS S3 and Athena setup with Basin, but gives no pricing, limits, or benchmark numbers.

Why: If you had Pipelines, R2 Data Catalog, or R2 SQL in beta docs, scripts, or Terraform, those product names changed, so configs and internal references need updating before the old names drift out of the docs. Beyond the rename, the announcement gives no pricing, quotas, latency figures, or SLA details, so you cannot make a cost decision from this post alone — you would need to pull current pricing for R2 storage, Pipelines, and Basin SQL and compare it against your existing warehouse or S3-plus-Athena spend, especially if egress fees are a real line item for you.