VMware’s Developer Play
VMware has a new CMO in Laura Heisman, who joins VMware from GitHub where she was Vice President of Communications and Corporate Marketing. Near simultaneously, Ex-VP Product and Technical Marketing Lee Caswell has left VMware to join arch-rival Nutanix as SVP Product and Solutions Marketing.
This looks a lot like VMware’s new CEO, Raghu Raghuram, getting his team in place to deliver a change in strategy since Pat Gelsinger left VMware for Intel back in Feb 2021. Given the challenges of the 2021 pandemic year, it’s not surprising that getting all the pieces into place would take some time.
As I wrote in October last year, VMware has been trying to appeal to developers for some time, with mixed results. Rather than trying to turn developers into VMware people, VMware is trying to become more like what developers already use: cloud and containers.
The change in marketing leadership indicates that VMware has had enough of trying to convince developers to get interested in infrastructure and wants to try a different approach. At PivotNine, we think the timing is likely better now than it was a few years ago, for several reasons.
There now appears to be sufficient familiarity with cloud techniques like infrastructure-as-code among traditional enterprise IT folk that it’s no longer a scary threat to your employment and thus to be resisted at all costs. The keen and eager folks who enthusiastically embrace every new trend have been using cloud techniques long enough that their knowledge has diffused out to the more sceptical, results-demanding mainstream. The diffusion process has been working for long enough that we now see widespread adoption of ideas that were once radical, like scripted automation of routine administrative tasks.
The cloud brought APIs to developers who were used to writing code, so they just kept using code for everything. Infrastructure vendors who for years had only provided text-based consoles as the only programmable interface—rather than true API access—to their systems were eventually forced to copy the cloud approach as AWS grew into the behemoth it is today. Traditional vendors got on board the API train one by one as customers increasingly went elsewhere if they didn’t. Even Cisco finally succumbed, years after everyone else had already decided APIs were a good idea and maybe pasting commands into a serial terminal was getting a bit outdated.
Powershell brought scripting to Windows admins who were used to GUI-oriented admin which left them at the mercy of vendors who wrote code to support hidden and often undocumented APIs. They didn’t need to learn Linux like all their developer colleagues in order to start to get the benefits of automating their own daily grind. Clicking Next 700 times a day fell out of favour.
Note how developers didn’t learn to embrace they way infrastructure vendors thought things should be done. Infrastructure vendors eventually stopped trying to make them, and so it seems it is with VMware.
PivotNine thinks this really marks the beginning of the end of the traditional VMware approach to IT administration. Given the importance of VMware for enterprise IT, this is something VMware customers need to be considering.
You will need to change the way you operate your VMware infrastructure, so the time to start planning how to do it is now.
Wise enterprise IT veterans knows that change doesn’t happen overnight. For all the breathless rhetoric that cloud is the One True Way and everything will be cloud one day, after more than 15 years of publicly available AWS there is still an awful lot of traditional infrastructure out there. Even AWS finally caved to reality after more than a decade of insisting that it was the only true cloud and no other way of doing things was permissable.
It turns out there are lots of very large, successful companies that spend huge amounts of money on IT every year, and after you’ve got most of the fast-moving crowd to use your stuff, growth has to come from other parts of the market. It was inevitable that the unstoppable force of AWS would hit the immovable object of enterprise IT.
Enterprise IT doesn’t change quickly because it can’t. It is a complex mesh of interrelated services that underpin vital services for huge portions of humankind. You can’t just take the core banking mainframe down for six months to re-implement every CICS program as a microservice. It takes years of hard, tedious, detail-oriented grind to move the behemoths of the enterprise world from one way of working to another.
And this is VMware’s big opportunity. It has a strong foothold in the world of enterprise IT. It also has a heritage of being there as enterprise moved from one way of doing things (bare metal servers) to another (virtual machines). If VMware can provide a handy bridge between the worlds, and help enterprises across, it’s in a great position to be exactly what enterprise IT needs to adopt cloud operating models across more of their fleet.
Because this isn’t really about technology in the form of computers and software. It’s the technology of organising the work, of process and procedure. That is where the real prize lives.
VMware has finally realised that it can’t impose its view of how work should be organised on its customers. It is instead now embracing the way customers want to work, and changing its core products to suit. That’s why Project Cascade, and the wider VMware Tanzu effort, grab my attention. It’s changing VMware to suit the world as customers want it to be instead of needlessly clinging to a past that no longer exists.
VMware needs to see itself as a different kind of company if it wants to say what customers want to hear, and that’s what I see happening with these new appointments.
I look forward to seeing the results.
VMware has added Kubernetes capabilities to vSphere and elsewhere, but ease-of-use remains elusive.
Can VMware merge traditional IT ops with Kubernetes?
VMware has chosen multi-cloud as the central core of its strategy, and it is using a lot of confusing all-things-to-all-people messaging in trying to sell this strategy.