Skupper terminology and concepts

[Justin Ross]

Hi, all.  Here's an attempt to outline the entities and relationships in the Skupper model.  For now, the description is closely tied to Kubernetes to aid understanding, but I don't necessarily mean that to always be the case.

VirtualApplicationNetwork (VAN, Skupper network)
 - Is a multi-site application-layer network
 - Hosts one DistributedApplication
 - Connects all the ApplicationSites in a given DistributedApplication
 - Forms a graph of connected ApplicationSites (the network topology)

DistributedApplication (Application)
 - Is an application implemented as multiple independent services in communication with each other
 - Has one or more ApplicationServices, deployed across multiple Kube clusters
 - Runs on one VirtualApplicationNetwork
 - Forms a graph of connected ApplicationServices (the application topology)

ApplicationService (Service)
 - Is a piece of functionality exposed as a network-accessible interface
  - Has a name
   - This name features importantly in the presentation of a DistributedApplication
   - If not specified, Skupper tooling uses the Kube deployment name
 - Corresponds to one Kube service *name* (*not* one Kube *service* - see next point)
 - Corresponds to one or more Kube services (but only *one* Kube service *name* - see previous point)
 - Corresponds to one VirtualApplicationNetwork address
 - Has one or more ApplicationDeployments
 - Uses zero or more ApplicationServices

ApplicationDeployment (Deployment)
 - Is a configuration of the entities that support a running service
 - Has a name
   - If not specified, Skupper tooling uses the Kube deployment name
 - Runs in the context of one ApplicationSite (it has a "location")
 - Corresponds to one Kube deployment

ApplicationProcess (Process)
 - Is a piece of running code that implements the network-accessible interface of its service
 - Has a name
   - If not specified, Skupper tooling uses the Kube pod name
 - Corresponds to one Kube pod

ApplicationChannel (Channel)
 - In HTTP, represents a caller/callee relationship (not just one HTTP call)
 - In TCP, represents a client/server relationship (not just one TCP connection)
 - Forms the links in the application topology
 - Has traffic statistics
 - The channel endpoints are two ApplicationProcesses

ApplicationSite (Site)
 - Is a context for running a service deployment
 - Has a name
   - If not specified, Skupper tooling uses the Kube namespace name
 - Corresponds to one Kube namespace (in future, perhaps a cluster)
 - Hosts zero or more ApplicationDeployments

[Justin Ross]

On Thu, Dec 12, 2019 at 5:24 PM Justin Ross <justi...@gmail.com> wrote:

Hi, all.  Here's an attempt to outline the entities and relationships in the Skupper model.  For now, the description is closely tied to Kubernetes to aid understanding, but I don't necessarily mean that to always be the case.

VirtualApplicationNetwork (VAN, Skupper network)
 - Is a multi-site application-layer network
 - Hosts one DistributedApplication

The 1:1 relation of VAN to Application is something I want to think about some more.  For one, I think the Application may be a useful grouping construct for Services.  For two, if deployment resources are to some degree tied to the unit of one VAN, then maybe you don't want to have to have more than one for multiple Applications.

 

 - Connects all the ApplicationSites in a given DistributedApplication
 - Forms a graph of connected ApplicationSites (the network topology)

DistributedApplication (Application)
 - Is an application implemented as multiple independent services in communication with each other
 - Has one or more ApplicationServices, deployed across multiple Kube clusters
 - Runs on one VirtualApplicationNetwork
 - Forms a graph of connected ApplicationServices (the application topology)

ApplicationService (Service)
 - Is a piece of functionality exposed as a network-accessible interface
  - Has a name
   - This name features importantly in the presentation of a DistributedApplication
   - If not specified, Skupper tooling uses the Kube deployment name
 - Corresponds to one Kube service *name* (*not* one Kube *service* - see next point)
 - Corresponds to one or more Kube services (but only *one* Kube service *name* - see previous point)
 - Corresponds to one VirtualApplicationNetwork address
 - Has one or more ApplicationDeployments
 - Uses zero or more ApplicationServices

ApplicationDeployment (Deployment)
 - Is a configuration of the entities that support a running service
 - Has a name
   - If not specified, Skupper tooling uses the Kube deployment name
 - Runs in the context of one ApplicationSite (it has a "location")
 - Corresponds to one Kube deployment

Having Deployment and Process is probably the way to go, but I find the reasoning a bit subtle and hard to remember, which makes me think twice.

 

ApplicationProcess (Process)
 - Is a piece of running code that implements the network-accessible interface of its service
 - Has a name
   - If not specified, Skupper tooling uses the Kube pod name
 - Corresponds to one Kube pod

ApplicationChannel (Channel)

I wasn't able to immediately come up with an "is a" here.  Let me know if you have ideas.

[Gordon Sim]

On 13/12/2019 12:29 pm, Justin Ross wrote:
> On Thu, Dec 12, 2019 at 5:24 PM Justin Ross <justi...@gmail.com
> <mailto:justi...@gmail.com>> wrote:
>
> Hi, all.  Here's an attempt to outline the entities and
> relationships in the Skupper model.  For now, the description is
> closely tied to Kubernetes to aid understanding, but I don't
> necessarily mean that to always be the case.
>
> VirtualApplicationNetwork (VAN, Skupper network)
>  - Is a multi-site application-layer network
>  - Hosts one DistributedApplication
>
>
> The 1:1 relation of VAN to Application is something I want to think
> about some more.  For one, I think the Application may be a useful
> grouping construct for Services.  For two, if deployment resources are
> to some degree tied to the unit of one VAN, then maybe you don't want to
> have to have more than one for multiple Applications.

For me the key point is that the VAN is a single 'address-space'. If you
deploy distinct 'applications' to the same VAN, you are responsible for
ensuring their use of addresses does not collide.

To support multiple applications, they would (in my view) need to have
their own address-space (which is essentially their own VAN).

I see DistributedApplication as being essentially defined by its
association to a network, and a VAN as being defined by the application
it is designed to connect. That is true whether all the services
communicate or whether there are in fact several disjoint sets of
services (though if we care enough about that another term is needed to
distinguish those).

User defined groupings of services are also in my view a separate thing
(regardless of what we actually call them all).

>  - Connects all the ApplicationSites in a given DistributedApplication
>  - Forms a graph of connected ApplicationSites (the network topology)
>
> DistributedApplication (Application)
>  - Is an application implemented as multiple independent services
> in communication with each other
>  - Has one or more ApplicationServices, deployed across multiple
> Kube clusters
>  - Runs on one VirtualApplicationNetwork
>  - Forms a graph of connected ApplicationServices (the application
> topology)

As above, my assumption here is that the graph is not necessarily fully
connected. (I.e. the above perhaps would be Forms one or more graphs of
connected AppplicationServices.)

> ApplicationService (Service)
>  - Is a piece of functionality exposed as a network-accessible
> interface
>   - Has a name
>    - This name features importantly in the presentation of a
> DistributedApplication
>    - If not specified, Skupper tooling uses the Kube deployment name
>  - Corresponds to one Kube service *name* (*not* one Kube *service*
> - see next point)
>  - Corresponds to one or more Kube services (but only *one* Kube
> service *name* - see previous point)
>  - Corresponds to one VirtualApplicationNetwork address
>  - Has one or more ApplicationDeployments
>  - Uses zero or more ApplicationServices
>
> ApplicationDeployment (Deployment)
>  - Is a configuration of the entities that support a running service
>  - Has a name
>    - If not specified, Skupper tooling uses the Kube deployment name
>  - Runs in the context of one ApplicationSite (it has a "location")
>  - Corresponds to one Kube deployment
>
>
> Having Deployment and Process is probably the way to go, but I find the
> reasoning a bit subtle and hard to remember, which makes me think twice.

Can you elaborate? I think both are important concepts regardless of the
names we use. The 'deployment' concept is perhaps quite kubernetes
centric whereas the 'process' is more universal. At present however our
focus (rightly, in my view) is kubernetes, so I think having deployment
represented in the model at this point is important.

> ApplicationProcess (Process)
>  - Is a piece of running code that implements the
> network-accessible interface of its service
>  - Has a name
>    - If not specified, Skupper tooling uses the Kube pod name
>  - Corresponds to one Kube pod
>
> ApplicationChannel (Channel)
>
>
> I wasn't able to immediately come up with an "is a" here.  Let me know
> if you have ideas.

A process is a program in execution.

[Justin Ross]

On Fri, Dec 13, 2019 at 12:21 PM Gordon Sim <gordon...@gmail.com> wrote:

On 13/12/2019 12:29 pm, Justin Ross wrote:
> On Thu, Dec 12, 2019 at 5:24 PM Justin Ross <justi...@gmail.com
> <mailto:justi...@gmail.com>> wrote:
>
>     Hi, all.  Here's an attempt to outline the entities and
>     relationships in the Skupper model.  For now, the description is
>     closely tied to Kubernetes to aid understanding, but I don't
>     necessarily mean that to always be the case.
>
>     VirtualApplicationNetwork (VAN, Skupper network)
>       - Is a multi-site application-layer network
>       - Hosts one DistributedApplication
>
>
> The 1:1 relation of VAN to Application is something I want to think
> about some more.  For one, I think the Application may be a useful
> grouping construct for Services.  For two, if deployment resources are
> to some degree tied to the unit of one VAN, then maybe you don't want to
> have to have more than one for multiple Applications.

For me the key point is that the VAN is a single 'address-space'. If you
deploy distinct 'applications' to the same VAN, you are responsible for
ensuring their use of addresses does not collide.

To support multiple applications, they would (in my view) need to have
their own address-space (which is essentially their own VAN).

It's that parenthetical part that bothers me a little.  I'm not sure I want to couple namespacing to the access limits that distinct networks suggest.  It's not that it's terrible.  It just seems to fuse two concerns.

 

I see DistributedApplication as being essentially defined by its
association to a network, and a VAN as being defined by the application
it is designed to connect. That is true whether all the services
communicate or whether there are in fact several disjoint sets of
services (though if we care enough about that another term is needed to
distinguish those).

User defined groupings of services are also in my view a separate thing
(regardless of what we actually call them all).

>       - Connects all the ApplicationSites in a given DistributedApplication
>       - Forms a graph of connected ApplicationSites (the network topology)
>
>     DistributedApplication (Application)
>       - Is an application implemented as multiple independent services
>     in communication with each other
>       - Has one or more ApplicationServices, deployed across multiple
>     Kube clusters
>       - Runs on one VirtualApplicationNetwork
>       - Forms a graph of connected ApplicationServices (the application
>     topology)

As above, my assumption here is that the graph is not necessarily fully
connected. (I.e. the above perhaps would be Forms one or more graphs of
connected AppplicationServices.)

No objections.

 

>     ApplicationDeployment (Deployment)
>       - Is a configuration of the entities that support a running service
>       - Has a name
>         - If not specified, Skupper tooling uses the Kube deployment name
>       - Runs in the context of one ApplicationSite (it has a "location")
>       - Corresponds to one Kube deployment
>
>
> Having Deployment and Process is probably the way to go, but I find the
> reasoning a bit subtle and hard to remember, which makes me think twice.

Can you elaborate? I think both are important concepts regardless of the
names we use. The 'deployment' concept is perhaps quite kubernetes
centric whereas the 'process' is more universal. At present however our
focus (rightly, in my view) is kubernetes, so I think having deployment
represented in the model at this point is important.

I don't disagree, but as you say, process makes sense in any model.  Deployment on the other hand might not have a place in another, comparable system.

My discomfort I think really arises from my inability to easily defend its presence in the model in the absence of Kubernetes.  I want it to feel essential or obvious.  I can imagine a system that put all the deployment attributes instead on its local notion of a service.  Then I guess I'd have argue that that local service concept is what Skupper calls a deployment.

 

>     ApplicationProcess (Process)
>       - Is a piece of running code that implements the
>     network-accessible interface of its service
>       - Has a name
>         - If not specified, Skupper tooling uses the Kube pod name
>       - Corresponds to one Kube pod
>
>     ApplicationChannel (Channel)
>
>
> I wasn't able to immediately come up with an "is a" here.  Let me know
> if you have ideas.

A process is a program in execution.

My quoting made my request unclear.  I was asking about the "is a" for ApplicationChannel.

The "is a" I have for ApplicationProcess is a little different from yours:

 - A process is a piece of running code that implements the network-accessible interface of its service

 - A process is a program in execution

I like the "program in execution" part, but I also am interested in drawing the link between the interface contract of the service and the interface implementation of the process.

[Gordon Sim]

On 13/12/2019 7:39 pm, Justin Ross wrote:
> I'm not sure I want to couple namespacing to the access limits that
> distinct networks suggest.

I'm not sure I understand what you are saying here. If the applications
need to communicate then (at present) I would say they are in fact the
same application and using the same application network makes sense.

Communicating with something that wants it's own address-space would
require the address to be qualified by address-space which sort of then
gets back to a shared addressspace at some bigger scope.

All I am really arguing is that at present an application network is
'single tenant', and I understand the 'application' as essentially that
single tenant.

[Gordon Sim]

On 13/12/2019 7:39 pm, Justin Ross wrote:
> On Fri, Dec 13, 2019 at 12:21 PM Gordon Sim <gordon...@gmail.com
> <mailto:gordon...@gmail.com>> wrote:
>
> On 13/12/2019 12:29 pm, Justin Ross wrote:
> > Having Deployment and Process is probably the way to go, but I find the
> > reasoning a bit subtle and hard to remember, which makes me think twice.
>
> Can you elaborate? I think both are important concepts regardless of the
> names we use. The 'deployment' concept is perhaps quite kubernetes
> centric whereas the 'process' is more universal. At present however our
> focus (rightly, in my view) is kubernetes, so I think having deployment
> represented in the model at this point is important.
>
> I don't disagree, but as you say, process makes sense in any model.
> Deployment on the other hand might not have a place in another,
> comparable system.
>
> My discomfort I think really arises from my inability to easily defend
> its presence in the model in the absence of Kubernetes.  I want it to
> feel essential or obvious.

I think kubernetes is the primary target and in that context I think
deployment is both obvious and essential.

>  I can imagine a system that put all the
> deployment attributes instead on its local notion of a service.

Then the mapping in that system would be that the service and deployment
both map to that thing whatever it is, and that in that system a service
can be backed by at most one 'deployment'.

[Gordon Sim]

On 13/12/2019 7:39 pm, Justin Ross wrote:

> I was asking about the "is a" for ApplicationChannel.

An ApplicationChannel is a client-server (i.e. asymmetric,
bidirectional) relationship between two ApplicationProcesses.

[cro...@redhat.com]

Is there a formal Kubernetes document that defines all the Kube terms so that we can start from a common understanding?

Informally I can find several that don't exactly match each other...

[Gordon Sim]

On 11/02/2020 10:48 pm, cro...@redhat.com wrote:
> Is there a formal Kubernetes document that defines all the Kube terms so
> that we can start from a common understanding?
> Informally I can find several that don't exactly match each other...

* cluster
https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster

* namespace
https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-namespace

* service
https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-deployment

* deployment
https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-deployment

* pod
https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-pod

https://kubernetes.io/docs/concepts/ is also good for a more in depth
discussion

[Ganesh Murthy]

This was very useful ! Thanks.

--
You received this message because you are subscribed to the Google Groups "Skupper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skupper+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skupper/97e608e8-de36-0d99-eb08-60572feff7c2%40redhat.com.