[hyscale]

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.

[soamv]

Congrats on this launch, it's great to see serious efforts at Kubernetes simplification and I hope you succeed! K8s bills itself as a "platform for platforms", and such projects are a real test of that idea.

Questions:

1. How do you deal with the mutability of K8s resources? Do you assume people won't change the underlying resources that you generate, or do you keep k8s controllers running to ensure there's no deviation?

2. How understandable is your generated output to humans? Do users have a way to go "backwards" through your abstraction? (Since your tool lives in an ecosystem with many other kubernetes tools, your users will sometimes end up having to deal with the generated output, since other tools operate at the K8s level such as prometheus, log aggregators etc)

3. Do you interoperate with K8s-level resources well? Do _all_ my services need to be in this abstraction for this to work well? e.g. Can my hyscale yaml reference a non-hyscale service for any reason? Or are they essentially two separate worlds?

[hyscale]

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

[soamv]

Thanks for your answers.

> 2

I don't mean literally generating hspec from yaml -- I mean more like operational "source map" support. For example if I look at a pod taking up more CPU than I expect in a dashboard somewhere, I should be able to trace it back to the hspec file.

[miccah]

This looks like a really nice and polished app, thanks for releasing it!

Is there an option to only generate the yaml instead of generate and deploy altogether? This would allow me to create a lot of boilerplate while still having the option to fine tune the configurations if needed.

I also didn't see any information on rollbacks.

[hyscale]

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.

[devit]

Is there an easy way to customize the generated Kubernetes manifests if the abstraction turns out to be insufficient?

[hyscale]

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

[tombh]

Is there any overlap with Hyscale and Terraform's Kubernetes provider or Helm's Charts?