Develop, Test and Deploy on SunxVM using VMLogix

October 29, 2008

Sun has a powerful suite of virtualization product offerings – from the xVM server (for the data center) to VDI software (offering a secure virtual desktop). The also offer Ops Center (for VM and physical machine management in the data center) and VirtualBox (for VM creations on the desktop/laptop). Their platform support (x86 and Sparc) offers competitive differentiators with the current top 3 vendors (VMware, Microsoft, Citrix).

VMLogix has long maintained a hypervisor agnostic stance in the development of its award winning LabManager (and subsequently StageManager) products. A couple of months ago, VMLogix announced the support of Microsoft Hyper-V adding to the Citrix and VMware virtualization platforms which have been supported for a while.

In tune with the support of multiple virtualization technologies, VMLogix recently recorded a webinar with Sun. The webinar provides an introduction and overview of the Sun platform and highlights VMLogix’s complementary management products to the Sun product suite. Together the product suites provide a compelling proposition for customers as they start to use Sun’s virtualization technology across the dev/test labs to the data center.

You can register for the on-demand webinar presented by Sun and VMLogix.

Are you using/considering the use of Sun virtualization in your IT environment? What have your experiences been?

– Srihari Palangala

Bookmark and Share


Software trials and evaluations – How can they be made more effective?

October 24, 2008

Software Trials and Evaluations are Generally a Laborious Effort for ISVs & their Prospects

If you are an ISV, there is generally a lot of friction in getting your prospects a copy of your software and letting them evaluate/use it. Most ISV product managers are confident that once they can get their software in the hands of users and they test drive it, end users will be able to see the value and benefits the software provides.

To achieve this, traditionally ISVs have offered a free download of their software with a specified license trial period. There are multiple barriers for end users with this approach:

  1. Download the evaluation software after filling out the required forms on the ISV corporate web site.
  2. Prepare and have the infrastructure ready on premise to install and evaluate the software.
  3. Install and get configured with the software. Start flexing all functionality of the software to see that it works for them.
  4. Make the purchase, provided the software meets the requirements.

Some ISVs have started adopting the appliance packaging route to make step #3 above somewhat easier.

Though this trial download approach has barriers, in some product cases this is a preferred route for the prospects. For e.g., when the primary stakeholder/user is to be an IT administrator/technical user – they typically like to see all the bells and whistles accompanying the software (including its installation and administration). In such cases, they would like to evaluate on-premise locally.

In other ISV cases where the purchase decision/primary stakeholder is the end business user (e.g., financial software, business process software, HR software, accounting software etc.) – software trials via the trial download route can impose a lot of hurdles and needless friction.

How can Virtual Lab Automation help in this scenario?

Virtual Lab Automation ensures rapid, highly repeatable, resource-optimized deployments of complex, multi-virtual machine environments. It allows end users to create, access and work with multi-machine configurations in self-serve and no-hindrance way. If these configurations have the ISV software pre-installed and configured for trial, it provides prospects an easy way to get access and evaluate/try the software. Here are some of the benefits of migrating to such a scenario if it works for your prospects:

Benefits to the ISV of a hosted evaluation system

  • Reduce the hand-holding and effort required during software evaluations (especially around the installation and configuration stages). Setup the systems once and let products like VMLogix LabManager handle the management of the virtual machine environments (including the user access, control and self-serve management). Dramatically reduce the time taken for software evaluations
  • Easily install upgrades/patches/updates to the demo systems
  • Provide every prospect with a pristine evaluation environment with minimal administrative effort
  • Monitor the use of software by prospects (who are the ones conducting the most active evaluations? what features are they most interested in? etc.)

Benefits to the software evaluator/user

  • No-delays and friction in obtaining environments where the software is pre-hosted and ready for use/evaluation. Start evaluating the software immediately and reach a decision much more quickly
  • Access the systems in a self-serve manner (via the web browser)

How are you enabling your prospects with software evaluations currently? Would the use of virtual labs help your prospects and improve their evaluation experience?

– Srihari Palangala

Bookmark and Share

A Framework to Estimate Cost Savings from Virtual Lab Automation Solutions

October 20, 2008

Virtual Lab Automation (VLA) solutions reduce IT costs, accelerate the software time to market and improves the quality of the software developed. While evaluating the business value of a VLA solution, it is important to be able to estimate the magnitude of $ cost savings that a VLA solution can provide. We outline below a framework that you can use for quick estimates of cost savings in your software development and test scenario.

  1. Reduction in IT costs — Virtualization can help drive cost savings and many analysts seem to agree. Virtualization reduces power requirements and improves space utilization. Beyond these benefits provided by vanilla virtualization, a virtual lab automation solution provides cost savings via better storage utilization (see earlier post on linked clones) and better lab utilization (e.g., resource sharing between users and teams). In addition, VLA can be used to rationalize lab infrastructure and help IT administrators perform better capacity planning.
  2. Accelerate software time to marketVMLogix LabManager introduces a high degree of automation and dramatically reduces the manual effort and time necessary to provision multi-machine configurations. Features like automation with guest VMs brings about a huge saving (and practically eliminates user intervention) in the time required to provision and create multi-machine test bed environments. The VMLogix LabManager ROI calculator provides a framework for you to estimate the cost savings by transitioning a manual provisioning environment into one powered and driven by virtual lab automation.
  3. Imporve software qualityVMLogix LabManager provides powerful third party ALM tool integrations which combined with the guest VM automation capabilities helps dramatically improve the test matrix coverage and thereby the software quality. Again, the VMLogix LabManager ROI calculator includes a framework to estimate the bug reproduction costs and the potential savings by using a virtual lab automation solution in the environment.

Pulling it all together

You can easily add up your cost saving estimations based on the framework for points #2 and #3 above. For #1, we do not have a published framework (updated 11/4/2008 – check the post Control and Reduce the IT cost spending in your software test lab), but with the ability to consolidate (currently at around 30-40 VMs on a single host and this consolidation is continuously improving with better hardware available) you can derive a basic savings estimate (for e.g., this press release from the Butler group though somewhat dated estimates that a 250 dual core server environment can save UK£ 2 Million).

In comparison to the above cost savings, virtual lab automation solutions like VMLogix LabManager cost a small fraction and IT administrators/users can justify their purchase & deployment in a very short duration of time.

– Srihari Palangala

Bookmark and Share

VMLogix LabManager and VMware Lab Manager

October 16, 2008

[Note Added on Sept 4, 2009: VMware has released their Lab Manager version 4.0 in July, 2009, where  they support and work with VMware vCenter Server 4.0 and vSphere 4.0. VMLogix has also recently released (at VMworld 2009) version 3.8 of the LabManager software. We will make some updates to the table shortly to reflect the latest releases. Thanks.]

One of most often questions we were asked at the recent VMworld conference (2008) was “how is VMLogix LabManager different from VMware Lab Manager” (no surprise there!).

VMLogix LabManager is an award winning enterprise/ISV solution that consolidates and automates lab infrastructure to deliver software applications quickly, cost-effectively and reliably.

VMLogix LabManager provides all the leading functionality for virtual lab automation that is available in a competing product from VMware. However, in addition to matching functionality from VMware, VMLogix LabManager provides the following additional benefits (that are not available in VMware) that differentiate the product and make it a pioneer in the virtual lab automation arena. You can learn more about VMLogix by registering here or by making a request for a product evaluation. You can find a broader FAQ about the VMLogix LabManager product here.

[Updated Feb 24, 2009 – posted about our strategic OEM agreement with Citrix. One of the comments on the post stated

a colleague of mine who played with both products said that the vmlogix solution is so much better than vmware’s

[Readers of this post may find these related posts useful reading as well – The Total Cost of Ownership VMLogix and VMware Lab Management Solutions, VMLogix LabManager beats VMware at the awards]

Product Shootout: VMLogix LabManager and VMware Lab Manager

Bookmark and Share

The Benefits of Software Lab Consolidation using Virtual Lab Automation

October 13, 2008

ISVs and SMBs usually end up in a situation where they need to maintain and operate multiple software test labs (for e.g., as a result of offices/development centers in multiple geographic locations). However, maintaining and running multiple labs has many inherent disadvantages and can be very expensive. Centralizing lab operations is increasingly seen as a must-have capability for all software development organizations.

Lab consolidation and using VMLogix LabManager Virtual Lab Automation to drive the consolidation would provide the following immediate benefits and value (to lab users and administrators/managers):

  • Drive efficiency and foster synergies across locations:

VMLogix LabManager provides a standard web user interface for users and lab administrators to get and share access to virtual machine/software licenses/storage/etc. resources and artefacts in the lab. Distributed teams can now all access and use the same repository of lab resources. This centralization – (a) enables lab users/teams to collaborate (share artefacts such as software scripts), (b) drives lab efficiency and (c) reduces re-work done by individual users in the lab (users can leverage scripts/VM templates etc from other users). The centralization also brings in virtual machine sprawl under control.

  • Control lab operational costs:

Consolidating lab operations enables lab managers to rationalize the lab infrastructure – including the use of storage required in the lab and the hardware requirements of the lab. Creation of standalone virtual machines quickly takes up storage capacity (every virtual machine is a full image, including copies and clones created). With a centralized VMLogix LabManager operation using linked clones, the storage capacity required is dramatically reduced. Furthermore, lab administrators can plan lab capacity utilization – since VMLogix LabManager provides a central dashboard and reports of lab resource utilization and usage. With a distributed system, it is difficult if not impossible to keep track of lab resource utilization.

  • Enable a policy driven self-service environment:

Consolidating lab operations with VMLogix LabManager will allow lab managers/administrators to give lab users the benefit of “self-service”. That is, users can now automatically request and provision virtual machine resources – which they can get access to and use. Lab administrators only manage the policies and control – for e.g., user quotas, access permissions etc. to ensure that each lab user is operating under certain bounded conditions.

  • Speed up mundane provisioning tasks:

VMLogix LabManager provides automation and self-service in the provisioning of multi-machine environments. In addition, VMLogix LabManager supports guest VM automation operations. Both of these advanced automation capabilities mean that users spend less time on mundane provisioning tasks and instead focus on higher value lab operations. For example, this lab automation enables multi-machine test environments to be created rapidly.

  • Centrally manage all software assets:

VMLogix LabManager allows users and administrators to bring multiple lab assets under central control. For example, user scripts/software packages/licenses etc. can be brought under central administration and control. With this, lab administrators can enforce license compliance (either hard or soft license compliance can be enabled). This is particularly useful in terms of SOX compliance requirements (which again is very difficult to do across multiple lab locations). Combined with the ability to share and collaborate (e.g., the sharing of software scripts), this is a powerful way for lab users to benefit from avoiding re-work.

  • Integrate with ALM and Test Automation Tools:

VMLogix LabManager integrates with leading ALM tools from IBM Rational and HP. With lab consolidation, lab administrators can now enable their users to leverage the lab in conjunction with these tools. For example, users can enable IBM Rational Build Forge to leverage a set of central virtual machines (created, used and torn down on the fly by VMLogix LabManager) for the build automation process.

  • Control and manage lab security:

With a distributed set of operations, it is difficult for the lab administrator to control lab security. Once the lab operations are consolidated, the administrator can enable audit trails and logs in VMLogix LabManager. This automatically captures the users accessing the lab including the changes made in the lab artefacts/resources. This allows the administrator to keep a logical security view on the lab resources (beyond just the traditional security to individual machines).

  • Expand the Lab Relevance to Other Groups:

With lab consolidation, the lab manager can expand the relevance and applicability of the lab to other groups. Traditionally, only developers and testers would have access to distributed lab locations. With centralization and the ability to access the lab via a web browser, support/training/pre-sales/field etc. teams can now remotely login and share the pooled lab resources. This also means that feedback loops from the field/support are a lot faster and quicker.

Are there other benefits that you can see as a result of the consolidation of lab operations? Drop me a note or leave a comment here.

– Srihari Palangala

References to other posts on this blog:

Bookmark and Share

Webinar – Boost Operational Productivity in your Software Engineering Cycles with Virtualization

October 8, 2008

VMLogix will be hosting a webinar on the Global Rational User Groups (GRUG) webinar series – titled “Boost Operational Productivity in your Software Engineering Cycles with Virtualization“. You can register for the webinar, it is scheduled on October 22, 2008 at 12:00 – 13:00 EDT (GMT-0400).

About the webinar

Server virtualization is a strategic and operationally important technology that is being widely adopted by software development, testing and operations in their lab and staging infrastructure. VMLogix virtual machine management solutions applications combined with the IBM Rational suite of tools provides a powerful solution that increases collaboration and improves the productivity of the software development lifecycle. This webinar presents the combined solution offered by the IBM Rational and VMLogix, highlighting the integration of VMLogix LabManager with IBM Rational Build Forge.

VMLogix LabManager enables the instant provisioning of complex multi-machine build environments for a build project to be executed within. This eliminates the IT bottleneck (reducing provisioning time by 80-90%, from hours/days to seconds/minutes), makes it easy to manage the build farm, controls physical & virtual machine sprawl and dramatically improves the utilization of the build farm machines. The presentation will also provide an overview of the integration between VMLogix LabManager and one of the latest product offerings from IBM – the Rational Quality Manager. Finally, the presentation will provide a demonstration of VMLogix StageManager which can be used to stage multi- virtual machine configurations in a pre-production environment (following service development and testing) prior to publishing them into production.

About VMLogix LabManager
VMLogix LabManager is a Virtual Lab Automation (VLA) management system that leverages virtualization from Citrix, Microsoft and VMware and by which the recurrent labor-intensive manual tasks, processes and infrastructure necessary in test and development labs can be automated, streamlined and centrally managed.

About VMLogix StageManager
VMLogix StageManager is a centralized management system that enables users to create a customizable staging workflow, streamline and unify the service staging process and stages the IT services and applications through the workflow for comprehensive service preparation and testing prior to publishing virtual machine configurations in the production environment.

Increasing the Role and Relevance of Software Labs in Building Quality Software

October 6, 2008

Dennis Stevenson blogs at Original Thinking and is a Director of Software as a Service (SaaS) for a software company in the healthcare automation space. He has extensive experience working on software engineering and in software labs. You can read his bio here.

He recently posted on “Getting Software Development Out of the Lab” on his blog. It was an interesting post and brought forth the relevance of involving the field in the software development/testing and lab processes. Clearly, Dennis is an expert in this domain and we caught up with him to get his perspective on the Changing Role and Expectations of Software Labs.

This blog has focused on virtual lab automation and lab management tools like VMLogix LabManager – we hope you find this detailed discussion on increasing the role/relevance of software labs in building great software useful.

In summary, Dennis made the following very important points:

  • Traditionally, the software lab is a place where rapid prototyping and experimentation was done. In more recent times, the trend has shifted towards using the lab as an isolated sandbox where developers/testers can focus on building great software

  • The three most important (technology) requirements of a lab today are – (a) Automation (b) Collaboration between multiple users and (c) Ability to mimic field like conditions in the lab

  • The lab is treated as a black box in organizations today – this is an important problem for business – which demands the need for more transparency and communication between the lab and various other business/engineering functions
  • The executive leadership in an organization needs to be a stakeholder in the lab – which will help transform the lab as a strategic asset
  • Ultimately – the ability to ship great software (e.g., software being requirements compliant) – largely depends on the entire efficiency of the lab experience

[VMLogix] How have you been involved with software labs in your career?

[Dennis] In my experience, historically, the lab has been a very vague concept. Earlier in my career, we had engineering software labs where the real focus was the ability to try new things. And whenever I used the lab it was always in the prototyping and rapid deployment kind of a scenario. Labs for me were a place where the traditional production rules did not apply, where I did not have to follow the same methodologies and I did not have to worry about building production grade software, but where I could very rapidly deploy an idea and determine if that idea was going to make sense or not. I could run a pilot out of the lab very quickly and easily and make a decision about whether or not a given technology had relevance or applicability to the business problems that I was trying to solve or if it was something that I just wanted to let pass by. I had a very successful venture doing Wiki deployment where rather than developing it internally, we were trying different software products to decide which one we wanted to use as an enterprise solution. In that case the lab was the place where I could install software that I could not do in traditional data center environments, play with them and see in a “no-penalty” type of a way.

In other organizations, I’ve seen lab concepts exist though they did not recognize it as such. We had a series of engineers who were trying very hard to maintain an isolated environment where they could develop software according to requirements that were provided to them. In this case they were disconnected from the user experience. We attempted to simulate in the laboratory environment the end customer and the kinds of experience that they would bring to the software. The real driver for the lab was “here are the requirements” just “write good code”, “be very efficient”, “be productive”. Labs gave us isolation, which meant focus and concentration and hence enabled great progress. We invested enormous amount of effort and time into building processes for creating, testing and certifying software. But none of those agile build, continuous integration or other processes could be used once systems went into a client or field environment. So more recently, I began to wrestle with – how do we use the lab? What is the proper role of a lab? Do we try to support the field experience out of the lab or do we have to do something else in order to be relevant to the field users?

[VMLogix] What are the top technical challenges for a software lab today?

[Dennis] Several things jump to mind, here are the key points:

  • The lab environment must be automated. The concept of a lab is destroyed in my opinion if you don’t have automated testing, some sort of automated build, if you don’t have tools that look at the code produced and render some sort of verdict about its suitability, usability or its quality. And it is very important in a lab environment that the developers in a lab environment not be burdened down with a lot of administrative or repetitive tasks. The lab is more productive if it can make this process smoother and enable faster feedback to the developers about whether the code they’ve written works or doesn’t work.
  • The other piece to this is the offshored/outsourced relationship in software engineering teams today – the lab absolutely needs to be portable. It is very easy to get in and build a heavy lab, where it is very site specific, where the processes are very heavily and locally customized and where the automation is unique to this particular place or circumstance. This ends up being a limitation and barrier over time, because we are working through the issue of how do we replicate our lab environment for somebody else to participate or collaborate with us. I think collaboration is an ongoing theme that we really have to wrestle with these days in terms of one team working on software, handing it off to another team or integrating things from another team and so on. To the extent that the lab environment were to operate the same, feel the same, and produce similar kinds of results, the stitching together process becomes so much easier. In my mind, the purpose of the lab is to get the efficiency and let people get focused on the real hard problems not the brute force problems.
  • The lab cannot be entirely self focused. It is easy to think that the world is a sterile place that I can replicate or create in a lab environment. The reality is that when my software hits the real world and real users with completely different assumptions about what it should do and how it should work, interact with it, have different priorities than what the software developer or product manager think about – there needs to be fast communication loops with the field communicating back to the labs so that the lab can increasingly mimic what the field looks like and also so that software can be rapidly modified as it deals with this new scenario and is worked upon to work in a manner that it is designed to perform.

[VMLogix] What do you think business expects from the lab? And how can you have lab goals aligned with those priorities?

[Dennis] Business expects predictability and quality. By predictability, they need to know: How long software is going to be in the lab? When is it going to be released? And will it be what they expect when it comes out? The risk is that the lab becomes a tremendous black box environment to the rest of the business and that fosters this really difficult tension of “us” and “them” between the business users, software engineers and the lab. Penetrating this and being able to establish the relevancy and maintain cohesion is hard, especially if you are an ISV. It is easy for the business to move off in a direction — that maybe the lab does not understand and the lab is always playing catch up in that scenario… always trying to understand what the expectations are because the business seems to be running away. Software engineering is a discipline and someone does not understand that casually along the way. Attention needs to be given. Methodologies like Agile can help, but it is not a requirement for a lab. Lab as an organization needs to be able to communicate and give confidence to the business that they are getting what they expect / want or what they need. This has been the fundamental tension. Contrast this with the software development that happens in the field. In this case, business is very clear and comfortable with what’s happening – the problem, what fix is happening and the scope of the activity is relatively small. The challenge comes when software needs to be in the lab for 4-5 months, that is long time for the business to say “I don’t understand what you are doing”.

[VMLogix] Do you think labs can be a strategic asset?

[Dennis] Labs can be a black box mode, but at the same time be a strategic asset. Do we think the industry as a whole will migrate there? No, I don’t think so. However, players in the industry may adopt this. But as much as I know about people as software engineering, these tend to be more people kind of management problems, like communication management problems – and that is a lot harder to solve. Tools and technology make this problem easier and can mitigate some challenges that the lab faces in establishing its strategic value. I don’t know if this problem is entirely solvable with technology but is certainly made a lot less daunting with technology.

[VMLogix] Who are the lab stakeholders? And according to you, who should be the lab champion?

[Dennis] The technical leadership is clearly a stakeholder because the lab is the main vehicle by which the technical development happens. In my opinion the other big stakeholder is the product management organization who very often is the key driver of activity into the lab and validator of output out of the lab. Now that is really challenging because as a rule, product management tends to be outwardly focused. And so it is very difficult for a product manager to maintain that dual role (“we understand the market and what the market wants” AND “we understand how the lab is responding to the requirements and how they are creating software”). That is a difficult spot for one organization to be in. In my experience the other stakeholder is the parts of the organization that deal with the software once it goes out into the field. That may be a customer support or client services organization that has to face the slings and arrows of the user base when the software does not behave as it should in particular circumstances. To the extent that those organizations can be stakeholders and actually exercise influence, I think it is a powerful force for the delivery of market relevant functions.

At a higher level, the executive leadership of an organization needs to be considered as a stakeholder because they create the strategic direction that places the lab in a central role or requires the lab to move into a central role. And they need to understand what it takes to harvest value out of that or what it takes to create that value in the first place.

[VMLogix] What are your top wish list capabilities that you want to see labs enabled with?

[Dennis] The development process needs to be well thought out, well understood and embedded into the culture. The big piece that is difficult is the integration of the development and testing of software. And the better that can be done, the better the flow of the software and I think that ultimately the testing and the certification of the software as being requirements compliant – the extent to which you can do that and the speed with which you can do that is very closely hinging on the efficiency of the entire lab experience. You want an independent testing organization, but you don’t want a lot of organizational overhead or process overhead between the development and the testing of the software. Testing can go such a long way too – you can get into usability testing, feature function testing, integration testing, system testing, acceptance testing, performance testing, load testing etc. When you look at the number of available testing that can be performed on software (all of which are incredibly relevant as software starts getting deployed and people begin to depend upon it), having the ability in the lab to do all of those things quickly and easily is incredibly important. Honestly, it is so easy to say “we’re not setup to do load testing…we’re going to attempt to do it, but not do a good job at it, so we’re not going to know how the software is going to perform under a real load, because we never put it under the load because we did not have the means/mechanisms to do it”. Also, when we do find issues how do we feed that back to our development organization capturing ways in which software was unsatisfactory and what we would like to see development change, so that they can cycle back again. From requirements concept to installation – how do we get line of sight that what we are producing as output of this lab is conforming to the original requirements that came in. Historically, development hated requirements traceability. We need some means of determining what we are delivering meets what we were asked to deliver.