FAQ
General
Managed Kubernetes services such as EKS/AKS/GKE solve the infrastructure challenges that come up with operating Kubernetes clusters. These include creating and managing the Kubernetes control plane, K8s version upgrades, patching, Virtual Machine provisioning, etc.
However, as a developer if you are to deploy an application in such a managed K8s environment, you still need to understand K8s in depth. These include creating Kubernetes Pods, managing configs and secrets for your containers, scaling, performing no downtime deployments, deploying and managing a service mesh, integrating cloud services, wiring observability, etc.
You will also have to take care of security and compliance of your Kubernetes workloads and infrastructure, enforce governance policies, etc.
Gravity provides a platform where developers can deploy their apps (such as microservices) to Kubernetes without the need to learn Kubernetes. DevOps and platform teams can offer a self service platform to developers while they can enforce security, compliance and governance centrally in the platform.
Based on our past experience in managing Enterprise Grade Kubernetes environments, creating such a platform would require a team of seasoned Kubernetes experts working for 9-12 months to create a baseline version of the platform.
Gravity can accelerate your Kubernetes adoption and get you ready for Day 2 operations in less than a day.
Terraform scripts and Helm charts help in automating regular infrastructure activities such as provisioning, configuration updates. However Gravity is a platform that goes beyond just infrastructure automation and provides:
- Self Service experience
- Workflows that eliminate the need for someone to have deep expertise in Kubernetes
- Observability for workloads
- 1-Click integration for workloads with Cloud Services
- Security capabilities such as Role Based Access Control, Single Sign On
- Governance for Kubernetes and Cloud Services
- Cost visibility & management
A Terraform / Helm Charts based automation does not provide such a platform but rather focuses on automating regular activities performed by DevOps teams.
No. Here are the main reasons:
- Gravity doesn’t provide a custom Kubernetes distribution. Gravity runs on top of Managed Kubernetes Services of Cloud Providers such as Amazon EKS, Azure AKS and Google’s GKE
- You have full access to the Kubernetes infrastructure created through Gravity. They are provisioned within your Cloud Accounts
- If you decide to stop using Gravity (though we will not be quite happy about it), you can simply take all the manifests generated by Gravity and you can continue to manage them by yourselves
Gravity currently supports AWS. Support for Azure is currently under development and Google Cloud is in our immediate roadmap.
We currently do NOT support on-premise K8s clusters. This is in our roadmap.
Red Hat OpenShift primarily targets DevOps teams where OpenShift takes care of managing the Control Plane and automating many of the Kubernetes operational aspects. OpenShift is a custom Kubernetes distribution and users of OpenShift need to understand Kubernetes in depth to be able to use the platform.
However Gravity is a full fledged developer platform that makes it very easy for developers to deploy to Kubernetes without knowing Kubernetes at all. DevOps teams can offer a self service experience to developers while having control to centrally implement security, compliance and governance.
A detailed comparison between OpenShift and Gravity is available here: https://invisibl.io/resources/openshift-vs-gravity/
Workloads
Gravity currently supports running Microservices workloads. We are currently building support for Background Workers. Support for Serverless, Data Analytics and MLOps are in our immediate roadmap.
Gravity comes with pre-built workflows to deploy and manage your Microservices based applications. Gravity provides the following capabilities for your Microservices based applications:
- Pre installed, fully configured and ready to use Istio Service Mesh
- End to end Observability for your Microservices - Logging, Monitoring and Tracing
- Pre configured Grafana dashboards that provides immediate access to your Microservices’ Logs, Metrics and Traces
- Built in Configuration and Secrets Management (integrated with Cloud Secret Stores)
- AutoScaling and fine grained resource management of your Microservices containers
- External event (such as a Queue, Kafka) based Auto Scaling
- One click provisioning of Cloud Services (such as AWS DynamoDB, Google CloudSQL)
- Automated Kubernetes Service Accounts to securely connect your Microservices to Cloud Services
- Automatic TLS certificates and DNS record management for services that are exposed to the internet
- Perform no downtime deployments through built-in Deployment Workflows. Support for different types of deployment strategies - rolling, Canary, Blue/Green
You can configure your Microservices to automatically scale based on varying demand. Gravity offers several different ways of Auto Scaling:
- Metrics Based: You can scale your Microservices based on metrics such as CPU, Memory.
- Schedule Based: Based on a schedule, you can have your Microservices automatically scaled and ready to meet peak demand (such as every day evenings 6-9PM).
- Event Based: Microservices can be automatically scaled based on events from other sources. For example, automatically scale whenever a queue depth/length increases or lag in a Kafka topic.
Yes. You can connect your existing domains in Gravity. Once connected, whenever you deploy your workloads, Gravity will automatically create and manage DNS records.
Gravity by default uses Lets Encrypt to issue TLS certificates for workloads. In addition, Gravity can be configured to use alternate certificate providers such as AWS Certificate Manager. We constantly add support for additional certificate providers based on customer requests.
There are two choices:
- Edit the Workload configuration manually and provide the container image tag
- If you enable Continuous Deployment for your workload, Gravity will automatically deploy any new image that is pushed to the container repository
Note: Both the above choices expect you to have pushed a new container image tag into your container repository
Workload Versions allow you to maintain multiple versions for the same Workload. For example, you could have v1 and v2 versions for the same payments microservice. You can use Workload Versions to test out new features/changes and perform canary deployments for your Workloads.
Here are the high level steps:
- Create one or more versions of your Workload
- Edit the Ingress that’s attached to your Workload. If you do not have one, create a new ingress
In the ingress configuration, select Route as “Split”. In the Split configuration, mention the percentage split of traffic between your versions.
Configs & Secrets
You can maintain configurations for your Workloads centrally in Gravity through Configs and Secrets. You can add one more Key-Value pair in Configs & Secrets. Use Configs for non-sensitive configurations and Secrets for sensitive ones (such as Database credentials, API Tokens).
In the workload configuration, you can add one more Configs or Secrets. You can have Configs and Secrets available as:
- Environment Variables in your Container
- As a file at a mount path in your Container
Secrets that you create in Gravity are directly stored in an underlying Secret Store that you select. Gravity currently supports Secret Stores offered by Cloud Providers such as AWS Secrets Manager.
Secrets are by default encrypted by the Secret Stores offered by Cloud Providers. Both in-transit and at-rest encryption is by default.
Yes. You can import your existing secrets stored in Cloud Secret Managers through the Import Secrets feature available in Gravity. Imported secrets can be later connected to your workloads just like secrets created through Gravity.
Observability
Many organizations today use multiple tools for Observability. Logs, Metrics and Traces are collected and stored in different tools and troubleshooting a production issue requires engineers to switch between them.
Gravity’s Unified Observability provides a single dashboard where Logs, Metrics and Traces are all unified. Engineers can use one single dashboard for troubleshooting their applications.
Gravity’s Observability stores observability data directly in a combination of Cloud Object Stores and time series datastores. This results in significant cost savings when compared to running dedicated server fleets (such as ElasticSearch clusters) to store observability data.
No. Gravity automatically ships observability data from your Workloads. All necessary plumbing is taken care of by Gravity.
In addition to Gravity’s default Grafana based dashboards, we are constantly evaluating integrations with other popular observability tools. Please reach out to us and we would be happy to understand your use cases and integrate.
Cloud Services
When your Kubernetes Workloads needs to connect to a Cloud Service (such as Amazon SQS or Amazon S3), Gravity securely provides the required credentials. Gravity automatically creates required Kubernetes Service Accounts and Cloud IAM Roles.
Yes. Through the built-in Cloud Service Catalog, you can provision Cloud Services in 1-click.
Gravity offers a built-in Cloud Service Catalog. This is a custom catalog that can be populated with the Cloud Services that you wish to offer to developers within your organizaion. For each Cloud Service that you onboard, you can create different “plans” that pre-configures how a Cloud Service is provisioned.
When you onboard a Cloud Service (say, Amazon RDS), you can create multiple plans that enforces policies in your organization. For example, you can have a “Production RDS” plan that has encryption turned on by default while a “Development RDS” plan restricts developers to provision only t3.medium instance types.
Yes. You can bring your existing Cloud Services through “Import” feature. Imported Cloud Services can later be connected with your Kubernetes Workloads in 1-click and Gravity will take care of all the plumbing for securely providing required credentials to your workload.
Support
Yes, we provide 8 * 5 (Mon-Fri, Business Hours) technical support through our team of in-house Kubernetes experts. You can reach technical support through Email, Chat, Phone
Our technical support engineers will be available to help you address any technical issues that you are experiencing in accessing and using the Gravity platform. These include:
- Issues with the Gravity platform console and any other tools provided by Gravity
- Operational issues with respect to the Kubernetes clusters and apps deployed through Gravity
- How-to questions about Gravity platform and Kubernetes
- Best practices to successfully use Gravity and Kubernetes for your workloads
- Custom code/app development
- Troubleshooting application/workload related issues
- Performance tuning / optimization of apps, databases and any other components of your stack
- Debugging any third party / custom software
Support is currently included as part of the pricing. There are no additional charges.
Pricing
You can see all the pricing plans available here: https://invisibl.io/#pricing
Yes. We offer a generous free tier that is not charged upto 50 vCPUs per month.
Yes. We offer discounts when you sign up for annual contracts.
Support is currently included as part of the pricing. There are no additional charges.
Professional services are charged based on the scope of work. We would provide the costs as part of the professional services contract.
Professional Services
- Build customization of certain features of Gravity to suit your organizational needs
- Extend Gravity through custom integrations with your existing tools and software (such as authentication systems, delivery pipelines)
- Perform one time activities such as security audits, infrastructure hardening (beyond what’s provided by default)