I recently wrote about a new project I'm starting in the Kubernetes world. Its overarching goal is to build an open source, app developer friendly system built on top of Kubernetes. Since then, there has been a lot of interest and a few developments that I'm excited about.
Technical Reference and Proposal Document
Along with the GitHub issue that started the project, there is now a proposal and technical overview of the system. Like most proposals, this document will serve as the proposal submitted to the KEDA maintainers and also as a reference document that the project will build against.
Included in this document is an overview of all the components in the system, an architectural diagram of how they're assembled, and a discussion of the extensibility of the system [1].
Acceptance to the KEDA Organization
The proposal has been accepted and a new repository under the KEDA organization to house these components.
This development is important because the people and the idea now have the support [2] of the KEDA organization and a wider discussion has been started around the direction and featureset. We also have a wider team of developers that have joined to contribute.
What's Next
I'm pleased with the direction of this project and looking forward to the next few months. Things are moving very quickly in the new repository. I did a pairing session yesterday with coworkers in which we completed the entire serving and metrics infrastructure [3], and the next component on deck is the operator [4].
If you're interested in seeing this component progress -- along with the project at-large -- I live code it on Twitch 2-3 times per week. I encourage you to tune in and ask questions/leave comments in the chat.
Contributing
We're not yet ready for contributions from the community at-large. We have two major tasks to complete before we'll be open for contributions from the at-large community.
First, we need to finish the minimal infrastructure. The components and supporting artifacts (Helm charts, CI scripts, etc...) are being built in PR #2, and once we have them completed, we will merge it [5]. Second, we need to establish a roadmap. We're beginning to outline it now and will finish it shortly after merging.
We believe that when these two tasks are complete, the project will have an established foundation and be well situated to accept contributions and support a larger community.
I along with others will broadcast when we're ready to welcome the wider community.
[1] In addition to the discussion in there, I've had more concrete discussions elsewhere about extensibility. Most of them are around alternative levels of abstraction that this system could support. The given architecture is highly extensible, and after this particular abstraction is built, we'll explore others.
[2] The word "support" has different implications in different open source projects and communities. In this case, I mean that there is a repository created and the general idea to support HTTP based autoscaling is on the roadmap of the larger KEDA project.
[3] We based much of our code on the prototype codebase
[4] This component is notable because it's being implemented in Rust. The decision to do so was inspired by my former colleagues in the Deis Labs group at Microsoft. They are innovating in significant ways in the Cloud Native community.
[5] Depending on how we progress, we may create and merge multiple PRs.
Top comments (0)