Skip to main content

How it works

Tensor9 runs vendor software inside a virtual appliance living in the customer's cloud. Tensor9 does work behind the scenes to provide vendors and customers with a SaaS-like experience they are familiar with. Vendors deploy their code and infrastructure stack using familiar tools to their own cloud. Behind the scenes, Tensor9 continuously replicates the vendor's stack into the customer's appliance. Customers treat their appliance like an access point, sending requests to their appliance's private on-prem endpoint as if it were the vendor's public SaaS endpoint. The customer's on-prem experience has high fidelity to the SaaS experience they are familiar with.

In the customer's cloud​

The customer's appliance contains an isolated VPC that runs the vendor's code (including ML models), and is network isolated from the outside world. The vendor owns the keys to the hardware capacity inside the isolated VPC - so nobody else can access it: neither the customer nor Tensor9. The customer's requests are processed within this isolated VPC, which is secured by a firewall that inspects all data into and out of the isolated VPC. The customer controls the firewall's policy; data cannot leave the customer's appliance without their explicit permission.

The firewall as depicted here is actually another VPC, the control VPC, comprised of:

  • A network proxy that enforces a firewall policy controlling what data can enter and leave the appliance. Vendor software running in the isolated VPC has no external network access except through this network proxy. See Security and control.
  • An audit logger that creates an audit trail of data that leaves the appliance. Every byte the vendor's software sends externally through the network proxy is appended to the audit log. See Security and control.
  • A capacity manager that manages virtual machine capacity inside the isolated VPC. The capacity manager is responsible for scaling the appliance's capacity to match customer demand. See Capacity and cost management.

Notice that if the vendor's software needs to communicate with external services, the customer's firewall must explicit allow it. As always, every byte that egresses the vendor’s stack running in the appliance’s isolated VPC is appended to the audit log.

The customer accesses the vendor's software through their appliance's private endpoint, not the vendor's public SaaS endpoint. This is a clear trust signal to the customer that they are communicating with their private appliance, not the vendor's servers.

In the vendor's cloud​

A SaaS-like experience​

To provide vendors with a SaaS-like development experience, we introduced the concept of a facade.

A facade is a lightweight cloud resource living in the vendor’s cloud that reflects a real cloud resource living in the customer’s appliance. For a deep dive into how facades work, see Facades.

The vendor can deploy, update, configure, observe and delete a facade in their own cloud as if it was a real resource. Behind the scenes, Tensor9 does the work of reflecting cause and effect inside the customer’s appliance.

Tensor9 also mirrors the operational state (e.g. CPU utilization) of the real resource back to the facade. The facade mechanism provides vendors with a lever to influence, and a window to observe, a customer’s appliance without direct access. The end result is that vendor engineers can build and operate their software in a way that feels like the familiar SaaS experience they are used to.

A vendor can build facades for a wide range of software and infrastructure, including: containers, virtual machines, and cloud-native infrastructure (e.g. queues, buckets, databases). In all cases, the vendor's hosted facade is a lightweight resource of minimal cost. The real (more expensive) container, virtual machine or infrastructure resides in the customer's appliance in the customer's cloud account.

Deployments​

The simplest type of facade is a (Docker) container facade. A container facade running in the vendor’s cloud corresponds to a real container running in the customer’s appliance. A vendor engineer builds a container facade by running their real container through the Tensor9 CLI. This creates a container facade that embeds their real container. The vendor engineer can then deploy that container facade however they like (e.g. AWS CDK) and wherever they like (e.g. AWS Fargate). Doing so will deploy their container embedded in the facade to the customer’s appliance. This means that, to the vendor engineer, software deployments continue to work the same way.

To read more about container facades and to learn about machine facades and infrastructure facades, see Facades.

Observability and auto-scaling​

Tensor9 enables vendors to use familiar tooling to observe and capacity-manage the software and infrastructure running in the customer's appliance.

The stack running in the customer's appliance publishes metrics back to their corresponding facades (subject to the customer's firewall policy). Vendor engineers can then understand the operational health of the system by looking at metrics published by their own facade to their prefered observability tools (e.g. Grafana, AWS CloudWatch). The same pattern is used for log publishing (e.g. to New Relic, DataDog, AWS CloudWatch). An important consequence of this is that cloud-native features like auto-scaling continue to work, since the facades reflect the operational state of their real counterparts in the appliance (e.g. CPU usage).