Cloud is IasS ( Done ) , PaaS ( Not adequate extensions ) , SaaS ( Limitation of APIs and closed for purpose )

How about evolution of PaaS by "Plugins". Plug-In Architecture can be of the following types. e.g (1) ELK based Logging Plugin (2) JIRA based PMO Plugin (3) Prometheus based Monitoring Plugin etc.

Cloud Native -CNFC has so many software. Each could be plugin to start with Kubernetes Operator and make it Kubernetes-Native ( Cloud-Native ) and since it is plugin it wouldn't be bulky and light-weight. Cloud-Operators can sell Plugins in Marketplace.

But wait there is KubeCtl Plugin. Also there is "krew"... So what's new.

Coming back to "Cattles vs Pets" story. Application Platform is still.... how do we change that. We now have kubernetes of kubernetes but do we have Kubectl of Kubectl :) Let me make it simple.

Application Platform is heterogeneous. How do we solve it by Computer science first principle --> Everything is solvable by indirection - Configurator of Configurator....

Let me talk VR Plugin.

Theme is Cloud VR/AR and DevOps. Let us put our thoughts for this usecase.

(*) Mobile ( Client ) request Cloud Platform for VR App. [ May be playstore to search and request ]

(*) Cloud Platform give ability for device authenticated to be "Worker Nodes". Devices like Mobile can be authenticated from telco etc for authenticity. Worker nodes to cloud platform should be dynamically added and removed. Kubectl commands ensures client worker node is utilised only for Client VR image.

(*) Cloud Platform registers the client device as "worker node" and adds to the cluster. Master nodes downloads the VR-Client Image with respective kubectl-commands to client. Fetching of VR-Image from Registry is dynamism we are looking forward to... e.g. Mobile has asked XYZ VR game ; we need to search and send the right Client image from registry. Things what happened from API to GraphQL which is super charged API should happen. e.g Give me VR game which is like XYZ and runs based on my device. Platform based on personalisation rule and device characteristics sends to the client right image with kubectl commands to register.

(*) Mobile has Sandbox to run Kubectl commands from server. [ Remember Java Sandbox ]. Bad Server security challenge taken care of.

(*) Mobile is now dynamic worker node. It is all one nice happy cluster.

(*) Mobile VR Client in Sandbox called for server VR image and VR experience is great.

(*) VR is over. Client request to de-register itself.

(*) Platform depending whether it is paid or free ; bills appropriately to Mobile bill.

SideNote : We can have Linkedin of VR/DevOps guys alone - Call it "DO_Link" . ( Invitation based registration ) . Recommendation based on the help provided on "StackOverflow" of the portal. Peer Recognition , Cloud/DevOps talks, Pull Requests etc making it a vibrant community.

What it does

It is Collaborative platform for Kubernetes based Cloud where plugins are installed and hence custom Platform can be made. It is Platform-making-Platform. Work-Done ( Volunteer and Paid ) and Recommendation is on Block chain.

How we built it

Operator which assembles Kubernetes Operators.

Challenges we ran into

Accomplishments that we're proud of

Idea.. and Hope "Platform can be assembled"

What we learned

Think BIG

What's next for SmartBusiness

Implement :) We already have Garderner by SAP ( Kubernetes of Kubernetes)

Share this project: