2019-02-19: New Cloud Sizing Analytics and Metrics, Plus Updated ARC Data!

We are incredibly excited to provide our users with greater insight into Movere's cloud sizing recommendations, as well as provide powerful updates to ARC data. 

Updated ARC Data Aging

Movere currently visualizes the last 30 days of ARC data at the tenant level. These visualizations are presented in memory, which means the volume of data presented impacts load time experienced by users. All performance data collected is retained in the Movere data warehouse, including the cloud sizing recommendation and pricing, but data can "age out" for one device as more recent data is uploaded for a different device. For example, if Device A has not been ARC scanned for more than 30 days, while Device B is actively ARC'ing, then the performance data from Device A would no longer appear on the Movere website. More importantly, the cloud sizing recommendation and pricing would revert to an inventory sizing for Device A, even though its ARC data is still available from our data warehouse. With this release, we are removing the 30-day tenant-wide window and replacing it with a 30-day window down to the device level. Even if Device A is only ARC scanned in January, and Device B is ARC scanned through March, the January data (sizing and pricing) for Device A will still appear on the website.

To illustrate this better, see the below comparison in the “Devices ARC’ed” row:

This means that all ARC data, (Process, Disk, Netstat, SQL, etc.), as well as all cloud sizings and pricing data, will remain active in Movere for 30 days for every device from the moment ARC until the same device is ARC’ed again. It's also important to highlight that Movere's sizing recommendations incorporate all performance observations received from each device. For example, if a device is ARC scanned in January, then ARC scanned again in March, the cloud sizing recommendation will include all performance observations across both months.

Additionally, we have standardized the ARC data refresh cycle. With this release, all ARC data processed daily for all customers in all regions.

Movere's New Private Data Warehouse

How is this possible? Well, the new ARC Data Age feature becomes a reality thanks to amazing work from the Movere engineering team. They not only re-worked the visualization engine, but also the backend that stores the ARC data before it is loaded in memory. By moving to our own (Private) Data Warehouse, (running on SQL on Linux and fine-tuned to the n^th degree), we can provide the most performant and scalable solution for our customers.

New Support for CPU Constrained VMs (Azure) / CPU Optimized Instances (AWS)

Since day one we strived to make our Cloud Sizing Engine recommendations maximize value ($/hr) without the loss of performance (compute or storage). Today, we add one more dimension to this data: Licensing for SQL Server, one of the most coveted (and costly) products on the market. After doing this work for over 10 years, we have learned the ingredients of an optimal SQL deployment, both from a performance and licensing perspective. Today, we are very proud to bring all that knowledge to our customers, fully automated and backed by real data.

Over the past 20 months Movere has processed over 225 billion performance data points. As we studied this data, we identified an urgent need to provide great analysis into the average compute cost of instances running SQL versus the cost of SQL. To demonstrate, consider the cost of SQL in the cloud: 4 cores of SQL Standard ($0.48 ph), 4 cores of SQL Enterprise ($1.50 ph) versus the average compute cost of instances running SQL ($0.40 US). Optimizing just 4 cores of SQL Enterprises covers the compute cost of almost 4 instances running SQL. As we researched further, we noticed that customers licensing SQL at the guest level can move almost all of their existing SQL Servers to the cloud at no additional compute cost by leveraging CPU Constrained (Azure) / CPU Optimized (AWS) instances. We have been studying this issue since September 2018 and we are proud to announce that this analysis has been automated.

In the Movere site, you will see a new size recommended, called CPU Constrained (Azure) or CPU Optimized (AWS).This new recommendation is available for both Windows and Linux servers running SQL. This new size will still provide the performance each device requires (CPU, memory, throughput and IOPS), but with the added benefit of a constrained/optimized vCPU count to optimize licensing costs. This is especially good news for customers with active Software Assurance seeking to bring their own SQL licensing to the cloud.

Updated pages include:

• Summary\Cloud Readiness\Azure\VM Sizing
• Summary\Cloud Readiness\Azure\VM Pricing
• Summary\Cloud Readiness\AWS\VM Sizing
• Summary\Cloud Readiness\AWS\VM Pricing
• Summary\Licensing\SQL Server\BYOL Analysis

New "Headroom" Dimensions for Cloud Sizes

What drives a VM’s size? Well, it’s a combination of several ingredients including system resources, benchmark data, available sizing options in each region and cost per hour. Movere will always favor the least expensive and guaranteed-to-be-available profile in each region that supports the instance's current performance needs, whether it is physical or virtual. Since each sizing is driven by system resources, let’s focus on the 4 most important ones: Compute (CPU), Memory (RAM), IOPS and Throughput.

Let’s assume that a server is sized as a Profile XYZ. We often get the question, what drives this size recommendation? Well, in 99% of cases it is one of the four system ingredients listed above. This is why we are now presenting the "headroom" available in the Movere calculated sizing with the lowest figure across all four variables being the driver of the profile designation. This is represented as a percentage (%) of the total capacity of the profile offered by the cloud vendor that is not needed to meet the maximum resources used on-prem (with 2 or 3 Standard Deviation, 95% or 99% confidence). Based on the below example, one can conclude that server ABC’s profile is driven by Throughput since it has the lowest overhead value (3.5%):

Each machine will have overhead as Movere will only recommend a sizing that satisfies all performance requirements. This, in our opinion, makes the cloud even more attractive as this translates into provisioning the correct size from the beginning, while having extra capacity that can be used when system load increases without having to upsize. In addition to this, the overhead percentages will automatically adjust as the sizing’s are switched between 2 and 3 Standard Deviations, so that the impact of switching between the two sizing can be instantly quantified.

Movere offers these 4 new dimensions (Headroom CPU, Headroom RAM, Headroom IOPS, Headroom Throughput), as well as the Average Headroom computed across the entire population of active servers, as new attributes that can be added using the “Edit Report” feature on the following pages:

• Summary\Cloud Readiness\Azure\VM Sizing
• Summary\Cloud Readiness\AWS\VM Sizing

Improved Token.txt File

We fixed a small bug in the token.txt file, which caused unexpected errors for some customers when uploading data. Please ensure you and your customers download a new token file from the Upload to Cloud tab in the Movere console.

Time of Tenant Expiration Now Visible

We received several requests to expose the specific date and time a tenant will expire. This data is now visible from the Stats tab, by hovering over the expiration date of any given tenant:

This provides greater insight into when a tenant will expire, enabling partners and customers to prepare for expiration more efficiently.