In the world of message streaming, connectors quite often play a crucial role in facilitating data exchange between different systems. While Apache Iggy remains the core messaging infrastructure, focusing on extreme efficiency (high throughput, low latency, and minimal resource consumption), it could also benefit from a more extensible architecture. This is where connectors come into play.
Apache Iggy considers performance as one of its core principles. We take pride in being blazingly fast, as proof of that, we have made benchmarking first-class citizen.
Zero-copy schema was a natural next step in our high-performance journey, it was part of our roadmap for quite a while, until the day we have finally merged it. In this blog post, we will share our path to implementing it.
In the world of software development, benchmarks are often treated as a second-class citizen. They're more of an addition to the codebase, rather than a crucial part of it, which should be the other way around, especially when it comes to the performance-critical systems or infrastructure tools.
We are thrilled to announce that Iggy has officially joined the Apache Incubator! This marks a major milestone in our journey to redefine message streaming — one that is blazingly fast, hyper-efficient, and built for the future. Since the very first day, Iggy was always meant to be a truly FOSS project — not just open-source in name, but deeply rooted in the values of transparency, collaboration, and community-driven innovation.
Quite recently (a few days ago), Iggy has been listed on Technology Radar by Thoughtworks - a well-known technology consulting company.
If you're not familiar with the Technology Radar, it's essentially an opinionated set (updated twice a year and subscribed by the thousands of developers worldwide) of the tools, platforms, frameworks, techniques etc. which you may want to try out & explore in your IT projects. Everything is split into the different categories, depending on the maturity or popularity of the particular tool.
It's been a little over a year, since the Iggy.rs was born. The initial idea of building a side project (as a way of studying Rust) — an infrastructure for the message streaming (think of Kafka, RedPanda, Aeron etc.) — eventually turned out to be something much bigger that I could've ever imagined. In the previous post (from almost half a year ago), I did describe what's Iggy.rs all about, how it started, what's the ecosystem around it, what our goals are etc.
Over half a year ago (in April, to be exact), I eventually decided to learn Rust for good. My previous attempt during the 2022 AoC had failed rather quickly, after a few days of completing the exercises - I finally realized that I needed a real project to work on. For the last few years, I've been dealing with the different kinds of distributed systems (mostly using C#), including the typical microservices architecture or Web3. Regardless of their nature, some sort of the messaging between the independent components was always required. I had a chance to use the tools such as RabbitMQ, ZeroMQ, Kafka or Aeron (just to name a few), as well as implementing the low-level peer-to-peer communication protocols.
We are happy to announce that Iggy.rs has reached the 0.1.0 release. This is a major milestone for the project, as it's getting closer to the first stable release.
Since the most recent update, Iggy.rs supports personal access tokens, which can be used to authenticate the clients, instead of the username and password. The tokens can be created and deleted using the available APIs.
In the latest update, the Iggy server as well as the clients for all the available transport protocols have been extended with the support for consumer identifier. Whether you poll the messages, store the consumer offsets, or create consumer groups, you can use the well-established identifier type, instead of just u32, which is now a common standard for the resources' identification such as streams, topics, users and consumers.