Sunday 28 June 2009
The Virtual Glue
Available today is latest beta release of VMware Studio 2.0 beta which enables you to create pre compiled Virtual Appliances, you can then create them as OVF's and also add these appliances into a new form of grouping applications in vSphere called vApps. With VMware studio offerings you can compile your own internal wrapped appliances for your own Virtualised environment and is not exclusively for ISV's, to show this it even does Microsoft in the 2.0 release.
I recommend you check out full detail and recorded demos at the official vmware site on http://tinyurl.com/n7lv7l . The benefits of VM Studio and using vApps are huge, it is certainly going to be the enabler for future strategy of application delivery in completely virtualised environments and something I will be looking into in more detail.
Culture change
By deploying turnkey Virtual Appliances with for example a new SAP ERP Landscape on 10-20 Machines in a period of say 2-3 days rather than 2-3 Machines in 10-20 days clearly shows that current long deployment processes are redced and less people need to be involved on a deployment when using Virtual Appliances alongside side orchestration and groupings such as vApp. The problem however with this is you get people protective on roles and the oldage turf war developing so it is not something that can be just implemented straight away.
I recommend you check out full detail and recorded demos at the official vmware site on http://tinyurl.com/n7lv7l . The benefits of VM Studio and using vApps are huge, it is certainly going to be the enabler for future strategy of application delivery in completely virtualised environments and something I will be looking into in more detail.
The release of VMware studio got me thinking about the state of the whole current Virtual Appliance scene, one of the questions that I asked myself when looking at the presentation was;
Virtual Appliances's, shouldn't they be mainstream now?
Virtual Appliances (VA's) are at some point going to certainly become more and more present within Virtualised datacentres but the main question around this is when. Mendel Rosenblum the original Virtualisation visionary and founder, intially promoted the whole Virtual appliance trend by quoting in 2007 that Virtual appliances would be mainstream and adopted heavily by external ISV's to wrap COTS applications, he also stated that this would also replace the OS as we know it and be almost baremetal to the Hypervisor.
Highlighted value proposition included;
- Removal of the OS in the stack, replacing MS Windows with JeOS/busybox type OS's to run core services
- Application deployment turnkey capability of say a whole CRM landscape into one OVF file, this would include multiple VM's within
- Sending OVF content and updates to the customer by a dynamic delivery process via the internet/cloud or shipping on DVD etc directly to the customer
- Appliances and application would be tuned by the ISV and not the internal application or IT ops team, this removes any burden incurred on configuration.
- Licensing is much easier, you throw this burden to the ISV to manage, this is the same for product updates too, they deliver these dynamically.
All benefits of pre packaged VA's ultimately means that any work and scope of activity that is undertaken pre project phase today is heavily reduced in scope, even the system sizing is a breeze as the ISV does this and tunes it to the volume of users physically possible on that relevant appliance. This is no different to networking/security appliances that exist in datacentres today, they are built with a BSD/Linux variant and finely tuned to a maximum amount of theoretical user base.
Contrary to all of the benefits of Virtual appliances being quoted by the visionaries we are still in 2009 yet to see vast arrays of Virtual Appliance offerings from the big vendors such as SAP, HP and Oracle. To date I am only aware of one example that has had high amounts of advertisement and was targeted at organisations was the BEA Weblogic LiquidVM, this consequently with the Oracle merger appeared to get quashed.
So Why the lack of mainstream adoption of VA's into virtualised datacentres? A few things I believe that maybe the reason and possible barriers of adoption are;
The R word...Responsibility!
Ultimately large amounts of responsibility needs to be taken onboard by Internal Virtualisation teams to promote the art of the possible with VA's and to educate on what benefits they provide as apposed to current methodologies. Development tools such as the latest release in VMware Studio can also enable internal teams to build wrapped custom builds for internal applications and take away the large amount of work of deploying components in the VM. The barrier of adoption here is that there is limited amount of mileage in promoting VA's and custom packages unless business application teams and other parties involved in a typical deployment are able to share pre deployment options on there side of the story for the relevant application stack.
Responsibility also lies with ISV's to educate in a sideways fashion any customers on Virtual Appliances. Your App bods probably meet on a more regular basis with ISVs than you think and do what the Infrastructure peeps do on typical engagements with hardware suppliers such as the gaining regular technology updates, presentations and roadmaps on latest products, I am sure the ISV does educate or have the odd slide on Virtual Appliances (if your lucky) but more interaction between app bods and infrastructure bods is needed when this is known to allow you to use this technology.
It is clear that the future datacentre whether mainframe or x86 will be fully virtualised so therefore its time for ISV's to start aligning their strategy, ultimately it may mean more revenue certainly if the appliances can be delivered dynamically across the internet and be dropped straight into the customers virtualised farm.
Culture change
As you can see from my pathetic attempt at a rough process flow diagram (excuse the poor resolution) below I show a rough guide of typical people and processes involved on the delivery of applications, also shown are the areas that are manually performed deployment tasks against automated tasks. It is clear to see multiple people are involved in the average deployment, the role call in many corps include change teams, test teams, project managers, procurement, architects, IT ops and many more bods.
By deploying turnkey Virtual Appliances with for example a new SAP ERP Landscape on 10-20 Machines in a period of say 2-3 days rather than 2-3 Machines in 10-20 days clearly shows that current long deployment processes are redced and less people need to be involved on a deployment when using Virtual Appliances alongside side orchestration and groupings such as vApp. The problem however with this is you get people protective on roles and the oldage turf war developing so it is not something that can be just implemented straight away.
Evangelising about the agility that VA's provide within Virtual appliances is definitely something that can aid the adoption of Virtual Appliances. For education purposes it is recommended to start on showing the quick win examples such as LAMP Stacks, this will get end users aware of what can be packaged within a VA, it will show that VA's are nothing out of the unusual and they will certainly become ok with the fact that its not all bad once seeing a basic example that they are familiar with in typical VM's. Once confidence has grown move onto cut down appliance OS's such as JeOS...its just a matter of breaking the barrier down.
vApps functionality in vSphere enables organisations to reduce even more manual and people process. It enables you to compile the complete application stack and configure all associated components by one single master definition. Tie this in with some VMware orchestration capability where you could say deploy via API the Database components as part of the VM build and provision the relevant Networking components and it is clear the potential is going to be huge.
ISV's
It is going to be quite a while before current licensing models that ISV's offer and what companies signed up for in 4-5 year agreements are moved and migrated into licensing plans tailored for Virtual Appliances. Also at the moment very few organisations are likely deploying new application landscapes due to the economic climate. For those who have apps that do have VA alternatives there is naturally a transformation project cost associated with this to move the application.
Also important to highlight is the reseller chain that large ISV's use to distribute software would most likely be redundant. By deploying applications dynamically from centralised HQ's would almost remove any reseller and distribution partnerships.
Ye olde IT engineer
Something also which maybe a reason for lack of adoption is this guy/gal, they like to deploy a full SOE and to customise according to the application requirement, they also like the fact that they can administer that server and the relevant OS nuts and bolts such as running processes and services, also they like the fact it can be monitored and looked at if things go Pete Tong (wrong).
Take this role away from the average IT ops guy and run bare minimal Appliances and its quite easy to see how you can be disillusioned and disgruntled by changing how things are done today.
Summary
Hopefully this post gave some hindsight into what barriers you may experience and how to overcome them. Massive amounts of potential exists in Virtual Appliances and what VMware studio can do. The vApp potential is rather large and I will hopefully write a post on this when I get time to have a look in more detail at the beta of vmware studio.
Comments:
<< Home
I agree with you, vApps are a great thing. But the cultural change is huge. One customer once told me: "I will not use vApps because I cannot apply my existing OS patching process, and my company forces me to follow existing processes." or "Where do I get security warnings (CERT messages) for my vApp?" It also has to do with trust, or lack thereof, of the vApp vendor.
Frank, thanks for your comments here, you are so right. Your prime examples from the field shows that the People power is winning at the moment.
I think we all know deep down that the Application Bod will naturally listen to any of his trusted ISV's first as apposed to any internal colleagues such as you and I.
Fundamentally the ISV's play a large role in enabling vApps to be mainstream. Being someone who has continuously pushed ISV's for support of VMware even within a standard OS on a VM I think it will be a long long time before we start to see much movement here.
Lets hope products such as VMware Studio can start to enable and allow Infrastructure bods to actually build vApps without the Application bods even knowing they are running within them!
I think we all know deep down that the Application Bod will naturally listen to any of his trusted ISV's first as apposed to any internal colleagues such as you and I.
Fundamentally the ISV's play a large role in enabling vApps to be mainstream. Being someone who has continuously pushed ISV's for support of VMware even within a standard OS on a VM I think it will be a long long time before we start to see much movement here.
Lets hope products such as VMware Studio can start to enable and allow Infrastructure bods to actually build vApps without the Application bods even knowing they are running within them!
# posted by 
: 7 July 2009 at 09:07
: 7 July 2009 at 09:07
Fully agree with the thought process here. Clearing the terminologies though, vApp may or may not be a virtual appliance. The way we put it, VMs and vApps(container for VMs) are the fundamental building blocks. If they are built and shipped by ISV, they are termed as virtual appliance since the expectation is now the ISV, not the end-user is responsible for the lifecycle of this virtual appliance(vm or vApp). This also means, IT admins can build vApps through virtual center simply by grouping the related vms in a vApp and providing metadata around it as required by the app they are assembling.For more on vApps, virtual appliances and VMware Studio check our blog at http://blogs.vmware.com/vapp
I've pushed my employer (an ISV) into pitching/embracing a VMWare Appliance as an offering. Since they were too slow to move on it, I built it myself and presented it to the company - they loved it.
The problems now, however, is training the sales team on what kind of benefit it provides , and then trying to explain to customers/prospects on how the whole thing is managed. A lot of customers have been reluctant because they can't tweak/patch/destroy the OS the components run on.. but little do they know this is actually a HUGE benefit for everyone. Since I am in support, I now know exactly what to expect when poking around the appliance since it was built by yours truly , and when a problem arises its MUCH easier to troubleshoot and resolve. Software Developers can now have almost complete control over the environment as a whole, amongst other things.
Too bad I'm just a support guy who enjoys software development since I've never had any formal training .. Nobody listens to us self-taught , passionate yet uneducated folks :)
The problems now, however, is training the sales team on what kind of benefit it provides , and then trying to explain to customers/prospects on how the whole thing is managed. A lot of customers have been reluctant because they can't tweak/patch/destroy the OS the components run on.. but little do they know this is actually a HUGE benefit for everyone. Since I am in support, I now know exactly what to expect when poking around the appliance since it was built by yours truly , and when a problem arises its MUCH easier to troubleshoot and resolve. Software Developers can now have almost complete control over the environment as a whole, amongst other things.
Too bad I'm just a support guy who enjoys software development since I've never had any formal training .. Nobody listens to us self-taught , passionate yet uneducated folks :)
# posted by : 20 October 2009 at 19:15
: 20 October 2009 at 19:15Subscribe to Post Comments [Atom]
<< Home
Subscribe to Posts [Atom]
Post a Comment