What defines an application in this model?

[SteveCurran]

When an architect designs a micro-services application they usually identify a group of components to be used. The operational configuration seems to be identifying itself as both a deployment and an application. I see it more of an instance of an application (group of components) with configuration. Application scopes seems to be the place for this. However, the available application scopes (Network, Health, Resource, Identity) don't seem to fit. There seems to be a need for more clarification on Identity. Would this be used for identifying an application? Maybe what I am talking about is not in the scope of the model. Kubernetes has the concept of namespaces to identify separate projects or applications.

[vturecek]

This is a good question and one that could probably use some more clarity in the spec introduction and overview.

The short answer is that there is no canonical structure for an application defined in the spec by design. It is only defined loosely by the application scopes applied to a set of components to form application boundaries. These boundaries have meaning and can overlap, allowing a set of components to have different application "views."

Here's an example: An architecture in which closely related services are grouped together with a common API gateway. Groups of services only communicate to other groups of services through their API gateways. The totality of these groups of services compose a complete functioning system. What do you define as the application in this case?

Application scopes allow us to handle more complex architectures like this without having to fight against the model. In this case, we could put each group of services into a unique network scope with an ingress for the API gateway and view those as "applications," while simultaneously placing the totality of components in a second scope for a complete picture of the whole "application". There is an opportunity from this example, I think, to define an application scope that is just metadata for an application.

The ops config is just a declarative deployment tool. We can deploy all or part of a complete application. In the example above, we could deploy everything in one giant ops config if the goal is to stamp out copies of the complete application, or we could deploy each sub-application separately if the goal is autonomy between teams that own each sub-application.

This is very different from namespaces in Kubernetes, which is a fairly blunt instrument to use to define an application boundary. I think the intent with namespaces was to allow virtual clusters within a single cluster for isolation between teams or environments, with the expectation of having multiple "applications" in one namespace, the definition of which is currently left as an exercise to the user.

[technosophos]

I believe this can be closed in favor of #95