Skip to main content

Rightsizing

When migrating infrastructure to the cloud, choosing the correct size of the target cloud instances is an important task, as the machine size is a dominating factor in the final cloud costs. Choosing an instance which is too small to handle the workload will result in slow or even unresponsive applications while an oversized instance will increase cloud costs while being idle most of the time. In Txture, the rightsizing features are integrated in the computation of the Cloud Proposals in the Target Architecture section of the Transformation Cockpit and in the Business Case Builder.

The settings for rightsizing are included in the Target Architecture Preferences. There are multiple options to rightsize instances:

  1. Directly based on the scaling factors.
  2. Based on the scaling factors and an additional positive or negative margin.
  3. Using the overriding factor to apply the same scaling factor to all assets, regardless of the scaling factors.

Rightsizing with Scaling Factors​

By default, Txture considers the scaling factor properties of an asset to scale your cloud instances up or down with respect to your current configuration.

The following scaling properties for instance rightsizing exist:

  • CPU Scaling Factor
  • RAM Scaling Factor
  • Storage Scaling Factor

Examples​

  1. If you have a server with 2048MiB of RAM and a RAM scaling factor of 200%, Txture will look for an instance that offers at least 4096MiB of RAM.

  2. If you have a server with 8 CPU Cores and a CPU scaling factor of 25%, Txture will attempt to find an instance that has 2 CPU Cores.

Rightsizing with Scaling Factors & Margins​

On top of that you can define an additional margin, that gets directly added to the resulting scaling factor. The percentage value for the margin can be positive or negative.

Examples​

  1. If you have a server with 2048MiB of RAM, consider the RAM scaling factor of 200%, and add a margin of 20%, Txture will look for an instance in the cloud that offers at least 4506MiB of RAM.

  1. If you have a server with 8 CPU Cores, consider the CPU scaling factor of 85%, and add a margin of -10%, Txture will try to find an instance in the cloud that has 6 CPU Cores.

If no values are given for the scaling factors, the Default factor as defined in the target architecture preferences will be used without adding the defined margin.

Instance Selection for very small / very large instances

There are a couple of important differences in instance selection in case that the instance that should be migrated is very small or very large:

  • In case that the desired instance is smaller than the smallest available instance of a certain cloud product, the smallest instance will be selected.

  • For equal-sizing only, if the desired instance is larger than the largest available product instance in the cloud, the product will be disregarded as a migration target. A corresponding warning will be added to the migration report when this happens.

Rightsizing with Overriding Factors​

A third option allows you to scale all instances up or down by a fixed percentage. Information on utilization, which can be maintained in Txture in the scaling properties is not taken into account. Instead, an “overriding factor” is defined that applies to all assets. 110% means that the existing instance size for the target architecture is increased by 10%.

Determining Scaling Factors​

There are various approaches to determining and setting scaling factors for your cloud resources. Each method has its own advantages and limitations. Here, we discuss two primary approaches:

1. Scaling Based on In-Depth Knowledge​

In many cases, your company's IT operation experts possess invaluable insights into your infrastructure. They can readily identify whether an instance is currently over-provisioned or under-provisioned based on their understanding of the technologies and tools in use. This approach allows for a more tailored and precise rightsizing strategy that aligns with the specific needs of your applications.

To harness this knowledge effectively, consider conducting a survey through Txture with your IT experts. Gather their insights and recommendations, and incorporate them into your rightsizing strategy or allow them to directly set the scaling factors. By doing so, you can benefit from their experience and domain-specific expertise to optimize resource allocation.

2. Universal Scaling Based on Utilization​

Alternatively, you can adopt a more automated approach by using utilization reports from monitoring tools and hypervisors. To implement this method, consider using a Property Importer to populate the scaling factors of your assets.

The advantage of universal scaling based on utilization is its reduced reliance on manual user input. However, it's important to be aware that this approach may not always capture the nuanced requirements of specific applications or workloads. While it offers a good starting point for Rightsizing, it may require additional fine-tuning to ensure optimal performance and cost efficiency. Additionally, this method may have limitations in addressing evolving resource demands.

Virtual Cost and Cluster Utilization​

For applications that contain a cluster element (e.g. a compute cluster or a database cluster), the cluster replacement will typically be more expensive than removing the cluster and replacing every element running on top of it (e.g. with IaaS VMs). In order to make proposals with cluster replacements comparable, the comparison is performed based on the Virtual Cost. This cost is depicted directly above the actual cost which is calculated by the sum of each replacement and added element.

The Virtual Cost is a ratio of the total cost based on the resource utilization. This utilization is calculated by summing up RAM and CPU of all elements running on the cluster, then the percentage value from the available cluster resources is computed. The higher percentage value is used for calculating the Virtual Cost.

In the following image, we see two proposals of an application that contains a cluster element. The left proposal replaces the Cluster itself and has a resource utilization of 2%. This means that the elements running on the cluster consume only 2% of the total resources. The right proposal replaces the virtual machine and removes the cluster, therefore the resource utilization is 100% as all resources are in use.

Please be aware that while Virtual Cost allows for a fair comparison, the actual cost has to be paid to the cloud provider.