- Friday 04 January 2019
- 0 Comments
As CTO of Strencom, Ed has overall responsibility for managing a team of technical architects that design, build and deliver the various digital platforms utilised by Strencom’s customers. Ed has worked at Strencom since 2002 when he joined as IT Manager. Since then both the company and landscape has grown significantly and it's this first-hand experience of being part of a growing business that gives Ed that extra insight when dealing with Strencom customers on business transformation projects.
From each of the three keynotes at VMWorld 2018 it is clear that VMWare's strategy over the next few years is to extract the cloud layer / hypervisor out from under the security and management tools, providing a common posture for both security and orchestration. It would be easy to make the assumption that they are trying to hedge their bets and become a broker type layer between AWS, Azure and IBM cloud, but the plan seems to run a lot deeper than this. To elaborate, let's take a look at the vmware journey so far over the last 20 years (This year’s vmworld was the 20th birthday party).
VMware Workstation started as a piece of software used to abstract the physical hardware in your PC to allow you to run a virtualised operating system inside your main operating system. The guest operating system saw a common set of hardware, regardless of the make and model of your CPU, Graphics cards and once your host operating system was in good working order, trying to solve issues like IRQ conflicts, DMA addresses and TSR programs was a thing of the past for virtualised operating systems.
The next significant change was ESX or more importantly VCentre Server. This allowed an administrator to take the benefits of the hardware abstractions mentioned above, and manage it across a number of hardware servers from a single pane of glass. Because ESX created a large load on the network elements for services like vmotion, it tended to create silos of teams - the network team and the servers team - both teams unhappy with each other because issues on either product impacted the load on the others. The answer, NSX.
NSX is a product that abstracts the detail of the network from the hypervisor platform. This gives the same user experience to the administrators regardless of your vendor, which also allows for a common network security policy to be deployed across virtual machines.
vSAN did exactly the same thing for storage, removing the complexity of whatever storage vendor you use along with the complexity of your storage network, be it FC / iSCSI
The current strategy is now focusing on bringing the tools developed over the last few years to other vendors clouds(like they did with other vendors hardware with virtualization) i.e using NSX-T to provide you with a common security experience and posture regardless of whether you decide to deploy your virtual workload and give you the flexibility to use: Azure or AWS; your own on-prem cloud; one of a vmware VCPP cloud providers; or using VrOPS manager to manage not only the performance of your virtual machines, but also identify over provisioned machines that could deliver cost savings to your organisation regardless of what compute platform they reside on.
Are we going to see true cross platform workload mobility through this strategy? No. Regardless of that, orchestration tools exist, and each cloud will have its own strengths and weaknesses. However, this strategy will give technologists at all levels in a business, from Developer to CxO a common dataset to work from and great tools to stitch it all together.
If you’d like to learn more about Strencom’s vCloud IaaS on VMware, click the link below to download our latest VMWare Case Study: https://bit.ly/2SEoE9B