Virtualization best practices: Why Root Cause Analysis Shouldn’t be Needed
You’ve inevitably heard the phrase “an ounce of prevention is worth a pound of cure” at some point in your life. There is a reason that this adage exists. We are often finding that when we let things get to a bad state, it becomes too difficult to bring it back to a good state. Another challenge is the battle to understand what a good state is because it is often an intangible, objective definition. This is the root of what we are doing at VMTurbo and may sometime not neatly fit into virtualization best practices.
Too little, too late: The Root Cause Analysis Conundrum
The heart of the demand-driven control platform at VMTurbo is the drive towards embracing control of the infrastructure based on the application demand, and the available supply of resources. All of this is done to assure application performance while utilizing the environment as efficiently as possible. This is what we call the desired state.
The fundamental reason for working with this goal is because we have recognized that while monitoring is important, there is an unfortunate comfort by some to accept that the system should be allowed to fail only to be left trying to figure out what actually went wrong in the environment.
No system exists today which provides completely automated root cause analysis for your applications. That’s a bold statement, but it is true. While some products lay claim to being able to do root cause analysis, the reality is that they are only really aggregating system logs and other leading details and presenting them to an operator for manual review. More importantly, this is being done too late, and only in a reactive fashion once the system or application has already failed.
Let’s use a more relatable real-life example: Parachuting.
Some of you may have experienced directly. Even if you have not done this yourself, you can still imagine the experience. Now imagine parachuting with the same mentality as our break-fix loop and manual root cause analysis that we see in our data center infrastructure. In other words, would you accept that no mid-flight work is done to ensure that your parachute is operating at the best efficiency knowing that someone is touting that they have a great root cause analysis process once things go wrong? I know that I wouldn’t.
Abstracting the Data Center Stack
While the goal of root cause analysis seems important, it is inherently flawed because it does not fully understand the breadth and depth of the data center stack. Every aspect including networking, storage, compute, memory, applications and more is a part of what creates the supply of infrastructure resources. Individually, each resource has its own set of dimensions and utilization levels. Collectively sufficient access to these resources is what enables you to assure application performance which is really what you are trying to solve for when adopting virtualization best practices.
Creating an equilibrium by understanding the trade-offs between all of these available resources is what differentiates VMTurbo from others in the data center. The desired state is the intersection of those trade-offs which we solve in a very simple way.. The way that our software solves this problem is that we represent everything as a buyer and seller of these data center commodities. This supply chain within the data center drives our patented economic scheduling engine to assure application performance, and continuously bring your data center into the desired state.
The goal for VMTurbo is eliminating the need for root cause analysis by preventing the failure to begin with. Whether you are flying a turbo prop, parachuting out of a plane at 10,000 feet or operating your data center environment, we imagine that you would rather prevent the issue than to try to figure out what went wrong after it happened.
So set aside your virtualization best practices play book and your parachute and give VMTurbo a try.