Document deploying your own database, object storage and registry

[mrsimonemms]

"Database, object storage and registry" is a long and repetitive phrase to write. In this PR, it will be referred to as DOR

Is your feature request related to a problem? Please describe

For Gitpod self-hosted, we always recommend using managed cloud instances for DOR - they are more performant and easier to manage and backup. It is anticipated that all enterprise customers and the majority of community users will follow this path. For convenience, we offer DOR as in-cluster dependencies - these are intended to be used when running proof of concept installations, or for installations with a small number of users.

There are times when users can't/don't want to use a cloud-managed DOR and the in-cluster configuration is not quite to their needs, eg #9698

Describe the behaviour you'd like

The DOR configuration was written with an explicit "in-cluster" vs "external" dichotomy. The implication is that this is "internal/external to the cluster" when it's actually "internal/external to the Installer". This means that if you want to configure your own DOR, you can simply deploy your own version to your cluster and access is over the internal service URL (eg, service.namespace.svc.cluster.local:port).

As far as the Gitpod installation is concerned, there's no difference between this and a cloud-managed DOR - it's just a service that's accessed over a network (go 12Factor App!).

As part of the Advanced Installation docs, we should document examples of how to deploy custom DOR. It is important to note that we shouldn't write it in a way that opens up lots of support questions of "I want to do this with my database deployment" - these must be explicitly written so that readers are aware that this is an advanced topic that is how people can customise their DOR.

Describe alternatives you've considered

Do nothing and point to this issue every time we're asked.

Additional context

We should probably think of a naming convention. I've been using "external in-cluster dependencies", but that's a bit wordy and doesn't really explain the problem/solution.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.