Why Platform9 Kubernetes is the DevOps Alternative to Google Anthos

Platform9 Kubernetes (PMK) is a fully SaaS managed Kubernetes platform that makes your multi-cluster, multi-cloud Kubernetes management delightfully uncomplicated.

Unlike Google Anthos, we bring up your POC environment in a matter of hours, with much better support for VMware vSphere, Linux KVM, and at a fraction of Anthos pricing.

Detailed Comparison

Platform9 Managed Kubernetes
Google Anthos


Management plane

Both Google Anthos and Platform9 claim to offer "Managed Kubernetes". One would imagine that Managed Kubernetes would involve the use of a Management plane to handle management work. For instance, centralized management, cluster CRUD, service configuration, SSO / user auth, diagnostics and troubleshooting. So, how good is the 'Management Plane' for these two offerings? Is it a purpose built, well designed system that was expressly created with a focus on simplifying Kubernetes management or is it just vaporware?
100% Platform9 pioneered the use of a Management plane to operate private, hybrid and multi cloud environments. This management plane has been built with over 100s of man years of engineering investment and IP, has a dedicated UI and API, and is offered as a SaaS service by default. Platform9's management plane is what enables automation at scale for complex Kubernetes cluster monitoring, alerting, cluster upgrades, and SLA management.
75% Google Anthos does NOT provide a dedicated, cloud-hosted Management plane. It requires an "Admin cluster" to be supplied by the customer, so that it can deploy its key components in order to manage user's clusters. See the problem: you need a bootstrap Kubernetes cluster to deploy the software that is supposed to manage Kubernetes? Needless to say, this leads to additional resources and additional complexity (upgrades are more complex because you have to match the versions of two different types of clusters). While Google Anthos does enable use of the GKE console, this is only better for organizations that are entirely bought into Google cloud as their cloud strategy. If you are looking for a more open, neutral strategy, this approach just doesn't make sense.

Depth of infrastructure integrations

To fully utilize the power of Kubernetes, you want your Kubernetes environments to take advantage of the specific strengths of your underlying infrastructure; or a variety of infrastructure endpoints. As opposed to simply aggregating various Kubernetes clusters for better visibility, a fully-managed Kubernetes offering would provide maintenance, upgrades, deploys, and other capabilities on the supported infrastructure that go beyond providing basic visibilty.
100% Platform9 has deep and native integrations for the most common infrastructure deployments:
  • on-premises: bare metal, VMware, OpenStack or on Linux servers
  • public clouds: deep and native integrations with AWS, Azure and Google cloud
  • at the edge: small server configurations, large numbers of small sites
With every environment, Platform9 has deep and native integrations. For instance, you have very fine grained control for how networking, auto-scaling groups, compute instances are configured in AWS. When running on bare metal, you can configure advanced networking policies to optimize performance and eke out every last bit from your hardware assets.
75% Google Anthos claims to support Kubernetes clusters running on-premises, in Google Cloud and AWS (Azure support is in preview mode). However, several enterprise features are only available when deployed on GKE, such as: multi-cluster Ingress, security/encryption features, service mesh features, usage metering, and auto-scaling. Outside of GKE, Google Anthos lags Platform9 in its depth of feature integrations. If you are looking for deep, and native infrastructure integrations, look elsewhere.

Speed of Onboarding

A Managed Kubernetes platform must be easy to implement and maintain so organizations can leverage containers at scale with a small operations team. This alone is a major barrier that many organizations do not overcome.
100% Fully automated deployment and easy UI-driven wizard gets your Kubernetes clusters running in a few minutes. POCs can be fully self service or done in collaboration with our enterprise Solution Architects team
50% Requires setup of multiple tools. Manual setup and configuration process. POCs may run for weeks and can not be self service

Multi-version support

Organizations often need to run multiple versions of Kubernetes rather than be forced to stick to a single, specific version based on the managed service providers' support. This is advatageous when test/dev clusters are not preferred to be on the same Kubernetes version as production clusters, or when an organization is currently on a different version of Kubernetes than the one that the managed service supports.
100% Platform9 Managed Kubernetes maintains a list of supported Kubernetes versions and users are able to deploy a selected version at the time of cluster creation.
  • Anthos does not offer multi-version support. Each version of Anthos is tied to a single Kubernetes version, so upgrading your cluster requires an Anthos upgrade.
  • Multiple clusters can't be deployed with different versions of Kubernetes.

Bare metal support

For organizations looking to deploy Kubernetes clusters on premises, deploying clusters on bare metal must be a seamless experience in order for them to fully realize the value of Kubernetes and containers.

This enables organizations to do away with virtualization licensing costs, the management overhead associated with the virtualization stack, and the performance hit that applications incur because of the hypervisor layer.

Does the Managed Kubernetes solution include or tightly integrate with bare metal orchestration and automation tools? How well does it enable the value of bare metal without additional complexity?

  • Platform9 Managed Bare Metal provides end-to-end automation: from server power-up to deploying operating system on the servers, to the servers joining Kubernetes clusters with a designated role.
  • Platform9 bare metal includes the provisioning and configuration of customer selected OS images, pre-requisites, and upgrades to newer patch releases as well as major versions.
  • Google Anthos does not offer bare metal automation capabilities to perform provisioning, configuration, oe upgrades of your bare metal servers; this is left as an exercise for the customer.
  • Google Anthos provides a command line tool to add existing, pre-provisioned bare metal servers into Anthos Kubernetes clusters

Virtualization Support

While running containers efficiently is usually the main motivation for adopting Kubernetes, most organizations find that they still need to run and manage VMs. This happens because of various reasons - some applications are not designed to be run on containers, legacy workloads are harder to containerize, the effort needed to migrate applications to containers is too large and expensive, to name a few. This results in the maintenance of separate stacks for VMs and containers, which increases the operational burden on infrastructure teams. Support for VM management alongside Kubernetes containers simplifies this.
  • Platform9 Managed Kubevirt enables VMs to be deployed and managed by Kubernetes, alongside containers.
  • Managed Kubevirt is generally available and is in production at retailers, SASE providers and large private clouds.
  • Google Anthos support for VMs is not in production.
  • Migrate for Anthos helps transition VM-based workloads into container-based workloads.


Multi-Cluster Management

A single Kubernetes cluster can scale horizontally to support large sets of workloads. However, running Kubernetes in production requires being able to run multiple Kubernetes clusters, as you will want to fully isolate your dev/test/staging applications from production applications by deploying them on a separate cluster.
  • Built in multi-cluster support.
  • Admins can create and manage multiple clusters across different regions, data centers, edge locations, and public clouds.
  • Supports multi-cluster management and configuration.
  • Clusters can span a range of on-premises or multi-cloud infrastructure.


A production Kubernetes cluster must be monitored at all times to handle any issues and outages without severely affecting cluster and application availability to users. An enterprise Kubernetes solution must provide this capability out of the box.

  • 24 x 7 live monitoring
  • 99.9% guaranteed SLA
  • Proactive repair
  • Automated email notifications for any issues
  • Automated support ticket creation and triaging of issues
  • Out-of-the-box automated deploy of Prometheus and Grafana
75% Uses Google Cloud’s Cloud Logging and Cloud Monitoring platforms by default to monitor clusters. Prometheus and Grafana may also be used. However, Cloud Logging and Cloud Monitoring are required if customers seek official support.

Production grade support/SLAs

As more and more organizations are running their business on Kubernetes, IT must ensure that it can support the SLAs that the business requires. IT must ensure that Kubernetes is available to developers and the business to support key initiatives. Most organizations require 99.9% uptime.

  • Platform9 contractually promises 99.9% cluster uptime and high availability
  • Provides self healing and problem resolution through the service
  • GKE clusters have 99.5% for regional clusters and 99.95% for zonal clusters
  • Anthos GKE on-prem support covers most components like Kubernetes and container runtime, F5 controller, Calico, and Ingress controller

Private registry support and image management

Running containerized applications on Kubernetes clusters requires having access to a container registry where your application images will be stored. A large enterprise organization will typically want a secure private container registry to store their proprietary application images. An enterprise Kubernetes solution should provide image management capability out of box.

  • No out of the box support for private registries.
  • Registries and secrets required to authenticate with the registries need to be managed by the customer separately.
  • No built-in registry service
  • Compatible with all standard Docker registries

Cluster upgrades

Kubernetes has a large community of contributors and a new version is available every 3 months. An enterprise-class solution will support rolling upgrades of clusters, such that the cluster and the cluster API is always available even while the cluster is being upgraded. Additionally, it will provide the ability to rollback to previous stable version upon failure.

It is critical to support concurrent use of multiple Kubernetes versions. This is often required in order to enable testing and validation of an application on a new version; but is also required because different versions of applications or teams may have compatibility constraints.

  • Fully automated, rolling cluster upgrades delivered seamlessly
  • Platform9 supports a broad range of Kubernetes versions, enabling greater flexibility in when users upgrade
  • Multi-version support so don’t need to upgrades all clusters at the same time

  • Google Anthos offers limited control over the versions of Kubernetes in comparison to Platform9.
  • Google Anthos' architectural dependency on the Admin cluster requires a carefully orchestrated sequence of first upgrading the Admin Workstation tool, then upgrading the user clusters and then the Admin cluster. Version compatiiblity between those clusters is unclear and complex.

Multi-Tenancy, Role-Based Access Control, and Single Sign-On Support

Kubernetes supports multi-tenancy at the cluster level using the namespace abstraction. However, in a multi-cluster environment, you need a higher level multi-tenancy abstraction to supplement Kubernetes multi-tenancy and provide the right level of isolation across different teams of users. It should integrate with Single-Sign On (SSO) solutions most commonly used by enterprises such as Active Directory or ADFS, Okta, and other popular SAML providers.

  • Support for multi-region management
  • Built-in multi-tenancy support
  • Kubernetes RBAC is fully supported
  • Full support for Single- Sign On (SSO). Integrate with a SAML-based provider that your organization uses such as Okta, ADFS, Ping Identity, etc.
  • Uses native Kubernetes RBAC
  • RBAC settings can be managed centrally through Anthos Config Management
  • Full support for multi-tenant clusters
  • Google Anthos only supports OIDC or LDAP, doesn't support SAML2 which is common in the enterprise

Support for automated application deployments

Application catalog and Helm provides easy one-click deployment for a set of pre-packaged applications on top of Kubernetes. It also provides end users a vehicle to build and publish their own applications via the catalog for others in their team or their organization to deploy in a one click manner. The application catalog enables organizations to standardize on a set of application deployment recipes or blueprints, avoiding sprawl of configurations.

  • Administrators can provide users access to applications that are private to the organization
  • Support for managed apps
  • Users can leverage Helm to deploy applications on Platform9, and Platform9 support will help with issues. Application catalog will be available in Platform9 in 2021.
  • Applications can be deployed from Google Cloud Platform Marketplace
  • Applications can also be deployed using Helm charts or similar techniques using Anthos Config Management repos; however, this requires some manual setup

Managed CNI

Networking in Kubernetes can get complex, and is not trivial to understand. Kubernetes specifies a Container Network Interface (CNI) which enables software defined networking plugins like Calico and Flannel to be integrated with Kubernetes clusters. The lifecycle of the CNI must be managed by the platform provider, and the vendor is able to help troubleshoot issues with the CNI. Services are provided on the design and implementation of cluster networking by the managed offering.

  • Platform9 supports both Flannel and Calico, with Calico as the defualt and prefered CNI
  • As an experienced managed provider, Platform9 manages the entire lifecycle of Calico. This is made possible through a combination of software and years of experience operating SDNs for large enterprise Openstack Neutron deployments.
  • Works with networking options provided by GKE (Flannel, Calico)
  • Anthos Service Mesh provides Istio CNI out of the box, on-prem and on GKE

Managed Load balancing

Load balancers are an important component of Kubernetes clusters - not just for load distribution, but also for Ingress. A complete, production-ready Kubernetes solution should include load balancers that are supported on the underlying infrastructure. It should also manage the lifecycle of the load balancer.

  • Platform9 installs, suports and manages the life cycle of a service load balancer across all cloud and on-premises infrastrucure
  • On public clouds Platform9 will deploy the natvie cloud load balancer and manage the deployment within the lifecycle of the cluster
  • For Edge and On-premises deployments Platform9 deploys and manages MetalLB.
25% Integrates with F5 natively for on-prem deployments, Google Cloud Load Balancer on GKE, and various third party options on-prem and on AWS/GKE.


Support for CI/CD integrations

One of the most critical workloads run by the developers is Continuous Integration / Continuous Delivery. A robust CI / CD pipeline is critical to ensure agile development and rapid delivery of new software releases to customers.

50% Platform9 integrates with most major third party CI/CD toolchains.
  • Any CI/CD tools that are compatible with GKE can deploy to clusters managed via Anthos
  • Cloud Build is Google Cloud’s native CI/CD solution, but most major third-party tools are supported as well

Storage Integrations

Similar to networking, integration with enterprise grade storage is an essential component of running Kubernetes clusters in production. Kubernetes provides an abstraction called Persistent Volumes to hold data persisted by stateful applications. It is important for a Enterprise Kubernetes product to map PVs to an actual highly-available storage technology. Enterprises will typically want their Kubernetes deployment to integrate with storage solutions that they have already deployed such as NetApp, Pure, SolidFire, etc. or they may want to integrate with a container native storage technology such as Portworx

  • Supports integration with any FlexVolume drivers
  • Integrates with any Cinder-supported storage backend (NetApp, Pure Storage, etc.)
  • Compatibility with all CSI-compliant backends
  • Compatible with GKE-supported storage solutions (standard Kubernetes volumes and certain GCP storage services)
  • Storage add-ons can be deployed through Google Cloud Platform Marketplace

Portability and Readiness

Effort to migrate off of provider

Lock-in occurs in differnet ways. Some of the common ways are: cloud services that tie organizations to vendors, vendor-specfiic Kubernetes distributions, architecture, and the skillsets and culture of teams. This is an important factor to consider when adopting a managed Kubernetes service.

  • Organizations use Platform9 to deploy upstream Kubernetes versions of their choice, on any infrastructure. The clusters could be deployed on multiple public clouds, in data centers, or at edge locations. The functionality and managed offerings do not vary at all between the various deployment options.
  • Platform9 provides managed services around Kubernetes (like MetalLB and Calico), and these are all open-source technologies which are provider-agnostic.
75% Customer deploys upstream Kubernetes, but will lose several important operational services when switching. Especially for clusters deployed on GKE, services running on top like multi-cluster Ingress, security/encryption features, service mesh features, usage metering, and auto-scaling will all have to be re-architected to move off of Anthos.

Production readiness

Given the complexity of Kubernetes, it is important for the managed Kubernetes service to have been generally available in the market for a reasonable amount of time. Especially for clusters deployed in production environments, experienced support and a reliable, battle-tested product are important factors to consider.

100% Launched in February 2017 as the industry’s first infrastructure-agnostic managed Kubernetes service.
50% Generally available since April 2019, and support for connecting bare metal nodes to Kubernetes clusters has been generally available since November 2020


Getting the most out of Kubernetes for multi-cloud, edge, and distributed deployments is very complex and challenging. Despite all of the built-in automation features that Kubernetes offers for managing container workloads intelligently, achieving optimal performance, cost and reliability at distributed scale requires careful planning and tuning of Kubernetes environments. 

The operational complexity increases exponentially with large-scale distributed sites such as 5G rolls-outs or retail stores have to deal with. Challenges increase when you add requirements for advanced networking, stringent latency and performance needs, central/remote management, and bare metal orchestration. 

Unlike Google Anthos which is basically an extension of GKE to work with on-premise environments, Platform9 Managed Kubernetes has been designed from the ground up to centrally manage massively distributed and diverse infrastructure environments. Platform9 has large-scale production deployment experience since 2017 using 100% open source Kubernetes that is 100% cloud or infrastructure agnostic.

The browser you are using is outdated. For the best experience please download or update your browser to one of the following:

VMware admin? Join our hands-on OpenStack workshopRegister Now