Infrastructure sizing guide

Modified on Fri, 21 Aug at 9:44 AM

Infrastructure Sizing & Pricing Workbook:
Cubyts — Infrastructure Sizing and Pricing

Note: The Excel workbook is the source of truth for all infrastructure sizing, capacity, and pricing values. This document explains the sizing concepts and infrastructure model; numerical values are intentionally maintained in the workbook.

1. Purpose

The Cubyts Infrastructure Sizing Guide explains the infrastructure components required to deploy and operate Cubyts in a customer environment and describes the factors that influence the infrastructure footprint as adoption grows.

The guide is intended to help infrastructure, cloud, security, and platform teams understand:

  • What infrastructure is required to run Cubyts

  • What each infrastructure component is responsible for

  • How compute, storage, database, and networking requirements are determined

  • How the infrastructure scales as the Cubyts deployment grows

  • How to use the accompanying sizing workbook to determine the required capacity and associated cost

The accompanying Excel workbook is the source of truth for all infrastructure sizing values and pricing.

2. Infrastructure Sizing Model

Cubyts infrastructure is sized as a deployment-level environment rather than as an individually provisioned infrastructure stack for every workspace.

A deployment consists of a set of shared infrastructure services that collectively support the configured Cubyts workspaces.

The infrastructure footprint is determined by the expected workload and capacity of the deployment. The sizing model considers the following broad dimensions:

  • Application and processing workload

  • Number of workspaces supported

  • Data volume

  • Database requirements

  • Storage requirements

  • Network traffic

  • Backup requirements

The sizing workbook translates these requirements into a specific infrastructure configuration and corresponding cloud cost.

Therefore, the document explains the sizing approach, while the workbook provides the actual sizing recommendation.


3. Infrastructure Components


3.1 Kubernetes

The Cubyts application is deployed using a Kubernetes-based architecture running on the hyperscaler’s Compute resources.

Kubernetes provides the runtime environment for the Cubyts services and supporting workloads.

The sizing workbook maps this requirement to the appropriate managed Kubernetes service for the selected cloud provider.

The underlying Kubernetes implementation may therefore differ by cloud provider while serving the same Cubyts deployment requirement.

The Kubernetes layer also hosts supporting services required by the deployment.

3.2 Database

The database provides persistent storage for Cubyts application data.

Database sizing is an important part of the overall infrastructure model because database requirements grow with the amount of information managed by the deployment.

Database sizing is influenced by factors such as:

  • Number of workspaces

  • Volume of application data

  • Data growth over time

  • Data retention

  • Application workload

The sizing workbook specifies the database tier, capacity, and associated cost for the recommended deployment.

When the deployment exceeds the supported capacity of the configured infrastructure, the database must be evaluated and resized along with the application infrastructure.

3.3 Object Storage

Object storage is used for data that is better represented as objects or files rather than transactional database records.

The sizing model accounts for object storage used for activities such as:

  • Uploads

  • Exports

  • Other persistent file-based data generated or consumed by the platform

Object-storage requirements are primarily driven by the amount of data stored and its retention.

As data volumes increase, the object-storage requirement can increase independently of compute requirements.

3.4 Networking

Networking provides connectivity between Cubyts services and the systems with which it communicates.

The infrastructure model accounts for networking components required to expose and operate the deployment and to support outbound communication.

This includes considerations such as:

  • Load balancing

  • Network address translation

  • Outbound traffic

  • Connectivity to required services

Network requirements can change with application usage and data-transfer volumes.

The workbook captures the infrastructure and pricing assumptions associated with networking.

3.5 Backup

Backup infrastructure provides protection for the Cubyts deployment and its persistent data.

The sizing model treats backup as a separate infrastructure consideration because backup requirements are different from primary compute and storage requirements.

Backup capacity and cost are influenced by:

  • Amount of data being protected

  • Backup frequency

  • Retention requirements

  • Recovery requirements

The workbook includes the backup infrastructure associated with the deployment.

4. Supporting Platform Services

Observability and Logging

Observability and logging provide operational visibility into the Cubyts environment.

They enable platform teams to monitor the health and behaviour of deployed services and investigate operational issues.

The workbook specifies how observability and logging are provisioned for the Cubyts deployment.

Secrets Management

Secrets management is required to securely store and manage credentials, tokens, keys, and other sensitive configuration used by the platform.

The deployment uses the secrets-management approach specified in the workbook rather than treating secrets as application configuration.

Container Registry

The container registry provides storage and distribution for the application container images used by the deployment.

The infrastructure model assumes the use of the customer's existing container-registry capability.

5. Cloud Provider Model

The Cubyts sizing model supports deployment on multiple cloud providers.

The same logical Cubyts infrastructure requirements are mapped to the corresponding managed services available from the selected cloud provider.

The purpose of this approach is to maintain a consistent Cubyts deployment architecture while allowing the customer to use its preferred cloud environment.

The workbook contains the provider-specific infrastructure configuration and pricing.

6. Capacity Model

Cubyts infrastructure is provisioned to support a defined deployment capacity.

The capacity model establishes a relationship between:

Deployment → Workspaces → Workload → Infrastructure Capacity

A deployment is initially sized for a defined number of workspaces and an associated workload profile.

As adoption increases, the infrastructure may eventually reach the capacity supported by the original configuration.

At that point, the deployment should be re-evaluated rather than simply continuing to add workspaces to the existing infrastructure.

This approach allows infrastructure sizing to remain aligned with actual platform demand.

7. What Drives Infrastructure Growth?

Infrastructure requirements are primarily influenced by the scale and activity of the Cubyts deployment.

Workspace Growth

Adding workspaces increases the amount of platform data and activity managed by the deployment.

Workspace growth can therefore influence:

  • Application workload

  • Database growth

  • Storage consumption

  • Processing requirements

Data Growth

As more data is collected and retained, persistent storage requirements increase.

Data growth can affect:

  • Database capacity

  • Object storage

  • Backup capacity

Processing Growth

Higher processing activity can increase compute requirements.

Examples include increased:

  • Data processing

  • Background activity

  • Platform operations

  • Concurrent workload

Network Growth

Higher levels of data movement can increase network requirements, particularly when the deployment exchanges larger volumes of data with external systems.

8. Scaling the Deployment

Cubyts infrastructure should be scaled when the workload approaches the capacity of the existing deployment.

Scaling should be considered when there is sustained growth in:

  • Number of workspaces

  • Data volume

  • Processing activity

  • Storage consumption

  • Database utilization

  • Network traffic

Scaling does not necessarily mean increasing every infrastructure component by the same amount.

For example:

  • Compute may need to scale because of increased processing demand.

  • Database capacity may need to scale because of data growth.

  • Object storage may need to scale because of increased file retention.

  • Network capacity may need to scale because of increased data transfer.

The appropriate scaling decision should therefore be based on the component whose capacity is being constrained.

9. When to Revisit the Sizing

The infrastructure sizing should be revisited when there is a material change in the expected deployment profile.

Typical triggers include:

  • Onboarding additional workspaces

  • Significant repository or data growth

  • Increased platform usage

  • Increased processing volume

  • Changes to data-retention requirements

  • Changes to backup requirements

  • Changes in deployment architecture

  • Migration to a different cloud provider

  • Changes in enterprise networking requirements

The sizing workbook should be updated or re-evaluated when these conditions materially change the original assumptions.

10. Using the Infrastructure Sizing Workbook

The accompanying Excel workbook should be used to determine the actual infrastructure configuration and cost for a Cubyts deployment.

The workbook provides the numerical details that are intentionally not duplicated in this guide, including:

  • Infrastructure capacity

  • Resource sizing

  • Database configuration

  • Storage requirements

  • Cloud-provider-specific configuration

  • Monthly infrastructure cost

  • Annualized cost

  • Engagement-period cost

  • Workspace-level cost calculations

  • Capacity assumptions

The guide should therefore be read together with the workbook.

11. Infrastructure Cost Model

The infrastructure cost is calculated from the resources required to operate the deployment.

The major cost categories are:

  1. Compute

  2. Networking

  3. Object storage

  4. Backup

  5. Database

Each cloud provider may have different pricing for the underlying infrastructure services.

The workbook therefore provides the provider-specific cost calculation rather than embedding cloud pricing in this document.

This separation also makes the sizing model easier to maintain as cloud-provider pricing changes.


12. Infrastructure vs. AI Cost

Infrastructure sizing and AI consumption are treated as separate cost categories.

The infrastructure sizing model covers the resources required to host and operate the Cubyts platform.

AI model consumption is a separate cost consideration associated with the use of AI models by the platform.

Accordingly:

Infrastructure cost = platform hosting footprint

AI cost = model consumption

The AI component should therefore be evaluated using the separate AI costing model rather than incorporated into the infrastructure sizing numbers in this guide.

AI Cost model reference: https://support.cubyts.com/support/solutions/articles/80001220940-ai-consumption-cost-model-for-cubyts

13. Summary

The Cubyts infrastructure sizing model is based on a deployment-level capacity approach.

The deployment consists of:

  • Compute

  • Kubernetes

  • Database

  • Object storage

  • Networking

  • Backup

  • Supporting platform services

The required capacity is determined by the expected workload and deployment scale.

As the deployment grows, individual infrastructure components may need to be scaled based on their respective capacity drivers.

The Infrastructure Sizing and Pricing workbook is the authoritative source for all numerical sizing, capacity, and cost information.

This document provides the conceptual framework for understanding those numbers and should be used alongside the workbook when planning a Cubyts deployment.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article