Skip to content

Latest commit

 

History

History
60 lines (37 loc) · 2.8 KB

why_exists.adoc

File metadata and controls

60 lines (37 loc) · 2.8 KB

Why does Application Catalog exist?

The application catalog is the successor to the classic VSHN Managed Services on virtual machines, managed by Puppet. It’s a very similar concept, applied to Kubernetes, but extended with Cloud services integration, which wasn’t available with Puppet.

More resources:

For the user

There are different users:

  • The VSHNeer who engineers the application hosting environment for a VSHN customer

  • The APPUiO Cloud user who needs a service for their application running on APPUiO Cloud

  • The APPUiO Managed user who cares about the application themselves

  • The developer who needs a service for the application but doesn’t want to be concerned about platform topics

Consume services for the application

Software running on a Kubernetes cluster usually needs one or many backend services (databases, caches, object storage, and so on). Ordering and consuming of such a service must be as simple as possible to not cause friction and the focus can lie on the application.

Self-Service with Best-Practices

When a service from the application catalog is needed, it must be available straight away without waiting for someone to provision it. Best-practices should already be applied by the platform team, which isn’t the developers concern.

For VSHN

Enable self-service for Developers

By enabling the developer to self-service order a service we can focus on providing the service, instead of provisioning of the service.

Simplify service brokering

Brokering of external services gets much easier when we have a set of pre-defined services available, rather than reinventing the provisioning and cloud architecture every time again and again.

Standard way to provide services

All services which are offered in the application catalog have the same identity. They adhere to a defined resource model which makes them well-discoverable. It’s easy to start with a new service, as they have a common look.

For a Cloud Service Provider

A cloud service provider might want to onboard new customers and needs to provide more services.

For a software vendor

A software vendor might want to provide their software in a Kubernetes cluster and have it as a part of the application catalog.

Differentiation to Project Syn

Project Syn, namely Commodore Components, are static configuration options for a whole Kubernetes cluster. It lacks the self-service aspect completely and hasn’t been built for that.