devkulkarni

We have an FAQ about Operators here: https://github.com/cloud-ark/kubeplus/blob/master/Operator-F...

It should be helpful if you are new to the Operator concept.

Operators are generally useful for handling domain-specific actions - for example, performing database backups, installing plugins on Moodle/Wordpress, etc. If you are looking for application deployment then a Helm chart should be sufficient.

Referring to Microsoft's original announcement post of OAM, (https://cloudblogs.microsoft.com/opensource/2019/10/16/annou...), the problem of defining application workflows and their dependencies that OAM is addressing is genuine. We have also faced this problem as part of providing Kubernetes-native platform stacks to our customers.

It will be interesting to see how OAM evolves, especially since it is coming from the same team that is leading the charge on Helm and CNAB (https://cloudblogs.microsoft.com/opensource/2018/12/04/annou...).

Here is what we have learnt about this space in the last one and a half years.

Application portability - While the point about application portability is true, if an organization has decided to adopt Kubernetes, the portability requirement is solved by Kubernetes itself to a large extent. If your application platform workflows are built as Kubernetes YAMLs, then they can be run on any cluster. Kubernetes YAMLs of built-in resources (Pod, Secret, etc.) and Custom Resources (MySQL, Postgres, etc.) can be leveraged to create such Kubernetes-native platform workflows. Our learning has been that a solution that focuses on solving the platform workflows problem on Kubernetes needs to augment existing Kubernetes tools such as Helm, Kustomize, etc. We have been developing such a tool (https://github.com/cloud-ark/kubeplus). Check out this blog post which provides detailed comparison between existing tools. https://medium.com/@cloudark/discovery-and-binding-of-kubern...

On separation of concern between Devs & Ops - Again with adoption of Kubernetes, our observation has been that Kubernetes YAML and the tooling around it such as Helm is becoming a common language of communication between Devs & Ops. In our view the goal for anyone developing new tools/frameworks in this space should be to help break the barriers that have existed between Dev and Ops teams further. One way we are trying to do this is by extending the vocabulary of ‘as-Code’ systems from the Infrastructure world to the ‘platform’ world of application development teams. Check out some of our work in this space primarily focusing on Kubernetes Custom Resources here - https://cloudark.io/platform-as-code

Hey community,

We are looking for feedback on KubePlus API Add-on (https://github.com/cloud-ark/kubeplus), which is our on-going work for declarative platform stack creation using Custom Resources on Kubernetes. For popular cloud platforms, there have been tools like AWS CloudFormation and Terraform that enable ‘as-Code’ creation of infrastructure stacks. With KubePlus our goal is to provide similar experience on Kubernetes simplifying the discovery and use of Kubernetes Custom Resources.

Your thoughts, comments and general feedback on KubePlus is much appreciated.