Openshift Vs Gravity

User Experience
  • Driven through simplified web based UI
  • Developers do not have to know Kubernetes to use Gravity
  • Mix of web based UI and command line
  • Exposes Kubernetes (some features require direct YAML editing)
  • Developers required to understand Kubernetes terminologies (can make mistakes without proper understanding)
  • Platform or central Devops teams need to build additional tooling to provide developer experience
  • Gravity eliminates developers making mistakes without understanding Kubernetes
  • Gravity is Application Developer friendly with tailor made experiences for each type of workload that they deploy (more on this below)
  • OpenShift has steep learning curve whereas Gravity can be adopted in a day
Platform Setup & Onboarding
  • Fully automated, installed and configured in customers public cloud
  • Platform operational in less than 6 hours
  • Requires expertise in customer's organization to install & configure Open Shift Container Platform initially
  • RedHat SRE team takes over post initial installation
Kubernetes Distribution
  • Upstream open source Kubernetes
  • Custom Kubernetes Distribution by RedHat
  • Locked into OpenShift
  • Gravity uses fully open source components. Customers can move out of Gravity anytime by simply exporting all the YAML definitions
Cluster Provisioning
  • Yes
  • Yes
  • Fully automated and managed Cluster Provisioning process
Control Plane
  • Managed by Cloud Provider (AWS, Azure, GCP)
  • Managed by OpenShift and RedHat SRE
  • Cloud Providers have vast Operational Excellence in managing hyper scale infrastructure. By using Control Planes provided by Cloud Providers customers benefit the scale, performance and availability that the Cloud Providers provide as part of the service
Control Plane Cost
  • AWS: $80
  • Azure/GCP: Free
  • ~ $1500 per cluster
  • OpenShift requires 3 Master nodes and 3 Infrastructure nodes per cluster with additional components like Load Balancers
  • OpenShift Control Plane nodes run as Virtual Machines in customer's Cloud Accounts and are charged by Cloud Providers
  • OpenShift Control Plane costs can increase as customers scale their cluster infrastructure
Cloud Provider Support
amozone web server circle icon logo
amozone web server circle icon logo
On-Premise Cluster Support
  • Not Currently
  • Bare Metal, VMWare Vsphere, IBM Power Systems
Machine Sets / Node Groups / Node Pools/ Spot Instances/ Cluster AutoScaler/ Horizontal Pod AutoScaling
  • Yes
  • Yes
Types of Workloads
  • Microservices
  • Background Jobs & Cron
  • Data Processing*
  • MLOps*
  • Serverless*
  • Database
  • Operator Backed
  • Helm Chart
  • Git Repo
  • Container Image
  • Pipelines
  • Serverless
Workload Lifecycle Management
  • Tailor made end to end lifecycle management for each type of workload
  • Workflows built for engineer's day to day needs around managing their applications
  • Additional integration work to be done by developers for each type of application
  • Developers or Devops engineers need to have deep Kubernetes understanding and write YAML definitions to manage full lifecycle of their applications/workloads
  • In Gravity, Developers can manage entire lifecycle of an application/workload without any Kubernetes knowledge
  • Eg: For Microservices Workload, Gravity automatically integrates Autoscaling, Ingress, HTTPS Certificates, Config, Secrets, etc and developers do NOT have to write a single YAML definition
Backup & Restore
  • Control Plane Backup
  • Project/Workload specific Backup
  • Backup Scheduling & Policies*
  • Restore entire Cluster/Project/Workload to a previous state
  • Persistent Volume Backups*
  • Experience: Web based UI to create backups and restore
  • etcd Backup
  • Project/Application level backups
  • Restore entire Cluster/Project/Application to a previous state
  • Persistent Volume Backups
  • Experience: Command Line
  • Gravity employs modern GitOps based model that stores Cluster state & definitions in Git respositories. Additional Backups are maintained in Cloud Object Stores
  • OpenId Connect
  • Basic Auth
  • GitHub
  • GitLab
  • Google
  • OpenId Connect
  • RBAC, Service Accounts
  • RBAC, Service Accounts
  • Fully managed & Integrated with Cloud Secret Managers
  • Default K8s Secret
  • Cloud Secret Manager to be integrated by customer
  • Gravity out of the boxes uses Cloud Secret Managers (which are encrypted by default) as secret stores.
  • When Workloads need a Secret, Gravity automatically pulls secrets from external secret stores and makes them available as ENV variables with ZERO engineering effort from your developers of devops teams.
  • OpenShift requires additional engineering effort to integrate Cloud Secret Managers as external secret stores.
Cost Management
  • Cost visibility at Cluster/Node/Project/Workload level
  • Cost optimization recommendations
  • Unified Kubernetes & Cloud Service costs
  • Cost visibility at Cluster/Node/Project/Application level
  • Gravity provides cost optimization recommendations that be used to identify unused/overprovisioned Pods in your Kubernetes clusters and optimize your spends.
  • In addition, Gravity also integrates Cloud Costs along with Kubernetes Costs so that customers get an unified, comprehensive view of their costs
Cloud Service Provisioning
  • Use Gravity to provision Cloud Services such as Amazon S3
  • Many popular Cloud Services are already pre-integrated with the Kubernetes clusters provisioned through Gravity
  • Developers can deploy Cloud Services in one click
  • Platform Administrators and central Devops teams can use Gravity's buil-in catalog to govern Cloud Resources through custom plans & policies
  • Automatic Cloud Service Credential binding with workloads. Gravity automatically creates necessary IAM Service Accounts for workloads to connect to Cloud Services
  • Not provided natively
  • To be implemented by customers with significant additional engineering effort or use existing Infrastructure As Code tools (such as Terraform) and custom automation scripts
  • Gravity uses the latest emerging pattern of leveraging Kubernetes as control plane for provisioing Cloud Resources. Customers need not use additional tooling (such as Infrastructure As Code tools) or cloud provider specific tools to provision Cloud Resources. This allows organizations to drastically reduce custom tooling and embrace open source Kubernetes as the control plane for all infrastructure orchestration. This is very important factor for customers who want to save Integration efforts and costs and ship their products faster to market.
Observability (Logs, Metrics, Traces)
  • Unified Observability providing Logs, Metrics and Traces in a single dashboard
  • Engineers can troubleshoot quickly as logs, metrics and traces are available in a single place
  • Best in class stack using Loki, Prometheus, Jaegar, Tempo & PromTail
  • Uses Cloud Object Stores for long term storage to optimize costs
  • ElasticSearch + Kibana for Logs, Prometheus with in-cluster Persistent Volumes for Metrics, Jaegar + ElasticSearch for Traces
  • Needs additional ElasticSearch Infrastructure to be provisioned and managed
  • Expensive to operate
  • Developers need to use different tools and interfaces during troubleshooting
  • Gravity uses Kubnertes native stack for Observability components. Gravity has carefully engineered the Observability stack that is Kubernetes native, can scale and also remain cost effective. Gravity automates the entire provisioning and configuration of the stack which otherwise requires organizations to spend significant engineering efforts in conducting multiple POCs, benchmarks and integrations
  • Gravity's observability stack is also cost effective to store large volumes of data. Eg: Storing 1TB of logs costs roughly $50 in Gravity whereas 10X more in an ElasticSearch based setup (excluding human costs for operating the infrastructure)
Service Mesh
  • Opensource Istio
  • Based on Istio, custom mesh by RedHat
  • Yes, using ArgoCD. Offered by default
  • Requires Red Hat OpenShift GitOps Operator addon installation by customer
  • Gravity uses GitOps by default where infrastructure configurations and definitions are stored in Git repository. All definitions and configurations provided to the Gravity platform are stored in Git acting as the source of truth.
  • The Git repository always maintains the state of the clusters and workloads that are launched through Gravity. All historical changes are also always available in the Git repository so that trail of changes are visible and auditable.
  • Any manual changes done outside Gravity are automatically rolled back.
Container Scanning
  • Default Container Registry scanners
  • Clair
Vulnerability Management
  • Integrated and out of the box using Trivy
  • Container Security Operator to be installed to peform continuous scans fo container images
  • Needs expertise within your organization to install and configure the operator with support from RedHat
Continuous Governance and Compliance
  • Integrated and out of the box using Open Policy Agent / Gatekeeper. No additional installation/configuration to be done by you.
  • Compliance Operator to be installed additionally. Installation, compliance scans to be performed by you using command line tools
  • Needs expertise within your organization to install and configure the operator with support from RedHat
  • Gravity's customers can manage their Governance, Compliance Rules and Violations through a simple to use Continuous Governance application. Customers who are planning sizeable Kubernetes footprint on public clouds can govern both their Kubernetes and their related Cloud Infrastructure through a single unified Continuous Governance application.
* - Available in a future release of Gravity