Date   

Re: Incubating and Inception levels in marketing materials

Dan Kohn <dan@...>
 

On Mon, Feb 5, 2018 at 11:16 AM, Jessica Frazelle <me@...> wrote:
Quick question: what are the platinum members, the ones who paid the 300k?

Yes, platinum members are the ones backing CNCF at the highest level. Our membership fees: https://www.cncf.io/about/join/
 
Do they need to be on the same slide / materials as the projects? Is
that written into a contract or something? Also I'm more than happy to
ask this on the call :)

Nope, there's no such contract. However, this is intended to be a one-slide summary of CNCF, it's projects and it's main backers. When I meet with prospective end users, members, project contributors, developers, etc. those are regularly their first questions.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io


Re: [RESULT] Vitess project proposal ACCEPTED (incubation)

alexis richardson
 

Can I have Camille's second vote?

+1 binding


On Mon, Feb 5, 2018 at 4:21 PM, Chris Aniszczyk
<caniszczyk@linuxfoundation.org> wrote:
Hey everyone, I'm happy to announce that Vitess has been accepted into CNCF
as an INCUBATION level project (sponsored by Brian Grant):
https://github.com/cncf/toc/pull/57

+1 TOC binding votes (8 / 9):
- Sam Lambert: https://lists.cncf.io/g/cncf-toc/message/1488
- Ben Hindman: https://lists.cncf.io/g/cncf-toc/message/1491
- Camille Fournier: https://lists.cncf.io/g/cncf-toc/message/1512
- Brian Grant: https://lists.cncf.io/g/cncf-toc/message/1517
- Bryan Cantrill: https://lists.cncf.io/g/cncf-toc/message/1523
- Ken Owens: https://lists.cncf.io/g/cncf-toc/message/1535
- Jon Boulle: https://lists.cncf.io/g/cncf-toc/message/1549
- Camille Fournier: https://lists.cncf.io/g/cncf-toc/message/1558

+1 non-binding community votes:
- Richard Li: https://lists.cncf.io/g/cncf-toc/message/1487
- Nick Chase: https://lists.cncf.io/g/cncf-toc/message/1489
- Bassam Tabbara: https://lists.cncf.io/g/cncf-toc/message/1490
- Jitendra Vaidya: https://lists.cncf.io/g/cncf-toc/message/1493
- Hedieh Yaghami: https://lists.cncf.io/g/cncf-toc/message/1494
- Guido Iaquinti: https://lists.cncf.io/g/cncf-toc/message/1495
- Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/1496
- Sugu Sougoumarane: https://lists.cncf.io/g/cncf-toc/message/1497
- Robert Navarro: https://lists.cncf.io/g/cncf-toc/message/1498
- Anthony Yeh: https://lists.cncf.io/g/cncf-toc/message/1499
- Bryan Beaudreault: https://lists.cncf.io/g/cncf-toc/message/1500
- Amit Khare: https://lists.cncf.io/g/cncf-toc/message/1501
- Michael Demmer: https://lists.cncf.io/g/cncf-toc/message/1502
- acharis@hubspot.com: https://lists.cncf.io/g/cncf-toc/message/1503
- jscheinblum@slack-corp.com: https://lists.cncf.io/g/cncf-toc/message/1504
- Ameet Kotian: https://lists.cncf.io/g/cncf-toc/message/1505
- Rafael Chacon: https://lists.cncf.io/g/cncf-toc/message/1506
- Derek Perkins: https://lists.cncf.io/g/cncf-toc/message/1507
- hmcgonigal@hubspot.com: https://lists.cncf.io/g/cncf-toc/message/1508
- Maggie Zhou: https://lists.cncf.io/g/cncf-toc/message/1509
- Jon Tirsen: https://lists.cncf.io/g/cncf-toc/message/1510
- Ashudeep Sharma: https://lists.cncf.io/g/cncf-toc/message/1511
- Tony Shu: https://lists.cncf.io/g/cncf-toc/message/1513
- Michael Pawliszyn : https://lists.cncf.io/g/cncf-toc/message/1514
- Nathan Xu: https://lists.cncf.io/g/cncf-toc/message/1515
- Chakri Nelluri: https://lists.cncf.io/g/cncf-toc/message/1518
- Xie Jinke: https://lists.cncf.io/g/cncf-toc/message/1519
- Shlomi Noach: https://lists.cncf.io/g/cncf-toc/message/1520
- Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/1531
- Mark Peek: https://lists.cncf.io/g/cncf-toc/message/1550
- JungHyun Kim: https://lists.cncf.io/g/cncf-toc/message/1551
- Joseph Jacks: https://lists.cncf.io/g/cncf-toc/message/1572

We'll be working with the Vitess community over the next few weeks to
welcome them to the CNCF project family and move over to
https://github.com/vitessio

Thanks again to everyone who voted and participated in the due diligence
process:
https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md

Finally, please welcome the Vitess community!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [RESULT] Vitess project proposal ACCEPTED (incubation)

alexis richardson
 

Can I have Camille's second vote?

+1 binding


On Mon, Feb 5, 2018 at 4:21 PM, Chris Aniszczyk
<caniszczyk@linuxfoundation.org> wrote:
Hey everyone, I'm happy to announce that Vitess has been accepted into CNCF
as an INCUBATION level project (sponsored by Brian Grant):
https://github.com/cncf/toc/pull/57

+1 TOC binding votes (8 / 9):
- Sam Lambert: https://lists.cncf.io/g/cncf-toc/message/1488
- Ben Hindman: https://lists.cncf.io/g/cncf-toc/message/1491
- Camille Fournier: https://lists.cncf.io/g/cncf-toc/message/1512
- Brian Grant: https://lists.cncf.io/g/cncf-toc/message/1517
- Bryan Cantrill: https://lists.cncf.io/g/cncf-toc/message/1523
- Ken Owens: https://lists.cncf.io/g/cncf-toc/message/1535
- Jon Boulle: https://lists.cncf.io/g/cncf-toc/message/1549
- Camille Fournier: https://lists.cncf.io/g/cncf-toc/message/1558

+1 non-binding community votes:
- Richard Li: https://lists.cncf.io/g/cncf-toc/message/1487
- Nick Chase: https://lists.cncf.io/g/cncf-toc/message/1489
- Bassam Tabbara: https://lists.cncf.io/g/cncf-toc/message/1490
- Jitendra Vaidya: https://lists.cncf.io/g/cncf-toc/message/1493
- Hedieh Yaghami: https://lists.cncf.io/g/cncf-toc/message/1494
- Guido Iaquinti: https://lists.cncf.io/g/cncf-toc/message/1495
- Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/1496
- Sugu Sougoumarane: https://lists.cncf.io/g/cncf-toc/message/1497
- Robert Navarro: https://lists.cncf.io/g/cncf-toc/message/1498
- Anthony Yeh: https://lists.cncf.io/g/cncf-toc/message/1499
- Bryan Beaudreault: https://lists.cncf.io/g/cncf-toc/message/1500
- Amit Khare: https://lists.cncf.io/g/cncf-toc/message/1501
- Michael Demmer: https://lists.cncf.io/g/cncf-toc/message/1502
- acharis@hubspot.com: https://lists.cncf.io/g/cncf-toc/message/1503
- jscheinblum@slack-corp.com: https://lists.cncf.io/g/cncf-toc/message/1504
- Ameet Kotian: https://lists.cncf.io/g/cncf-toc/message/1505
- Rafael Chacon: https://lists.cncf.io/g/cncf-toc/message/1506
- Derek Perkins: https://lists.cncf.io/g/cncf-toc/message/1507
- hmcgonigal@hubspot.com: https://lists.cncf.io/g/cncf-toc/message/1508
- Maggie Zhou: https://lists.cncf.io/g/cncf-toc/message/1509
- Jon Tirsen: https://lists.cncf.io/g/cncf-toc/message/1510
- Ashudeep Sharma: https://lists.cncf.io/g/cncf-toc/message/1511
- Tony Shu: https://lists.cncf.io/g/cncf-toc/message/1513
- Michael Pawliszyn : https://lists.cncf.io/g/cncf-toc/message/1514
- Nathan Xu: https://lists.cncf.io/g/cncf-toc/message/1515
- Chakri Nelluri: https://lists.cncf.io/g/cncf-toc/message/1518
- Xie Jinke: https://lists.cncf.io/g/cncf-toc/message/1519
- Shlomi Noach: https://lists.cncf.io/g/cncf-toc/message/1520
- Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/1531
- Mark Peek: https://lists.cncf.io/g/cncf-toc/message/1550
- JungHyun Kim: https://lists.cncf.io/g/cncf-toc/message/1551
- Joseph Jacks: https://lists.cncf.io/g/cncf-toc/message/1572

We'll be working with the Vitess community over the next few weeks to
welcome them to the CNCF project family and move over to
https://github.com/vitessio

Thanks again to everyone who voted and participated in the due diligence
process:
https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md

Finally, please welcome the Vitess community!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


[RESULT] Vitess project proposal ACCEPTED (incubation)

Chris Aniszczyk
 

Hey everyone, I'm happy to announce that Vitess has been accepted into CNCF as an INCUBATION level project (sponsored by Brian Grant): https://github.com/cncf/toc/pull/57

+1 TOC binding votes (8 / 9):

+1 non-binding community votes:
- Richard Li: https://lists.cncf.io/g/cncf-toc/message/1487
- Nick Chase: https://lists.cncf.io/g/cncf-toc/message/1489
- Bassam Tabbara: https://lists.cncf.io/g/cncf-toc/message/1490
- Jitendra Vaidya: https://lists.cncf.io/g/cncf-toc/message/1493
- Hedieh Yaghami: https://lists.cncf.io/g/cncf-toc/message/1494
- Guido Iaquinti: https://lists.cncf.io/g/cncf-toc/message/1495
- Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/1496
- Sugu Sougoumarane: https://lists.cncf.io/g/cncf-toc/message/1497
- Robert Navarro: https://lists.cncf.io/g/cncf-toc/message/1498
- Anthony Yeh: https://lists.cncf.io/g/cncf-toc/message/1499
- Bryan Beaudreault: https://lists.cncf.io/g/cncf-toc/message/1500
- Amit Khare: https://lists.cncf.io/g/cncf-toc/message/1501
- Michael Demmer: https://lists.cncf.io/g/cncf-toc/message/1502
- acharis@...: https://lists.cncf.io/g/cncf-toc/message/1503
- jscheinblum@...: https://lists.cncf.io/g/cncf-toc/message/1504
- Ameet Kotian: https://lists.cncf.io/g/cncf-toc/message/1505
- Rafael Chacon: https://lists.cncf.io/g/cncf-toc/message/1506
- Derek Perkins: https://lists.cncf.io/g/cncf-toc/message/1507
- hmcgonigal@...: https://lists.cncf.io/g/cncf-toc/message/1508
- Maggie Zhou: https://lists.cncf.io/g/cncf-toc/message/1509
- Jon Tirsen: https://lists.cncf.io/g/cncf-toc/message/1510
- Ashudeep Sharma: https://lists.cncf.io/g/cncf-toc/message/1511
- Tony Shu: https://lists.cncf.io/g/cncf-toc/message/1513
- Michael Pawliszyn : https://lists.cncf.io/g/cncf-toc/message/1514
- Nathan Xu: https://lists.cncf.io/g/cncf-toc/message/1515
- Chakri Nelluri: https://lists.cncf.io/g/cncf-toc/message/1518
- Xie Jinke: https://lists.cncf.io/g/cncf-toc/message/1519
- Shlomi Noach: https://lists.cncf.io/g/cncf-toc/message/1520
- Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/1531
- Mark Peek: https://lists.cncf.io/g/cncf-toc/message/1550
- JungHyun Kim: https://lists.cncf.io/g/cncf-toc/message/1551
- Joseph Jacks: https://lists.cncf.io/g/cncf-toc/message/1572

We'll be working with the Vitess community over the next few weeks to welcome them to the CNCF project family and move over to https://github.com/vitessio

Thanks again to everyone who voted and participated in the due diligence process: https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md

Finally, please welcome the Vitess community!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Incubating and Inception levels in marketing materials

alexis richardson
 

Jess

That's really one for Dan but AIUI the whole website is in the process
of being nurtured into an optimal state for 2018 .... So all comments
good & timely, anywhere.

a

On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@jessfraz.com> wrote:
Quick question: what are the platinum members, the ones who paid the 300k?

Do they need to be on the same slide / materials as the projects? Is
that written into a contract or something? Also I'm more than happy to
ask this on the call :)

On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson <alexis@weave.works> wrote:
thanks Dan & team

@all TOC community, please do comment to Dan directly or on tomorrow's TOC call


On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@linuxfoundation.org> wrote:
We'll be discussing maturity levels on the TOC call. This is just a quick
note that at the TOC's request, we revised CNCF marketing materials to
clearly separate Incubating and Inception projects:

https://www.cncf.io/
https://www.cncf.io/projects/
https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0

We will obviously add a more prominent graduated section as soon as the
first projects graduate. The same project separation will carry over to our
marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com



--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu



Re: Incubating and Inception levels in marketing materials

Jessica Frazelle <me@...>
 

Quick question: what are the platinum members, the ones who paid the 300k?

Do they need to be on the same slide / materials as the projects? Is
that written into a contract or something? Also I'm more than happy to
ask this on the call :)

On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson <alexis@weave.works> wrote:
thanks Dan & team

@all TOC community, please do comment to Dan directly or on tomorrow's TOC call


On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@linuxfoundation.org> wrote:
We'll be discussing maturity levels on the TOC call. This is just a quick
note that at the TOC's request, we revised CNCF marketing materials to
clearly separate Incubating and Inception projects:

https://www.cncf.io/
https://www.cncf.io/projects/
https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0

We will obviously add a more prominent graduated section as soon as the
first projects graduate. The same project separation will carry over to our
marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu


Re: Incubating and Inception levels in marketing materials

alexis richardson
 

thanks Dan & team

@all TOC community, please do comment to Dan directly or on tomorrow's TOC call

On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@linuxfoundation.org> wrote:
We'll be discussing maturity levels on the TOC call. This is just a quick
note that at the TOC's request, we revised CNCF marketing materials to
clearly separate Incubating and Inception projects:

https://www.cncf.io/
https://www.cncf.io/projects/
https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0

We will obviously add a more prominent graduated section as soon as the
first projects graduate. The same project separation will carry over to our
marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com


Incubating and Inception levels in marketing materials

Dan Kohn <dan@...>
 

We'll be discussing maturity levels on the TOC call. This is just a quick note that at the TOC's request, we revised CNCF marketing materials to clearly separate Incubating and Inception projects:


We will obviously add a more prominent graduated section as soon as the first projects graduate. The same project separation will carry over to our marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com


Agenda for TOC tomorrow

alexis richardson
 

On Tue, Jan 30, 2018 at 2:17 PM, John Belamaric <jbelamaric@infoblox.com> wrote:
Thanks. I have a couple slides in the deck already, I may update them a bit
before the meeting.


On Jan 30, 2018, at 9:16 AM, alexis richardson <alexis@weave.works> wrote:

John, yes, we can definitely cover that.


On Tue, Jan 30, 2018 at 2:11 PM, John Belamaric <jbelamaric@infoblox.com>
wrote:

Hi Alexis,

We planned to have the annual inception review for CoreDNS at the Feb 6
meeting. Is there still space on the agenda for that?

Thanks,
John


On Jan 29, 2018, at 4:53 AM, alexis richardson <alexis@weave.works> wrote:

Hi everyone

Thank-you for a very well attended and productive TOC call on Jan
16th. The next call is on Feb 6th, in eight days time. This is a
call for Agenda items from the TOC community. I propose the following
rough draft agenda for Feb - shown below. If someone proposes
something more important or pressing, that will get tabled.

alexis



Feb 6

Theme: Project Status

Tiering:
* Graduation reviews: timeline to completion
* Inception to Incubation reviews: ditto
* Discuss project tiers:
- do we want to tweak criteria for entry / promotion
Inception > Incubation > Graduation
Attic
- Mature/Stable, slower moving projects
CNCF Github Org?
- do we need a Sandbox?
idea here is for all CNCF projects to share one sandbox
for super-early stage experiments that otherwise have
gone into K8s incubator
- Sandbox == Inception?
- Sandbox is a CNCF Github Org?

Health:
* Reviews & healthchecks
what / when / how?
* Service desk
what else is needed here?
* Project TLC WG?
RFC / Volunteers

Feb 20

Theme: Working Groups

* Purpose
* Scope / Authority
* Status / Progress
* Exit Criteria










Re: updating what it means to be "Cloud Native"

Brian Grant
 

On Sun, Feb 4, 2018 at 10:16 PM, Justin Garrison <justinleegarrison@...> wrote:
I feel like "secure" is more along the lines of the end goals, not engineered attributes.

I agree that it's an end goal. I also agree that it's vague and not specific to cloud-native approaches. Even the principle of least privilege dates back to at least the 70s, so I don't think it's particularly helpful as a distinguishing characteristic unless we can further qualify it.
 
I agree it's very important (see chapter 8 of Cloud Native Infrastructure) but many of the ways to make something secure are combinations of other attributes. From my experience the best you can do to secure any infrastructure and application is make the them verifiable (operability + observibility), agile to respond to vulnerabilities, and provisioned with least privilege. No amount of securing would have made you not vulnerable to spectre, heartbleed, or other critical vulnerabilities found in the past few years. Your best hope was if you could audit your systems (verifiable) and have an automated build/deploy pipeline (agile) to patch/replace impacted components. Even if the components were only provisioned with the minimum privileges needed vulnerabilities could still have huge impact and make your systems susceptible to hacking.

The only secure attributes not covered by one of the existing attributes is least privilege access. How that is implemented depends a lot on the application and environment. Kubernetes' RBAC and SPIFFE are examples for how to secure systems but I feel like saying "Cloud Native is least privilege" doesn't clarify anything. Does that mean least privilege for services? How about user accounts? Does that mean I need to enable SElinux/AppArmor? What about VPCs and overlay networks?

Maybe we can think of a way to clarify how to say "least privileged" without being too vague and sticking to engineered attributes and not end goals or product specific implementations.


--
Justin Garrison
justingarrison.com

On Sun, Feb 4, 2018 at 2:15 PM, Michael Gasch <embano1@...> wrote:
Great thread and I totally agree what's been discussed and summarized so far here.
Do you mind incorporating a notion on security in the definitions?

Something like:

  • Secure by design
    • Zero-trust (vs. solely relying on underlying/external components, e.g. firewalls)
    • Incorporating and complying with high encryption standards of data in transit and at rest (especially secrets)
    • Enforcing RBAC, this is including authorization/authentication/accounting primitives
    • Only exposing minimal attack surface (L4-7)
    • The list goes on
?

Btw: I am German and can help thinking about more prescriptive "Attribut- und Zustandsbeschreibungen"  :D




Re: updating what it means to be "Cloud Native"

Justin Garrison <justinleegarrison@...>
 

I feel like "secure" is more along the lines of the end goals, not engineered attributes. I agree it's very important (see chapter 8 of Cloud Native Infrastructure) but many of the ways to make something secure are combinations of other attributes. From my experience the best you can do to secure any infrastructure and application is make the them verifiable (operability + observibility), agile to respond to vulnerabilities, and provisioned with least privilege. No amount of securing would have made you not vulnerable to spectre, heartbleed, or other critical vulnerabilities found in the past few years. Your best hope was if you could audit your systems (verifiable) and have an automated build/deploy pipeline (agile) to patch/replace impacted components. Even if the components were only provisioned with the minimum privileges needed vulnerabilities could still have huge impact and make your systems susceptible to hacking.

The only secure attributes not covered by one of the existing attributes is least privilege access. How that is implemented depends a lot on the application and environment. Kubernetes' RBAC and SPIFFE are examples for how to secure systems but I feel like saying "Cloud Native is least privilege" doesn't clarify anything. Does that mean least privilege for services? How about user accounts? Does that mean I need to enable SElinux/AppArmor? What about VPCs and overlay networks?

Maybe we can think of a way to clarify how to say "least privileged" without being too vague and sticking to engineered attributes and not end goals or product specific implementations.


--
Justin Garrison
justingarrison.com

On Sun, Feb 4, 2018 at 2:15 PM, Michael Gasch <embano1@...> wrote:
Great thread and I totally agree what's been discussed and summarized so far here.
Do you mind incorporating a notion on security in the definitions?

Something like:

  • Secure by design
    • Zero-trust (vs. solely relying on underlying/external components, e.g. firewalls)
    • Incorporating and complying with high encryption standards of data in transit and at rest (especially secrets)
    • Enforcing RBAC, this is including authorization/authentication/accounting primitives
    • Only exposing minimal attack surface (L4-7)
    • The list goes on
?

Btw: I am German and can help thinking about more prescriptive "Attribut- und Zustandsbeschreibungen"  :D



Re: updating what it means to be "Cloud Native"

Erin Boyd
 

Wonderful collaboration!
I think this is a very strong definition of the essence of CNCF!
Great job all!

On Fri, Feb 2, 2018 at 6:22 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> wrote:
Another go:

The mission of the Cloud Native Computing Foundation is to drive the adoption of technologies designed for modern dynamic, distributed environments, such as public clouds and private data centers. Cloud-native applications, services, platforms, and infrastructure are engineered to provide and/or enable operability, observability, elasticity, resilience, and agility. The Foundation seeks to foster an ecosystem interoperable Cloud-Native technologies and to advance the state of the art by fostering open-source projects that embody and/or support these attributes:


  • Operability: Expose control of application/system lifecycle.

  • Observability: Provide meaningful signals for observing state, health, and performance.

  • Elasticity: Grow and shrink to fit in available resources and to meet fluctuating demand.

  • Resilience: Fast automatic recovery from failures.

  • Agility: Fast deployment, iteration, and reconfiguration.


Example technologies and patterns that can be used to implement the above attributes, such as declarative configuration, APIs, application containers, and service meshes, are discussed in more detail in Schedule A, below.




On Fri, Feb 2, 2018 at 9:10 AM, Justin Garrison <justinleegarrison@...> wrote:
Do you mind if we incorporate some/all of them?

​Not at all. Please do! I shared them​
 
​so they could be incorporated​

I prefer the engineered attributes:
  • Operable
  • Observable
  • Elastic
  • Resilient
  • Agile
Over the end goals:
  • Scalable
  • Durable
  • Continuous
I agree. Many things can claim to be "scalable" but every design decision has trade-offs. How you get to scalability is what matters most to differentiate cloud native from other approaches. Some of the words might be interpreted as an end goal instead of an attribute (e.g. agile) so it may be hard to make a clear distinction. Deciding on specific attributes will be the hard part.

Maybe we can find more specific and descriptive German words since it has a word for pretty much everything (j/k)


--
Justin Garrison
justingarrison.com

On Fri, Feb 2, 2018 at 8:26 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:
On Tue, Jan 30, 2018 at 11:13 PM, Yaron Haviv <yaronh@...> wrote:

I’m also more aligned with Justin’s definition, the way I usually describe Cloud-Native architecture in my posts is that it provides:

 

  • Durability — services must sustain component failures
  • Elasticity — services and resources grow or shrink to meet demand
  • Continuity — versions are upgraded while the service is running

 

I think declarative may be the way to achieve those, but can be added explicitly

Containers, unikernels, serverless, foo… are ways to implement this


As much as I'm a strong proponent of declarative configuration and APIs (and declarative APIs :-)), I agree that they are implementation techniques. I think we should provides examples of such techniques, but probably not in the mission statement.
 

 

Yaron

iguazio, CTO

 

From: <cncf-toc@...> on behalf of Bryan Cantrill <bryan@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Wednesday, 31 January 2018 at 8:30
To: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] updating what it means to be "Cloud Native"

 

 

Wow, I really like Justin's (and Kris's) definitions.  As I read Brian's proposed attributes, it occurred to me how much software we have that is indisputably cloud native and yet doesn't exhibit the attributes as described.  I think part of the problem is that it's too focused on artifact attributes and not on the principles behind those attributes.  Justin's definitions are more expansive in that regard and (from my perspective, anyway), a better fit for us...

 

        - Bryan

 

 

On Tue, Jan 30, 2018 at 9:42 PM, Justin Garrison <justinleegarrison@...> wrote:

This is just my opinion. Feedback is encouraged. I did a lot of thinking about definitions when writing Cloud Native Infrastructure with Kris Nova last year.

 

In the book I define cloud native infrastructure as

 

Cloud native infrastructure is infrastructure that is hidden behind useful abstractions, controlled by APIs, managed by software, and has the purpose of running applications.

 

​The definitions for the CNCF are not just about running infrastructure and also impact how applications are designed and managed.

 

I defined cloud native applications as

 

A cloud native application is engineered to run on a platform and is designed for resiliency, agility, operability, and observability. Resiliency embraces failures instead of trying to prevent them; it takes advantage of the dynamic nature of running on a platform. Agility allows for fast deployments and quick iterations. Operability

​ ​

adds control of application life cycles from inside the application instead of relying on external processes and monitors. Observability provides information to answer questions about application state.

 

A possible elevator pitch could be something like.

 

Declarative, dynamic, resilient, and scalable.​

 

For me these expand to mean

 

Declarative APIs backed by infrastructure as software (not static code) that converge on a desired state. This applies to infrastructure, policy, application deployments, everything!

Dynamic because of the high rate of change and making frequent deployments (applications and infrastructure). This also can be used to describe service discovery as well as testing patterns and service mesh style routing.

Resilient to changes and discovery of environments. Microservices is one pattern for this but it also can include other options. Resiliency enables reliability which is the single most important factor of complex systems (or so I've read from numerous sources)

Scalable means applications need to be packaged in a way to scale horizontally instead of vertically. Ideally this would be containers but it can also be what I'd call "accidental containers" for things like lambda, app engine, or any PaaS where you don't explicitly package your code into an executable unit.


 

--
Justin Garrison
justingarrison.com

 

On Tue, Jan 30, 2018 at 4:49 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

Good point. I'll think about that (and am open to suggestions). "Automation" is a bit too terse, and not differentiated from the numerous automation systems of the past.

 

On Tue, Jan 30, 2018 at 4:45 PM, Bob Wise <bob@...> wrote:

Although the new definition is deeper and more inclusive, I think it is much less approachable especially to an less technical audience.

 

The "container packaged, dynamically managed, micro service oriented" was (and is) a great elevator pitch. It's simple, and has really helped give

those in organizations trying to sell upward on transformation paths great clear air cover. I think we would all agree that containers incorporate

many of the approaches indicated in the bits below. 

 

If we are going to replace those points (rather than enhance them) can we work on three simple bullets, or something that helps the entry?

 

-Bob

 

 

 

On Tue, Jan 30, 2018 at 9:30 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

The CNCF Charter contains a definition of "Cloud Native" that was very Kubernetes-focused. This definition proved to be inadequate during a number of recent discussions, particularly those around "cloud-native storage" in the Storage WG. I would like to update the definition. My first attempt follows. 

 

Existing charter text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes.

Cloud native systems will have the following properties:

(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for cloud native applications.

(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.

(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.

Proposed text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm, dubbed Cloud-Native computing, designed to facilitate a high velocity of change to applications, services, and infrastructure at scale in modern distributed-systems environments such as public clouds and private datacenters, while providing high degrees of security, reliability, and availability. To that end, the Foundation seeks to shape the evolution of the technology to advance the state of the art for application management and to foster an ecosystem of Cloud-Native technologies that are interoperable through well defined interfaces, and which are portable, vendor-neutral, and ubiquitous.

 

The following are some attributes of Cloud Native:

  • Cloud-native services should enable self-service. For instance, cloud-native resources should be self-provisioned from an elastic pool that for typical, on-demand usage appears to be of unlimited capacity.
  • Cloud-native environments are dynamic. They necessitate self-healing and adaptability of applications and services running in such environments.
  • Cloud-native applications, services, and infrastructure facilitate high-velocity management at scale via continuous automation, which is enabled by externalizing control, supporting dynamic configuration, and providing observability. In particular, resource usage is measured to enable optimal and efficient use.
  • Cloud-native services and infrastructure are decoupled from applications, with seamless and transparent consumption experiences.

 

Non-exhaustive, non-exclusive examples of mechanisms and approaches that promote Cloud-Native approaches include:

  • Immutable infrastructure: Replace individual components and resources rather than updating them in place, which rejuvenates the components/resources, mitigates configuration drift, and facilitates repeatability with predictability, which is essential for high-velocity operations at scale.
  • Application containers: Running applications and processes in containers as units of application deployment isolates them from their operational environments as well as from each other, facilitates higher levels of resource isolation, fosters component reuse, enables portability, increases observability, and standardizes lifecycle management.
  • Microservices: Loosely coupled microservices significantly increase the overall agility and maintainability of applications, particularly for larger organizations.
  • Service meshes: Service meshes decouple service access from the provider topology, which reduces the risk of operational changes, and support inter-component observability.
  • Declarative configuration: Intent-oriented configuration lets users focus on the What rather than the How, and reserves latitude for automated systems achieve the desired state.
  • Event-driven execution: Enables agile, reactive automated processes, and facilitates systems integration.

 

As new Cloud-Native techniques and technologies emerge, they will be incorporated into the Foundation’s portfolio of recommended practices, approaches, and projects.

 

 

 

 

 






Re: updating what it means to be "Cloud Native"

Michael Gasch <embano1@...>
 

Great thread and I totally agree what's been discussed and summarized so far here.
Do you mind incorporating a notion on security in the definitions?

Something like:

  • Secure by design
    • Zero-trust (vs. solely relying on underlying/external components, e.g. firewalls)
    • Incorporating and complying with high encryption standards of data in transit and at rest (especially secrets)
    • Enforcing RBAC, this is including authorization/authentication/accounting primitives
    • Only exposing minimal attack surface (L4-7)
    • The list goes on
?

Btw: I am German and can help thinking about more prescriptive "Attribut- und Zustandsbeschreibungen"  :D


Re: [VOTE] SPIFFE project proposal (inception)

Bob Williams <vcbobw@...>
 

+1 (non-binding)


Re: updating what it means to be "Cloud Native"

Brian Grant
 

Another go:

The mission of the Cloud Native Computing Foundation is to drive the adoption of technologies designed for modern dynamic, distributed environments, such as public clouds and private data centers. Cloud-native applications, services, platforms, and infrastructure are engineered to provide and/or enable operability, observability, elasticity, resilience, and agility. The Foundation seeks to foster an ecosystem interoperable Cloud-Native technologies and to advance the state of the art by fostering open-source projects that embody and/or support these attributes:


  • Operability: Expose control of application/system lifecycle.

  • Observability: Provide meaningful signals for observing state, health, and performance.

  • Elasticity: Grow and shrink to fit in available resources and to meet fluctuating demand.

  • Resilience: Fast automatic recovery from failures.

  • Agility: Fast deployment, iteration, and reconfiguration.


Example technologies and patterns that can be used to implement the above attributes, such as declarative configuration, APIs, application containers, and service meshes, are discussed in more detail in Schedule A, below.




On Fri, Feb 2, 2018 at 9:10 AM, Justin Garrison <justinleegarrison@...> wrote:
Do you mind if we incorporate some/all of them?

​Not at all. Please do! I shared them​
 
​so they could be incorporated​

I prefer the engineered attributes:
  • Operable
  • Observable
  • Elastic
  • Resilient
  • Agile
Over the end goals:
  • Scalable
  • Durable
  • Continuous
I agree. Many things can claim to be "scalable" but every design decision has trade-offs. How you get to scalability is what matters most to differentiate cloud native from other approaches. Some of the words might be interpreted as an end goal instead of an attribute (e.g. agile) so it may be hard to make a clear distinction. Deciding on specific attributes will be the hard part.

Maybe we can find more specific and descriptive German words since it has a word for pretty much everything (j/k)


--
Justin Garrison
justingarrison.com

On Fri, Feb 2, 2018 at 8:26 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@lists.cncf.io> wrote:
On Tue, Jan 30, 2018 at 11:13 PM, Yaron Haviv <yaronh@...> wrote:

I’m also more aligned with Justin’s definition, the way I usually describe Cloud-Native architecture in my posts is that it provides:

 

  • Durability — services must sustain component failures
  • Elasticity — services and resources grow or shrink to meet demand
  • Continuity — versions are upgraded while the service is running

 

I think declarative may be the way to achieve those, but can be added explicitly

Containers, unikernels, serverless, foo… are ways to implement this


As much as I'm a strong proponent of declarative configuration and APIs (and declarative APIs :-)), I agree that they are implementation techniques. I think we should provides examples of such techniques, but probably not in the mission statement.
 

 

Yaron

iguazio, CTO

 

From: <cncf-toc@...> on behalf of Bryan Cantrill <bryan@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Wednesday, 31 January 2018 at 8:30
To: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] updating what it means to be "Cloud Native"

 

 

Wow, I really like Justin's (and Kris's) definitions.  As I read Brian's proposed attributes, it occurred to me how much software we have that is indisputably cloud native and yet doesn't exhibit the attributes as described.  I think part of the problem is that it's too focused on artifact attributes and not on the principles behind those attributes.  Justin's definitions are more expansive in that regard and (from my perspective, anyway), a better fit for us...

 

        - Bryan

 

 

On Tue, Jan 30, 2018 at 9:42 PM, Justin Garrison <justinleegarrison@...> wrote:

This is just my opinion. Feedback is encouraged. I did a lot of thinking about definitions when writing Cloud Native Infrastructure with Kris Nova last year.

 

In the book I define cloud native infrastructure as

 

Cloud native infrastructure is infrastructure that is hidden behind useful abstractions, controlled by APIs, managed by software, and has the purpose of running applications.

 

​The definitions for the CNCF are not just about running infrastructure and also impact how applications are designed and managed.

 

I defined cloud native applications as

 

A cloud native application is engineered to run on a platform and is designed for resiliency, agility, operability, and observability. Resiliency embraces failures instead of trying to prevent them; it takes advantage of the dynamic nature of running on a platform. Agility allows for fast deployments and quick iterations. Operability

​ ​

adds control of application life cycles from inside the application instead of relying on external processes and monitors. Observability provides information to answer questions about application state.

 

A possible elevator pitch could be something like.

 

Declarative, dynamic, resilient, and scalable.​

 

For me these expand to mean

 

Declarative APIs backed by infrastructure as software (not static code) that converge on a desired state. This applies to infrastructure, policy, application deployments, everything!

Dynamic because of the high rate of change and making frequent deployments (applications and infrastructure). This also can be used to describe service discovery as well as testing patterns and service mesh style routing.

Resilient to changes and discovery of environments. Microservices is one pattern for this but it also can include other options. Resiliency enables reliability which is the single most important factor of complex systems (or so I've read from numerous sources)

Scalable means applications need to be packaged in a way to scale horizontally instead of vertically. Ideally this would be containers but it can also be what I'd call "accidental containers" for things like lambda, app engine, or any PaaS where you don't explicitly package your code into an executable unit.


 

--
Justin Garrison
justingarrison.com

 

On Tue, Jan 30, 2018 at 4:49 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

Good point. I'll think about that (and am open to suggestions). "Automation" is a bit too terse, and not differentiated from the numerous automation systems of the past.

 

On Tue, Jan 30, 2018 at 4:45 PM, Bob Wise <bob@...> wrote:

Although the new definition is deeper and more inclusive, I think it is much less approachable especially to an less technical audience.

 

The "container packaged, dynamically managed, micro service oriented" was (and is) a great elevator pitch. It's simple, and has really helped give

those in organizations trying to sell upward on transformation paths great clear air cover. I think we would all agree that containers incorporate

many of the approaches indicated in the bits below. 

 

If we are going to replace those points (rather than enhance them) can we work on three simple bullets, or something that helps the entry?

 

-Bob

 

 

 

On Tue, Jan 30, 2018 at 9:30 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

The CNCF Charter contains a definition of "Cloud Native" that was very Kubernetes-focused. This definition proved to be inadequate during a number of recent discussions, particularly those around "cloud-native storage" in the Storage WG. I would like to update the definition. My first attempt follows. 

 

Existing charter text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes.

Cloud native systems will have the following properties:

(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for cloud native applications.

(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.

(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.

Proposed text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm, dubbed Cloud-Native computing, designed to facilitate a high velocity of change to applications, services, and infrastructure at scale in modern distributed-systems environments such as public clouds and private datacenters, while providing high degrees of security, reliability, and availability. To that end, the Foundation seeks to shape the evolution of the technology to advance the state of the art for application management and to foster an ecosystem of Cloud-Native technologies that are interoperable through well defined interfaces, and which are portable, vendor-neutral, and ubiquitous.

 

The following are some attributes of Cloud Native:

  • Cloud-native services should enable self-service. For instance, cloud-native resources should be self-provisioned from an elastic pool that for typical, on-demand usage appears to be of unlimited capacity.
  • Cloud-native environments are dynamic. They necessitate self-healing and adaptability of applications and services running in such environments.
  • Cloud-native applications, services, and infrastructure facilitate high-velocity management at scale via continuous automation, which is enabled by externalizing control, supporting dynamic configuration, and providing observability. In particular, resource usage is measured to enable optimal and efficient use.
  • Cloud-native services and infrastructure are decoupled from applications, with seamless and transparent consumption experiences.

 

Non-exhaustive, non-exclusive examples of mechanisms and approaches that promote Cloud-Native approaches include:

  • Immutable infrastructure: Replace individual components and resources rather than updating them in place, which rejuvenates the components/resources, mitigates configuration drift, and facilitates repeatability with predictability, which is essential for high-velocity operations at scale.
  • Application containers: Running applications and processes in containers as units of application deployment isolates them from their operational environments as well as from each other, facilitates higher levels of resource isolation, fosters component reuse, enables portability, increases observability, and standardizes lifecycle management.
  • Microservices: Loosely coupled microservices significantly increase the overall agility and maintainability of applications, particularly for larger organizations.
  • Service meshes: Service meshes decouple service access from the provider topology, which reduces the risk of operational changes, and support inter-component observability.
  • Declarative configuration: Intent-oriented configuration lets users focus on the What rather than the How, and reserves latitude for automated systems achieve the desired state.
  • Event-driven execution: Enables agile, reactive automated processes, and facilitates systems integration.

 

As new Cloud-Native techniques and technologies emerge, they will be incorporated into the Foundation’s portfolio of recommended practices, approaches, and projects.

 

 

 

 

 





Re: updating what it means to be "Cloud Native"

Brian Grant
 

On Fri, Feb 2, 2018 at 12:34 PM, Drew Rapenchuk <drapenchuk@...> wrote:

This is much, much better!

On Tue, Jan 30, 2018 at 09:30 am, Brian Grant wrote:

 
  • Cloud-native environments are dynamic. They necessitate self-healing and adaptability of applications and services running in such environments 

 

What exactly is a Cloud-native environment? Infrastructure? A platform on top of infrastructure? The resources provided by the platform?
One could argue a Cloud-Native environment includes all of the above,

Deliberately vague. Yes, it could include the platform, such as Kubernetes.
 
But I know some who would disagree.  I think it is worth it to really try to nail down at what point is a platform or system no longer itself cloud native.  At what level does something being handled by a human touching it no longer make it cloud native?

I don't know that we're ready to draw a firm boundary yet. Cloud Native is still somewhat aspirational.



Re: updating what it means to be "Cloud Native"

Drew Rapenchuk <drapenchuk@...>
 

This is much, much better!

On Tue, Jan 30, 2018 at 09:30 am, Brian Grant wrote:

 
  • Cloud-native environments are dynamic. They necessitate self-healing and adaptability of applications and services running in such environments 

 

What exactly is a Cloud-native environment? Infrastructure? A platform on top of infrastructure? The resources provided by the platform?
One could argue a Cloud-Native environment includes all of the above, But I know some who would disagree.  I think it is worth it to really try to nail down at what point is a platform or system no longer itself cloud native.  At what level does something being handled by a human touching it no longer make it cloud native?


Re: [VOTE] SPIFFE project proposal (inception)

Spike Curtis
 

+1 (non-binding)


Re: updating what it means to be "Cloud Native"

Justin Garrison <justinleegarrison@...>
 

Do you mind if we incorporate some/all of them?

​Not at all. Please do! I shared them​
 
​so they could be incorporated​

I prefer the engineered attributes:
  • Operable
  • Observable
  • Elastic
  • Resilient
  • Agile
Over the end goals:
  • Scalable
  • Durable
  • Continuous
I agree. Many things can claim to be "scalable" but every design decision has trade-offs. How you get to scalability is what matters most to differentiate cloud native from other approaches. Some of the words might be interpreted as an end goal instead of an attribute (e.g. agile) so it may be hard to make a clear distinction. Deciding on specific attributes will be the hard part.

Maybe we can find more specific and descriptive German words since it has a word for pretty much everything (j/k)


--
Justin Garrison
justingarrison.com

On Fri, Feb 2, 2018 at 8:26 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> wrote:
On Tue, Jan 30, 2018 at 11:13 PM, Yaron Haviv <yaronh@...> wrote:

I’m also more aligned with Justin’s definition, the way I usually describe Cloud-Native architecture in my posts is that it provides:

 

  • Durability — services must sustain component failures
  • Elasticity — services and resources grow or shrink to meet demand
  • Continuity — versions are upgraded while the service is running

 

I think declarative may be the way to achieve those, but can be added explicitly

Containers, unikernels, serverless, foo… are ways to implement this


As much as I'm a strong proponent of declarative configuration and APIs (and declarative APIs :-)), I agree that they are implementation techniques. I think we should provides examples of such techniques, but probably not in the mission statement.
 

 

Yaron

iguazio, CTO

 

From: <cncf-toc@...> on behalf of Bryan Cantrill <bryan@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Wednesday, 31 January 2018 at 8:30
To: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] updating what it means to be "Cloud Native"

 

 

Wow, I really like Justin's (and Kris's) definitions.  As I read Brian's proposed attributes, it occurred to me how much software we have that is indisputably cloud native and yet doesn't exhibit the attributes as described.  I think part of the problem is that it's too focused on artifact attributes and not on the principles behind those attributes.  Justin's definitions are more expansive in that regard and (from my perspective, anyway), a better fit for us...

 

        - Bryan

 

 

On Tue, Jan 30, 2018 at 9:42 PM, Justin Garrison <justinleegarrison@...> wrote:

This is just my opinion. Feedback is encouraged. I did a lot of thinking about definitions when writing Cloud Native Infrastructure with Kris Nova last year.

 

In the book I define cloud native infrastructure as

 

Cloud native infrastructure is infrastructure that is hidden behind useful abstractions, controlled by APIs, managed by software, and has the purpose of running applications.

 

​The definitions for the CNCF are not just about running infrastructure and also impact how applications are designed and managed.

 

I defined cloud native applications as

 

A cloud native application is engineered to run on a platform and is designed for resiliency, agility, operability, and observability. Resiliency embraces failures instead of trying to prevent them; it takes advantage of the dynamic nature of running on a platform. Agility allows for fast deployments and quick iterations. Operability

​ ​

adds control of application life cycles from inside the application instead of relying on external processes and monitors. Observability provides information to answer questions about application state.

 

A possible elevator pitch could be something like.

 

Declarative, dynamic, resilient, and scalable.​

 

For me these expand to mean

 

Declarative APIs backed by infrastructure as software (not static code) that converge on a desired state. This applies to infrastructure, policy, application deployments, everything!

Dynamic because of the high rate of change and making frequent deployments (applications and infrastructure). This also can be used to describe service discovery as well as testing patterns and service mesh style routing.

Resilient to changes and discovery of environments. Microservices is one pattern for this but it also can include other options. Resiliency enables reliability which is the single most important factor of complex systems (or so I've read from numerous sources)

Scalable means applications need to be packaged in a way to scale horizontally instead of vertically. Ideally this would be containers but it can also be what I'd call "accidental containers" for things like lambda, app engine, or any PaaS where you don't explicitly package your code into an executable unit.


 

--
Justin Garrison
justingarrison.com

 

On Tue, Jan 30, 2018 at 4:49 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

Good point. I'll think about that (and am open to suggestions). "Automation" is a bit too terse, and not differentiated from the numerous automation systems of the past.

 

On Tue, Jan 30, 2018 at 4:45 PM, Bob Wise <bob@...> wrote:

Although the new definition is deeper and more inclusive, I think it is much less approachable especially to an less technical audience.

 

The "container packaged, dynamically managed, micro service oriented" was (and is) a great elevator pitch. It's simple, and has really helped give

those in organizations trying to sell upward on transformation paths great clear air cover. I think we would all agree that containers incorporate

many of the approaches indicated in the bits below. 

 

If we are going to replace those points (rather than enhance them) can we work on three simple bullets, or something that helps the entry?

 

-Bob

 

 

 

On Tue, Jan 30, 2018 at 9:30 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

The CNCF Charter contains a definition of "Cloud Native" that was very Kubernetes-focused. This definition proved to be inadequate during a number of recent discussions, particularly those around "cloud-native storage" in the Storage WG. I would like to update the definition. My first attempt follows. 

 

Existing charter text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes.

Cloud native systems will have the following properties:

(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for cloud native applications.

(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.

(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.

Proposed text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm, dubbed Cloud-Native computing, designed to facilitate a high velocity of change to applications, services, and infrastructure at scale in modern distributed-systems environments such as public clouds and private datacenters, while providing high degrees of security, reliability, and availability. To that end, the Foundation seeks to shape the evolution of the technology to advance the state of the art for application management and to foster an ecosystem of Cloud-Native technologies that are interoperable through well defined interfaces, and which are portable, vendor-neutral, and ubiquitous.

 

The following are some attributes of Cloud Native:

  • Cloud-native services should enable self-service. For instance, cloud-native resources should be self-provisioned from an elastic pool that for typical, on-demand usage appears to be of unlimited capacity.
  • Cloud-native environments are dynamic. They necessitate self-healing and adaptability of applications and services running in such environments.
  • Cloud-native applications, services, and infrastructure facilitate high-velocity management at scale via continuous automation, which is enabled by externalizing control, supporting dynamic configuration, and providing observability. In particular, resource usage is measured to enable optimal and efficient use.
  • Cloud-native services and infrastructure are decoupled from applications, with seamless and transparent consumption experiences.

 

Non-exhaustive, non-exclusive examples of mechanisms and approaches that promote Cloud-Native approaches include:

  • Immutable infrastructure: Replace individual components and resources rather than updating them in place, which rejuvenates the components/resources, mitigates configuration drift, and facilitates repeatability with predictability, which is essential for high-velocity operations at scale.
  • Application containers: Running applications and processes in containers as units of application deployment isolates them from their operational environments as well as from each other, facilitates higher levels of resource isolation, fosters component reuse, enables portability, increases observability, and standardizes lifecycle management.
  • Microservices: Loosely coupled microservices significantly increase the overall agility and maintainability of applications, particularly for larger organizations.
  • Service meshes: Service meshes decouple service access from the provider topology, which reduces the risk of operational changes, and support inter-component observability.
  • Declarative configuration: Intent-oriented configuration lets users focus on the What rather than the How, and reserves latitude for automated systems achieve the desired state.
  • Event-driven execution: Enables agile, reactive automated processes, and facilitates systems integration.

 

As new Cloud-Native techniques and technologies emerge, they will be incorporated into the Foundation’s portfolio of recommended practices, approaches, and projects.

 

 

 

 

 




Re: [VOTE] SPIFFE project proposal (inception)

Olivier Mallassi <olivier.mallassi@...>
 

+1 (non-binding)

5341 - 5360 of 6990