Getting Started

Getting started with your BYOC environment

Introduction and benefits

Running Altinity.Cloud in your cloud provides the convenient cloud management of Altinity.Cloud but lets you keep data within your own cloud VPCs and private data centers, all while running managed ClickHouse® in your cloud account. We sometimes call this Open Cloud for ClickHouse. There are Kubernetes clusters that contain ClickHouse clusters running in your cloud account; those are called Altinity.Cloud environments.

This approach has several important benefits:

  • Compliance - Retain full control of data (including backups) as well as the operating environment and impose your policies for security, privacy, and data sovereignty.
  • Cost - Optimize infrastructure costs by running in your accounts.
  • Location - Place ClickHouse clusters close to data sources and applications.
  • No vendor lock-in - Disconnect the control plane at any time and continue operating ClickHouse using open-source components.

No matter where or how you’re running Altinity.Cloud, the Altinity Cloud Manager UI manages your environments. You can control multiple environments from the same Altinity.Cloud account and can mix and match environment types. No matter what environment you’re in, ClickHouse management works the same way.

Open-source analytic stack

Altinity.Cloud uses open-source software for the analytic stack and selected management services–the Altinity Kubernetes Operator for ClickHouse, Loki, Prometheus, and Grafana. The following diagram shows how the principal components map to resources in AWS. (GCP is essentially identical.) Open-source components are in dark blue rectangles.

Altinity.Cloud Management Plane
Figure 1 - The open-source analytic stack

Users can terminate the service, disconnect the Altinity.Cloud environment from Altinity.Cloud, and run ClickHouse services themselves. There is no migration, since all data, software, and support services are already in the user’s Kubernetes cluster. The only component not in the Kubernetes cluster is the management plane.

Service architecture

The Altinity.Cloud service architecture consists of a shared management plane that serves as a single point of management for all tenants and a data plane that consists of isolated environments for each tenant.

The key component is the Altinity Connector. Altinity Connector is a secure management channel between Altinity.Cloud and the managed environment. It is deployed inside Kubernetes, dials back to the management plane and enables Altinity Cloud to manage ClickHouse and infrastructure components. An important property of Altinity Connector is that it only establishes an outbound connection, which pleases corporate Infosec teams.

The basic model looks like this:

The basic Altinity.Cloud service architecture
Figure 2 - The basic Altinity.Cloud BYOC service architecture

Altinity.Cloud uses a VM-based approach on AWS. It provides the best isolation between Altinity and user account, with the VM serving as a secure bridge between two. It can be deployed using a CloudFormation template that sets an EC2 instance up and sets up the Altinity Connector. Altinity.Cloud does not have direct access to the user’s account in this case; all management operations are routed via this EC2 instance.

Here’s the architecture diagram for AWS:

The Altinity.Cloud BYOC service architecture for AWS
Figure 3 - The Altinity.Cloud BYOC service architecture for AWS

The other approach requires users to grant an Altinity Cloud service account direct access to the user’s cloud infrastructure. It works well in GCP, where it is easy to create a dedicated new project and manage security on the project level.

Here’s the architecture diagram for GCP:

The Altinity.Cloud BYOC service architecture for GCP
Figure 4 - The Altinity.Cloud BYOC service architecture for GCP