[Platforms] Create Prototype Platform

[lianmakesthings]

We want to build a prototype of a Developer Platform with a focus on Developer Experience. First iteration will be based on this demo, @salaboy presented at KubeCon Detroit 2022

Current working group:

• building out prototype @salaboy @Saim-Safdar
• defining developer persona @lianmakesthings

Working Doc: https://docs.google.com/document/d/10kHdKOidRS8lQzzHmcKjsCdEsUOrYRuWYXDDuz0MHH4/edit?usp=sharing

[salaboy]

Link to the example: https://github.com/salaboy/kubecon-na-keynote

[Saim-Safdar]

Happy to work on this

[Saim-Safdar]

Sharing here for everyone's visibility. In this prototype, what I'm thinking here is we need to shift our focus toward cloud adoption phase two, by addressing the problems of managing the cloud chaotic way in phase 1, where every team using the cloud providers of their own choice and using CI, a version system of their own comfort which ends up two many services are still sitting ideally, two many pipelines to manage, two many ticketing approval systems, faded responsibilities of app and DevOps team, no clear separation of concerns, or we can drive the demo towards phase two where there’s an abstraction layer we can call it platform team, whose job is to make sure services are up and running for consumption for developers where they only need to care about the apps, and eventually platform team marching up the stack by providing observability for the apps running in the production, a main persona is to cover in this prototype, you build it and run it all cost, DevOps 1.0, platform engineering is like DevOps 2.0 you build and run it intelligently.

@salaboy I believe we can leverage your KubeCon demos as this has some sort of similar concerns, wanted to know your opinions on using the theme or storytelling behind the prototype.

[lianmakesthings]

FYI, I'm currently doing some exploratory work on the developer persona on a Miro board https://miro.com/app/board/uXjVPrhjnJM=/?share_link_id=627435064088

[cmoulliard]

We want to build a prototype of a Developer Platform with a focus on Developer Experience.

This is a great and fantastic idea. As the target platform is k8S, then we should have a look to the following project aiming for java applications to generate the needed k8s resources and to avoid to create them

https://dekorate.io/ https://quarkus.io/guides/deploying-to-kubernetes

[salaboy]

Ok folks, @joshgav @Saim-Safdar @lianmakesthings @cmoulliard sorry for being quiet here.. but I am making some progress:

• I will create a new repo for scoping down what this example should include
• I want to make sure that our platform prototype focuses on developers and application development teams as the primary persona besides the platform engineering teams
• Our platform should be based on Kubernetes, but also make sure that Kubernetes doesn't get in the way of Application Development teams
• Our platform does more than just create clusters and cloud resources, it also installs tools and set up things for developers to use out of the box.

The answer to the question "how do we achieve this?" is by showing how multiple CNCF (and other) projects can be glued together to provide a set of experiences focused on platform builders and app dev teams.

Does this sounds as a good starting point?

[debuggerpk]

@salaboy looking forward to this.

[cmoulliard]

• Our platform does more than just create clusters and cloud resources, it also installs tools and set up things for developers to use out of the box.

Which tools (and setup) are you thinking ? Which tool do you plan to offer to install such tools locally (bash, ...) ?

NOTE: As installing tools depends on the OS, permissions, it will be needed to check/verify many things locally.

[salaboy]

@cmoulliard if we are talking about Kubernetes based platforms you will have tools like kubectl, helm, I am working on Knative Functions func CLI and dapr CLI for example. If we add Vcluster into the picture vcluster CLI.. and keep adding (argocd CLI too)

[cmoulliard]

Here is my favorite list of tools ;-) To be reviewed and challenged of course

• k9s: https://k9scli.io/
• kubectl
• kind
• helm
• kube ctx and namespace: https://github.com/ahmetb/kubectx
• kube tree: https://github.com/ahmetb/kubectl-tree
• kubernetes control plane (to define user 's workspace, provision x clusters): https://www.kcp.io/

[cmoulliard]

Creating a demo/prototype is certainly a great idea at the condition that we define clearly the following points:

• Which patterns do we plan to support top of the platform (innerloop, outerloop, service claiming and binding, composition, eventing, etc) ?
• Should we design a workable prototype or the skeleton demonstrating the different principles to let the users to extend them ? Here is an example about a project which provides a kind of prototype with a basic controller https://github.com/kubernetes-sigs/application/blob/master/controllers/application_controller.go able to compose kubernetes applications
• Who will maintain the prototype ?
• Will the prototype licensed using the Apache Licence ?
• Could the prototype become a concrete project/product (aka Apache Tomcat, etc) ?

[salaboy]

@cmoulliard let me take a stab at your questions, others feel free to express your own opinions:

• There is no reason just to have a single prototype. trying to build a single example that shows all the patterns that you mention is hard and too time-consuming. I would suggest to do it the other way around, we create prototypes and then we describe how they follow the patterns. I would prefer to have simple examples that can demonstrate a couple of patterns than a complex one that try to tackle all of them together.
• While controllers are a big part of extending Kubernetes I wouldn't focus on that. I haven't been focusing on building custom integrations, because I think that we should start promoting projects in the CNCF to interop so people can wire them up together without the need to write their own custom controller that they will need to maintain.
• This group should maintain the list of patterns and links to references.
• Apache v2 sounds like ok to me
• I am not sure to understand this question at this stage. Examples that can be produced by the group can be skeletons for other teams to build upon, but this group will not focus on creating a product.

wdyt?

[cmoulliard]

• I would prefer to have simple examples that can demonstrate a couple of patterns than a complex one that try to tackle all of them together.

I'm fine to develop an example or x examples but then we will be faced to the same question: Will the example(s) been maintained/tested/well documented ? That represents a huge volume of work to achieve this goal !

[cmoulliard]

• While controllers are a big part of extending Kubernetes I wouldn't focus on that.

I dont say that we should develop some controllers but was just giving an example of a project where they developed the skeleton of a component without concrete implementation. The controller word can be replaced with a Java Application ,etc

[salaboy]

I see a benefit in creating and maintaining these examples based on community feedback. I think that the team suggested using my example as the base building block to bring more technologies to the table:

• https://github.com/salaboy/kubecon-na-keynote

By bringing an example like this to a Working Group, my expectation is that we will have more hands to improve and maintain this example in the long run. If each member of the WG installs the example and try it out, we can iteratively improve it and have it in a stable state.

[lianmakesthings]

as we discussed in the platform WG today, a good first step could be to document the use-case / problem this solution addresses as well as an architecture diagram

[cmoulliard]

Here is my favorite list of tools ;-) To be reviewed and challenged of course

Do you agree that we propose such a bash script + function able to install tools

./platform.sh kube-tools

example from: https://github.com/halkyonio/tap/blob/1baeef2a83b94a19e3a65520cb944d5c7022b7e2/scripts/tap.sh#L590-L697

function kube-tools() {
  if ! command -v k9s &> /dev/null; then
    sudo yum install jq -y
    wget -q https://github.com/derailed/k9s/releases/download/$K9S_VERSION/k9s_Linux_x86_64.tar.gz && tar -vxf k9s_Linux_x86_64.tar.gz
    sudo cp k9s ${DEST_DIR}
  fi

  if ! command -v ${KREW_ROOT:-$HOME/.krew}/bin/kubectl-krew &> /dev/null; then
    log "CYAN" "Install kubectl krew tool - https://krew.sigs.k8s.io/docs/user-guide/setup/install/"
    (
      set -x; cd "$(mktemp -d)" &&
      OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
      ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
      KREW="krew-${OS}_${ARCH}" &&
      curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
      tar zxvf "${KREW}.tar.gz" &&
      ./"${KREW}" install krew
    )

    log "CYAN" "Install kubectl-tree - https://github.com/ahmetb/kubectl-tree"
    ${KREW_ROOT:-$HOME/.krew}/bin/kubectl-krew install tree

    log "CYAN" "Install kubectl-ctx, kubectl-ns - https://github.com/ahmetb/kubectx"
    ${KREW_ROOT:-$HOME/.krew}/bin/kubectl-krew install ctx
    ${KREW_ROOT:-$HOME/.krew}/bin/kubectl-krew install ns

    log "CYAN" "Install kubectl-konfig - https://github.com/corneliusweig/konfig"
    ${KREW_ROOT:-$HOME/.krew}/bin/kubectl-krew install konfig

    BASHRC_D_DIR="$HOME/.bashrc.d"
    if [ ! -d ${BASHRC_D_DIR} ]; then
        mkdir -p ${BASHRC_D_DIR}
    fi

    log "CYAN" "Export krew PATH to ${BASHRC_D_DIR}/krew.path"
    echo "PATH=\"${KREW_ROOT:-$HOME/.krew}/bin:$PATH\"" > ${BASHRC_D_DIR}/krew.path

    log "CYAN" "Create kubectl & plugins aliases to ${BASHRC_D_DIR}/aliases"
    cat <<EOF > ${BASHRC_D_DIR}/aliases
# kubectl shortcut -> kc
alias kc='kubectl'
# kubectl shortcut -> k
alias k='kubectl'

# kubectl krew
alias krew='kubectl krew'

# kubectl tree
alias ktree='kubectl tree'

# kubectl ns
alias kns='kubectl ns'

# kubectl ctx
alias kctx='kubectl ctx'

# kubectl konfig
alias konfig='kubectl konfig'
EOF
  fi

  log "CYAN" "$(cat ${BASHRC_D_DIR}/aliases)"
  log "WARN" "Source now the .bashrc file: \". $HOME/.bashrc\" in your termnal"

  if ! command -v helm &> /dev/null; then
    log "CYAN" "Installing Helm"
    curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
    chmod 700 get_helm.sh
    ./get_helm.sh
  fi

  ...
}

[salaboy]

Hmm.. I think scripts like this hide the complexity of installing and managing these tools, which might be a good approach. I am more in favor of showing people step-by-step what they need to do. Like for example, in the new examples that I am working on here (I will move this soon): https://github.com/salaboy/rejekts-eu-2023/blob/main/README.md#glue-things-together

This doesn't mean that we cannot have both, then you run into the problem of supporting different Operating Systems and stuff. We need to have a section to discuss pre-requisites. Wdyt?

[cmoulliard]

This doesn't mean that we cannot have both, then you run into the problem of supporting different Operating Systems and stuff.

This is the tricky part as macos is not linux and not windows too ;-)

[cmoulliard]

We need to have a section to discuss pre-requisites.

Yes

[cmoulliard]

I propose to combine both approaches:

• Have a prereq page detailing the different tools to be installed and needed
• Have a bash script supporting at least to install them on linux, macos Note: If some windows could help us around the .bat file, that could be fantastic too ;-)

[lianmakesthings]

I propose to combine both approaches:

• Have a prereq page detailing the different tools to be installed and needed
• Have a bash script supporting at least to install them on linux, macos Note: If some windows could help us around the .bat file, that could be fantastic too ;-)

Sorry it's taken me some time to come back to this issue. May I suggest running a devcontainer via https://github.com/loft-sh/devpod as a means to make the development environment declarative and repeatable? :)

[cmoulliard]

As mentioned on slack, such cloud platform project should include:

• Cloud or Microservices Pattern(s) adopted and their reference: 12-factor, etc
• ADR and template used to fill the proper information
• Components/Packages = list of packages/components proposed as part of the foundation (example which is not exhaustive at all: https://github.com/halkyonio/tap#components) and included in a high-level architecture diagram
• Pitfalls (not sure about the exact wording of this section) to list/highlight what currently it is missing. Example: lack of enough industry standard around service binding and credentials security - https://github.com/halkyonio/primaza-poc#introduction
• k8s needed tools (already discussed on this github issue)
• Q/A & FAQ, references

[cmoulliard]

I would also suggest that we name it CNCF Prototype platform to stimulate to use as much as possible to use CNCF projects part of the platform that we assume should be a kubernetes developer and deployment platform ;-)

[lianmakesthings]

We discussed the topic of prototypes in today's WG meeting. The preliminary decision we've made is to create a section on our website where we can showcase platform prototypes which are not maintained by the TAG / WG.

To get new projects on there, we'd invite members of the community to propose their platform, similar to a CfP. The proposal must include

• A backstory about the platform
• Useful tags that relate to platform capabilities
• Link to the repository We'd leave it up to the applicants to be as detailed as they'd like

Thoughts?

[asarenkansah]

We discussed the topic of prototypes in today's WG meeting. The preliminary decision we've made is to create a section on our website where we can showcase platform prototypes which are not maintained by the TAG / WG.

To get new projects on there, we'd invite members of the community to propose their platform, similar to a CfP. The proposal must include

• A backstory about the platform
• Useful tags that relate to platform capabilities
• Link to the repository We'd leave it up to the applicants to be as detailed as they'd like

Thoughts?

Love this. Think it's a great idea and removes the bulk of the effort from falling on a select few people.

My assumption would be that the proposals would happen at the TAG App Delivery group? Since the Platform WG is temporary, that's the only thing that makes sense to me. Doesn't necessarily need to be a physical presentation for it, seems like it could facilitated by only leveraging PR's/Issues. Not sure if you guys had something else in mind, I had to leave the meeting a bit early yesterday

[lianmakesthings]

Doesn't necessarily need to be a physical presentation for it, seems like it could facilitated by only leveraging PR's/Issues.

Yes that's also what I was thinking. I would say it's not required to present the prototype to the group, but if an applicant really wants to do it, I don't see a reason why they shouldn't.

My assumption would be that the proposals would happen at the TAG App Delivery group? Since the Platform WG is temporary, that's the only thing that makes sense to me.

Oh good point, I didn't even think of that yet. I would say, while the WG Platforms exists, let's do it in the working group. We can cross the bridge when we get to it.