Cloudamize, Movere and Other Techniques for Right Sizing for the Public Cloud

The Problem Statement

Most VMs (and physical servers) inside data centers are OVERPROVISIONED. They are allocated far more resources than they need. This leads to significant compute charges, storage charges and network bandwidth charges for hosting in the data center.

Most Customers inaccurately size their public cloud VMs prior to migrating their workloads. This is because they fail to ‘right size’ based on actual consumption (i.e. actual compute, actual storage and actual bandwidth usage).

This leads to customer OVER PAYING inside their data centers – as well as over paying on the public cloud! Surely, there’s a better solution.

Enter Cloudamize and Movere

Cloudamize is a tool that inspects your on premises workloads (typically, for a 2-week period) and provides you with right sized VMs on each of the 3 major cloud platforms (AWS, Azure and GCP).  Cloudamize can perform two exercises based on this collected data. A Budgeting/Pricing Assessment (based on Right Sizing Instances) as well as a more comprehensive Migration Planning (based on workload analysis).  Some concerns that can be addressed by this right sizing exercise include:

1. Have you encountered significant price differences when estimating your Total Cost of Ownership in the public cloud?
2. How do you know which instances to map to on AWS or Azure? Are you guessing based on current VM specs?
3. Have you had trouble factoring in your BYOL (Bring your own license) pricing to the estimate? (Typically, you should see a HUGE decrease in pricing if you have either BYOL or Azure Hybrid Use Discount)
4. Do you have Azure Hybrid Use Licenses? Were you able to account for the discounts that Azure would provide, were you to use your AHUB to it’s max?
5. Do you have Mobility Licenses? Were you able to factor those in during your AWS or Azure budgeting estimation?

Collecting the Data (How does Cloudamize gather data?)

Cloudamize offers three potential routes to collecting the data from each of your VMs PLUS Physical boxes

1. vCenter (or VMS for Hyper V) based data collection (requires a special Cloudamize OVM installation inside vCenter)
2. Agentless Data Collection – Requires a special, Cloudamize ‘Master VM’ to be installed within the data center, that can login to each of the individual VMs. This would require all admin login credentials to be configured on the Cloudamize VM.
3. Agent based Data Collection (RECOMMENDED) – This avoids the additional ‘Master VM’ install. Instead of a Master VM, there is a lightweight agent installed on each of the VMs.  This agent collects data for a 2 week period.

What Budgeting / Pricing Exercises Can I Perform?

• Workload Mapping (right sized mapping) versus Hardware Mapping (pure lift and shift);
• SLT – Service Level Threshold – 60% SLT is the target peak threshold that the compute estimation uses (assumes that 90% of the time, you run at 60% or less. If you exceed the 60% for 10% of the time, then you are UPSIZED to the next instance). 80% SLT is recommended as a best practice.
• AHUB – Azure Hybrid Use Benefit – applies to Windows Server Licenses
• BYOL – Applies to SQL Server Licenses
• Workload, Pay as you go
• Hardware, Pay as you go
• 3 YEAR RI, 80% SLT, AHUB and BYOL SQL – Could be almost 50% cheaper on Azure to BYOL and AHUB

Cloudamize FAQ

Discrepancy in the Hardware on demand (Lift and Shift) and Workload on Demand (Right Sized Lift and Shift) costs

The right-sizing applied is the same across all CSPs. At first glance, it appears that the compute costs are not dramatically different and that is why we are not seeing a large difference in cost. If we apply an 80% SLT, instead of Cloudamize’s default 60% SLT, we do see a more dramatic difference.

Can I Right Size based on specific IOPS?

Yes – Especially on Azure. Machines with high IOPS can be ‘right sized’ on the storage side because this is typically where we can optimize for cost the most based on how fixed IOPS work in Azure.

Right Sizing and Bursty (Unpredictable) Traffic
If the target peak capacity of 60% was used to calculate the appropriate instance size, what happens if their App experiences a burst – say 100 % usage for close to an hour? Is the instance right sized enough to handle such spikes?

To add a bit more context here, we take a look at the peaks in the 95th percentile when it comes to CPU. The SLT is the CPU threshold in place. We try to get the predicted peak as close to the SLT as possible. We allow the predicted peak to go over the SLT 10%. If it goes over more than 10% of the time, Cloudamize will make the next larger instance recommendation. You can quickly identify the machines where CPU is the reason we’re recommending a particular instance by filtering the “bottleneck” column.

Bandwidth and Network Usage Estimation – What prices were used in the network component? For e.g. – do you use 2cents/GB (on AWS, Azure egress). Do you ignore any egress between AZs?

Cloudamize uses the standard pricing offered by the CSPs. It’s important to note that Cloudamize does not distinguish between ingress & egress traffic.  That said, the network cost represented in the results is the worst case scenario cost. One can edit / make changes to this in the designer feature by working with the client to understand their ingress vs. egress traffic a bit better.

PaaS Right Sizing?

While PaaS right sizing is typically not part of any tool, Cloudamize allows you to right-size for the Azure SQL options. There are two canned designs made for you that right-size for Azure SQL managed instances w/ and w/o AHUB applied. If you’d like to right-size for other Azure SQL options, you can use the designer feature to do this. Please note you will have to select the SQL machines individually to apply the changes to that specific machine.

Licensing Specific Questions – Factoring in AHUB, License Mobility and BYOL SQL Discounts

One can apply AHUB and BYOL in the designer feature. You can apply this to the entire environment and it will be applied to the appropriate workloads.

The cost summary for ‘hardware on demand’ and the ‘workload on demand’ are almost identical. This is not the case for AWS or GCP. It seems like something different was done in right sizing the load for Azure.

The right-sizing applied is the same across all CSPs. At first glance, it appears that the compute costs are not dramatically different and that is why we are not seeing a large difference in cost.

• If we apply an 80% SLT, instead of Cloudamize’s default 60% SLT, we do see a more dramatic difference.
• Digging a bit deeper into the machines with high IOPS on the storage side because this is typically where we can optimize for cost the most based on how fixed IOPS work in Azure.

Cloudamize’ Migration Planner

Once Cloudamize finishes it’s right sizing exercise, you have the option to plan your actual migration using the same tool. This feature allows you to discover the application dependency mappings (works with both AGENT based and  AGENTLESS data collections), and plan out ‘move groups’ for your VMs.

Movere Right Sizing

Movere is a tool that works in a similar fashion as Cloudamize. It too,  can be used to ‘right size’ your workloads before moving them to the Public Cloud.  It can provide pricing scenarios as well as a migration readiness plan. It doesn’t currently handle GCP, but has several built in scenarios for AWS and Azure.

Inventory Scan vs. ARC Scan

Inventory Scan – You will need to start with an Inventory scan.  This is typically AD based (type in AD name).  AD based will discover ALL objects in your AD – whether active or inactive.

ARC Scan – To get  actual metrics (CPU, Memory…) from the VMs, you will nee to select ‘Windows Servers’ and ‘ARC Only’ – in the console. You CANNOT do Windows and Linux Servers at the same time from the console. However, you COULD launch one from the Console and another one from the CLI.

Factoring in BYOL

Movere has BYOL options that let you individually target Sharepoint Servers, SQL Servers and of course, Windows Server licenses.

Summary

If you are not performing a ‘right sizing’ assessment, chances are you will end up overprovisioning (and overpaying), regardless of which public cloud you migrate to. To get a realistic picture of your TCO on AWS, Azure or GCP, you need a tool like Cloudamize or Movere. Here are some high level observations / lessons learnt during right sizing exercises:

1. Try and not size yourself (manually), The tooling has become significantly more sophisticated over the last couple of years.
2. Right Sized Pricing can be VERY different on different clouds – While infrastructure costs can be substantially different on public cloud platforms, License (BYOL) Savings usually exceed any infrastructure discrepancies. When you factor in License Mobility, AHUB and BYOL SQL – Azure may end up being close to 40% lower than the LOWEST infrastructure options on AWS or GCP.
3. AWS wins on Infrastructure, Azure on Licensing – AWS offers far more ‘pricing’ options on instances – including something called ‘Cost Optimized Pricing’. This is usually the cheapest as far as infrastructure right sizing goes. However, with the three BYOL license discounts (BYOL SQL, License Mobility and Azure Hybrid Use Discounts), Azure ends up being substantially (up to 40%) lower than AWS.
4. GCP Anyone? – All other things being equal (no licensing factor in, and no Reserved Instance Pricing), GCP provides the cheapest compute costs (VM instances). Since Compute is usually a bigger component than storage or networking, the overall (infrastructure) costs on GCP are typically lower. Keep in mind that this is INFRASTRUCTURE only pricing (i.e. – no BYOL scenarios).

Right sizing used to be a challenge to get right, because of the custom needs of each customer. Tools such as Cloudamize can help you right sized based on actual traffic, CPU and memory usage monitoring. In addition, the tool helps you predict savings by bringing your own licenses and applying other discounts that you would not be able to ordinarily apply (on AWS’ calculator, for instance).

Appendix A – Cloudamize FAQ

How can I install the agent on Multiple VMs?

1. Use SCCM
2. Use and AD custom policy to install and configure the agents
3. Manually install the agents on each VM

What happens if my VMs / workloads are not continuously running?

1. This is not an issue as long as the VMs are up for at least half the day.

How does the right sizing work (what is the algorithm / criteria used to map to VMs in the cloud?)

• SLT – Service Level Threshold – 60% SLT is the target peak threshold that the compute estimation uses (assumes that 90% of the time, you run at 60% or less. If you exceed the 60% for 10% of the time, then you are UPSIZED to the next instance).

Appendix B – Movere FAQ

Custom Scan Lists

For subsets of the entire DC objects, you can create custom scan lists. More importantly, using the CLI, you can customize to individual OUs as well.

LINUX Servers

1. SSH keys based access is all that is needed.
2. To Run a Linux Server Scan alongside a windows server scan, need to run it from the CLI (since the Console only allows one scan at at time).

Movere Licensing

Movere has a flat rate licensing. This is due to the nature of it’s discovery process (inventory scanning). Typically, an AD scan can / will pull back more objects than you are interested in.

• 1- 250 VMs – flat rate
• 251-500 VMs – another flat rate

Command Line Options on Movere

Apart from running a scan from their console, Movere also offers a command line option. For e.g. – for running specific Linux scans or running an OU based subset of your AD.

Custom Scan Lists

For subsets of the entire DC objects, you can create custom scan lists. More importantly, using the CLI, you can customize to individual OUs as well.

LINUX Servers

1. SSH keys based access is all that is needed.
2. To Run a Linux Server Scan alongside a windows server scan, need to run it from the CLI (since the Console only allows one scan at at time).

Movere Licensing

Movere has a flat rate licensing. This is due to the nature of it’s discovery process (inventory scanning). Typically, an AD scan can / will pull back more objects than you are interested in.

• 1- 250 VMs – flat rate
• 251-500 VMs – another flat rate

Command Line Options on Movere

Apart from running a scan from their console, Movere also offers a command line option. For e.g. – for running specific Linux scans or running an OU based subset of your AD.

PaaS Right Sizing on Movere?

Movere does not provide PaaS right sizing.

Best Practices around using Movere for Right Sizing and Migration Planning

1. Step 1 – Inventory via AD  – For Inventory Data Collection, use an AD scan as opposed to other scans. Provides better App Dependency Info and also User Access Info
2. Step 2 – ARC through Windows Devices and ARC , run windows devices scan with ARC only.
3. Step 3 – Either run a CMD line scan for Linux servers or, simply wait for the Windows Server scan to complete before running the Linux scan.