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.

The HyScale specification looks familiar to most developers/devops who have been doing development or deployment for some years as we wanted to create a spec that is intuitively understood and application-centric, while at the same time grows to support 80% of the use-cases out there. The spec is meant to also support K8s native elements such as sidecars, ingress, etc. We are also looking at the compose-spec to see if there is some convergence in the near/late future.

The HyScale spec schema itself is available at the companion repo here: https://github.com/hyscale/hspec

You can access the project here https://github.com/hyscale/hyscale#readme or at https://hyscale.github.io

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.

Thanks for your encouraging comments :)

Answers to your Questions:

1. The expectation is that people deploying through hyscale don’t want to go and modify K8s resources directly on the cluster behind the scenes. If they do, then it either deviates from the hspec files in git or they have parallel K8s yamls which won’t make much sense either. As of now, hyscale deploys and doesn’t keep anything (eg. controller) running, But it's a good suggestion to keep the K8s resources in sync with the desired state (hspec) and we’ll certainly put some thought into it.

2. HyScale outputs standard K8s manifest yamls which are as readable as any well hand-coded. On the other hand, if there was a way to generate back hspec files from existing K8s yamls, would that be interesting/useful?

3. Suppose you have K8s resources/snippets already written for some of your services, you can refer to them in hspec and add application context to it and make use of profiles for environment variations. If the question is more about off-the-shelf services (eg postgres, redis, etc), we have helm chart support coming up. https://github.com/hyscale/hyscale/wiki/Roadmap#2-ots-off-th...

You simply specify the stack image that your service needs along with the service source/binaries. See here for more: https://github.com/hyscale/hyscale/wiki/Tutorial#using-hysca...

:-) 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.

Wonder what kind of conditional logic you would want to apply. If its more for managing differences between different environments (say staging vs prod), you could just use the profiles option in HyScale: https://github.com/hyscale/hyscale/wiki/Tutorial#specifying-...

Terraform takes a more infrastructure-centric approach and its strength is typically for provisioning infrastructure such as putting up a K8s cluster, etc. than for deploying apps (although you can). Whereas HyScale is aimed at defining higher-level entities in a language that developers understand intuitively without any extra learning curve.

HyScale also aims to reduce the amount of abstraction leakage by dealing with aspects of troubleshooting and runtime operations as well. So this application-centric abstraction enables self-service deployments as well as development on K8s with minimal IT/DevOps intervention.

For more, see: https://github.com/hyscale/hyscale/wiki/App-centric-Abstract...

Yes, you can simply generate manifest YAMLs using the “generate service manifests” command. Refer here: https://github.com/hyscale/hyscale/blob/master/docs/hyscale-...

HyScale also helps you troubleshoot any errors during deployment. So rather than generate with HyScale & deploy using kubectl, you may want to fine-tune generated yamls by merging your custom config snippets via: https://github.com/hyscale/hyscale/issues/284 (in the upcoming release)

Currently, no support for rollbacks. It's a good suggestion for the roadmap, thanks. For now, you’d have to redeploy from a previous git commit.

Our initial goal is to achieve sufficient abstraction levels to satisfy at least 80% of the app deployment use-cases out there. Meantime, for any insufficiencies, we’re coming up with a way to merge K8s manifest snippets into the generated YAMLs. See this issue and associated PR for more: https://github.com/hyscale/hyscale/issues/284

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.