kubeflow
community: Improve Kubeflow Ecosystem diagram
/area website
This PR splits out the "Kubeflow Ecosystem" diagram updates from https://github.com/kubeflow/website/pull/3981 so we can seperate the discussions about each.
The reasons for the change:
- make the diagram more "square" (so its more easy to use in a slide deck)
- make padding more consistent
- make colors more distinct
- remove "BentoML" from "External Add-Ons" (as we already did on the website)
- NEW: I have removed the "istio/cert-manager" sections and simply placed a horizontal "kubernetes" layer above the "platforms" (aws, gcp, on-prem).
New Diagram
See: Files Changed
@andreyvelich @franciscojavierarceo @varodrig these updates significantly improve the architeture diagram and make it easier to use in presentations.
It does not significantly change the content (other than removing BentoML), so as long as we agree on the new "section names" (left side), I think we can merge.
@thesuperzapper why did you change the description on the left. This looks like a significant change to me. Is it possible to stay closer to the original? The terms Hardware and infrastructure seem better to me than chips and platform.
@thesuperzapper why did you change the description on the left. This looks like a significant change to me. Is it possible to stay closer to the original? The terms Hardware and infrastructureseem better to me than chips and platform.
It's simply that "Hardware" is too long to fit vertically, but I think "Chips" also makes a lot of sense for the bottom layer.
But I think that "Platforms" is a more correct term to refefer to AWS/GCP/On-Prem, but we can discuss this further.
Hey everyone, please see the updated diagram from the last commit.
I have added a separate horizontal layer for "Kubernetes" that sits above the "Platforms", this is to show that all our tools run on Kubernetes (on any Platform).
Also, I have removed the "dex" and "istio" logos because they are not strictly required and are left up to the user/distribution, and most users will not know what they are.
@andreyvelich @franciscojavierarceo I think this is ready for another review.
I would like to get this one updated so @varodrig can use the updated one in the Kubecon slides.
What's the rationale behind whether to have a "kubeflow" prefix for each project?
@terrytangyuan Because these are the actual "names" of each project, with exception of "Katib" and "KServe" which don't stylize with the "Kubeflow ..." prefix.
Many of our project names would be very generic without the stylization, e.g. "Notebooks" or "Pipelines", or "Model Registry".
fwiw I believe the prefix can be omitted if there is a wat to distinguish KServe add-on, which is currently in the same box as other KF projects, my2c
fwiw I believe the prefix can be omitted if there is a wat to distinguish KServe add-on, which is currently in the same box as other KF projects, my2c
I strongly disagree, it's critical that we consistently brand our tools. For example, the name of our pipeline tool is "Kubeflow Pipelines" not "Pipelines".
I strongly disagree, it's critical that we consistently brand our tools. For example, the name of our pipeline tool is "Kubeflow Pipelines" not "Pipelines".
We can name everything with Kubeflow prefix. I believe, we should be good to use Kubeflow Katib and Kubeflow KServe in this diagram.
fwiw I believe the prefix can be omitted if there is a wat to distinguish KServe add-on, which is currently in the same box as other KF projects, my2c
I strongly disagree, it's critical that we consistently brand our tools. For example, the name of our pipeline tool is "Kubeflow Pipelines" not "Pipelines".
That's fine :) the actual point in my comment however, I thought it was important that someone might confuse KServe for being "inside" Kubeflow (the "External Add-on" is not retained from the old diagram) for a Kubeflow hosted project (based label of the frame which encloses it).
If nobody feel this might be confusing for new users, ignore my comment altogether! 👍
I strongly disagree, it's critical that we consistently brand our tools. For example, the name of our pipeline tool is "Kubeflow Pipelines" not "Pipelines".
We can name everything with Kubeflow prefix. I believe, we should be good to use Kubeflow Katib and Kubeflow KServe in this diagram.
@andreyvelich Every time we have renamed Katib to "Kubeflow Katib", people end up reverting it, as far as I can tell, the official name is "Katib".
It is also less of a problem than pipelines/notebooks/etc because Katib is quite a distinct name.
@andreyvelich Every time we have renamed Katib to "Kubeflow Katib", people end up reverting it, as far as I can tell, the official name is "Katib".
It is also less of a problem than pipelines/notebooks/etc because Katib is quite a distinct name.
On behalf of Katib project, I can say that it is fine if we are going to use Kubeflow Katib name. cc @kubeflow/wg-automl-leads @Electronic-Waste @helenxie-bit. Additionally, in the near future we are going to re-brand Katib project to Kubeflow Optimizer to be aligned with Kubeflow SDK naming: https://github.com/kubeflow/community/pull/823. So it is totally fine if we keep Kubeflow Katib in the ecosystem diagram for now.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: franciscojavierarceo
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~content/en/docs/started/OWNERS~~ [franciscojavierarceo]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
![google-oss-prow[bot] avatar](https://avatars.githubusercontent.com/in/143327?v=4 "Published by a pub.dev verified publisher"){kind=small}