That's the promise of every new technology. Although there's been massive progress over the past 50+ years, the amount of free time that people have has actually gone DOWN (https://clockify.me/working-hours)..."I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do my laundry and dishes"...we'll see
A lot of the current AI economics seems to depend on three assumptions being true at once: 1. inference costs fall fast enough 2. usage grows into very large recurring revenue 3. customers don't cut once handed the bill
We should draw a distinction between "AI is valuable" and "AI justifies its current investment levels." There's real productivity value in AI, especially for things like search, boilerplate, tests, refactoring, etc...BUT that doesn't mean every enterprise should let token spend grow without strict telemetry, cost-attribution and outcome-based measurements.
The teams that win here will not be the ones using the Most AI, but the ones that treat it like any other expensive production dependency, which means measuring unit economics, cap runway usage, properly align models with tasks(not just Opus everything), and scale workflows with ROI in mind.
MSFT, GOOGL, META, AMZN guided ~$285B combined capex for 2025 — roughly matching their total net income. Every dollar of profit is being plowed back in, which only works if #1 and #2 both hold.
Proxies are deployed to enhance observability, enforce security, and facilitate connectivity between clients and servers. However, these benefits usually come at a cost, as an additional "hop" is added to the critical data path.
We're building a high-performance, streaming-native protocol-agnostic proxy. After completing an OpenMessaging Benchmark on the proxy deployed in front of Apache Kafka, we've shown that it has near-zero impact on p99 latency, and actually absorbs and smooths out latency variation in a Kafka deployment, ensuring low and predictable latency at the 99th percentile, even under long-running, high-throughput workloads.
A link to the benchmark repo is included in the post to validate/confirm results.
Thanks and we have more coming! Yes, Zilla is deployed at a handful of companies. Notable ones are NBrown Group and a large German manufacturer that's big in the IoT space and starts with an "S" :).
We’re building a Kafka-native, multi-protocol proxy called Zilla (https://github.com/aklivity/zilla)* that helps connect apps, clients, and services to Apache Kafka via stateless OpenAPI and AsyncAPIs.
We're excited to share that Zilla officially supports another protocol — MQTT! With this, MQTT clients can publish and subscribe to Kafka directly without running a dedicated MQTT broker and Kafka Connect. In fact, Zilla turns Kafka into a full-fledged MQTT broker, meaning it doesn’t just mediate between the MQTT and Kafka wire protocols but maintains MQTT client state across Kafka topics!
The latest Zilla feature highlights include:
- MQTT v5 and v3.1.1 Support: Zilla supports both major versions of the MQTT protocol, ensuring it works with legacy and modern IoT clients.
- MQTT-Kafka Proxying: Zilla maintains MQTT client state across Kafka topics, providing all of the features and guarantees of a dedicated MQTT broker, such as Keep-Alive, Last Will and Testament, and all three Quality of Service (QOS) agreements. MQTT over WebSocket is also supported, so you can use Zilla to deliver MQTT messages from Kafka down to a browser.
- Manage Millions of Clients: Zilla is stateless, scales out linearly and handles MQTT to Kafka connection offloading.
We’re building a multi-protocol, event-native edge/service proxy called Zilla. Zilla can abstract Kafka topics for web apps, IoT clients and microservices through user-defined REST, Server-Sent Events (SSE), MQTT, or gRPC APIs.
Zilla has no external dependencies and does not rely on the Kafka Consumer/Producer API or Kafka Connect. Instead, it natively supports the Kafka wire protocol and uses advanced protocol mediation to establish stateless API entry points into Kafka. Zilla also addresses security enforcement, observability and connection offloading on the data path.
You can try Zilla out by running the Quickstart linked in the ReadME. The Quickstart uses a Postman Workspace with pre-defined API endpoints and a Docker Compose stack running pre-configured Zilla and Kafka instances to make things as easy as possible.
To demonstrate how event-streaming can be used to support Command Query Responsibility Segregation (CQRS), and what a fun, practical application of this architectural pattern could look like, we built a p2p payment app called StreamPay and wrote up a blog post. Hope you like it!
We’re building an open source event-driven API getaway called Zilla (https://github.com/aklivity/zilla). Zilla natively supports Kafka and enables you to create event-driven REST and SSE APIs that cleanly expose Kafka topics and services to mobile and web clients.
Zilla is super easy to get started with because it's declaratively configured via JSON; however, we’ve made it even easier via a GUI tool called Zilla Studio. Check out the announcement and give the Studio a try. Thoughts/comments/feedback/questions are welcome!
