Transforming VMware into an as-a-Service Company

It’s no secret VMware has been trying to move to an As-A-Service model. It won’t be the first or the last company to transition its primary go-to-market model from permanent licensing and on-premises-based software to a cloud- and subscription-based model.

Adam Bohle, Gary Hamilton and I had the opportunity to present on this topic at our R&D Innovation Offsite (RADIO) in San Francisco in May 2019.

This blog post will cover some of the challenges and benefits for companies moving to an -aaS (-as-a-Service) model and our personal experience.

This blog post (like the rest of the content on this blog) is a personal view and not my employer’s…

Why move to -aaS ?

The benefits for the vendor and for the customers are well-established.

• Customers can consume the software or infrastructure through OPEX and not CAPEX, (avoiding a large bill every 4 to 5 years) and pay based on what they actually consumed, instead of what they might need at peak times.
• Customers get access to the latest features of the platform they’re consuming.
• Finally, customers can focus their time and effort on applications and business platforms instead of infrastructure and software building, patching and upgrading.

At the same time:

• Vendors are paid more regularly through subscription and the predictable revenue is almost universally liked by shareholders and investors.
• Offering its product as a service would, in theory, enable faster customer acquisition – if built well, the platform can be consumed with little involvement from 3^rd parties.
• Vendors can iterate faster, resolve issues faster and stop supporting obsolete platforms faster than they could with the traditional go-to-market model.

What are the challenges with moving to -aaS?

1. It’s a cultural change – it starts at the top and will not be successful unless your executive decision makers are fully on-board. The change will impact all business units – HR, Legal, Marketing, R&D, Sales, etc…
2. It dramatically impacts the way your product is sold: Sales Operations have to adapt its back-end systems and operations to support subscription services (it’s a massive undertaking), Sales teams have to evolve and position a solution they might not be comfortable with (often with the lure of some financial incentives) and finally your company has to slowly reduce the funnel of opportunities from traditional sales to the cloud/subscription bases.
3. Your company has to adopt its support model – you are now operating the platform on behalf of the customer who can simply use it without having to worry about maintenance, patching and upgrades. You need to build a support organization (often 24/7 and covering the entire globe) and finally you need to build an achievable SLA policy and commit to it.
4. You need to make the platform self-service. By self-service, it means:
   1. Customers need to be able to register and leave the service with no human involved in the process
   2. Customers need to be able to consume the platform easily – with an exceptional user experience and an up-to-date online documentation
   3. Customers need to be able to interact with the platform over a browser or via the APIs – it might seem like a minor technical aspect but in this software world, public and well-documented APIs are absolutely essential.

How does it apply to VMware?

Well, I imagine all our traditional software will be available As-A-Service sooner rather than later:

On-prem	Cloud
vRealize Network Insight	Network Insight
vRealize Log Insight	Log Intelligence
vRealize Automation	Cloud Assembly
vCenter / vSphere / NSX / vSAN	VMware Cloud on AWS and other cloud providers

From my perspective in the VMware Cloud on AWS team, some of the benefits for our customers include:

• Customers can consume VMware on-demand and only pay based on what they need
• Customers get access to the latest features – we are running the latest and greatest software on VMware Cloud on AWS and we’ve already pushed over 16 SDDC versions since we launched the service.
• We take care of all the patching, monitoring and upgrading and our customers can focus on running their virtual machines and virtual desktops on our platform.

At the same time, it’s great for the VMC team and VMware as a whole as:

• Our customers can consume VMware very quickly – now that we have credit card support, it takes our customers 2 hours to have a cloud-based Software-Defined DC up and running.
• Our customers are accepting and adopting vSAN and NSX faster than on-prem (2 years in the NSX Pre-Sales team have taught me that disruptive and innovative tech can be a tougher ‘sell’).
• We are iterating really fast. Why? Because we have the exact same configuration across all our customers (same physical servers, same configuration).

Has it been easy for us to adapt? Absolutely not! But I am optimistic:

1. Pat Gelsinger is absolutely determined to make our transition successful (that’s the exec sponsor I mentioned earlier).
2. After a roller-coaster 24 months, the majority of our sales team ‘gets’ it and our backend platform has been updated to reflect SaaS Metrics (ARR, ACV and TCV and many more acronyms…).
3. We have built a 24/7 follow-the-sun support team to support our SLA and Cloud Success Team to enable adoption and consumption and the feedback of the work these teams do has been overwhelming positive.
4. We’re constantly improving our documentations (although AWS and Azure are ahead of us there) and our APIs (again, we still have a long way to go to document our APIs).

Last point – it’s not just VMware that needs to adapt but also our customers – when you consume a platform as-a-Service (that includes VMware), you need to let go some of the control and finer knowledge of the environment. Here is an anecdotal evidence:

Customers would ask me: “Where are the VMC servers physically located? Are they in the same rack?”. And I’d answer: “🤷🏾‍♂️”.

The servers might be in the same rack or they might be in another DC. I don’t know and I don’t really care and neither should the customer. If the customer is worried about resiliency, they should just deployed a multi-AZ stretched cluster to have that peace of mind.

An As-A-Service model will always bring a level of abstraction… or obfuscation. If you’re not comfortable with it, maybe you are not ready for the Cloud.

And that’s OK.