Expose Executor as a Service as First class citizen in Documentation.

[JoanFM]

Describe the feature
Right now we have added Executor.serve method and we are seeing increasing interest in serving a single Executor as an isolated service.

After Head is removed as a result of the service mesh introduction, this will be even more performant, and gateway remains a useful entity in the picture.

I think code-wise perspective, I belive the only needed thing is to add a method Executor.to_k8s_yaml() and Executor.to_docker_compose_yaml that under the hood create a simple Flow and call its to_* method.

The main work would be in documentation and storytelling about exposing this as a first-class option of Jina.

[JoanFM]

Blocked by #4503

[JohannesMessner]

Seems like a good thing to do.
I see some conceptual overlap with external Executors, and we probably need to be careful to make the distinction clear.

[JoanFM]

Seems like a good thing to do. I see some conceptual overlap with external Executors, and we probably need to be careful to make the distinction clear.

Good point, did not think about it, but it would be the biggest blocker

[jacobowitz]

Let's restrict this for now to gRPC? Otherwise it will be more complicatd to integrate as external Executor

[JohannesMessner]

Let's restrict this for now to gRPC? Otherwise it will be more complicatd to integrate as external Executor

Makes sense. Remind me, did we land on served executors being the only recommended way of doing external Execs from now on?

[jacobowitz]

I would say that serve is the recommended way. But this includes to_k8s_yaml/to_docker_compose methods @JoanFM was mentioning.
Also we may want to think about exposing serve as part of CLI? I think sth like jina executor serve or so makes sense? I dont to force people to run python code

[JohannesMessner]

Also we may want to think about exposing serve as part of CLI?

Agree

[jacobowitz]

We somehow should be able to deploy this with and without a gateway?