Christine Austria and Curvature’s Server & Storage Solutions Sales Engineer, Matt Swann, returns for the second episode of our special series of Ask the Expert to delve into the Broadcom acquisition of VMware. In this episode, Matt discusses some implications of the changes from the Broadcom acquisition of VMware.
Christine: Hi everyone and welcome back to the second episode of our Broadcom-VMware edition of Ask the Expert. I’m Christine Austria and we’re joined by Matt Swann, our Server and Storage Solutions Sales Engineer. Last time, we outlined some of the high-level changes that took place when Broadcom took over VMware’s product line. Today, we’re going to discuss some implications of these changes. Take it away, Matt.
Matt: Thanks, Christine. The most important thing I want to highlight in today’s video is the need for users to be more intentional with their CPU choices now under this new subscription model. The previous vSphere perpetual licenses licensed a single CPU up to a maximum of 32 cores, which means that end users may have opted for higher core count CPUs than they needed – since they were going to be paying for these cores whether they use them or not. Now, subscriptions are core-based, with a minimum core count of 16 cores per CPU. This means that if you previously opted for a higher core count than necessary for your workload, under the new model you’ll likely be overpaying for licenses you don’t technically need if your current CPUs have more than 16 cores.
Christine: Why don’t you give us a quick example to help illustrate this point?
Matt: Sure. So, say your workload only required two 18-core CPUs in your servers, but because of the previous perpetual licensing, you opted to use 24-core CPUs because you got a good deal on them, and the perpetual license was the exact same cost (because they would license a single CPU up to 32 cores). Now, under the core-based subscription model, you’d be paying licensing costs for every single core, so 24 cores per CPU times two CPUs, even though your workload only needs two 18-core CPUs. This means you’ll essentially be paying for an additional 12 CPU cores to be licensed under the new model that you technically don’t need, leading to unnecessary costs.
Christine: That makes sense. Are we able to provide guidance to customers surrounding this critical change?
Matt: We can certainly assist in guiding through this new landscape, and that’s actually what we’ll talk about in the next episode, so stay tuned.
Christine: Great! So why don’t we touch on the other implications of these changes?
Matt: Yeah, so another obvious one is that due to the shift from perpetual to subscription-based licensing, it’s likely that OpEx cost is going to increase in the long term under this new model, so you’ll want to make sure you take these new costs into account for your annual budget. And finally, one last thing to point out is that vSAN can now only be utilized when paired with the 2 higher-end vSphere bundles – vSphere Foundation and VMware Cloud Foundation. You won’t be able to use it with the basic vSphere Standard licensing.
Christine: Thanks, Matt, for a great overview on this topic. For an in-depth detail on changes brought by the VMware acquisition, we’ll add a link to our blog written by Matt Swann in the comment section below. But if you have any other questions for any of our sales engineers, just leave a comment or contact us. We’ll see you next time on our special edition of Ask the Expert.
For questions about the VMware Acquisition, reach out to one of our skilled sales engineers today.
