-
Notifications
You must be signed in to change notification settings - Fork 246
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
base: master
Are you sure you want to change the base?
Conversation
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
This proposal looks great and promising. |
4.application_model.md
Outdated
|
||
## Representation | ||
|
||
The `ApplicationModel` object follows the same basic structure as all Hydra manifests. |
There was a problem hiding this comment.
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
4.application_model.md
Outdated
|
||
### Metadata | ||
|
||
Metadata describes this trait. The metadata section is defined in [Section 3](3.component_model.md#metadata). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll fix this.
4.application_model.md
Outdated
|
||
### Metadata | ||
|
||
Metadata describes this trait. The metadata section is defined in [Section 3](3.component_model.md#metadata). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
aece3d1
to
3847b6e
Compare
- name: path | ||
value: "/" | ||
# For these, we are just declaring the instance names, not setting params or | ||
# traits. |
There was a problem hiding this comment.
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?
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. |
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 matt.butcher@microsoft.com