When Broadcom took over VMware, a new licensing model came with it. The perpetual licences are gone, the products have been bundled into larger subscription packages, and many organisations have seen sharp price increases – without their needs or their consumption having changed.
You may have spent years building a stable platform. Now the rules of the game have suddenly changed. So the question is no longer whether you need to respond, but how and when.
Make haste slowly
When the bill goes up from one day to the next, the natural reaction is to look for the fastest way out. But that is rarely the best solution. The virtualisation platform is typically the foundation under large parts of IT operations, and a rushed move can quickly cost more in downtime, errors and extra work than the licence increase does in a year.
The first step is therefore not to choose a new platform. It is to build a clear overview of the existing one. Which workloads run where? Which systems depend on each other? What is business-critical, and what can be moved with limited risk?
Without that overview, you risk taking a major decision on far too thin a basis.
There are three routes – and they can be combined
The first option is to stay on VMware and renegotiate the agreement. For some organisations it makes good sense to use the situation as an occasion to tidy up the licences, adjust the capacity and negotiate better terms. That can buy you time, but it does not change the dependence on a single supplier.
The second option is to change virtualisation platform. There are mature technologies and platforms based on open source, among them KVM and OpenStack, which can cover many of the same needs without the same vendor lock-in. It requires a planned migration and the right skills, but in return it gives you greater control over both the platform and the economics.
The third option is to hand operations over to someone else. Instead of building, running and staffing a new virtualisation platform yourselves, you can move your workloads to a managed private cloud, where the provider is responsible for the underlying platform.
The right solution depends on your system landscape, your in-house skills and your appetite for risk. For many, the best route will be a combination of the three.
Do not trade one vendor lock-in for another
Whichever route you choose, there is one principle worth holding on to: the goal is to get your freedom to act back – not to replace one vendor lock-in with another.
That is why Edora is built on open source and open standards. You can move your workloads in, but also out again – including back to your own infrastructure, if that becomes relevant.
Because Edora is a managed private cloud, you do not have to build and staff the platform yourselves. You get a dedicated and redundant infrastructure with a clear operating agreement, run by a Danish team and located on Danish soil.
Broadcom has changed the terms for VMware, but that does not mean you have to act in haste. Start by mapping your platform, your workloads and your most important dependencies. Then the next decision can be taken on an informed basis – not as a reaction to the next invoice.
