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.

Agree that the operator framework looks useful. Here is an article that I wrote recently analyzing the Operator Framework:

https://medium.com/@cloudark/analyzing-value-of-operator-fra...

As to whether this or other similar projects will become part of Kubernetes core, my guess is probably there will be resistance to it as it will mean choosing one particular way of how Kubernetes can be extended over others. And this will be against the overall philosophy of Kubernetes that components in it are optional and pluggable[1]. On the other hand, some standardization will mostly likely evolve around the end-user experience of consuming multiple Operators in a single Kubernetes Cluster.

[1] https://kubernetes.io/docs/concepts/overview/what-is-kuberne...

We have developed CloudARK (Platform-as-Code) for full-stack microservices development and deployment. It currently supports deployments to Google Kubernetes Engine and Amazon ECS. Here is the blog post that explains rationale behind building CloudARK (Platform-as-Code system) - https://medium.com/@cloudark/introducing-platform-as-code-b6...

Looking forward to your feedback.

I have written this blog post to explain rationale behind building CloudARK (Platform-as-Code system) - https://medium.com/@cloudark/introducing-platform-as-code-b6.... Looking forward to your feedback on CloudARK.

Good comprehensive description of steps involved in deploying to ECS.

One thing that I did not see was information about the required IAM setup. It might be helpful to identify specific AWS IAM policies that need to be granted to the AWS user for working with ECS.