Date   

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

Yaron Haviv <yaronh@...>
 

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

 

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@...> 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@...> 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"

Bryan Cantrill <bryan@...>
 


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@lists.cncf.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"

Justin Garrison <justinleegarrison@...>
 

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@...> 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
 

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@lists.cncf.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"

Bob Wise
 

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@...> 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] Vitess project proposal (incubation)

Junghyun Kim
 

+1 (non-binding)


On Thu, Jan 25, 2018 at 08:50 am, Chris Aniszczyk wrote:
ase vote (+1/0/-1) on this thread... remember that the TOC h


Re: [VOTE] Vitess project proposal (incubation)

Mark Peek
 

+1 non-binding

 

 

From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Thursday, January 25, 2018 at 8:50 AM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Vitess project proposal (incubation)

 

The TOC has decided to invite Vitess (https://github.com/youtube/vitess) as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC.

Vitess is a MySQL-compatible data orchestrator/platform. It orchestrates management of MySQL instances and has been serving all YouTube database traffic since 2011. Vitess has grown to encompass tens of thousands of MySQL nodes. It is also used by companies such as HubSpot, Slack and Square. 

_._,_._,_


Re: [VOTE] Vitess project proposal (incubation)

Jonathan Boulle <jon@...>
 

+1 binding

On 30 January 2018 at 06:14, Sugu Sougoumarane <ssougou@...> wrote:
Many of these companies have talked to us, and we are still in some form of conversation with some of them. The logos we've listed are only those from whom we've received explicit permission from.

PS: mineraftly is an aweseom find! LOL.

PPS: I missed Nozzle's contribution in my original response. Ironically, they are the most noteworthy contributors because they're refactoring our helm charts.

On 29 January 2018 at 21:04, Brian Grant via Lists.Cncf.Io <briangrant=google.com@lists.cncf.io> wrote:
FWIW, it looks like there is decent demand for something like Vitess (13790 commits) based on the number of companies that have implemented their own solutions:


On Mon, Jan 29, 2018 at 8:03 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

On Mon, Jan 29, 2018 at 7:28 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:
To follow up on this, with some links for external confirmation:

I think some of the confusion arose due to data being sampled at different times. The original presentation to the TOC was last April, for instance.
 
Slack presentation from 4-5 months ago. They are contributing heavily to vitess, as can be seen from the contribution stats I just sent, and even a small fraction of traffic was non-trivial.

Stichlabs has fully migrated production to Vitess: video

BetterCloud mentions that they use Vitess on their blog.

IMO, the production usage bar is intended primarily to assess maturity and production-worthiness, and secondarily general applicability (though 3 users isn't really enough for that). I don't think maturity and production-worthiness are concerns in this case. I think better documenting production usage via case studies is something the CNCF could help with.

As with Prometheus, Envoy, and Jaegar, Vitess was developed over the last 7 years or so for Youtube's own use. It has become more relevant to other companies with the (comparatively recent) emergence of Kubernetes. If we're looking for more user-initiated projects, Vitess is one of those.



On Mon, Jan 29, 2018 at 6:41 PM, Sugu Sougoumarane <ssougou@...> wrote:

Ah, I should have made this explicit in our slides, but here is the information to address your concerns about the graduation criteria:


The following eight companies have vitess serving production traffic:

  • YouTube

  • Slack

  • Hubspot

  • Flipkart

  • Stitch Labs

  • Square (Cash App)

  • BetterCloud

  • Quiz of Kings


Of these, engineers from the following companies have made significant contributions to the vitess code base:

  • YouTube

  • Slack

  • Hubspot

  • Flipkart

  • Square (Cash App)

  • StitchLabs


Additionally, the following companies have started making contributions, while in the process of evaluating:

  • Booking.com

  • Github

  • Pinterest (new)


There are also other companies listed in the adopters page. They are evaluating vitess with the intent to mainly use it.


Finally, there are other companies, who are involved with Vitess at various levels, that wish to remain anonymous. So, we haven’t listed them here.


Please let me know if this answers your questions, or if you have others.



On 29 January 2018 at 18:08, Quinton Hoole <quinton.hoole@...> wrote:
I share Camille’s concern.

Note that the only explicit requirement in this regard w.r.t. Incubation level is as follows (from https://www.cncf.io/projects/graduation-criteria/):

  • Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgement, are of adequate quality and scope.
The proposal says this about adopters:

This is an alphabetical list of known adopters of Vitess. Some have already gone into production, and others are at various stages of testing.


Can we perhaps get some clarification about which are in production, and which are still in testing.

Sorry, this should have been brought up in the due diligence, but unfortunately got missed, by the looks of things.

Q

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc@...> on behalf of Camille Fournier <skamille@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Monday, January 29, 2018 at 17:54
To: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Vitess project proposal (incubation)

Basically, I'm concerned that there are not really actual production users who also are project committers that aren't YouTube/Google.

On Jan 29, 2018 9:53 PM, "Camille Fournier" <skamille@...> wrote:
But it is not yet in prod? Bringing it to prod sounds like not.

On Jan 29, 2018 9:51 PM, "Sugu Sougoumarane" <ssougou@...> wrote:
Just got this confirmation from Hubspot: "Definitely using. Two dedicated full timers working on bringing it to prod. Three others supporting part time, plus me. We have a handful of prod clusters at this point and are starting wider scale rollout soon."

It's likely that the slides were prepared at different times, because they were on staging for a while.

On 29 January 2018 at 17:36, Camille Fournier <skamille@...> wrote:
I'm confused, is hubspot using or evaluating this product? The different slide decks seem to disagree.

On Jan 25, 2018 12:50 PM, "Chris Aniszczyk" <caniszczyk@...g> wrote:
The TOC has decided to invite Vitess (https://github.com/youtube/vitess) as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC.

Vitess is a MySQL-compatible data orchestrator/platform. It orchestrates management of MySQL instances and has been serving all YouTube database traffic since 2011. Vitess has grown to encompass tens of thousands of MySQL nodes. It is also used by companies such as HubSpot, Slack and Square. 

The full project proposal is located here: https://github.com/cncf/toc/pull/67

Please vote (+1/0/-1) on this thread... remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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










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

Dee Kumar <dkumar@...>
 

Hi Brian, Thank you. This is very timely with some of the efforts that are underway with the CNCF website. We intend to have a high level messaging on several use cases and applications. 

Regards,
Dee


On Tue, Jan 30, 2018 at 9:30 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> 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"

Paul Fremantle <paul@...>
 

Yes I do.

Paul

On 30 January 2018 at 18:06, alexis richardson <alexis@...> wrote:

Paul

Do you agree that mesh is helpful, but otherwise neither necessary nor sufficient?

A


On Tue, 30 Jan 2018, 18:05 Paul Fremantle, <paul@...> wrote:
I think the overall definition is much better. 

I really like how service meshes enable DRY and declarative intent, but there are lots of other important technologies (such as network attached storage, software defined firewalls, message brokers, etc) that also might been seen as important to successful cloud native architectures. All the other elements of your list seem to be about approaches not mechanisms, hence the service mesh line therefore seems to be a different category.

Paul

On 30 January 2018 at 17:48, alexis richardson <alexis@...> wrote:
Nice one Brian

Once you said "cloud native is automation"

Re the second section, I suggest "promote... but are not necessary for".  In particular i am not convinced immutability is quite "right", and service mesh is overkill for many use cases 



On Tue, 30 Jan 2018, 17:30 Brian Grant via Lists.Cncf.Io, <briangrant=google.com@lists.cncf.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 Tue, Jan 30, 2018 at 9:48 AM, alexis richardson <alexis@...> wrote:
Nice one Brian

Once you said "cloud native is automation"

 

Re the second section, I suggest "promote... but are not necessary for". 

Good suggestion. I agree they aren't all necessary in every situation. They are intended to serve as examples.
 
In particular i am not convinced immutability is quite "right"

There's certainly some nuance, which I discuss some in my doc on declarative application management (https://goo.gl/T66ZcD). In particular, it is typically necessary to automatically modify immutable resources via configuration.
 
, and service mesh is overkill for many use cases 

Most automation is overkill for some cases, and there are certainly other means (e.g., Kubernetes services, Weave Scope) of achieving some of the same objectives as service meshes. 
 



On Tue, 30 Jan 2018, 17:30 Brian Grant via Lists.Cncf.Io, <briangrant=google.com@lists.cncf.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"

alexis richardson
 

Paul

Do you agree that mesh is helpful, but otherwise neither necessary nor sufficient?

A


On Tue, 30 Jan 2018, 18:05 Paul Fremantle, <paul@...> wrote:
I think the overall definition is much better. 

I really like how service meshes enable DRY and declarative intent, but there are lots of other important technologies (such as network attached storage, software defined firewalls, message brokers, etc) that also might been seen as important to successful cloud native architectures. All the other elements of your list seem to be about approaches not mechanisms, hence the service mesh line therefore seems to be a different category.

Paul

On 30 January 2018 at 17:48, alexis richardson <alexis@...> wrote:
Nice one Brian

Once you said "cloud native is automation"

Re the second section, I suggest "promote... but are not necessary for".  In particular i am not convinced immutability is quite "right", and service mesh is overkill for many use cases 



On Tue, 30 Jan 2018, 17:30 Brian Grant via Lists.Cncf.Io, <briangrant=google.com@...> 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"

Paul Fremantle <paul@...>
 

I think the overall definition is much better. 

I really like how service meshes enable DRY and declarative intent, but there are lots of other important technologies (such as network attached storage, software defined firewalls, message brokers, etc) that also might been seen as important to successful cloud native architectures. All the other elements of your list seem to be about approaches not mechanisms, hence the service mesh line therefore seems to be a different category.

Paul

On 30 January 2018 at 17:48, alexis richardson <alexis@...> wrote:
Nice one Brian

Once you said "cloud native is automation"

Re the second section, I suggest "promote... but are not necessary for".  In particular i am not convinced immutability is quite "right", and service mesh is overkill for many use cases 



On Tue, 30 Jan 2018, 17:30 Brian Grant via Lists.Cncf.Io, <briangrant=google.com@lists.cncf.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"

alexis richardson
 

Nice one Brian

Once you said "cloud native is automation"

Re the second section, I suggest "promote... but are not necessary for".  In particular i am not convinced immutability is quite "right", and service mesh is overkill for many use cases 



On Tue, 30 Jan 2018, 17:30 Brian Grant via Lists.Cncf.Io, <briangrant=google.com@...> 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"

Chris Aniszczyk
 

I converted this to a gdoc for easier editing/commenting for now:

Thanks Brian for spearheading this discussion.

On Tue, Jan 30, 2018 at 11:30 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> 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.






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


updating what it means to be "Cloud Native"

Brian Grant
 

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: Agenda for upcoming CNCF meetings in Feb 2018

John Belamaric
 

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@...> wrote:

John, yes, we can definitely cover that.


On Tue, Jan 30, 2018 at 2:11 PM, John Belamaric <jbelamaric@...> 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@...> 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: Agenda for upcoming CNCF meetings in Feb 2018

alexis richardson
 

John, yes, we can definitely cover that.

On Tue, Jan 30, 2018 at 2:11 PM, John Belamaric <jbelamaric@...> 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@...> 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: Agenda for upcoming CNCF meetings in Feb 2018

John Belamaric
 

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@...> 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: [VOTE] Vitess project proposal (incubation)

Sugu Sougoumarane
 

Many of these companies have talked to us, and we are still in some form of conversation with some of them. The logos we've listed are only those from whom we've received explicit permission from.

PS: mineraftly is an aweseom find! LOL.

PPS: I missed Nozzle's contribution in my original response. Ironically, they are the most noteworthy contributors because they're refactoring our helm charts.

On 29 January 2018 at 21:04, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> wrote:
FWIW, it looks like there is decent demand for something like Vitess (13790 commits) based on the number of companies that have implemented their own solutions:


On Mon, Jan 29, 2018 at 8:03 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@lists.cncf.io> wrote:

On Mon, Jan 29, 2018 at 7:28 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:
To follow up on this, with some links for external confirmation:

I think some of the confusion arose due to data being sampled at different times. The original presentation to the TOC was last April, for instance.
 
Slack presentation from 4-5 months ago. They are contributing heavily to vitess, as can be seen from the contribution stats I just sent, and even a small fraction of traffic was non-trivial.

Stichlabs has fully migrated production to Vitess: video

BetterCloud mentions that they use Vitess on their blog.

IMO, the production usage bar is intended primarily to assess maturity and production-worthiness, and secondarily general applicability (though 3 users isn't really enough for that). I don't think maturity and production-worthiness are concerns in this case. I think better documenting production usage via case studies is something the CNCF could help with.

As with Prometheus, Envoy, and Jaegar, Vitess was developed over the last 7 years or so for Youtube's own use. It has become more relevant to other companies with the (comparatively recent) emergence of Kubernetes. If we're looking for more user-initiated projects, Vitess is one of those.



On Mon, Jan 29, 2018 at 6:41 PM, Sugu Sougoumarane <ssougou@...> wrote:

Ah, I should have made this explicit in our slides, but here is the information to address your concerns about the graduation criteria:


The following eight companies have vitess serving production traffic:

  • YouTube

  • Slack

  • Hubspot

  • Flipkart

  • Stitch Labs

  • Square (Cash App)

  • BetterCloud

  • Quiz of Kings


Of these, engineers from the following companies have made significant contributions to the vitess code base:

  • YouTube

  • Slack

  • Hubspot

  • Flipkart

  • Square (Cash App)

  • StitchLabs


Additionally, the following companies have started making contributions, while in the process of evaluating:

  • Booking.com

  • Github

  • Pinterest (new)


There are also other companies listed in the adopters page. They are evaluating vitess with the intent to mainly use it.


Finally, there are other companies, who are involved with Vitess at various levels, that wish to remain anonymous. So, we haven’t listed them here.


Please let me know if this answers your questions, or if you have others.



On 29 January 2018 at 18:08, Quinton Hoole <quinton.hoole@...> wrote:
I share Camille’s concern.

Note that the only explicit requirement in this regard w.r.t. Incubation level is as follows (from https://www.cncf.io/projects/graduation-criteria/):

  • Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgement, are of adequate quality and scope.
The proposal says this about adopters:

This is an alphabetical list of known adopters of Vitess. Some have already gone into production, and others are at various stages of testing.


Can we perhaps get some clarification about which are in production, and which are still in testing.

Sorry, this should have been brought up in the due diligence, but unfortunately got missed, by the looks of things.

Q

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc@...> on behalf of Camille Fournier <skamille@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Monday, January 29, 2018 at 17:54
To: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Vitess project proposal (incubation)

Basically, I'm concerned that there are not really actual production users who also are project committers that aren't YouTube/Google.

On Jan 29, 2018 9:53 PM, "Camille Fournier" <skamille@...> wrote:
But it is not yet in prod? Bringing it to prod sounds like not.

On Jan 29, 2018 9:51 PM, "Sugu Sougoumarane" <ssougou@...> wrote:
Just got this confirmation from Hubspot: "Definitely using. Two dedicated full timers working on bringing it to prod. Three others supporting part time, plus me. We have a handful of prod clusters at this point and are starting wider scale rollout soon."

It's likely that the slides were prepared at different times, because they were on staging for a while.

On 29 January 2018 at 17:36, Camille Fournier <skamille@...> wrote:
I'm confused, is hubspot using or evaluating this product? The different slide decks seem to disagree.

On Jan 25, 2018 12:50 PM, "Chris Aniszczyk" <caniszczyk@...g> wrote:
The TOC has decided to invite Vitess (https://github.com/youtube/vitess) as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC.

Vitess is a MySQL-compatible data orchestrator/platform. It orchestrates management of MySQL instances and has been serving all YouTube database traffic since 2011. Vitess has grown to encompass tens of thousands of MySQL nodes. It is also used by companies such as HubSpot, Slack and Square. 

The full project proposal is located here: https://github.com/cncf/toc/pull/67

Please vote (+1/0/-1) on this thread... remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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








6001 - 6020 of 7556