Why don't we naming operationalConfiguration to Application？

[wonderflow]

In hydra spec, we can see that OperationalConfiguration is the entry point of the application definition. I think it's more easy to understand by naming it to Application instead of OperationalConfiguration.

I know maybe OperationalConfiguration can contain some aspects of operation out of the application scope. But if we think the concept "Application" as the lifecycle of an application, then it's also reasonable.

[tomkerkhove]

That's a good point if you ask me

[yaron2]

That's a great suggestion.

[mikkelhegn]

What we've found in a lot of conversations is that application is simply too disambiguous to mean anything specific in the spec. It seems to correlate with the size of what is being talking about. E.g. a few components running together could easily be defined as an application, but in larger systems or services, what's the boundary of the application? We've found that it doesn't necessarily make sense to define that.

But what does make sense to define is the artifacts tied to operations you do: deployment, scaling, monitoring etc.

For deployment the operationalConfiguration is the artifact, and you could easily image a larger system, which is based on multiple operationalConfigurations being deployed individually and making up the application or system. This in particular was an issue in a lot of Service Fabric scenarios.

For monitoring, I'm not sure we have it right yet, there has been talk about monitoring for application scopes - I'm unfortunately not all up-to-date on that :-) But application scopes was introduced as a mean to define other groupings (tied to some feature or functionality), which traverses the deployment grouping (the opsConfig).

As a comparison, consider in Kubernetes, how a Wordpress Helm chart is the deployment artifact, but you can choose to say that's how you deploy a Wordpress application in Kubernetes.

[yaron2]

The problem with using the term OperationalConfiguration is that it violates seperation of concerns, and promotes a blending of concerns instead.

Looking at the examples and the spec for OperationalConfiguration shows this:

apiVersion: core.hydra.io/v1alpha1
kind: OperationalConfiguration
metadata:
  name: custom-single-app
  description: Customized version of single-app
spec:
  variables:
  components:
    - componentName: frontend
      instanceName: web-front-end
      parameterValues:
      traits:
      - name: ManualScaler
          properties:
            replicaCount: 5

Paying attention to the highlighted items in the example above shows how operations and apps are tied together: the manifest is marked as OperationalConfiguration, its name and description define an app, and its components make up the topology an application as defined by Hydra.

(Taken from the link above: an application is a collection of components with a set of operational traits and scoped together into one or more application boundaries.)

If an application is a collection of components, and the OperationalConfiguration above consists of a collection of components, then its easy to see how OperationConfiguration should actually become an Application, albeit with changes to promote a clear seperation of concerns, because currently the components themselves have inline definitions of further operational aspects such as scaling as shown above.

Lastly, I do not think using the term Application should be confusing as mentioned: the Hydra Spec can, and should, proactively define and clearly communicate what an Application is in terms of the Hydra model, rather then tying the use of the term to the ability to come up with a broadly accepted external definition of it.

An example of this would be a Kubernetes Service, which unlike most definitions of services in distributed systems, is merely a type of east-west Load Balancer and a networking abstraction over a set of Pods.

[tomkerkhove]

I agree and would dare to say that calling it "application" would make it easier to grasp what it represents as well, but that's maybe because I'm not and expert on the spec. (but again, should I be an expert to understand that this is ~ to an app?)

Another interesting point is that we already have things that are called "application" scope so we already kind of use the terminology.

For me an app represents everything that is ready to ship - Both what it is (components/code/etc -> dev persona) and how it will be operated.

To your point of what is even an application, I get what you are trying to say @mikkelhegn but I'm afraid that will always be an issue but it's up to the customers to decide that, no?

In smaller products the app will be everything that they want to ship, while in the scenario of a distributed microservices infrastructure the app will be your microservice and not the whole infrastructure so wouldn't that make sense to call it an app as well?

Anyhow, I do not have a strong opinion but I think calling it application would make it a lot easier to grasp and use.

[resouer]

For the Configuration vs Application argument, I agree with @mikkelhegn :-)

In Kubernetes, there's no such concept of "application" . Anytime we refer "application", it actually means "application configuration". This is one of the original ideas of declarative app management in Kubernetes (as well as in Borg), i.e. this system is essentially an app configuration mgmt system.

With this in mind, I am hesitating to merge application(app metadata) with application configuration (app config data) directly even though the former is not clearly defined in Hydra/K8s. While after reading thru the issue, it comes to me that end users of Hydra may expecting a concrete definition of "Application", as we are indeed trying to build app centric focus based on underlying runtimes.

Here're several very quick thoughts come to my mind:

1. Clarify the same application = application configuration philosophy in Hydra repo and explain it a bit.
2. Create an Application object, which includes basic metadata (only name, description, no app distribution fields like publisher, logo, owner etc) and OperationalConfiguration, so users will use this object as "application". It can also be used as the common owner of all other objects belonging to it.
3. Claim application = application packaging with concrete examples of Helm or CNAB + Hydra files. i.e. Hydra is building blocks of application but the final call would be made by app distributors.

Other ideas?

[yaron2]

@resouer Yes, totally on board with your suggestions, namely no. 2:

Create an Application object, which includes basic metadata (only name, description, no app distribution fields like publisher, logo, owner etc) and OperationalConfiguration, so users will use this object as "application". It can also be used as the common owner of all other objects belonging to it.

The creation of an Application object which is the owner of components will leave OperationalConfiguration with a more clearly defined, single designated purpose and provide a clear seperation of concerns.

Finally:

In Kubernetes, there's no such concept of "application"

This is exactly the reason why Hydra, as a higher level platform, should be converting Application models into Application Configuration primitives used by Kubernetes.

[tomkerkhove]

I fully agree with @yaron2!

In Kubernetes I'm currently missing the application concept and is why I was happy to hear about Hydra, hoping to bridge this gap. Service Fabric Mesh is/was a good example of how it leverages an application that contains all components a bit imo.

[wonderflow]

I fully agree with @resouer .

end users of Hydra may expecting a concrete definition of "Application"

Create Application object including metadata and OperationalConfiguration, users will understand hydra as an Application models better.

[markrussinovich]

It's an application model, so I don't understand arguments that it shouldn't be called 'application'.

[SteveCurran]

I brought this up in issue #62

[mikkelhegn]

@vturecek response in #62 explains the thoughts behind the current model: https://github.com/microsoft/hydra-spec/issues/62#issuecomment-516192243

In regards to @resouer suggestions earlier in the thread: https://github.com/microsoft/hydra-spec/issues/95#issuecomment-524044601:

ad 1. I think it's a good point to explain this further, I would suggest an FAQ style approach to this.
ad 2. One of the issues we've seen in Service Fabric, is that a hierarchical approach to this ends up being constrained in defining your workflow and structuring of the assets you work with. See the post from @vturecek .
ad 3. As CNAB is dealing with packaging and distribution (Hydra is not), it's a good idea to start describing how these can work together in some scenarios. However, I don't think there should be a requirement for using CNAB.

Is this main concern that users will be looking for the word "application" in the spec and implementations? Or are there functionality applied to having an application object, that you think the spec needs to specify? And what would that functionality be?

Using an application scope to define the sum of components you want to see / query etc. could be a way to go. I don't have a good idea of what a name for such application scope could be, as if would have no functionality applied to it? (But something similar to a label on all components might do it?)

[mikkelhegn]

Another related thread: Where will the Application Metadata be defined https://github.com/microsoft/hydra-spec/issues/87

[tomkerkhove]

From my perspective I'd love to be able to deploy an "application" resource which has everything it needs.

This allows us to list all installed applications via the CLI, etc.

If that means renaming operationalConfiguration, then I'm all for it!

The bottom line is that application is very clear what it represents - Our application that we have built and run. Will there be one definition of "an application"? Probably not, but it feels like it is missing in an "application focused" specification imo.

[hongchaodeng]

Sharing my real world experience:

When I tried to show potential adopters Hydra the first time, I got being asked again and again what's configuration. Users only get it once I told them it is an application.

I would agree that application would better be schematic, and AppConfiguration would be a better replacement.

[technosophos]

I would not be opposed to calling it an AppConfiguration (or some variant of that terminology).

OperationalConfiguration had been proposed as a way of pointing out that the role this file is intended for is the app operator. However, AppConfiguration might be a clearer description of what the file is.

I will re-echo the point made repeatedly here in the issue queue and in dozens of meetings: The term "Application" is not at all an agreed-upon term when it comes to distributed applications. So renaming it is still going to raise the ire of a number of people. But to me, maybe we should just cut the Gordian knot and say, "what we intend to model in this configuration is a functional unit big enough to be called an application." Of course, that will leave us telling a harder story about how multiple AppConfigs can be deployed together to make one bigger application... but... at this point I think that is no more taxing than our current situation.

There was a suggestion to re-label this simply as Application. If we're considering applying the term "application" to this particular chunk, then I think we should weigh in on which of these two names is best:

• Application
• ApplicationConfiguration
• AppConfiguration

[markrussinovich]

The component schematic is really the application model. It would be helpful to emphasize that through the docs. That makes what’s currently called operational configuration the application configuration. I’m fine with appconfig for short. While I’m here, it would be really helpful to start the spec with an overview of how the different artifacts relate to each other, as well as what objects are represented in each artifact. **Edited by M Butcher**: For brevity, removed the auto-attached copy of earlier messages in this thread.

[xiang90]

E.g. a few components running together could easily be defined as an application, but in larger systems or services, what's the boundary of the application? We've found that it doesn't necessarily make sense to define that.

While I agree with you that application is a pretty general word without any context, but I think we can define what an application means in Hydra Spec clearly.

Currently, an application in hydra is "an application is a collection of components with a set of operational traits and scoped together into one or more application boundaries.". We can further make it more concretely defined if necessary.

[mikkelhegn]

@xiang90 I support making that definition (tagging on to the idea of an Application Metadata Application Scope - suggested here: https://github.com/microsoft/hydra-spec/issues/87#issuecomment-521804320):

"In the Hydra model, an application can be considered to be any collection of components and operational traits running in the system. Application Scopes help define boundaries for functionality and grouping of these. The Application Configuration is a deployment object, which will add and configure any of the aforementioned objects to the collection of running instances.

To ease operations against a larger collection of components and operational traits, the Application Metadata Application Scope can be used to form a complete overview of a running application or system."

[chzbrgr71]

Though I really like the simplicity of "Application", I suspect it is so generic that it would overlap or cause confusion.

"ApplicationConfiguration" or "AppConfiguration" sound like the best choices to me. My preference would be "ApplicationConfiguration" since spelling it out is more consistent with other names in the Hydra spec.

[jschluchter]

ApplicationConfiguration or AppConfig IMHO.

[mikkelhegn]

Looking at commit histories ;-) https://github.com/microsoft/hydra-spec/pull/21

I believe Configuration should be OperationalConfiguration. (not sure operational configuration is the best naming though

and

LGTM, although I agree that the name could be improved upon

Those statements were clearly correct :-)

Happy Friday!

[tomkerkhove]

Hehe.

ApplicationConfiguration sounds good to me!

Happy to send a PR for that if you want

[mikkelhegn]

It's already in the baking :-) https://github.com/microsoft/hydra-spec/pull/98

[vturecek]

I think @resouer is right about not merging the application configuration and metadata. That would again be the same rigid hierarchical application structure we've seen before that makes complex architectures difficult to work with. If we name this Application then it puts us on that path.

I'm personally fine with ApplicationConfiguration though, along with an ApplicationScope that provides application metadata. Simple architectures are easy - everything can be deployed in a single ApplicationConfiguration and you can think of that as your entire application. Complex architectures are possible as well, with multiple ApplicationConfigurations for different parts and one or more application scopes to tie it all together.