Quick Summary
Introduction
Workspot is introducing a new self-service consumption model that gives customers the ability to deploy a wider range of desktop configurations, including a choice of rate plans—hourly, monthly, and annual—giving customers more granular control over their Workspot operations.
Who is Affected
This self-service consumption model is the default model for all new Workspot customers. Existing Workspot customers will be contacted by their Customer Success team prior to migrating from the legacy entitlement licensing model to the consumption model.
The Self-Service consumption model is fully available for Google's GCP Cloud and currently Microsoft Azure supports both the Annual and Monthly. Full Azure support is planned in a future release.
The power management controls are available to Bring Your Own Cloud (BYOcloud) customers, but BYOcloud is a a different billing concept from Consumption Billing: with BYOcloud, you pay your Cloud provider directly for your virtual machines and pay Workspot separately for its services. See Workspot BYOcloud (Bring Your Own Cloud).
Rate Plans
There are three basic rate plans available: hourly, monthly, and annual. Hourly billing has the lowest level of commitment and offers customers the greatest control over cost. Monthly and annual billing trade off longer commitments for lower prices with normal desktop usage and offer customers a predictable, flat-rate cost.
Customers specify a rate plan for each desktop pool and can use different options for different pools.
Hourly
This rate plan is suitable for both low-usage scenarios and long-running batch scenarios, such as compiling code overnight, because you control when and for how long the VMs are in use. Power management is up to you, but Workspot Control provides settings to facilitate it.
With hourly-rate desktops, you are billed for the time a desktop VM is powered on, regardless of whether a user is actively using the desktop. When used in a persistent desktop pool, you are also billed an access fee to maintain the users’ disk image once a pool is created.
You can minimize costs by minimizing the number of desktops provisioned in a pool at any given time and configuring the desktops to sign out idle users.
Hourly desktops are billed every month for the previous month’s usage, with fractional hours for each desktop rounded up to the next whole hour (that is, 44.3 hours would be billed as 45 hours).
Monthly
Monthly-rate desktops have a fixed cost per month. Monthly desktops are appropriate when committing to an annual-rate desktop is not desirable, such as when the user population fluctuates from month to month, but when usage is high enough to warrant a flat-rate plan. Workspot controls its costs through technical means such as automatic power management. Power management renders monthly-rate desktops unsuited to long-running batch jobs, such as compiling code overnight, because the desktops will automatically enter Sleep mode (use hourly desktops instead).
Charges for monthly-rate desktops begin when they are created in a pool, regardless of whether the desktops are powered on or used. Customers are billed every month for the desktops that existed in the previous calendar month. The billing granularity is one month. For example, if a desktop is created on the 25th of the month, you will be billed for the entire month.
Annual
Annual-rate desktops are the best option for a predictable user population that does not change from month to month. They offer a predictable, flat-rate cost that is substantially lower than an equivalent monthly desktop that is kept for a whole year. Workspot controls its costs through technical means such as automatic power management. As with monthly-rate desktops, power management renders annual-rate desktops unsuited to long-running batch jobs such as compiling code overnight (use hourly desktops instead).
Charges for annual-rate desktops begin when they are created, regardless of whether the desktops are powered on or used. Customers are billed every month for desktops created in the previous calendar month for the entire price of the desktop for the period between its creation date and the annual rate plan anniversary date. This date can be found on the Dashboard page in Workspot Control.
For example, if a desktop is created on the 25th of February and your annual rate plan expiration date is the 1st of July, you will see a charge for (annual_rate*165 days/365 days) for that desktop on your next bill.
With annual desktops, you can delete a desktop and replace it with an identical desktop (with the same CPUs, RAM, disk, region, pool type, etc.). In this case, the replacement desktop doesn’t create any new charges. For other substitutions, contact Workspot.
Anniversary date. Annual desktops that exist on your annual rate plan anniversary date are billed for the new year. Deleted desktops that were not replaced are not rolled over.
Custom Changes and Migrating Desktops Between Rate Plans
Customers cannot currently change the basic parameters of any desktop pool on their own, including its rate plan, nor can they change the parameters of individual desktops contact Workspot to make such changes.
VM Type and Costs
Regardless of the plan chosen, desktop charges vary according to the resources customers have assigned to them. Customers are billed monthly for their usage in the previous month. What “usage” means varies with the plan type, as discussed above.
The cost of a given desktop depends on:
The Cloud provider (such as Azure or GCP) and region.
The resources assigned to the desktop VM (CPU, disk, RAM, GPU, etc.).
The pool type (persistent or non-persistent).
The billing type: annual, monthly, or hourly.
Customers specify these parameters when they create a desktop pool (see the screenshot below).
Hourly desktops have a rate for each hour spent running. Hourly persistent desktops have an additional rate to maintain their persistent disk state.
Note: Preview desktops, used to test Workspot templates before using them more widely, are charged as if they were normal desktops. Workspot recommends deleting Preview desktops as soon as they are no longer needed.
Time Zone Effects
Pacific Time is used to determine the hour and date for billing purposes, regardless of the customer’s time zone. (Pacific Time is UTC- 0700 or UTC -0800). The start and end time of a contract month and your contract anniversary use Pacific time.
Contracts, Rates, etc.
This document is about the basic mechanisms underlying self-service consumption billing, especially those visible to Workspot customers in Control. All topics relating to contracts, discounts, payment methods, and so on are well beyond the scope of this article. See your Workspot representative for all such issues.
Effect of Self-Service Consumption Billing on Pool Types
Consumption billing interacts with pool types as follows:
Persistent Pools
Persistent pools are the typical Workspot desktop pool. Each user is assigned a dedicated desktop VM that is always available. Its disk contents are also dedicated to the user, allowing custom and personalized changes.
Power management will put persistent desktops to sleep, but they are awakened as soon as their users connect to them with the Workspot Client.
What’s new:
Hourly, Monthly, and Annual billing. Note: hourly billing is currently available on GCP but not Azure.
More granular choices in configuration (CPU/RAM, disk, etc.) per pool.
Except for hourly pools, power management is handled transparently by Workspot.
Non-Persistent Pools
The desktops in non-persistent pools are assigned to the user only for a single session. Desktops are reimaged between uses for maximum security.
You only need to have as many desktops as simultaneous users, but not total users. When the pool is overcommitted this way, users are not guaranteed to get a desktop when they want one.
What’s new:
Hourly billing only (monthly and annual are not supported).
Currently supported on GCP but not Azure, since hourly billing is not supported on Azure.
Reimaging between users is now mandatory.
Roll-your-own configuration (CPU/RAM, disk, etc.) per pool.
Power management: desktops are launched when an end-user clicks the desktop icon in the Workspot Client. Desktops can also be powered up on a schedule so they are ready before the users sign in by configuring a Warmup Policy. Desktops are shut down when the user signs out from the desktop.
Summary of the New Consumption Model
With the new model, you pay for what you use. You specify the CPU/disk/RAM/etc. of your desktops when you create a desktop pool. You no longer pay for entitlement licenses (whether they’re associated with a desktop or not), but for desktops.
You can add desktops without contacting Workspot (which you had to do with entitlement licenses)
Summary of different rate types for a single desktop | |||
Desktop Pool Type | Hourly Plan | Monthly Plan | Annual Plan |
Persistent | Base monthly rate + hourly rate * hours | Monthly rate | Annual rate |
Non-Persistent | Hourly rate * hours | N/A | N/A |
| |||
Power Management
Power management is mandatory on Clouds that support it. Currently, Workspot power management is fully supported on GCP, with partial support under Azure. (Additional coverage and features will be rolled out over time.) The goal is to be as transparent as possible without leaving desktops running when they are not in use.
Power-management parameters can be adjusted in Workspot Control with Time Limit Policies and Warmup Policies.
Persistent Desktops
GCP persistent desktops remain active for a specified period (for example, eight hours) after the user first signs in for the day. They are subject to power management after that period and are paused (hibernated) once they remain idle, with no keyboard or mouse input, for the selected period (say, fifteen minutes), or when the user signs out. Desktops are resumed if the user reconnects, and the user can continue from where they left off. This resembles normal Windows power management (sleep and hibernate).
Azure persistent desktops can optionally use shutdown as an approximation to pausing. This is a selective feature that is disabled by default and restart as an approximation to resuming. This is more intrusive than pause/resume but is the only method currently offered by Azure. Contact Workspot to have it enabled.
Power management in persistent desktop pools
Non-Persistent Desktops
For non-persistent pools, desktops are typically deleted after the user signs out, whether manually or after an idle session timeout. When the user reconnects, a new desktop is imaged and launched for them. Obviously, a desktop that doesn’t exist doesn’t incur any runtime charges.
Power management in non-persistent desktop pools
Controlling Costs with Hourly Desktops
Hourly, Non-Persistent Desktops
You are billed from when a desktop is created to when it is shut down or put to sleep.
Desktop Creation
Creation occurs when:
A user attempts to connect to a desktop and no warmed-up desktops are available.
A Warmup policy calls for more active desktops than currently exist. Desktops are warmed up twenty minutes before the start of a thirty-minute time slot.
Thus, a warmed-up desktop is billed for twenty minutes in addition to its nominal lifespan.
Its nominal lifespan starts at the beginning of the time slot. If a user signs into the desktop, the nominal lifespan ends when the user signs out. Otherwise, the nominal lifespan ends when the warmed-up desktop is no longer required, which happens whenever the number of active plus warmed-up desktops is more than the number specified for the current time slot.
Desktop Shutdown or Sleep
Shutdown or sleep occur when:
A user signs out manually.
A user is signed out as the result of idle and session timers in a Time Limits policy, or via the default time limits if there is no policy.
A user is signed out as the result of Windows RDP idle/session timeouts or other session-ending Windows actions.
A user is signed out or the desktop is rebooted by a Control administrator.
Billing stops when the desktop actually stops running, not the moment the user signs out.
Guidelines
Thus, to control uptime and thus costs, observe the following guidelines:
Set Warmup policies to specify non-zero numbers of desktops only during periods when you expect users to sign in. Warmup policies speed up the sign-in process but have no effect on users who are already signed in, so they have value mostly at the start of a shift.
Keep in mind that the idle shutdown, and hence the cost of idle desktops, is the sum of the Idle Disconnect timer and the Sign Out After Disconnect timer. Short idle disconnects will spam the users with disconnect warning popups. Short Sign Out After Disconnect values will deallocate user desktops after a too-brief delay, causing productivity delays as they get back to where they were. The default values of 15 minutes for Idle Disconnect and 60 minutes for Sign Out After Disconnect are good starting points.
The Maximum Session Length parameter can keep desktops from running indefinitely if they have a jittery mouse or some other problem that defeats keyboard/mouse idle detection. Setting it to more than the longest plausible interactive session (say, 12 or 24 hours) places an upper limit on this problem.
Hourly, Persistent Desktops
You are charged a fee when the desktop runs and another fee for the hours in which it exists (to maintain its persistent disk image).
To control the second category, you will obviously create new desktops as needed and delete them when no longer needed.
For runtime fees, the situation is similar to hourly, non-persistent desktops, described above. In practice, the main differences are:
Warmup policies are neither required nor supported.
With Time Limits policies, Disconnect on Idle (default: 15 minutes) is the same, and the settings should be about the same: set them long enough to avoid spamming the users with impending-disconnect popups but short enough to minimize the time spent on idle desktops.
Persistent desktops use Sleep After Disconnect instead of Sign Out After Disconnect. This is a safe, recoverable operation that only adds a few seconds to the user's reconnect time. For this reason, the default is only 10 minutes, compared with 60 minutes with non-persistent desktops.
Maximum Session Length is not available.
SKUs and Migration to Consumption Billing
After migration from entitlement licensing to consumption billing, an updated dashboard shows the SKUs of your new desktop VMs at the top of the page. The new SKUs are a combination of all the user-selectable parameters (Cloud, region, CPUs/RAM, disk size/type, pool type, rate type). Legacy SKUs are shown at the bottom of the page.
Examples: Creating/Editing Pools
Creating a New Persistent Pool
Creating a new persistent pool works as before, but with additional parameters:
Pool Usage Type. Use “Named” for persistent pools and “Concurrent” for non-persistent pools.
VM Class. Specified the number of CPUs and the amount of RAM per desktop.
Disk Class. The type of disk, such as Standard and Premium SSD.
Disk Size. The size of the disk, in powers of two between 128 GB and 1024 GB.
Rate Plan. Annual, Monthly, or Hourly. Hourly is available only on GCP.
Pool creation is otherwise the same as before.
Creating a New Non-Persistent Pool
This process has the same new parameters as persistent pools.
Non-persistent pools can only be created on GCP since they require that you use an hourly rate and GCP is the only Cloud provider that currently supports this.
Editing Pools FAQ
Q: If I want to change any of these new parameters in an existing pool, can I?
A: No. Once a pool is created, the VM, disk, region, etc. parameters are not editable. Contact Workspot if you need to make changes.
Q: Can I get a usage report for the previous calendar month?
A: Yes. Contact your Workspot Customer Success Manager to provide this report. We will introduce self-service access to usage reports in an upcoming release.
Q: Is billing based on the calendar month?
A: Yes. All bills cover the previous calendar month.
Q: On GCP, does the billing stop for hourly users when the VM is asleep?
A: Yes. Hourly billing starts when the VM is awake. This can be triggered by the user logging in or the Control administrator setting warmup policies to prewarm VMs on a schedule.
Q: Can I combine entitlement licensing and consumption billing?
A: No. The introduction of consumption billing removes the need for and desirability of entitlement licenses. Existing customers on entitlement licenses will be migrated to consumption billing. There should be no impact to existing users or VMs.