Providing external endpoint for Service Flavors

[fracappa]

Hi folks.

In the last few releases, the Service Flavor has been implemented and partially tested.

I'm currently skipping all the details that have been already provided by @andreacv98 in several occasions and I will try to summarize the details in schemas.

---

Current situation

The current design and implementation has the following schema.

Please, bare in your mind that the REAR ends after the colored boxes.

What I want to point out in this issue is that we have two possible scenarios in this implementation that depends on how the Service is consumed (the blue arrows depicted into the schema):

1. The service is hosted on the Provider cluster (hostingPolicy=Provider).
2. The service is hosted on the Consumer cluster (hostingPolicy=Consumer).

We can differentiate this approach by looking both the type of Liqo Peering and by the way the Service is consumed.

Please note the aterisks:
*Provider-to-Consumer-peering: this is needed when hostingPolicy=Consumer.
**Consumer-to-Provider-peering: this is needed when hostingPolicy=Provider.

However, some feedback has been received in order to support an additional scenario.

Extended solution

The scenario that come out from other people feedback is when having services that are hosted on external endpoint, neither on the Provider nor on the Consumer.

One example could be an application that has both a client and a server component, where we would need to install only the client.

So, a schema that follows this idea would be looking like the following shcema

Please, note that the REAR protocol involves only the Consumer and the Provider.

The External Endpoint is a third actor that is not involved into the protocol and it just provide access to a Service advertised and negotiated by the Provider.

Here, the Provider mainly acts as a broker to a third-party Service.

In this case, we could decide whether is worth it to specify a different hostingPolicy (e.g. hostingPolicy=External) or to assume a Service as External when no hostingPolicy is specified.

Waiting for any feedback you may have.

Thanks,
Francesco

[LorenzoMoro]

This third scenario seems reasonable to me, but I have a doubt: does the provider act just as a broker to the third-party Service or does it relay the connectivity to this Service as well? In the first case, that seems to me the most probable, couldn't it be managed by another REAR-speaking entity (like the Catalog), without the need of a k8s cluster? In the second case, on the contrary, the network manager of the provider should somehow proxy the sessions, shouldn't it?

[fracappa]

Hi @LorenzoMoro.

I believe it could be a combination of both.

The first case could be useful if the provider already uses (or it already has a sort of subscription to) a third-party service which is publicly exposed.
In this case you're right that we're using the Provider as a Catalogue but it hides away details about the owner of the service (as usually brokers do more than catalogue).

The second case could be useful when we want to establish connectivity to services defined into an isolated environment defined by the provider without exposing data on the internet. It's an idea similar to the Virtual PrivateLink of AWS.
I believe in this case you're right, the provider's network manager should be acting like a proxy.