Runtime types in Transfer

DoubleCloud allows you to select a runtime configuration for each transfer to adjust it for your needs. It offers two runtime types:

• Serverless

• Dedicated

Both these runtime types are scalable and you can configure their performance for your data amount. The main difference between them is that the serverless runtime is designed to transfer data from the external networks, and the dedicated runtime allows you to transfer data between the resources in isolated networks with peering connections.

Serverless

The serverless runtime fits for the transfers you perform from the sources that are available from the internet. This means that these resources shouldn't be located in isolated networks. The sources in this case might be on-premise databases, object storage buckets, and other data stores.

When you select this runtime type, the computational capacities are allocated in the DoubleCloud own pool. You can specify up to 8 instances targeting the same database and up to 10 processes for each instance to configure the transfer performance.

The Number of operations setting is designed to handle Apache Kafka® sources and sets the number of workers. Each worker in this case can copy multiple producers.

Dedicated

The dedicated runtime allows you to transfer data from the resources located in other cloud providers' networks. These resources include Amazon Redshift and managed databases in the RDS and Aurora services. This runtime is more secure since you need to establish a peering connection between another cloud provider's network (such as AWS) and DoubleCloud networks.

This runtime type is more resource-intensive than the serverless one. Each time you run a Transfer with this runtime, the service allocates a separate virtual machine in a VPC. You can select the network manually or allow the service to set the network automatically based on the target resource location.

When you select this runtime type, you can set the virtual machine performance for the dedicated instance. The following options are available:

• Tiny: 2 vCPUs (burstable instance)

  Tiny instances are ideal for scenarios where a transfer is typically idle

  They have 20% baseline performance, and the ability to burst to the maximum performance isn't guaranteed.

• Small: 2 vCPUs

• Medium: 4 vCPUs

• Large: 8 vCPUs