Why introduce new specifications instead of building on existing cloud-native standards?

General
7

Hello Felix,
We are happy you came and expressed your concerns. I would be happy to jump on a call and discuss any of the topics mentioned in this chat.

Key point in my feedback to your concerns:
I think about Margo as a collection of proven cloud native standards that are prescribed for OT environments. We only create what is necessary to enable the vendor interoperability the community is aiming to achieve. Our goal is always adopt proven technologies where available.

Could you give a concrete example where existing cloud-native standards don’t fit?

  • If this is a question of what Margo has created, outside of exisitng cloud-native standards, it really comes down to two items.
    • First, the Workload Fleet Managmeent(WFM) cloud to edge API was created to enable vendor interoperability between the Fleet manager and Device client
      • GitOps was introduced initially, but was not chosen as the standard interface for retrieving desired state files from the Workload Fleet Manager. Reasons can be found in the approved SUP linked here
      • Although your solutions utilize GitOps, many other cloud to edge managers maintain their own proprietary management interface, that requires device vendors to comply limiting largescale compute production.
      • Additional information on GitOps can be found here as well from a previous post to the community.
    • Second, Margo’s Application Description was created to enable application developers to describe their apps once, for inclusion in application catalogs and marketplaces. We did not find anything that fit our needs, mostly proprietary solutions requiring the app dev to manage one to many descriptors per WFM.
      • See details of the application description here

For example, is there a specific industrial use case where OCI, Helm or GitOps cannot express the required semantics, making a Margo-specific specification necessary?

  • Margo has adopted the following standards you are referencing holistically, with minimal limitations.
    • Helm
      • Minimal limitations regarding server side kubernetes API access.
    • OCI runtimes
    • OCI packaging and distribution
  • GitOps was the only solution from your list here that we did not adopt for reasons outlined above.

In our projects, we already build industrial edge platforms using technologies such as Talos Linux, GitOps (Argo CD), OCI and Helm. We deploy and manage edge devices this way, integrate machines through applications like Node-RED and even run industrial workloads such as soft PLCs, industrial apps or HMI integrations.

Some comments on the items you mentioned:

  • Talos Linux
    • This is considered a “black box” selection via the device supplier. Margo does not dictate a specific Linux or other OS.
  • Gitops
    • See notes above
  • OCI / Helm
    • Margo holistically adopts both of these technologies. OCI for runtime and packaging, and helm for manifests targeting kubernetes.

I appreciate @silvano and @andrii pitching in and replying.

@Felix I hope I addressed your concerns. If not, please follow up with additional questions/concerns.

Armand
TWG Chair