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.

You can deploy sidecar agents using HyScale for your mesh. We're looking at further abstracting out things like VirtualService and we're also watching SMI related developments. If there's any specific mesh use-cases that you’d like to see abstracted out from a service deployment perspective, do let us know on our github page.

Its a good suggestion. We'll aim to add this to our documentation soon.

Typically without an abstraction like HyScale, for a micro-service you might end up having to write / maintain a couple of hundred lines of K8s yaml including things like sidecars, ingress, PVCs, config-maps, etc. and linking up these yamls with the right selector-labels, etc.

Whereas the same service can be described in hyscale spec using a few dozen lines. But it's not just about the number of lines, the HyScale hspec is defined in terms of higher-level app-centric entities that are intuitive to most developers.

You also get simpler troubleshooting of deployment errors and worry less about having to maintain compatibility of your K8s manifest yamls with each new K8s version.

Your concern is justified. Any abstraction must deal with minimizing leakages. This is why we have started addressing deployment error troubleshooting with some level of diagnosis so that the tool can provide error info in terms of higher-level abstraction.

Helm does require understanding of all the underlying low-level objects defined in Kubernetes. HyScale hopes to provide higher-level entities to deal with, as well as providing ways to do higher-level ops & deployment introspection. We believe it should be possible to satisfy the needs of a reasonably large number (>80%) of apps.

:-) Actually less yaml. Typically without an abstraction like Hyscale, for a micro-service you might end up having to write / maintain a couple of hundred lines of K8s yaml including things like sidecars, ingress, PVCs, config-maps, etc. whereas the same service can be described in hyscale spec using barely 20-30 lines of yaml consisting of higher-level entities/language that is intuitive to most developers. You also get simpler troubleshooting of deployment errors and worry less about having to deal with backward compatibility with each new K8s version.

Kubernetes complexities are often acknowledged. In our team, we experienced this first-hand while migrating a large PaaS application onto Kubernetes about two years ago. This prompted us to seek out a way to simplify and speed-up app deployments to Kubernetes. This pursuit eventually led us to believe that Kubernetes complexities deserve an abstraction, in quite the same way as JQuery over Javascript, or Spring over Servlets. The HyScale project was born out of this, to create an app-centric abstraction that is closer to the everyday language of developers and devops.

With HyScale, a simple & short service-descriptor allows developers to easily deploy their apps to K8s without having to write or maintain a voluminous amount of K8s manifest YAMLs. This enables self-service deployments as well as development on K8s with minimal IT/DevOps intervention.

We would love to get feedback, ideas and contributions.