[Fiahil]

> HyScale hopes to provide higher-level entities to deal with, as well as providing ways to do higher-level ops & deployment introspection.

That's exactly why the operator pattern exists!

Kubernetes stands out from other container orchestration tools for one reason only: it's portable. I can apply my templates to any cluster -empty or not- and my services will be running with the same topology. I can make them work with an existing installation, if I need to. To this end, I need to be able to inspect, modify and understand how everything is fitting together. An abstraction layer will always complicate things.

As said before, Helm is great because it doesn't hide Kubernetes' insides.

[xiwenc]

The first thing that ran through my head when I saw the example of hyscale was: Why isn't this implemented as a CRD? It looks to me like this is a higher level abstraction on top of Deployment resource with more bells and whistles.

[hyscale]

CRD is a good idea and something to consider for this project. But it does require pre-installing into a cluster before deploying apps. One fundamental difference with HyScale as it currently stands is that it can deploy to any cluster anywhere from any machine and doesn’t require to store any state or install anything extra into the cluster. There are pros and cons of both approaches.

HyScale generates standard K8s manifest yamls from hspec as you would write by hand, and in that sense it is portable as well and doesn’t hide the underlying yamls if you really wanted to see. Our experience shows that for several apps, one doesn’t really need to dig down below. Especially in the case of large teams, you may still want one or two people who understand the underlying mechanism (just as Angular developers may understand underlying JS mechanisms), but everyone else can simply move faster and easier.

[ForHackernews]

Don't operators require pre-installing into a kubernetes cluster? And they usually have extra blobs running inside the cluster so there's added overhead?