How does Score compare to OAM (Open Application Model)?

[stevehipwell]

I'm interested as to how Score relates to the OAM (Open Application Model) specification? I've read the spec for both and can't help but notice the similarities and the paradox of both attempting to be the "One YAML to rule them all". I'm a big fan of the concept of having an application specification which is abstracted from the implementation (promise theory etc) but having multiple API specifications for this seems to be problematic from where I'm standing (please don't take the image the wrong way but it was the first thing which came to mind).

I'd be more than happy if you could explain why my initial observations are incorrect or how the nuances which I've missed make this less black and white? My current position on all of this is that I probably need to build my own abstraction as there isn't either a well established solution or a community consensus for establishing one (ironic given the image above right).

[russellmann]

This XKCD is what I immediately thought of when I read the first para of "What is Score?" Thank you for posting this so I didn't have to.

[m0un10]

Ha! I posted the same meme to my colleague when I saw the project. But I don't think there is anything concerning about others having tried similar things. That's obvious; and always happens in our industry.

The only observation I would make is that marketing something as a "thing to rule them all" leads only to a new standard as far as computing history is concerned. There isn't any evidence that I'm aware of where a player has come in and basically obsoleted a significant amount of competing data model standards.

The standard that wins is the one that's adopted the most.
Good luck to the score team on your journey ahead :)

[sujaya-sys]

That’s a very valid question! I’d recommend checking out these two articles that were published on the Score blog recently:

• How is Score different to the Open Application Model and Kubevela?
• How is Score different from other tools?

To summarise: OAM (Kubevela) and Score share a similar philosophy. Both advocate for workload/application-centric development. The main differences we found when looking over it:

A: Score provides a tightly scoped workload spec for developers. Its focus lies on the individual developer and the workload in front of them: Its a single file that describes what the workload needs to run. Score keeps such a tight scope as its overarching goal lies in reducing cognitive load and creating focus for developers. This is the main reason for why we’ve pushed back on ideas for extending Score’s feature scope in the past - its simple by design.
OAM on the other hand provides a model for creating end-to-end app development and deployment workflows. Its implementation (Kubevela) is a continuous delivery platform that offers a lot of additional features which can be defined by developers in their Kubevela file (e.g. policies, operation traits, deployment workflows). This risks large specs and an increase in cognitive load.

B: The Score Specification - score.yaml - can be translated into platform-specific configuration formats - such as Helm values.yaml - via a Score Implementation - such as score-helm (see here for context). This is where Score ends. How things are implemented in the target environment it totally up to the platform (team).
Kubevela on the other hand includes operations via “application definitions”. These are types of applications (e.g. web service) that ops define and developers can reference in their spec. If selected, the definition expands into all the resources that are required for the type of application and Kubevela automatically creates the according deployment.
This design difference again goes back to Score being solely focused on improving the developer’s experience. It is uninvolved with how things are done on the infra/ops side of things. As a consequence does it introduce minimal change to your existing set up: It integrates directly with your tech stack and workflows. It gives platform/ops the freedom to implement things according to their needs without being restricted by Score.

C: A concrete pain point that Score targets resolves around configuration inconsistencies between local and remote environments. For example: As a developer you might work with lightweight tooling such as Docker Compose locally while deploying to remote environments running on advanced orchestrators such as K8s. Score enables developers to do so without risking configuration inconsistencies (= translation gaps / errors) as the generation of required config is taken care of by a Score Implementation (see here for an example).
This is a use case that OAM doesn’t seem to support. For your local environments, you would need to provision a local cluster with a tool such as Kind while ensuring that all the components that are on the remote cluster are also found in your local environment.

So far a quick summary of our observations! That being said, if anyone here has experience with OAM/Kubevela, it’ll be great to understand how both tools differ in more detail. Don’t hesitate to reach out, it’ll be great to chat about this further and keep the discussion going.

And in regards to the other point about having several standards in place (xkcd): I totally agree, having different kind of specs out there helps teams understand which one fits their use case best. And while one might end up “coming out as a winner” would I argue that in the example of Score and OAM it makes sense for both to coexist next to each other. If you’re looking for a full blown CD platform, Kubevela might be your best bet. If you’re looking for a targeted solution to improve developer experience within your existing set up, you might want to have a look at Score.

[sujaya-sys]

FYI the question "What about a score-oam integration?" has been added to the discussion forum: #44

[stevehipwell]

@sujaya-sys your reply doesn't really answer the question I asked; you've focused on a specific OAM implementation rather than OAM as a specification. This also goes for the blog posts you linked to.

I still can't see what the benefit of the Score abstraction provides to a developer? If a developer commits to a single implementation, such as Helm, it would require a higher cognitive load than just using Helm directly and offer no real benefits. Using different implementations, such as Helm and Compose, would add significant extra cognitive load as they are different enough in how they work and support different functionality.

From the operations persona I can see even less of a reason to adopt or support Score as I can only see it increasing cognitive load and leaking abstractions.

Feel free to make this a discussion, I'd have made it one if it was an option when I created the issue.

[sujaya-sys]

your reply doesn't really answer the question I asked; you've focused on a specific OAM implementation rather than OAM as a specification. This also goes for the blog posts you linked to.

The design of the OAM is directly driven by Kubevela. Specification and implementation are tightly coupled. This is why I referenced Kubevela in my comment, it allows to illustrate OAM concepts in a tangible way. If there's a need to differentiate more clearly between both, it'll be great to understand how the points mentioned above don't apply to the OAM:

• point A: The Score and OAM spec differ in scope. Score is focused on workloads while OAM defines an end-to-end deployment model for applications [...]
• point B: The Score spec is uninvolved in the operational side of things, OAM however includes this part in form of a "how to operate" section [...]
• point C: OAM is focused on Kubernetes as a runtime which is why at this point an implementation would likely require you to provision a local cluster with a tool such as Kind [...]

That being said, there are definitely areas in which Score and OAM overlap as you mentioned in your initial comment. Both introduce a specification standard, are developer focused and platform-agnostic. The items above simply list differences while acknowledging that there are similarities.

I still can't see what the benefit of the Score abstraction provides to a developer? If a developer commits to a single implementation, such as Helm, it would require a higher cognitive load than just using Helm directly and offer no real benefits.

Score shines in a multi-platform set up. For example: Docker Compose for local development, Kubernetes for a shared development environment and Google Cloud Run for integration tests. The same Score spec can be used to deploy a workload to each environment without the developer needing to get involved with the underlying platform. We're following the same approach as OAM here by aiming to provide a platform/vendor agnostic experience for the developer.
If you're working in a single platform set up (for example Kubernetes from local to production) and your team is made up of experienced (Kubernetes) developers, I agree, Score probably won't provide a lot of value to you as this is not the use case that it targets.

Using different implementations, such as Helm and Compose, would add significant extra cognitive load as they are different enough in how they work and support different functionality.

The cognitive load stays the same for the developer independently of the amount of implementations their team makes use of. The Score Specification is defined once and can be executed against different CLIs to automatically generate required configuration. The developer simply runs a different CLI depending on the target platform.

From the operations persona I can see even less of a reason to adopt or support Score as I can only see it increasing cognitive load and leaking abstractions.

Score is solely focused on the developer experience. The cognitive load of the operations persona and any issues related to leaking abstractions depend on the teams infrastructure/platform set up. Score simply wants to set a standard for developer experience and leaves it to the ops team on how to set everything up behind the scenes. If your operations team works with some kind of internal developer platform that resolves configuration/resource requirements defined in Score automatically, you shouldn't run into any of the above named issues. Again, this totally depends on the maturity of your platform set up.

Feel free to make this a discussion, I'd have made it one if it was an option when I created the issue.

Agreed! @gguizza should we transform this into a discussion? It's definitely an interesting subject that would be great to explore further with a wider audience.

[stevehipwell]

The design of the OAM is directly driven by Kubevela. Specification and implementation are tightly coupled. This is why I referenced Kubevela in #23 (comment), it allows to illustrate OAM concepts in a tangible way.

@sujaya-sys I know OAM is currently being developed in parallel with KubeVela but I don't think that's a long term goal (see oam-dev/spec#475).

What I'm seeing is that the Score spec could be defined as a functional subset of the OAM spec. The fundamental difference is Score mandating a container(s) spec as part of a workload while OAM allows any workload specification. The other missing pieces are strongly types scopes (between workloads) and strongly typed traits.

It seems like at least on the spec side of things that both Scope and OAM are solving the exact same problem so the concepts should be pretty well aligned. My suggestions for the spec are as follows (based on the experience of building almost this exact system as part of an IDP).

• Support non container workloads
  • VM
  • Function
• Support user defined schema for resources
  • Allow "operations" to "request" data
  • Validate provided configuration
  • IDP ready
• Remove current environment variable logic/documentation
  • Support env lookup in the spec file (e.g. some syntax like @{MY_VAR-default} mainly used for local development)
  • Overrides to be preferred way of changing values
• Support Kubernetes YAML as preferred over Helm
  • Helm isn't the best choice for regularly changing CD workloads (it's great for externally packed applications)
  • Reference implementation to work like compose using default templates
  • User defined templates using sprig like Helm (allow unbundling of default templates to help get started)
  • YAML manifests are less opinionated than Helm but used like this would have all of the benefits of Helm

[sujaya-sys]

This is helpful feedback. Thanks for sharing! I'll also share this with our team internally. A couple of things you mentioned, such as a score-kubernetes integration as well as the support of non container workload types have been brought up by others as well. For the latter we have the following discussion post in place: #39.

[stevehipwell]

@sujaya-sys with OAM independent of KubeVela (oam-dev/spec#475 (comment)) could there be collaboration between Score & OAM to define a common model? Given they're two projects solving the same problem but with different starting points and biases that would make sense.

[sujaya-sys]

Agreed. Both models target a similar problem space and share similar views on how a solution could look like. We're always open to exploring opportunities for collaboration and knowledge exchange. However, as mentioned above, Score is limited by design and we're cautious about extending or modifying the spec as our main goal lies in reducing cognitive load for developers. Other differences such as OAM and Score not sharing the same approach to configuration management (overrides vs. dynamic injected values) would have to be explored in more detail.

[stevehipwell]

@sujaya-sys I think the danger for Score here is becoming an island, even if you want to primarily focus on developers there are still other roles needing to interact with the developers output. If you build the best tools possible for developers but forget about everyone else at best you've just shifted the pain "right", but at worse you've made someone else's task much harder. This goes against the DevOps spirit of not throwing things over the wall but collaborating on them and shifting "left" where possible.

I think OAM shifts "left" defining application traits, which although not perfect is conceptually aligned with DevOps. Unfortunately I think Score is currently closer to shifting "right".