Re: an interesting read, about "Cloud Native"


Brian Grant
 

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.


Join cncf-toc@lists.cncf.io to automatically receive all group messages.