HN user
From first-hand experience, for established OSS initiatives it's good for repetitive, high-volume work task like security alerts, fuzzing, duplicate issue detection, PR review, summarizing long threads, and legacy refactoring.
Bad patches are of course bad, but creating confident-looking noise for maintainers who are already stretched thin...now that's not good!
Issue trackers and PRs are definitely getting harder and harder to trust. That said, AI is helping ALOT in OSS, but we definitely need guardrails around provenance, automated issue actions, and sudden changes in a contributor’s behavior.
So AI infrastructure buildout is starting to feel a lot like emergency industrial mobilization...
Also, building rapid temp shells plus nearby gas turbines paints a very different picture than the one conveyed by the "clean-energy" PR around hyperscale data centers.
Very Apple-ish approach to AI catch up: wrap an external tool in a privacy architecture, embed into the OS and productize the orchestration layer.
It will be interesting to see if the Private Cloud Compute + on-device routing can make third-party model capabilities feel like a first-party system without leaking user context to the model provider.
If Apple handles the Google-Apple boundary right, this will be an elegant move on their part, otherwise it will feel like Apple Intelligence with a just a privacy-polished frontend for Gemini.
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.
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.
You can quickly try out MQTT-Kafka proxying with Zilla with the following https://docs.aklivity.io/zilla/latest/how-tos/mqtt/mqtt.kafk... (the guide includes a docker compose file for quick and easy setup). We also have a fun Taxi Hailing Demo that simulates an IoT mobility use case powered by Zilla and Kafka for a more end-to-end setup: https://github.com/aklivity/zilla-demos/tree/main/taxi
Looking forward to all feedback and questions!
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.
It would be great to get your feedback!
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!
Hey folks, we just launched the Zilla Project and would love to answer any questions or hear feedback. Will reply in the comments below.