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.
Yes so the idea would be to use something like "Kong" or "weave net" whatever as the "orchestrator" and then bundle ir up in an easy fashion. I'm always more inclined into lower performance requirements scenarios so for example not always we need a Kubernetes.. I have setup for PM2 on redundancy in which I can run on low-end VPS for example. The "Overload" of Kubernetes is just too much and the costs are way up in the roof it's becoming to bloated so focusing on minimalist with K3S is a must and people looking for mesh are certainly the ones not wanting to rely on any cloud provider's orchestrator, they want to have their machines spinned up anywhere by themselves. That's the beauty of the Mesh.
I was able to setup weave net on low-end machines but it takes up a lot of resources so it's not trivial, K3S also is possible within low-end but lacks a lot of stuff so for now I'm just sticking with PM2 only on low-end and K3S on bigger machines.
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.
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.
> 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.
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.
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.
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?
:-) 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.
You can abstract using TF capabilities, they just aren't hidden like HyScale. HCL is widely used, people already use the TF tool, so you end up not having to add more deps and yet another DSL to learn.
