1. Cncf-Toc
  2. Messages

Re: an interesting read, about "Cloud Native"

Lee Calcote
 

I agree that the mission section contains mechanics. It does contain a mission statement. Perhaps, mechanics are best separated. A separate “Cloud Native Qualities” section could include not only these mechanics, but softer properties of values held dear by the foundation (e.g. immutable infra, automatic discovery, self-healing, etc.). 

While I don’t disagree with Brian’s point that VMs are currently not explicitly included, they are not implicitly excluded either. With the vast amount of work, energy, effort it takes the foundation to track and steward the container ecosystem, I question whether this group (the foundation) will be successful if it tries to explicitly include consideration for VMs within the scope charter as well. Albeit not focused on microservices architectures, other foundations (even within the Linux Foundation like the OVA) are saddled with VM-specific charters. Understanding many organizations will run CNCF container projects within or pointed at VMs, is the lack of explicit inclusion ok or do people feel like there needs to be a specific statement here? 

With respect to the list of developer responsibilities, I’ll tack-on security as another responsibility.

- Lee

On May 4, 2016, at 1:36 AM, Brian Grant via cncf-toc <cncf-toc@...> wrote:

On Thu, Apr 21, 2016 at 5:57 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
Hi all,

Not too long ago Joe Beda wrote an interesting doc about "Cloud Native".  I have his permission to share it, and so I am posting a URL below. 

I bring this to your attention because it may help us think about how to define "cloud native" for prospective projects and end users.   Obviously this is Joe's take on things.  What do others think?


alexis

Our mission is currently defined more natively than Joe's definition of "cloud native":

The mission is described in terms of mechanisms rather than goals: containers, dynamic management, micro-services.

To me, "cloud native" implies turn-key/self-service/automated provisioning, predictable/reproducible deployment, elastic scaling, self-healing, automatic discovery, and automatic monitoring. These properties increase the velocity of application delivery and management scalability (i.e., manage N things as easily as 1).

ssh-ing into an instance to configure it manually in a non-reproducible fashion, manually creating a configuration file listing IP addresses of specific instances, and crashing if a dependency is not reachable are examples that don't quality as "cloud native".

Are containers more "cloud native" than VMs? Unless we want to change our mission/charter, this question doesn't really matter, but containers do facilitate higher-level and more automated management and introspection. VMs are by nature more opaque and responsible for more of the application lifecycle. However, we may consider a number of projects (e.g., Prometheus) that could be used equally well with either containers or VMs.

On DevOps: Joe mentions that developers are incentivized to make their applications production-ready, but one thing that's not made clear enough is that developers are responsible for meeting operational requirements: reliability, availability, scalability, efficiency, liveness and readiness signals, exported metrics, actionable logging, termination/signal handling, self-configuration based on the environment, configuration knobs exposed to operators, compatibility with the production environment, ... Failure to meet these requirements is a bug. Operators are both partners and customers.


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
Join cncf-toc@lists.cncf.io to automatically receive all group messages.