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.