VMware Cloud Director Availability Disaster Recovery to Cloud service recommendations.

The time for Disaster Recovery couldn’t be more acute, as businesses continue to transform and become more digital, they also increase their dependency on technology— exposing them more to risk.  Disaster Recovery as a Service (DRaaS) is a great option to cost-effectively improve IT resilience and streamline DR operations.  While there are many piecemeal options for protection against disaster, VMware Cloud Director Availability DRaaS offers a complete approach.

Before we get into the detail, this blog is quite a long read, I want to be upfront with you, if you are thinking about providing DRaaS on VMware Cloud Director, then read on, if you already have VMware Cloud Director Availability, then read on. If neither of these things apply, then bye for now!

Back to business – How do you go about creating and charging for the service? This blog will cover some of these topics for Disaster Recovery to cloud from a customer on premise. Firstly, let’s consider your investment, you have already got storage and a VMware Cloud Director cluster already and you offer infrastructure services. You have deployed VMware Cloud Director Availability and configured the plugin ready for tenants to access. There are a number of things to consider, amongst them:

• What tiers will the service have?
• How do I price the solution?
• Any additional professional or managed services?
• What to provide for Sales enablement?
• How do we market the solution?
• How can VMware additionally help drive business?

We will discuss these point by point to assist you on this journey to DRaaS!

Before we start, we need to decide what the service includes and what it doesn’t include.

Tiers of service

Everyone will have different estates and different workloads, if you are offering self-service DR, then you won’t have visibility of the workload sizes or perhaps volumes until you have the entire estate protected. For this reason, VMware recommends that you do not bound storage capacity using quotas, storage needs to be unlimited and monitored by operations.

Storage is always a tricky thing, too much and you are not realizing your investment, too little and the service will be impacted. For this reason, we provide you with a calculator to help you estimate the volume you require at the target site, please use this, you can find it here on the product page. The other reason for not using limited storage quotas is to do with how VCDA works;

During initial sync and for any failover operation a temporary disk is created the size of the allocated disk being replicated. Hence if you have a 100GB allocated and only 50GB used for a 12GB RAM VM, you should allow for roughly 162GB + deltas for a failover to work. Post a failover operation the temporary disk is destroyed, and the remaining allocated disk used, post a sync the allocated disk is actually shrunk to only the consumed size.

In order to be successful you need to ensure the customers, have enough storage to replicate their initial sync and failover test when they please. This means you shouldn’t limit the customer’s storage with an allocation quota. However, you can closely monitor (as can the customer) the disk space used by each VM or per customer organization, for disk usage for every replication in each direction for every organization.

This can all be done via the API and there is a Feature Friday to run help you understand more about the 4.x UI and API capabilities

VMware Cloud Director Availability since 3.0 has included “SLA Profiles” this are essentially policies around critical DR choices, such as the Recovery Point Objective and number of replications to keep over what duration. They will affect the storage used and granularity of the restore, however they could be confusing to a consumer and they need to choose these each time they create a replication. In order to remove confusion and to help the customer use the service these can be ‘abstracted’ to tiers of service with the choices already made and a simpler, gold, silver and bronze choice could be presented to the customer instead.

If each customer workload is different, then each will require a different priority on the recovery, customers can then align the cost of protection to the priority of the workload. Whilst Recovery Point Objective is important there is also a Retention Policy, this affects the ‘rotation’ of instance replicas (known as multiple-point-in-time-instances MPIT) and how often they are replaced. There is a total of 24 available in VCDA, and these can be cycled over a timeline up to a year or a timeline of a day, it is totally up to you. Of course, the further away the ‘image’ the less granularity there will be to the recovery and more chance of recent data not being there.

Again this ‘service design’ capability is talked through on another Feature Friday with our Product Manager Mariush Minkov, where we work though the SLA profiles and much more around the service considerations.

The replication policies provide some additional capabilities such as:

• Allow outgoing Replication/Migration and Allow incoming Replication/Migration. Making different combinations of them can form personalized service offerings. These can be used to control the customers activities and limit the service, particularly useful for migration purposes.
• Providers can cap the number of replications a customer can have, for example you could sell packs of 10 workloads. This is not a recommended approach as it will limit growth, but it maybe useful in situations where you want more control over capacity used.
• Providers can allow customers to create bespoke jobs and therefore overwrite the policy, this could be useful for a platinum service where the customer demands more control and is educated in the system and impacts of choices they make.
• Bandwidth controls are enforced at the customer side, so any throttling that is defined here is pushed directly to the customer side tunnel endpoint and will restrict the network traffic as defined. This can be very useful for bandwidth sensitive geographies.

So, there you have it – SLA profiles and replication policies give you the power to tier your service for your customers, then allow self-service replications to your cloud. There are additional aspects that you should also consider such as testing. A DR replication is only as good as it’s last test. So, you want to ensure customers test, but do you want them all to test at the same time? Of course not, given the compute required and the impacts on storage explained above, can you stop them? Unfortunately, no. So how should you control this?

Our recommendation about testing is that it should not be restricted, however it should incur production costs, which will limit how often it is performed. Also testing should not be done in large batches, this will impact storage hard given the temporary disks that will be created at the same time. Testing should be done in small groups or individually, this is a better approach as it doesn’t impact storage and enables the customer to test the workload post start up to ensure the applications start. A good recommendation will be to test only one vApp at a time.

Pricing considerations

Another question we often hear is how should DRaaS be priced. Firstly, as true cloud provider only aaS products, there are few out there for DR, so pricing is harder as we don’t have an enterprise to compare with. What will the market tolerate is equally a question to ask, and local research should be conducted into hyper-scale pricing and local provider pricing to get a feel on the ballpark sell price.

1. By matching your cost to produce against the market average you will be able to get to a per replication price which should be considered in Service Tier and Replication SLA (in line with VCD IAAS SLA you provide). You can extract metrics about the replication and the SLA profile used as well as all the data associated with the replication from the API and UI to meet your billing needs.
2. In addition, price per GB storage consumed, use VCD storage policies to match to different storage tiers. This is essential to make sure you are covered by the storage that is needed for failover operations and ongoing replication, do not restrict storage! Storage consumed is also available via API and UI for metering and integration.
3. Finally compute costs, which will only be required during test failover or after a real failover. This should be the same as your VCD current metering as it is as started workload in the environment and will align to current metering methods. It is common practice to overcommit compute resources sometimes up to 50% or more, but this will depend on your policies and what IAAS commitments are made to the customer for performance and capacity.
4. Lastly network traffic, if you are using 4.x, you will be able to query the API and UI for traffic consumption and historical data around bandwidth consumed for data going in and out of the provider cloud.

The picture below sums up how you could consider creating different tiers with the information mentioned in this blog.

One recommendation for pricing to gain visibility into regional pricing and variations in services could be from looking at the 451 Cloud Price Index, which is a subscription solution and can help with pricing and research.

Managed and Professional Services?

For the most lucrative revenue streams, cloud providers provide additional services to complement their existing services, either for onboarding to a service or for extension of a service. For DRaaS there is a very clear set of services that providers should consider, and it should start with assessment of the current estate.

As the first stage of your customer engagement, a Professional service Cloud Assessment Service gives you a detailed understanding of your customer’s infrastructure, and an authoritative basis from which to make future decisions and recommendations for DRaaS. Using a simple non-disruptive installation of VMware vRealize Operations and VMware vRealize Network Insight, the initial Cloud Assessment Service undertakes a 30-day data collection and automated evaluation of the most important areas of your customer’s environment.

The Professional service Assessment Services will help you streamline the setting up DR and accelerate your time to value and consumption. A good example for a service that is suitable for smoother onboarding is providing a network stretch to the customer. Once on board and replicating to cloud additional managed services can be sold to help them with items and highlights from the assessment service, particularly security improvements, the need to custom reporting services or reporting analysis and advisory, many different options are available, particularly in the application space. The customer’s application estate is their business, building a DR service must protect these, additional managed or professional services can be sold to provide individual application run books for recovery and best practices based on your skill sets and areas of expertise.

Sales enablement

All Cloud Providers have sales teams, but all providers have different sales motions and approaches, there is little that we can suggest that won’t already have been done and is known. However, we can provide guidance on how to position the value and provide assets to enable your sales teams to help you accelerate the growth of DRaaS services, to do this we have a go-to-market kit. The kit contains essential tools to accelerate your marketing efforts, educate interested customers, and train your sales to walk through an early-stage conversation.

Sales training is provided with a whiteboard, a detailed walk-through, complete with visuals for an initial sales encounter. It highlights the overall service value and should lead to a more in-depth conversation. There are also value messaging documents, filled with value prop statements that will resonate with your customers. We realize that everyone will provide the service differently, we have allowed for the most scope, but there are also suggestions in these assets, for how to break down an offering and where you can sell value-added services. A product manager will need to go through this prior sales enablement to ensure that all relevant sales value props align to what has been included or excluded from the technology in the service.

Marketing assistance

Cloud Providers have varying depths of marketing capabilities, some have a very small team of one, others larger teams of regional marketing capabilities. To cater for we have provided a simple eBook to be the start of the service assets. The eBook explains the value of the offer, what’s included, and why customers need it. Each eBook is fully designed and ready to be customized and branded. The eBook can act as follow-up to a sales conversation, or as a download in an email marketing campaign or from your web site. As with all the assets ensure it matches your offering / service / solution; this includes removing “[IF AVAILABLE]” tags if you offer a feature or removing that feature from the document if you don’t. Update generic service names with your branded offerings. Replace <partner name> with your company name and add your logos to the front and back.

How can VMware additionally help drive business?

To finish this blog, I will discuss how VMware can help you as a DRaaS partner. We have a program that is called DR Validated partners. Cloud Providers utilizing Cloud Director Availability in a commercially available service are eligible for a DRaaS technology validation when they meet VMware technology requirements. Upon validation, cloud providers will be listed on the VMware DRaaS section of the customer facing microsite https://cloud.vmware.com/providers/draas-powered  which consistently receives thousands of page views per quarter.

To drive leads directly to you as a DRaaS provider, customers landing on this page are prompted to select a cloud provider and fill out a form which is sent directly to your designated sales distribution list. The customer will receive an email with follow on instructions from you, the provider.

Additionally, validated DR providers are listed by distance priority in a vSphere 7 DRaaS plugin, available for free to all vSphere customers, indicating their geo availability to the customer. The customer is presented with a workflow within their vSphere client to setup the appliances and make the connection to the provider.

To become a VMware DRaaS Validated partner, you must fulfil the following high level requirements – have over 100 active protection replications reported in the commerce portal, have reported migration replications in the past and have each data center location that has VMware DRaaS enabled listed (https://vcloudvalidation.com/). If you have any questions regarding this program, please contact presto@vmware.com