This is an automated email from the ASF dual-hosted git repository.
kranti pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/iggy-website.git
The following commit(s) were added to refs/heads/main by this push:
new 316c294ff Update blog files
316c294ff is described below
commit 316c294ff50db6a1bc44a29bfff9631429c3af29
Author: kparisa <[email protected]>
AuthorDate: Sun Feb 9 22:51:44 2025 -0800
Update blog files
---
blog/2025-02-10-apache-incubator.md | 56 ++++++++++++++++++++++++++-----
blog/2025-02-12-transparent-benchmarks.md | 47 --------------------------
2 files changed, 47 insertions(+), 56 deletions(-)
diff --git a/blog/2025-02-10-apache-incubator.md
b/blog/2025-02-10-apache-incubator.md
index d17b046cc..127fbc61b 100644
--- a/blog/2025-02-10-apache-incubator.md
+++ b/blog/2025-02-10-apache-incubator.md
@@ -9,21 +9,47 @@ tags: []
hide_table_of_contents: false
date: 2025-02-10
---
-## Apache Incubation
++++
+title = "Iggy joins the Apache Incubator"
+date = "2025-02-10"
+author = "Piotr Gankiewicz"
++++
-We're extremely excited to announce that Iggy has been accepted into the
[Apache Incubator](https://incubator.apache.org) program! Since the very first
day, **Iggy was always meant to be a truly FOSS project**, and we're thrilled
to see it being recognized by the Apache Software Foundation (ASF). This is a
huge milestone for us, and we're looking forward to the journey ahead.
+We are thrilled to announce that **Iggy** has officially joined the **[Apache
Incubator](https://incubator.apache.org/)**! 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.
-Here you can find the [official
proposal](https://cwiki.apache.org/confluence/display/INCUBATOR/Iggy+Proposal),
along with the
[discussion](https://lists.apache.org/thread/q9whr3q9qd6wqm89f0vc1f6vkkvzc8xf)
and the [voting
results](https://lists.apache.org/thread/6zfgdjwrzs92h4z4x6b25v1r23g3f5yg).
+## ๐ A Journey Two Years in the Making
+Itโs been almost two years since the very first line of code was written, and
weโve come a long way since the initial release. What started as a bold idea
has grown into a high-performance, cost-efficient message streaming solution
with a thriving community of contributors, users, and advocates. Weโve received
invaluable feedback, contributions, and support, and weโre more excited than
ever to take Iggy to the next level.
-It's been almost 2 years now since the very first line of code was written,
and we've come a long way since the initial release. We've managed to build an
amazing community around Iggy, and we're grateful for all the contributions and
feedback we've received. We're confident that this move will help us grow even
further and make Iggy even better.
-What's also worth mentioning is that it's not just about the core Iggy
repository anymore, but also about the [ecosystem](https://github.com/iggy-rs/)
around it such as SDKs, CLIs, Web UIs, and more - we're already close to 20
repositories in total, and we want to ensure that all of them are following the
ASF guidelines.
+## ๐ฅ Beyond Just Iggy โ A Growing Ecosystem
+Iggy is no longer just about the core repository. Over time, weโve built an
entire ecosystem around it, including:
-We'll do our best to make Iggy the TLP (Top-Level Project) in the future, as
we already have a lot of ideas on how to improve the project and the community
around it.
+- โ
SDKs for seamless developer integrations
+- โ
CLIs for powerful command-line control
+- โ
Web UIs for intuitive management
+- โ
And many moreโฆ
-**The future of message streaming is with Iggy, and we want to make sure that
everyone can benefit from it as Free and Open Source Software, that will stay
this way forever.**
+Weโre already approaching 20 repositories under the Iggy organization ([see
them here](https://github.com/iggy-rs/)), and as we enter the Apache Incubator,
we are committed to ensuring that all of them follow ASF guidelines while
maintaining our core values of speed, efficiency, and simplicity.
-## Codebase transition
+## ๐ Why Apache?
+
+The Apache Software Foundation has nurtured some of the **most transformative
open-source projects in history** โ Hadoop, Spark, Lucene, Solr, Cassandra,
Kafka, Flink, and Airflow โ technologies that have **shaped big data, search,
and real-time processing**. By joining Apache Incubator, we align with this
legacy and **gain access to a larger community, better governance, and
long-term sustainability**.
+
+๐ Dive into the Apache Incubator Details
+
+- [Official
Proposal](https://cwiki.apache.org/confluence/display/INCUBATOR/Iggy+Proposal)
+- [Discussion
Thread](https://lists.apache.org/thread/q9whr3q9qd6wqm89f0vc1f6vkkvzc8xf)
+- [Voting
Results](https://lists.apache.org/thread/6zfgdjwrzs92h4z4x6b25v1r23g3f5yg)
+
+
+## ๐ Whatโs Next?
+**Our vision is clear: Iggy as a future Apache Top-Level Project (TLP)**. We
already have ambitious ideas on how to improve both the project and the
community around it:
+
+- **Scaling performance benchmarks** to push the limits of ultra-low-latency
streaming
+- **Expanding integrations** with modern data infrastructure
+- **Building a vibrant developer ecosystem** that makes message streaming
frictionless
+
+## ๐ฆ Codebase transition
After the recent
[discussion](https://lists.apache.org/thread/zrn96nlg23r9353lr5tp2by2ggx4zxqc),
we plan to stick to the **monorepo approach**, under which, we will have a
single repository for all the Iggy-related projects. This will make it easier
for the contributors to navigate through the codebase, and to see how the
changes in one project affect the others. This should also help us to keep the
consistency across the projects, especially, once we release the Rust bindings
to be used [...]
@@ -33,6 +59,18 @@ We'll also host our website under the
[iggy.apache.org](https://iggy.apache.org)
There will be most likely some changes related to hosting the Docker images,
as well as the other tools we're using, but we'll make sure to keep you updated
on that.
-**Last but not least, we've got a new logo**! Our lovely Italian Greyhound is
now a part of the Apache family, and we're proud to have it as our mascot. As
you can see, it's so fast, that even the light travelling through the optical
can't keep up with it :)
+## ๐ก Join the Movement
+If you believe in a future where message streaming is lightning-fast,
hyper-efficient, and accessible to all, we invite you to be part of this
journey. Whether you're a developer, architect, or enterprise innovator, your
contributions, feedback, and ideas will shape what comes next.
+
+And this is just the beginning. **Welcome to the era of Hyper-Efficient
Message Streaming at Laser Speed.**
+
+**Last but not least, we've got a new logo**! Our lovely Italian Greyhound is
now a part of the Apache family, and we're proud to have it as our mascot. As
you can see, it's so fast, that even the light travelling through the optical
fiber can't keep up with it :)
+
+๐ Follow us, contribute, and help to build the future of the message streaming!
+
+- [Discord](https://iggy.rs/discord)
+- [X (Twitter)](https://x.com/ApacheIggy)
+- [Bluesky](https://bsky.app/profile/iggy.rs)
+- [LinkedIn](https://www.linkedin.com/company/apache-iggy/)
\ No newline at end of file
diff --git a/blog/2025-02-12-transparent-benchmarks.md
b/blog/2025-02-12-transparent-benchmarks.md
deleted file mode 100644
index f2cb59c06..000000000
--- a/blog/2025-02-12-transparent-benchmarks.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Iggy and the Transparent Benchmarks
-authors:
- - name: Piotr Gankiewicz
- title: Iggy.rs founder
- url: https://github.com/spetz
- image_url: https://github.com/spetz.png
-tags: []
-hide_table_of_contents: false
-date: 2025-02-12
----
-## Benchmarks should be the first-class citizen
-
-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.
-
-Sometimes, the benchmarking results are nothing more than just a
**cherry-picking of the best-case scenarios**, which are not representative of
real-world usage. In such a case, they simply serve a sole purpose of either
making the project look better than it is or how well it does outperform the
competition, under the extremely optimized conditions when comparing with its
counterparts.
-
-**Trying to reproduce the benchmarks is often a nightmare**, as the
environment setup is not documented, the code is unavailable, or the
instructions are not clear enough. This makes it close to impossible to verify
the results, which are then taken for granted.
-
-Or even worse, the **benchmarking tool might be so complex, that it's hard to
understand how it works**, and what are the assumptions behind it. ALl of
these, does result in hard to extend or modify the existing benchmarks, which
are not covering the particular use case you're interested in. It's just here
to tell everyone that we do have benchmarks, but how we do it, and what they
measure, is a mystery.
-
-**Which is why at [Iggy](https://github.com/iggy-rs/iggy/), we've decided to
make the benchmarks a first-class citizen**.
-
-Our `iggy-bench` tool, which is used to run the benchmarks and is part of the
core open source repository (can be found under the `bench` directory), has
come a long way and has been serving us well.
-
-
-
-We use it to do quick performance checks, regression testing, and to see how
the changes we introduce affect the performance. **We run it on our localhost,
as well as on the Virtual Machines in the cloud, to see how it behaves under a
variety of environments.**
-
-## Iggy benchmarking dashboard
-
-**And today, we're proud to present
[benchmarks.iggy.rs](https://benchmarks.iggy.rs/)** - a benchmarking dashboard,
which is available to everyone. It's a website where you can see how Iggy
performs under the different conditions, and how it scales with the number of
clients, messages, and topics.
-
-This is our community-driven effort, where everyone can contribute, and add
their own benchmarks. Simply run the `iggy-bench` tool, and submit the results
to our
[iggy-bench-dashboard](https://github.com/iggy-rs/iggy-bench-dashboard/), which
is of course, an open-source project as well.
-Please check the current readme for the instructions on how to submit the
results.
-
-
-
-**And this is just the beginning**, as we plan to extend the dashboard, and
add more benchmarks, which are covering the different use cases.
-
-Our main goal is to make the benchmarking process (and its results)
**transparent, reproducible, and easy to understand**. We want to make them a
first-class citizen, and a crucial part of the Iggy project. We want to make
them a tool, which will help us to improve the performance, and to make Iggy
the best streaming server out there. We're looking forward to your feedback,
and we hope you'll enjoy the benchmarks.
-
-## Towards the microsecond latency
-
-**And as a cherry on top, we've recently managed to achieve the
sub-millisecond write latency**. This is a huge milestone for us, as it's a
proof that Iggy can be used in low-latency applications, where speed is
crucial. Lately, we've been experimenting a lot with
[rkyv](https://github.com/rkyv/rkyv) - zero-copy deserialization framework,
which has yielded some great results. Keep in mind that streaming the data
within the range of microseconds latency depends on the several factors, suc
[...]
-
-And the best part is that we're just getting started. We're looking forward to
pushing the limits even further, and to see how far we can go. There's still
tons of optimizations coming, including switching the runtime to the
[monoio](https://github.com/bytedance/monoio) which does support **io_uring**,
and we've experienced superb results with this one on our experimental branch.
Then, there's the whole concept of shared-nothing & thread-per-core design, and
many more. Stay tuned!
