Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Add an Application Model object #148

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

technosophos
Copy link
Contributor

This adds an Application Model top-level object.

This is currently a WIP, and is not complete. However, comments at this early phase are welcome.

Signed-off-by: Matt Butcher [email protected]

@technosophos
Copy link
Contributor Author

This feature was requested by Office of CTO. I would like to vet the idea among ourselves, then when we think it is looking good ask for their input as well (before merging).

The Hydra approach identifies four important roles:

- The developer: Creates and maintains components (microservices)
- The application architect: Defines an application as composed of components
Copy link
Member

@resouer resouer Sep 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The architect role makes sense, though we already have roles-and-responsibilities section, we may want to consider aligning them together?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I will fit the ideas in this document into the other sections.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the customer feedback I received last week was that developers shouldn't be concerned with component creation or maintenance. In the customers' opinion, workload type and resource consumption should be an application architect concern, and developer involvement should drop off @ CI/CD.

I'm not saying we necessarily have to nix the developer from the personas, but it's something to consider in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, and this is why components can be specified inline (by app architects) for those orgs. But I got other feedback saying the app developers ought to be able to have complete control over their component configurations, so they needed the option to have separate files.

To solve this conundrum, I made it so that the components section could either define the components inline (e.g. the "strong app architect" model) or provide a reference to component specs created by developers (the "strong developer" model).

@hongchaodeng
Copy link
Member

This proposal looks great and promising.
It also occurs to me that issue https://github.com/microsoft/hydra-spec/issues/87 could be resolved by this proposal with additional standard annotations.


## Representation

The `ApplicationModel` object follows the same basic structure as all Hydra manifests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just follows the structure as below


### Metadata

Metadata describes this trait. The metadata section is defined in [Section 3](3.component_model.md#metadata).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Metadata describes basic information of this object.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix this.


### Metadata

Metadata describes this trait. The metadata section is defined in [Section 3](3.component_model.md#metadata).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few references to trait here. Is that copy/paste artifact? I'm guessing yes....but if not, there should be something here that links to traits and clarifies the relationship.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops... copy/paste mistake. Good catch.

- name: path
value: "/"
# For these, we are just declaring the instance names, not setting params or
# traits.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Aren't parameters and traits required to instantiate the database and admin-portal components, both of which are necessary in order for the application to run successfully since they're part of the same application model as the front-end component?

@vturecek vturecek added this to the backlog milestone Sep 20, 2019
@technosophos
Copy link
Contributor Author

THIS PR IS ON HOLD. I don't think this is the correct solution to the problem. But there is still ongoing discussion, so I will leave this open for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants