Overview

This article will help you understand how Ternary Self-Hosted is implemented and describe what your team will need to take care of for a successful initial and ongoing deployment. When done correctly, Ternary Self-Hosted provides all the benefits of Ternary on the public internet, but housed within your own Google Cloud Platform projects, in agreement with your enterprise security policies, and with exclusive access to only your organization.

What is Ternary Self-Hosted?

Ternary Self-Hosted refers to deploying a complete Ternary stack into a separated space from Ternary's main SaaS operations. That could either be a dedicated project maintained by Ternary or contained within your own Google Cloud organization. After deploying Ternary Self-Hosted, you will have private access to the full capabilities of the Ternary platform, and continue to enjoy frequent feature updates on a cadence similar to our mainline product.

Self-Hosted is an ideal solution for customers who have strong security requirements, wishing to guarantee that data exfiltration cannot occur from the Ternary platform, or to guarantee a stronger air gap between the world and your private organization's data.

The rest of this article will describe what setup will look like if your organization chooses to adopt Ternary via self-hosting. For pricing information, please contact Sales.

Architecture Overview

Ternary Self-Hosted requires 2 Google Cloud projects to operate, Core and Access. Core will contain most of the components of the solution, including BigQuery datasets, Cloud Run / Kubernetes based container workloads, a Cloud SQL instance, and more. The Access project is mainly used to centralize IAM identities used to access your cloud resources and is the project from which BigQuery jobs will be launched against the data assets in Core. In total, we use the following services:

• BigQuery
• Cloud Tasks
• Cloud Scheduler
• Cloud Firestore
• Cloud Logging
• Cloud Storage
• Cloud DNS
• Cloud Memorystore (Redis)
• Cloud Pub/Sub
• Cloud SQL
• Compute Engine
• Kubernetes Engine
• Secrets Manager

Ternary requires Owner access to perform Terraform provisioning within the two projects. After the provisioning has taken place, our owner access can be removed until the next time Terraform updates are required.

Provisioning Steps

Create projects and networks

Create two Google Cloud Platform projects, preferably in a folder within your organization dedicated to Ternary. You can name them ternary-core-123456 and ternary-access-123456 (replace the 123456 with suitable nonces.)

Grant [email protected] Owner access to the folder (or the two projects), then supply Ternary with the newly created project IDs and project numbers. Additionally, if any VPN access is required to access Google APIs for your projects, then please supply Ternary with a VPN account. For best service, it's highly recommended to be able to assign multiple Ternary employees VPN access.

For Kubernetes Engine usage, Ternary will need access to a network, a subnet and secondary subnet assigned. If Ternary owners are not allowed to create the network and subnetworks, then Ternary will need someone from the networking team to assign us a subnetwork and secondary subnetwork. After this is provisioned or otherwise arranged, Ternary will be able to create the cluster with Terraform. If there are special instance types or regions that you would like us to use, please let us know.

Consider VPC Service Controls / Restricted Domains

If your organization requires the use of VPC Service Controls, please create the rules necessary for Ternary to host an internal web application service within the Core projects, and allow both projects to access the Google Cloud services listed in the Architecture Overview section, possibly through Private Google Access. We at Ternary should also have the ability to connect to this web app through our browser, possibly through a client VPN, so we can ensure that your system is in good working order at all times.

If your organization uses Restricted Domains, then please add the Ternary Google Workspace organization identifier: C01kf7ryi to your allow list. This is preferred to allow us to use our terraform@ service account identity to perform automation operations within the projects, however, if this is not permitted, we can use a different cloud identity within your organization to perform automation operations.

Decide on how to provide ingress functionality

Create a subdomain that Ternary will be able to access and use for your environment. For example, ternary.mycompany.com. Provide access to change the value of this record, or a resource within your team who can manage DNS updates, according to the needs below.

We will provision a HTTPS Load Balancer. If you would like that load balancer to have a corporate SSL certificate and use corporate IP space, please make sure that the Core project is joined to your corporate Shared VPC and that Ternary has access to the private and public parts of a SSL certificate that matches the subdomain you create. Additionally, if there are any other security considerations pertaining to network firewalls or web-application firewall, please discuss these matters with our Customer Success team prior to implementation.

Decide how to take updates

If it meets with your security requirements, we can grant you access to our CI/CD automation bot [email protected] so that your Ternary instance can be included in our weekly deployments. If this is not acceptable, we can run manual updates at a lower cadence (monthly by default.)

Note that these software updates will be deployed via a Helm chart repository and container images that will be accessible to your organization.

Billing considerations

While Ternary will make a best effort to deploy Ternary Self-Hosted in a way that is cost conscious and FinOps aware, ultimately, the costs of deploying this solution are your responsibility. We recommend the typical FinOps practices of assigning a budget to the Ternary operating stack once you understand what the daily / weekly run rate would be, so that surprises can be caught. And of course, you would be able to review the spend of Ternary Self-Hosted within the platform instance itself, once provisioned.

Depending on the size of your monthly cloud bills and quantity / complexity of connected accounts, here is some very general guidance on the retail rates of operation, given NO rate optimization:

• $1MM monthly of spend or below: $1,000 USD or less per month
• $1MM-$5MM of monthly spend: $3,000 USD or less per month
• Above $5MM of monthly spend: $5,000 USD or more per month

Aligning Ternary Self-Hosted with your existing rate-optimization policies will greatly impact the final cost numbers:

• Purchasing resource based or spend based commitments so Ternary's footprint can benefit from discounted usage, or aligning the instance types in your Kubernetes Engine to the resource based commitments that your organization already owns.
• Purchasing BigQuery annual slots on a 1 year or 3 year basis for Ternary to use, or allowing Ternary to consume already purchased slot capacity within your organization.