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
Create Cloud Native Definition #117
Conversation
environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable | ||
infrastructure, and declarative APIs exemplify this approach. | ||
|
||
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with |
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.
These techniques
which techniques ?
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 ones mentioned in the previous sentence. We could edit it further, but our consensus is that this writing is fairly clear, and that making it more wordy would actually hinder usability.
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 feel line # 2 and 3 are in reverse order. My point is that it makes sense to define something by the behavior it displays rather than by examples. By defining something by example (without any etc.), the definition becomes arbitrarily restrictive and probably susceptible to future innovation. Just my 2c.
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.
@tamalsaha Thanks. I understand what you are saying. But we tried the other order already -- see previous drafts. It didn't work as well.
The existing definition includes:
Cloud native systems will have the following properties:
(a) Container packaged. ...
(b) Dynamically managed. ...
(c) Micro-services oriented. ...
That's far more prescriptive and restrictive. These are intended as examples only.
Some earlier drafts removed all the examples, but many reviewers asked for different mechanisms/patterns from that list to be added back.
Admittedly it's a shorthand for what would otherwise be a much longer explanation, which, again, was attempted in earlier drafts.
There were actually a few dozen rounds of revisions. Those 11 drafts were just the major changes, and/or iterations started by different people.
The editing feedback rounds are done. They've been ongoing since January.
This is out for approval. Or not, but it's really much better than the current charter definition:
LGTM |
1 similar comment
LGTM |
formal vote kicked off on the @cncf/toc mailing list: https://lists.cncf.io/g/cncf-toc/message/2030 |
Some other comments:
|
we have enough +1 votes from the @cncf/toc for this to pass, however, going to leave this open for a few more days to allow other TOC members to vote: Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/2040 |
approved: https://lists.cncf.io/g/cncf-toc/message/2119 Thanks @cncf/toc and community. |
Based on 11 drafts from https://docs.google.com/document/d/1d9Ks3UvUV8sZj4ribAMwmq0MZwi1CwnOZWGtrCufOuk/