Separation of Concerns

KubeVela designs for separation of concerns, as a result, there’re two roles of users:

  • Platform Team
    • The platform engineers initialize the deployment environments, provide stable infrastructure capabilities (e.g. mysql-operator) and register them as reusable templates using KubeVela Definitions into the control plane. They should be experienced and skillful with the infrastructure.
  • End Users
    • The end users are usually app developers. They choose target environment, and choose capability templates, fill in values and finally assemble them as a KubeVela Application. They don’t need to understand the infrastructure details.

The KubeVela community has also maintained a bundle of infrastructure capabilities, they are called addons.

The work flow is shown as below:

alt

The separation of concern benefit the end users most. They can enjoy the “Application-Centric” experience without learning any infrastructure details. To make it more concrete, they can be free from the following scenarios:

  • No need to learn Kubernetes API deprecations from versions upgrade.
  • No need to care about the difference between several ingress implementations.
  • No need to understand the CPU limit or even deeper infrastructure knowledge such as pod disruption budget.
  • Declare high availability or other operation requirements as application traits.
  • Use the capability with more confidence as they’re enforced with best practices provided by platform teams.

As to platform teams, the benefits are also obvious:

  • They can provide reusable capabilities, enforce best practices and make application delivery safer.
  • They can provide flexible template parameters to serve different application teams with the same platform per their needs.
  • They can share and integrate capabilities with the whole open source community easily in a standard way.

Last updated on Feb 9, 2023 by dependabot[bot]