Open Application Model [OAM] describes a model where developers are responsible for defining application components.
While application operators are responsible for creating instances of those components and assigning them application configurations.
And infrastructure operators are responsible for declaring, installing, and maintaining the underlying services that are available on the platform.
OAM is platform-agnostic. Read the Intro doc for more background and user stories.
apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata: name: helloworld-python-v1 spec: name: helloworld-python workloadType: core.oam.dev/v1alpha1.Server containers: - name: foo image: oamdev/helloworld-python:v1 env: - name: TARGET fromParam: target - name: PORT fromParam: port ports: - type: tcp containerPort: 9999 name: http parameters: - name: target type: string default: World - name: port type: string default: "9999"
apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata: name: alpine-forever-v1 spec: workloadType: core.oam.dev/v1alpha1.SingletonServer parameters: - name: message type: string required: false - name: unused_integer type: number required: false default: 5678 containers: - name: runner image: technosophos/alpine-forever:latest env: - name: FOO value: bar fromParam: message - name: UNUSED value: "1234" fromParam: unused_integer --- apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata: name: example-env-vars spec: components: - name: alpine-forever-v1 instanceName: example-alpine-forever parameterValues: - name: message value: Hello World
Rudr takes an incremental approach to solving problems. The architecture is a set of plugins for Kubernetes which allow OAM specifications to be implemented and deployed on clusters with native APIs (you still use kubectl).
This allows app developers to focus on building OAM components, app operators to focus on operational capabilities through the OAM app config and infra operators to focus on Kubernetes. By leveraging the Open App Model, users now have a framework to define their apps on their Kubernetes clusters.
Currently, Rudr will leverage the defined trait to accomplish the task. This gives the freedom to use whatever underlying tool the user wants while providing a trait that focuses on the functionality and not the technology. In the future, Rudr might provide a set of default technologies to provide the functionality desired by a trait.