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.
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.
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.
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.
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.