Proposal: Adding a developer focused modeling language layer

[Haishi2016]

As OAM matures, its complexity increases. As OAM is designed to separate operation concerns from developers, there’s a need to provide a developer-focused modeling language on top of the OAM model. Architecturally, the new language layer will be layered on top of the OAM model. So, this proposal doesn’t affect the OAM object model itself, but introduces a developer-friendly modeling language layer on top of it.

The modeling language brings the following benefits to developers:

1. Developers can describe the topology of their applications and behavior of their components without making assumptions on availability of specific traits. For instance, a developer will be able to model auto-scaling needs without referring to a specific trait.
2. Provides a single source of truth of the application design. The modeling language allows developers to work with a single artifact to capture the application design. This artifact is the definitive truth of how the application is supposed to look like. It simplifies administrative tasks such as change management. It also serves as an anchor for application truth to avoid configuration drifts during operation.
3. Shorten the learning curve of new developers. OAM has been developed by leading software companies that run very complex workloads. However, for the bigger developer community, the new language layer provides a much simpler path to onboard OAM. This will help to encourage broader OAM adoption.

I believe separating the object model and the modeling language is a healthy thing to do regardless. As the object model evolves, the complexity unavoidably increases. Not separating the two exposes the increasing complexity, making new adoptions more difficult. Formally separating the two makes OAM stand apart from other existing modeling methods and allows us to control the complexity without sacrificing expressiveness of the model.

The language layer can be supported by the control plane implementation itself, or by client-side tools such as the OAM CLI tool. I think client-side support is preferable because it avoids duplicated efforts in control plane implementations, and it will work with existing control planes.

[hongchaodeng]

Can you talk about what is the modeling language and give some examples on OAM?

[Haishi2016]

A modeling language provides a syntax that can be translated into OAM primitives. The following is an example of a fictional syntax, which we can tentatively call it OAMLite ( :) ). Note how it allows inline definition of components, and auto-scaler is a native first-class construct (comparing to a generic trait). This syntax captures the entire application in a single artifact with simpler syntax.

This artifact will be translated to OAM object models by either CLI or the control plane itself.

apiVersion: oam.dev/v1alpha1
kind: Application
metadata:
  name: test-app
  namespace: default
spec:
  components:
  - name: myservice
    ingress:
      route: "/test"
    replicas: 1
    container:
      name: myservicev1
      image: some/nodeserver:cpu
      ports:
      - containerPort: 3000
      env:
      - name: VERSION
        value: "CPU HEAVY"
    auto-scale:
      minReplicas: 1
      maxReplicas: 5
      rules:
      - metric: CPU
        targetAveragePercent: 20

This is useful not only to attract more developers, but also to give more opportunities of control in an enterprise system. For example, an enterprise can further constrain the syntax with specific policies, such as demanding all components having multiple replicas.

[ryanzhang-oss]

Hi, Haishi, Here is my take. IIRC, you are not really proposing a OAMLite but more of an ApplicationConfigLite. OAMLite would include definition for workload/trait/scope. I don’t think we need OAMLite as workload/traits/scope are mostly defined by platform/runtime builder who are supposed to be experts in this domain. I agree that we can’t expect all end users to write an ApplicationConfiguration yaml file to deploy to any OAM enabled platform. I would argue that even the AppLite yaml file below can be too complicated. My vision is that for each OAM platform builders to provide their own UI/tools that is idiomatic to their platform users. I wonder if that makes sense?

-Ryan

On Feb 6, 2020, at 1:23 PM, Haishi2016 notifications@github.com<mailto:notifications@github.com> wrote:

A modeling language provides a syntax that can be translated into OAM primitives. The following is an example of a fictional syntax, which we can tentatively call it OAMLite ( :) ). Note how it allows inline definition of components, and auto-scaler is a native first-class construct (comparing to a generic trait). This syntax captures the entire application in a single artifact with simpler syntax.

This artifact will be translated to OAM object models by either CLI or the control plane itself.

apiVersion: oam.dev/v1alpha1 kind: Application metadata: name: test-app namespace: default spec: components:

• name: myservice ingress: route: "/test" replicas: 1 container: name: myservicev1 image: some/nodeserver:cpu ports:
  • containerPort: 3000 env:
  • name: VERSION value: "CPU HEAVY" auto-scale: minReplicas: 1 maxReplicas: 5 rules:
  • metric: CPU targetAveragePercent: 20

This is useful not only to attract more developers, but also to give more opportunities of control in an enterprise system. For example, an enterprise can further constrain the syntax with specific policies, such as demanding all components having multiple replicas.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/oam-dev/spec/issues/306?email_source=notifications&email_token=AODXOHDY6KDR4EOZHSI4ZO3RBR5UJA5CNFSM4KRABOQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELA2SLI#issuecomment-583117101, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AODXOHBMJ7VI5P2AFY2ZYSDRBR5UJANCNFSM4KRABOQA.

[wonderflow]

I'm afraid this layer would be another API for end user. In that case, the reusable benefit of OAM wouldn't come true. In fact, like Ryan said, OAM platform builders have their freedom to build a developer-friendly UI/tools. On the other hand, end user could use unified OAM spec to deploy their App directly.

[Haishi2016]

Okay. I agree with the comments. I'll close this for now.

[resouer]

I will re-open this issue since the community is now actively working on the appfile (ref: https://github.com/oam-dev/spec/issues/389), which is exactly originated from this proposal. /cc @Haishi2016

It will need to implemented it in server side if we follow K8s API style object (i.e. Application CRD)

[kminder]

I'm a bit confused by this proposal. My interpretation is that this proposal is suggesting that the ApplicationConfiguration syntax is too verbose/generic. This proposal seems to duplicate the content of the ApplicationConfiguration in a more human friendly format. Some thoughts...

1. If this format is sufficient (and better) why retain ApplicationConfiguration?
2. Much of ApplicationConfiguration's complexity is caused by extensibility. How does this appfile proposal support extensibility?

[resouer]

Hi @kminder, Appfile is designed as a client side abstraction to simplify user input and render OAM objects. But we are also discussing if need to move its implementation to a CRD, it will be a replacement of AppConfig then.

[resouer]

@kminder Another detail I'd like to reference is: https://github.com/oam-dev/kubevela/issues/399#issuecomment-711064876. As the tool/modeling language for developers, Appfile will include features in its upcoming releases such as build and release. They are not in scope of OAM but important for end users.