It is not a new concept, but I am hearing it more often lately. Here you have an example at Techcrunch.
In the article, Salil tries to go beyond what he mentions as the current standard definition "refers to the idea of running containers on bare metal (rather than on VMs)" and delves into the new way applications can be built purposely for container environments.
While I appreciate the need to envision the future, given my work at Cloudways. I am quite attached too to the realities of normal people doing normal stuff.
In this sense, even the current definition of container native so, some app running on a bare metal container, brings a number of benefits to just normal people that are worth exploring.
Let's quickly review them:
Running on bare metal, we remove a layer of virtualization (compared to running containers on a VM) and that can't be bad for performance. So at some extent (and it will vary from app to app), you should get some extra power for your bucks (we are currently checking with our supported apps).
Maybe not critical if you can wait, but provisioning a container (bare metal or not) is a few seconds stuff. With container native, you don't have to wait for the (much slower) VM to come up, click and go.
You can literally scale a bare metal container in two seconds and without downtime. The only limit to it, is the size of the physical host. You can do the same on a VM, and if the VM has all the resources of the physical host, it would be equivalent (albeit performance). But in a container native approach, you remove the hassle of the VM in between, and with ever larger physical hosts, most normal people will have more than enough power to scale their apps.
Now things start to get interesting. Still not many people providing this (know few working on it), but the nature of bare metal containers (instant provisioning) when paired with a proper storage solution to back container data, allows for live migration -i.e. if a physical server hosting a container goes down, this container can be up&running nearly instantly in another physical server (aka live migration).
This is relevant for normal people, as if paired with instant scalability, gives an extremely cost effective solution for high-availability and auto-scaling needs. Now you need to solve this via (typically VM based) somewhat complex load balanced web servers farms, with a highly available database layer behind and auto-scaling rules at the load balancer level.
All of this could be replaced with a single container on bare metal infrastructure with live migration capabilities at a fairly discounted price.
A few Infrastructure As a Service providers with this approach start to pop up (Kyup and Joyent i.e.) and my bet is that many more will appear while typical VM based IaaS transition to it. A trend worth watching.