Right, I should have been more clear: Anthos on-prem "just" gives you the Kubernetes part of that API consistency story.
On machine management, it's intentionally the case that administrators can control the base machine part via "Bring Your Own Node", because of all the processes and compliance things that customers have in place for their other boxes. They don't want their GKE cluster to be some rogue actor in their datacenter (more than it will be already).
Some customers are happy to let a provider own the end-to-end story of the base OS, including patching/upgrades, though we're not (currently) ready to support them running Container-Optimized OS (aka COS) on bare metal. We do have in-place upgrading of the K8s parts via ```bmctl upgrade cluster``` or ```kubectl apply``` [1], but expect that enterprises will prefer to use their existing patch management procedures. I don't expect most enterprises to jump on "single cloud provider" patch management (e.g., our own patch management [2]) anytime soon.
Think of the progression this way:
- many large enterprises wanted to add in K8s on-prem into their existing vSphere universes
- others wanted out of vSphere but still had their own machines and own ticketing/OS/patching systems
- others still want to "bring their own metal" with the rest managed by a provider.
- Outposts sort of jumps to "you want our boxes but in your datacenter"
The Outposts angle is definitely a great fit for customers who want a more "appliance-like" behavior. And I think that works great for new workloads, or customers who don't mind replacing their existing hardware. My take is that many folks want to modernize in place though, and setting up and maintaining K8s was the hard part for them (they kind of still like their patch management and machine ticketing systems). Getting their developers to just do kubectl apply all day instead of requesting boxes is already a big leg up.
On machine management, it's intentionally the case that administrators can control the base machine part via "Bring Your Own Node", because of all the processes and compliance things that customers have in place for their other boxes. They don't want their GKE cluster to be some rogue actor in their datacenter (more than it will be already).
Some customers are happy to let a provider own the end-to-end story of the base OS, including patching/upgrades, though we're not (currently) ready to support them running Container-Optimized OS (aka COS) on bare metal. We do have in-place upgrading of the K8s parts via ```bmctl upgrade cluster``` or ```kubectl apply``` [1], but expect that enterprises will prefer to use their existing patch management procedures. I don't expect most enterprises to jump on "single cloud provider" patch management (e.g., our own patch management [2]) anytime soon.
Think of the progression this way:
- many large enterprises wanted to add in K8s on-prem into their existing vSphere universes
- others wanted out of vSphere but still had their own machines and own ticketing/OS/patching systems
- others still want to "bring their own metal" with the rest managed by a provider.
- Outposts sort of jumps to "you want our boxes but in your datacenter"
The Outposts angle is definitely a great fit for customers who want a more "appliance-like" behavior. And I think that works great for new workloads, or customers who don't mind replacing their existing hardware. My take is that many folks want to modernize in place though, and setting up and maintaining K8s was the hard part for them (they kind of still like their patch management and machine ticketing systems). Getting their developers to just do kubectl apply all day instead of requesting boxes is already a big leg up.
[1] https://cloud.google.com/anthos/gke/docs/bare-metal/1.6/how-...
[2] https://cloud.google.com/compute/docs/os-patch-management