There are many lines and silos in an IT organization. In many IT organizations, the people who care about servers, networks, and storage are in fact three different teams that try hard not to talk to each other. There is often an OS team (for each major OS), which has to talk to the teams that provide the hardware that supports their OS. Virtualization has served as a forcing function to get many of these teams to talk to each other. But what about those applications teams?
In the physical (pre-virtualized) data center, the server, network, storage and OS teams may not have worked closely together. Once you drop virtualization into the picture, you will find that you really cannot get virtualization to work very well unless you get what used to be separate infrastructure fiefdom’s to communicate well with each other.
Virtualization also has a profound impact upon the management of applications. For the following reason. In the pre-virtual physical world the teams (and their business units) that own the applications usually have the budget to go buy more hardware as they need it. Once that application is virtualized (or is threatened to become virtualized) the ability to “throw hardware at the problem” goes away as the application starts to run in a shared virtual data center.
This causes many applications owners to actively resist the virtualization of their applications. In fact it results in the “stall” of many virtualization projects, as differing and irreconcilable political interests are thrown into the mix. IT Operations wants to run every application on a homogeneous shared virtual infrastructure. The owner of Application A demands a certain amount of guaranteed resource, and a guaranteed response time for his critical transactions. Other applications owners place similar but competing demands upon the virtualization team.
Once this occurs whoever is running the virtualization project needs to call timeout, and ask two very simple questions:
- How is the performance of this application that you care about so much being measured in the physical environment?
- Does that method of measuring and therefore ensuring the performance of that application translate over into its new virtualized environment?
Now what you are likely to find is this. For all of the yelling and screaming about applications performance, you will likely find that very few of the applications that are being yelled about, are in fact truly instrumented for real performance – which is response time of the application system as delivered by the system to its edge (forgetting about the network between the edge of the application system and the end user, and the end user screen paint time). What you will find is that the performance of most applications is being inferred by looking at whether or not they are using normal amounts of resources.
The reason for all of the yelling and screaming that goes on when the discussion of virtualization occurs, is that the applications owners know that they really do not have the question of true performance (response time) under control before the application gets virtualized, and they (rationally) expect the problem to get worse once it gets virtualized.
The Gordian Knot
A Gordian Knot is a mythical knot that cannot be untied. Trying to virtualize business critical applications in the absence of real data about their performance before and after virtualization can feel like a Gordan Knot – an intractable problem that feels like it has no solution.
There is in fact a solution. The solution is for the IT team that wishes to virtualize an application to take responsibility for the response time of that application end-to-end and hop-by-hop. In fact the Virtualization Team should offer to take responsiblity for the the end-to-end and hop-by-hop performance of EVERY application running on the virtual infrastructure.
Since the silo’ed IT organization over on the physical side never offered to do this, this would constitute a major benefit to the virtualization of these applications and offer a path to the untying of that Gordian Knot.
The key to this process is to find a tool that can do the following things:
- The tool works in physical and virtual environments. Why physical as well you say? Because if response time is not being measured today, you will want to baseline the response time profile of the application before you virtualize it so that you can prove that you are delivering equal or better service once it is virtualized.
- The tool works across the operating systems that your applications use (Windows, Linux, maybe a few others)
- The tool works for all of your applications no matter how they are procured (purchased or developed), and if developed works irrespective of how they were developed (C, C++, VB, ASP, Java, .NET, PHP, Ruby, Perl, Python, etc., etc.) – as long as the application runs on a supported operating system.
- The tool automatically discovers your applications and automatically discovers how each part of an application is talking to other parts of the application. This is essential for the IT use case, as no one in IT has the time to configure tools for each application.
- Finally, of course, the tool figures out end-to-end and hop-by-hop response time automatically with no manual per application configuration required.
The P2V Process
Once you have such a tool, the process for using it is simple. Deploy it on the physical servers that are running an application that you want to virtualize. Profile the response time, transaction load, network load, and storage load of the application in its physical environment (this will be invaluable information for the virtualization engineering team as it will help the successful design of the virtualized resources supporting the application).
Now comes the most important part. Show the response time and resource utilization profile to the applications owner. Come to an agreement about what is required for them to be happy with the performance of the application. You might want to go so far is to commit to a response time based SLA for the application. Note that since no one in IT has probably ever talked to this applications owner about response time before, IT will be perceived as being very enlightened and forward thinking for framing the conversation in this terms.
Now you can effectively untie that Gordian knot and virtualize that application – without getting screamed at.
Managing Performance Critical Applications in Production
Everything up until now was the appetizer – this is the main course. The goal is to be able to manage the performance of business critical and performance critical applications on your virtualized infrastructure, promise better response time profiles (the trade-off between response time and load), and deliver it. This means using your new tool to automatically discover applications as they arrive in your environment, automatically discover their topology (and keep this up to date as things move around), and measure end-to-end and hop-by-hope response times.
In many enterprises virtualization is stuck at 35% or 40%. Moving beyond this set of applications requires that the virtualization team step up to managing the actual response time profile of the applications that are yet to be virtualized. This will create a benefit to virtualization that is relevant to the applications owners and facilitate the virtualization process.
If you are wondering what tools you should choose from, come back next week where a review of the tools that can do this for you will be performance management post of the week.
Applications Performance Profiling is an essential step in the process of virtualizing business critical and performance critical applications. In this case “performance” means response time not resource utilization. The virtualization team should go even further and commit to meeting response time based SLA’s for business and performance critical virtualized applications. This process will dramatically accelerate the virtualization of these applications and remove many of the current political objections to the virtualization of these applications.