hey folks, I saw Score mentioned a few times, is anyone here using that and care to share experiences?

I evaluated it, and really like it, but.. since it only covers containerized workloads (and is very K8s-biased imho), and we use a lot of other workloads (serverless), it unfortunately did not fit for us.

Hey David! I am basically working with Score every day - for our internal projects and also for platforms that I help my customers build. Score simply works - not for every case OOTB but you can customize it if needed as it is OSS. If you have specific questions, we have Score maintainers here as well - e.g. @Mathieu Benoit. Or you could hop over to CNCF Slack and join the project community there.

like @Dirk Jablonski, I have >80% non containerized workloads. It looks like extending Score for these would be essentially writing serveral whole new standards.

Although we do not use score, I use it as an "inspiration" and try to mimick is as closely as possible (but also still in evaluation phase).

To give you some inspiration as well - most of the time it’s not the spec that needs to be adjusted but rather an implementation that needs to be built. Here’s an example how an implementation can be built out for Fly.io - https://github.com/astromechza/score-flyio. Writing another implementation for e.g. a serverless runtime that can consume containers would be down the same alley.

A question to all the Score experts around here (e.g. @Clemens Jütte): How do you deal with resources that are a bit more complicated, e.g. DynamoDB tables? They can't be provisioned with just a simple name and size, but require details about the key setup. Same for S3 buckets, when they need an resource-based policy, which is definitely not trivial to configure in the resource block of a score workload definition? 🤔

Hey @Dirk Jablonski! Sorry for the late answer - I’ve been on vacation. Yes, Score is meant to be an abstraction and as such not all configuration details should be accessible for developers in the Score file. Also Score files should be environment agnostic - which implies that you have another source of configuration that can be applied on a per environment basis by the platform that you’re targeting. Think of it like this - if a developer wouldn’t need to specify environment specific config, because the platform that helps him deploy the Score file in the end helps him to add those with sensible defaults per environment type, then there would be a lot less to worry for said developer. Apart from that, there’s nothing stopping you in adding more details for the developer to configure. It’s just that the provisioner (of the Score implementation) or the targeted platform (e.g. a platform orchestrator) needs to be able to understand them and react correctly. Just be cautious about adding nothing environment specific which would defeat the purpose. To give you an idea how this might look like, see the image.

Well, that at least means this is possible, we'll hopefully figuring out how (or maybe convince more devs that container images are also a good way to deploy 😉)