Skip to main content

Container type and replicas

This guide explains the available options for scaling your application to meet your performance needs. We offer two primary methods to scale your application:

Container Type​

You can upgrade or downgrade the container type at any point during the existence of your application. To do that, go to the Capacity tab (in the app view) and look at the section "Container Type".

Container type

Each tier varies its resources, mainly CPU and RAM and you can upgrade or downgrade. You can switch between the different container types. After selecting the desired option, a confirmation pop-up will show up.

Availability​

Generally, the changes will happen immediately without restarting the container, but if our load distribution algorithm determines that there's a better physical machine for your container with the new settings, your container will be restarted.

Cost​

Please note that each container type has its unique hourly price. When you change the type, you'll be charged for that new price starting the hour you changed the type.

Replicas​

Another way to scale your app is by allowing multiple replicas running at the same time. When you have more than one instance of your app running, Inteleto will automatically deliver the requests to have an even distribution of resource utilization across your instances, while automatically detecting unhealthy containers, preventing traffic from going to them, and replacing or restarting them.

To change the number of replicas, go to the Capacity tab (in an app), and look at the Replicas section.

Replicas

Basic I container type limitation​

Note that applications using the container type Basic I cannot have more than one replica.

Zero-downtime deployment​

To have zero-downtime deployments, you must have at least 2 replicas. This way, we can apply the update (deploy) to the first one, while the requests are redirected to the second one. This is ideal for the end user, since they won't have their interaction interrupted. For production applications, this option is highly recommended.

High availability​

To have high availability, you must have at least 3 replicas. The availability is highly increased because once you have at least 3 replicas, all of them will be running in separate physical machines, highly decreasing the possibility of a service interruption. Another benefit of that scenario is that 2 of your instances could fail, and you'll still serving users requests. This can happen if, for example, one instance is updating, the other one is overwhelmed by some report generation, and the third one is available.

Availability​

Changing the number of replicas (both increasing and decreasing) will never restart or cause downtime to your application.

Cost​

Once you change the number of replicas, the actual effect is that you'll have <number of replicas> containers of the type you selected running at the same time, so the final hourly cost will be <container type hourly price> * <number of replicas>, effective from the hour you applied that change.