|
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
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
|
|
|
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
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.
|
|
|
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
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.
|
|
|
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
|
|
|
|
|
|
Paul Fremantle <paul@...>
toggle quoted message
Show quoted text
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
|
|
|
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.
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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...
toggle quoted message
Show quoted text
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.
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?
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.
|
|
|
Duncan Johnston-Watt <duncan.johnstonwatt@...>
toggle quoted message
Show quoted text
On 31 January 2018 at 07:13, Yaron Haviv <yaronh@...> wrote:
I’m also more aligned with Justin’s definition, the way I usually describe Cloud-Native architecture in my posts is that it provides:
- Durability — services must sustain component failures
- Elasticity — services and resources grow or shrink to meet demand
- Continuity — versions are upgraded while the service is running
I think declarative may be the way to achieve those, but can be added explicitly
Containers, unikernels, serverless, foo… are ways to implement this
Yaron
iguazio, CTO
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...
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.
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?
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.
|
|
|
I really like the "declarative, dynamic, resilient, scalable". I think it fits the need for the elevator pitch.
-Bob
On Tue, Jan 30, 2018 at 10:30 PM, Bryan Cantrill <bryan@...> wrote: 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
|
|
|
Scott Hammond <scott.hammond@...>
I really like how Justin framed this but I don’t want to lose the “agility” piece he mentions. Applications have always been designed for resiliency, operability, and observability and have often delivered (at a huge price), but because of the constraints of non-cloud native approaches, they were never agile. This unique value of agility is why they deliver deliver disruptive business value.
Scott R. Hammond
President and CEO
Joyent, Inc.
(o)415-800-0872
(c)650-906-0740
On Jan 31, 2018, at 8:55 AM, Bob Wise < bob@...> wrote:
I really like the "declarative, dynamic, resilient, scalable". I think it fits the need for the elevator pitch.
-Bob
|
|
|
Justin Garrison <justinleegarrison@...>
I'm glad so many people found my definitions helpful!
I disagree that applications have "always been designed for resiliency, operability, and observability". I have worked on numerous systems that had none of those qualities.
While I obviously agree that agility is important and a key differentiating factor in a cloud environment in this condensed definition I was lumping agility into "dynamic". See my expanded definition from my previous email.
I'm sure there are opinions about things being agile, dynamic, and high velocity but at the end of the day I think it's all about the ability to change frequently to provide business value. No matter if that's the applications or infrastructure or if change is allowing a pivot (agility) or faster time to market (velocity). The DevOps movement really started this as a thing to aspire to with how many deployments per day you had. Sadly I think that was the wrong metric to measure but nonetheless defined much of that culture. Cloud native can empower lots of deployments per day (building on DevOps principles) but we should try to measure impact to the business instead of how fast we go.
On Wed, Jan 31, 2018 at 10:00 AM, Scott Hammond <scott.hammond@...> wrote: I really like how Justin framed this but I don’t want to lose the “agility” piece he mentions. Applications have always been designed for resiliency, operability, and observability and have often delivered (at a huge price), but because of the constraints of non-cloud native approaches, they were never agile. This unique value of agility is why they deliver deliver disruptive business value.
On Jan 31, 2018, at 8:55 AM, Bob Wise < bob@...> wrote:
I really like the "declarative, dynamic, resilient, scalable". I think it fits the need for the elevator pitch.
-Bob
|
|
|
Bernstein, Joshua <joshua.bernstein@...>
I know I’m late to the party here, but I really like the key bullets Yaron outlined below. I think this makes it pretty straight forward and is really a powerful statement.
I’d be in favor, of whatever we agree to here to be able to be distilled down to clear bullets like these.
-Josh
On Jan 31, 2018, at 1:38 AM, Yaron Haviv < yaronh@...> wrote:
toggle quoted message
Show quoted text
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
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...
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.
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?
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.
|
|
|
I feel an acronym coming on....
I know I’m late to the party here, but I really like the key bullets Yaron outlined below. I think this makes it pretty straight forward and is really a powerful statement.
I’d be in favor, of whatever we agree to here to be able to be distilled down to clear bullets like these.
-Josh
On Jan 31, 2018, at 1:38 AM, Yaron Haviv < yaronh@...> wrote:
I’m also more aligned with Justin’s definition, the way I usually describe Cloud-Native architecture in my posts is that it provides:
- Durability — services must sustain component failures
- Elasticity — services and resources grow or shrink to meet demand
- Continuity — versions are upgraded while the service is running
I think declarative may be the way to achieve those, but can be added explicitly
Containers, unikernels, serverless, foo… are ways to implement this
Yaron
iguazio, CTO
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...
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.
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?
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.
|
|
|
Great discussion. Thanks!
|
|
|
