Skip to content

FAQ

How much flexibility will I have for customization?

As we started working on Omnistrate, one of the core tenants was to allow our customers to extend and customize their control plane combined with best practices so that they don't have to reinvent the wheel again and again on this.

  • Our architecture is completely plugin based such that you can inject custom code at different phases of the control plane operations.
  • Extend your control plane operations outside of Omnistrate as you have the full infrastructure control.
  • We are completely based on open standards.
  • 200+ APIs to customize your SaaS

We also have customers in production including public companies who have thoroughly evaluated and tested our architecture. If you have a specific question or concern, we will be happy to jump on a call and help clarify.

We have built dozens of successful cloud services across domains and clouds at AWS, Confluent, and Microsoft. We have used our experience to build a general-purpose SaaS control plane platform that agnostic of any application and scales across different SaaS dimensions like clouds, regions, tenancy models, environments and so on.

What does your operating model looks like?

Our vision is to remove the barrier for entrepreneurs and enterprises alike to create their own SaaS businesses. Hence, its paramount for us to fully empower you with all the power and flexibility without requiring any properietory information to make it an easy decision. More specifically:

  • We don't require any access to your customers OR your data OR your software
  • No access or secret keys required. We worked on fine grained permissions that you can revoke at any time
  • We serve you directly and not your customers. Think of us as any other SaaS vendor like Zendesk, PagerDuty or Hubspot but just focussed on helping you build and operate your SaaS

Whats the responsibility model looks like?

For control plane, we take the full responsibility all the way from design choices, preventive measures to operational support.

To be more specific, our SaaS control plane architecture is resilient:

1/ decoupled from data plane 2/ per region separation avoiding single point of failure.

We have inbuilt safe retries for every control plane operation. If we can't recover, we provide full end-to-end support on the control plane issues with enterprise SLA. In addition, all the user activity will be audited and provide access control (RBAC) for your teams to grant fine-grained privileges. For more on this, please visit this page.

For your application, we have monitoring at different levels across process, pod, machine, network/AZ levels. We do basic recovery from restarting the process, replacing infrastructure etc. For more on this, please visit this page. If we still can't recover, we will alert you with relevant debugging information, metrics and logs.

If you have any other specific questions, please reach out to us at support@omnistrate.com

How do I integrate with Omnistrate if I already have some version of a control plane?

Please see this page

Do you have all the integrations I need?

We are adding new integrations as quickly as we can. If you need a specific integration that’s not supported yet, you can request it by contacting us, or simply create it yourself.

For the list of supported integrations, please see this page

How does the pricing looks like?

We have usage-based pricing and you only pay for what you use. Contact us for any questions on pricing.

In addition, we offer 2-weeks period to evaluate our product in your account or your customers' account at no cost.

How long does it take to get started?

You should be able to signup and configure your account in a few minutes. If you already have a docker compose, you can simply follow our compose extensions to complete your compose spec.

If you don't have a compose spec or prefer to follow our API, please see this

Does my data get sent to your servers?

Only what you choose to send.

The data plane (aka your application) runs on your infrastructure or your customers' infrastructure. For-example, when your customers interacts with your application, none of the data is sent to us or even run goes through our infrastructure unless you deploy your application in Omnistrate Hosted mode.

We only receive encrypted metadata needed to serve your control plane operations, and any data you choose to display on observability dashboards.

Can non-coders use this product?

Yes - as long as you can build compose YAML and know the product requirements, you can create your SaaS without any coding background.

Do you support any on-prem environment?

Currently, we support major cloud providers. However, our architecture is extendable to on-prem environments and continuously working with a few partners to extend our offering. Please contact us for more details and we would love to discuss more

What's your execution environment?

We use K8s underneath the scenes but easily extendable to non-K8s environment.

I have my own operator, can I integrate with Omnistrate?

Please see this page

I have my helm charts, can I integrate with Omnistrate?

We are working on extending the helm support, please reach out to us at support@omnistrate.com for more details

Do you have any standard compliance? Does it mean we will also be compatible?

We are SOC2 type I/type II compliant. We are looking to extend it to other standards.

If you have other needs, please reach out to us at support@omnistrate.com for more details

Yes - by definition, your control plane will also be compliant. While we help accelerate your compliance for your SaaS, you will still need to establish compliance for data plane and corresponding infrastructure, internal processes, and team.

How do you ensure reliability of my SaaS during major disaster?

We have a decoupled design to avoid any cross-region dependencies for your SaaS control plane. In addition, we take constant backups to protect any necessary metadata.

Please contact us if you have any specific questions.

How are you different from writing my own K8s Operators?

K8s Operators are great mechanisms to automate some of the control plane aspects. In-fact, if you already have an operator and looking to build your end-to-end SaaS, please see this page

However, it's important to recognize that having a K8s operator represents a first step towards building SaaS:

  • Restricted to 1 K8s cluster: You'll need separate components to orchestrate or bin-pack tenants/resources across multiple K8s clusters as you scale.
  • No infrastructure management: Infrastructure management must be automated separately or integrated with the Operator itself.
  • Failure handling: In the distributed systems, dependent services can temporarily fail. Operator is one giant control loop with no structured way to handle failures.
  • Limited visibility and control
    • No fine grain visibility into step by step execution
    • No native support to pause or resume new rollouts in case of issues
  • Service evolution and upgrades
    • Operator complexity for upgrading stateful systems
    • Evolution can become slow if it requires operator deployment
  • Coupled architecture: Introduces coupling between the control plane and data plane, and can lead to cascading failures if not managed carefully
  • Maintenance burden: Custom operators require ongoing maintenance and updates

Furthermore, K8s operators lack several essential features crucial for SaaS, including UX enhancements, metering, billing, serverless autoscaling with scale down to zero, comprehensive monitoring beyond pod failures, auto-recovery of infrastructure failures, advanced patching across the entire fleet (images, OS, infrastructure, configuration), cloud-native capabilities, automated operations, compliance measures, developer productivity tools, integrations, access control, and more. For further insights, please visit this page.

How are you different from Terraform?

Infrastructure provisioning and management is one of the things that we do among several things.

We think that Terraform is an excellent IaC tool if you want to setup your cloud infrastructure. It provides you a programmatic way to build infrastructure that can be replicated across regions. However, when it comes to SaaS, we feel that it falls short on many grounds:

  • SaaS deployments: If you have a need to deploy infrastructure per tenant, you will have to manage multiple state files, which is a big challenge.
  • Deploying across accounts: There is no support to manage different accounts for deployments natively
  • No Day-2 Infra support: Terraform is just limited to provisioning the infrastructure and leaves the big part of operating the infrastructure (from patching, monitoring, alerting, capacity planning, failure handling to evolution) to the owners
  • Multi-cloud support: Terraform requires manually creating and maintaining scripts for every cloud provider. Every time, there is any change, you have to manually update all the terraform scripts, run them appropriately across thousands of state files manually, handle any issues and manually fix them. At scale, this becomes quite unmanageable. In our previous experiences, we gave up on Terraform within a few months as we realized that it doesn't work at scale for SaaS use-case.
  • Not ACID compliant:
    • Not Atomic: In the case of any error during the apply phase, Terraform leaves the infrastructure in a broken state and leave it to DevOps to perfrom manual recovery. For SaaS with thousands and millions of tenants, this can be quite challenging. does not automatically rollback to the previous state. This may leave the infrastructure in a partially provisioned state.
    • Not Consistent: Due to the lack of basic recovery mechanisms, Terraform can leave the underlying infrastructure in an inconsistent state
    • Not Isolated: There is no built-in mechanism to run Terraform commands concurrently on the same state files. If two team members try to apply changes at the same time, they might face conflicts or undesirable outcomes. To avoid this, you will need to implement a state locking mechanism or follow certain operational practices.
    • Not Durable: By default, the state files are kept local and require explicit mechanism to store them durably for each tenant.
  • Drift Detection: Terraform struggles with drift detection, which means understanding if the actual state of resources has changed outside of Terraform since the last terraform apply. Terraform can refresh its state file before making changes to help mitigate this, but unexpected changes can still cause problems.
  • Manual: Operating with Terraform requires learning a new language, HCL (HashiCorp Configuration Language) and the learning curve for modular approach to manage large deployments is steep. Moreover, HCL is missing some of the common primitives. As an example, HCL lacks support for basic conditional logic, which can make complex configurations a challenge.
  • Performance issues: With large environments, Terraform can become slower to plan and apply changes.
  • Error handling: Terraform can be somewhat vague in the errors it produces, making it hard to debug complex scripts.

Omnistrate attempt to address the above IaC gaps for SaaS by providing a fully-automated solution. For more details, please see this page