[from Slack Community] Do we see score remaining focussed on containers alone? Or potentially expanding to encompass additional workload types?

[gguizza]

We deemed important bringing this public discussion happening on the Score Slack channel to a GitHub Discussion to include more contributors and team members. Pasting here the first comment, from Aaron Knauf, a community member:

As it stands today Score, with its required containers section seems to equate "workload" with container. Hashicorp's nomad is on the roadmap and supports many more workload types than just containerised ones. I'm also not sure how FaaS fits in.
It seems like the industry is still some way from the point where containers are the only game in town for most organisations. Whether dealing with legacy, (unorchestrated VMs and processes) or adopting new tech (FaaS, WASM, ...) everyone has plenty of alternative workloads to deal with.
Do we see score remaining focussed on containers alone? Or potentially expanding to encompass additional workload types?

Feel free to contribute to the discussion and to share your opinion.

[sujaya-sys]

Thanks @gguizza. I'll also share my comment here, to provide further context:

For now, Score is focussed on containers. Taking the example of Nomad, a score-nomad implementation would allow you to deploy containers with the platform but not necessarily support further nomad-specific features. We’re keeping such a tight scope because we want to ensure standardisation while keeping the cognitive load of developers low when working with the tool. Once we step outside of the container scope, it’ll become increasingly hard to maintain this level of abstraction and simplicity as we’d have to keep extending the Score spec to support system specific items - so far our philosophy and approach behind your question. We’re of course open to keeping the discussion going on this topic and explore further whether supporting additional workload types is something that could make sense for Score in practice.

[ghen]

Of course Score is not limited to containers alone. Moreover, it would make sense to support new tech in future.

However, at such an early stage it was really hard to accommodate all the possibilities and keep things simple without any in-field testing. To roll-over the very first version of the spec and to see a potential community interest and usage scenarios Score was intentionally limited to the most popular applications delivery standard, which is OCI.

Would be really nice to get more insights on what other standards are popular and what the real use cases. Score and be then expanded to adopt those as well.

[aknauf]

Speculating somewhat here, I suspect that an important market segment for nomad is people who have heterogeneous work loads.

All can do is point out that, as the owner of a nomad-based platform, I can't adopt score today as it precludes my non-containerised workloads. Why would I want to define some of my nomad workloads one way and some another?

OTOH, the idea of having one yaml to define both my nomad and k8s workloads (and dependencies across them) is quite appealing! (And probably not a very heavy lift!)

[jayonthenet]

It looks like the way that it is currently for containers would also be useful for non-containerized workloads.

If I read into https://docs.score.dev/docs/extensions/

The humanitec.score.yaml extension is used by score-humantic Score implementation (CLI). This is an optional configuration specific for Humanitec’s routes as a resource and services accounts.

Why are we not putting a more generalized term like “workload” in the main spec? The corresponding CLI must transform into something usable/deployable and does encapsulate the translation mechanism. If there is additional information needed about the workload, then this can go into an extension file, like the route info for humanitec.

This would provide exactly what is being asked for. A place to specify additional complexity, that is only needed for a specific runtime platform. The mechanism is already in place and we’re using it in this way - in this case, to add more depth to the DNS resource, to work in tandem with the runtime platforms ingress mechanism.

This would not lead to pollution of the core spec and also not water down the mandate to reduce cognitive load as good as possible - other workloads than containers might be leaky, but they can only leak complexity into the extension file for the runtime platform.

[aknauf]

As I understand it, the extension mechanism for score is really about providing resource implementations, not workload implementations. The containers section is required, so you can't deploy resources without containers.

I suggest that a simpler abstraction might be to have workload types be the extension point and resources simply point to a workload defined in another score file. This already works for cases where the resource is a containerised workload, so not a big leap.

[jayonthenet]

The extension mechanism currently is not defined to be only for resources. In the current state, it is pretty much up to the implementor of the CLI for a specific platform to decide on how to handle extensions. I would advocate for this to be an open mechanism that applies to the central workload as well - decided at the specification level.

It would make the definition of additional information for a specific workload type very easy and also uniform across implementations, which it currently isn't.

Using workloads as targets for resource definitions that point to them, would in my mind only move the problem one step down the dependency line, because it's currently only working for containerized workloads. Introducing workload types would not help with that, because the problem of the location of the additional information needed by a certain type is not solved. It would actually make it worse in my mind because then this additional information would need to become part of the core spec instead of being pushed to an extension file and by that binds the core specification to the lifecycle of the runtime implementation of the workload type.

[aknauf]

Right now, score adoption is minimal and it will be a while before adopters have rolled it out to just their containerised workloads. I don't know if, after that point, the industry trend will be to migrate everything to containers (including FaaS?) or whether the next logical step might be to extend score to non-containerised workloads and truly have one yaml to rule them all. (I don't think anyone can answer this right now.) In view of this, keeping our options open and deferring commitment to the last responsible moment seems sensible. For me, this means keeping the language abstract and avoiding coupling the spec to the implementation.

Edit - adding actual support is not what I would advocate for right now - just not precluding it through tight coupling to containers.

[stevehipwell]

I'd second this and suggest the workload spec should be decoupled.