Application Virtualization is a departure from the norm typically on how most Enterprise solutions are packaged and deployed. Communicating and planning based on what you know regarding the application life cycle is critical to both the customer and the company.
Key Questions to Ask:
- What are Target Application Dependencies?: are there any dependencies with physically installed applications on the endpoint? If so what are those applications? Should or can they also be virtualized? What will the potential impact be? Always good to get a list and/or dependency mapping of all applications.
- Why is the customer migrating the application to a virtual paradigm? The typical responses are either Application Compatibility issues, OS Migration requirements, Implement Software As A Service in a Cloud, Offshore support, Reduce Terminal Server Footprint or reduce life cycle overhead. How and what you architect and implement will vary depending on what the ultimate goal of the customer is. How they will measure the success or ROI of your product within their environment.
- Compatibility with Target OS?: Not all Application Virtualization can simply be migrated to a newer version of the OS. Some require additional repackaging of the application to move to the new version. If OS Migration is a key reason - it is important to see if the applications are already virtualized and to make sure that you are working with the version of the Application Virtualization solution that is compatible with the target OS.
- Who are critical People, Processes and Technology that will be impacted? It is important to identify all the stakeholders during a production roll out, educate them on what application virtualization is, the purpose of the deployment, and what the expected impact will be to them or their organization. Typically I suggest training a SWAT team initially of the key stake holders so there are less issues around communication and misunderstanding because it is a departure from the norm.
- What is the Plan from Inception to Maintenance? The road to hell is paved with good intentions. Key to vet out and plan for not only the knowns but add time for the unknown factors that will come up.
- What is the impact on Current Solutions, Processes, and Systems? Such as can internal products used for testing, deployment, troubleshooting etc work with the virtual application? If not what are the contingency plans for this new way of packaging applications? Does the vendor supply a virtual reg edit for example? How will current processes for deployments, change orders, and asset tracking be impacted? Any special integrations needed with existing tools such as Discovery, CMDB, or Delivery mechanisms?
- What is the CUSTOMER'S Starting Point? Every customer and environment is unique. It is critical to understand what the customer's understanding is of Application Virtualization, educate them on the different approaches and work with them to take baby steps to implementing a solution so they can adjust along the way. This last one is particularly critical because too often People don't know what they don't know. It is better to start with a smaller pilot, identify GAPs in technology, training, and processes - have them addressed and then continue.
- How critical is/are the applications being virtualized? I once had a Architect ask me the impact of using virtualization in the emergency room of a hospital and the best way to recover. My answer was not to use virtualization for that purpose as the technology in general is still in early stages. When it comes to life or death - always proceed with caution when deciding whether or not to give new technology a go. The more critical the application the smaller the steps that should be taken and more planning required to cover back out plans in the event something goes wrong.
- Does the proposed architecture meet hardware requirements? One of the key reasons many people did not migrate to Vista was the hardware tax. Meaning the overhead would exceed the capacity of their system requirements. When a customer is proposing to deploying multiple versions side by side on a machine - Disk Consumption, Port Conflicts, Network Capacity, I/O, and other hardware related questions should be considered as part of the equation. Understand what the overhead is going to be on a per application basis to architect a realistic solution. Just because you theoretically can deploy multiple versions of the same application doesn't mean existing hardware can support it when this exponentially grows as more applications are virtualized.
- What is the communication strategy? Meaning people are busy with their day to day distractions of their job - it is important to set aside time to clearly create the plan, touch point calls to ensure execution, and take time to evaluate overall plan to adjust if needed. This allows everyone to set the right expectations that are achievable and realistic.
Some of this may sound like simple project management - but one would be surprised by how many times key items like compatibility with current systems, regulatory requirements, or simple lack of communication cause deployments to fail.
Regards,
Jeanne
The proverbial virtualization train has left the station - yet many software vendors & customers alike are still scrambling on to understand the impact on their current technology, licensing models, and processes. Like many major paradigm shifts - customers are moving forward and carving out what they believe to be the right pathway based on limited information and their interpretation of where this market is headed based on decisions from major technology vendors such as Microsoft, Oracle, and SAP.
Unfortunately for most customers there are no true best practices across software vendors for supporting virtualization. As consumers you need to be aware of what the pitfalls are, precautions you can take to avoid them, and ways you can leverage your existing tools and processes to reduce not only the costs but impact of virtualization to your organization.
Considerations to Address
1. What Delivered - there are many different types of virtualization that can be leveraged such as Server, Desktop, or Application. What you are delivering will impact how you count and license the product. Is it an open source application, custom homegrown application, regulated and restricted access, or an expensive off the shelf application such as Adobe Photoshop. Whether the application is a desktop application, server application or combination of the two - Web 2.0 - makes a difference to cost structures and tracking.
2. How Delivered - For example - is it a server application running inside a virtual machine, a virtual application launched off a USB stick or file media share, or a combination of virtual applications with a virtual desktop from a datacenter, or a virtual application delivered from the Cloud or Managed Service Provider. All can have license impacts depending on the software vendors support policies. Different software vendors have different rules depending on delivery: Concurrent desktops in Datacenter (VDI/HVD), Virtual Applications from a Client Device, or Streaming from the Cloud all typically have different caveats. For example, Microsoft requires an additional Services Provider License Agreement to distribute their applications from a cloud environment to customers. There are many unanswered questions that have come up regarding traditional delivery of virtual applications - if I stage it - does that count as a license? Do virtual applications (not installed) count against a EULA that claims it has to be installed? One rule of thumb - if you use it, you should expect to pay for it - Software Usage becomes even more critical in the virtual world.
3. How Discover & Audit - Virtualization can have significant impact on existing tools and process for Audit & Control of applications.
- Application -If you are using application virtualization - does the provider provide transparency into the virtual bubble? Does the virtual application have digital rights management to prevent copying from client to next? How do you detect a virtual application that isn't registered? What hooks are available to ensure there are no invisibility cloaks hiding applications that can call back to ISVs but are undetected by company?
- Desktop -When you check out the type 1 hypervisor - will your traditional tools be able to know that the license on the user endpoint is the same one under the agreement with the hosted virtual desktop? If you vary your update schedule for discovery - how do you audit the virtual desktop? What happens if the user never logs in during the appropriate window? What is the impact on audit trail for tracking who touched what pieces? How will the discovery tool input and discern between licenses on the different virtual machines? Particularly - the personal VM and company approved VM?
- Server - When you dynamically move one virtual machine to another host - will the discovery tool know to not double count the application? Will the software vendor support the flavor of server virtualization being used? What level of support will be provided? How is it licensed compared to traditional licensing when server farms may have a cluster of more powerful boxes with multiple CPUs to support capacity on demand in the cloud (private or off premise).
4.
What is Impact on Performance - Oracle and many other major vendors provide prescriptive guidance on running certain applications in a virtual environment due to performance. There is no one perfect rule of thumb on virtualization and performance but there are some things to consider. Regardless of the type of virtualization - they all run on hardware of some type and are all affected by the traditional layers in the stack from network, to I/O, CPU, SAN/NAS, etc. The more layers you add to the stack will eliminate some problems but are still bound by the underlying hardware. When selecting the right type of virtualization - it is critical to understand what that is, where it will be run from, and impact on capacity requirements for individual users. There are tools out there from BMC - Capacity Management Essentials and Novell - Platespin acquisition- that can assist here.
5. What is impact on Security - If using Type 1 hypervisor approach - who is responsible for patching the personal VM and ensure there are no Distributed Denial of Service Attacks on the company network? What are the implications of regulations on this approach - Cyber Security Act, Personal Information Acts? For application virtualization - what measures are put in place to prevent viruses from executing from the virtual registry on systems that the users have Administrative rights to like their home PC, employee owned machines, or as required to support legacy applications that can not be virtualized? Is the right transparency there for virtual applications to detect if there is a virus in the virtual registry? Do they employ anti-injection techniques to prevent malware from impacting the virtual environment?
Like any paradigm shift - the benefits of virtualization and cloud computing far outweigh the risks and effort required to bring nascent markets and technology to mainstream but it will take time. The most important thing for customers and vendors both is to be informed and understand what the implications are, where adjustments need to be made and make decisions based on assessed impact. Typically I always advise customers to crawl, walk and then run when it comes to adopting new paradigms (this is not just new technology) that will impact the overall ecosystem in place around people, processes, and technology. An ounce of prevention is truly worth 100 pounds of cure when you consider how dependant we have all become on technology.
|
|