Whenever I get the opportunity to catch up with Shmuel Kliger, founder and president of VMTurbo, I take it.  I've been fortunate for many years now to be able to sit down and chat with him during VMworld and Citrix Synergy trade shows.  But with all the news coming out around VMTurbo lately, I thought it made sense to reach out to him directly, outside of these events, and ask him a couple of questions so I could get the inside scoop.

VMblog:  I always enjoy our conversations, and we share many of the same passions within this industry.  Can you explain to readers what the big problem is that VMTurbo helps to solve?

Shmuel Kliger: VMware created a revolution in the last decade starting with server virtualization. It then grew from server to storage and other parts of the IT stack. And in the last few years, the marketing people gave it a name: the software-defined data center.

The reality of this software-defined revolution is that once the IT silos of old were destroyed, once software could execute actions in the datacenter without human intervention, there was no going back to the old, siloed-IT approach of making decisions in isolation.

This new world requires much larger thinking to be managed - beyond isolated actions attempting to solve specific problems alerted to post hoc. The software-defined revolution requires an understanding of the entire environment holistically, so that it could reach a "Desired State".

This concept of "Desired State" is something you and I have discussed before: It's a dynamic equilibrium where workload demand is best satisfied by infrastructure supply. This equilibrium is a continuously-fluctuating target where application performance is assured while maximizing infrastructure utilization. 

A Desired State - this dynamic equilibrium - is fundamentally a tradeoff between an n-dimension of variables, none in of which can be addressed in isolation:

• between budget and cost,
• between resiliency, performance and agility,
• between application performance and infrastructure utilization,
• between workload QoS and sweating assets,
• between compute, storage and network bandwidth,
• between compute, storage and endpoint latencies,
• between infrastructure constraints and business constraints,
• between compute and storage,
• between CPU, memory, IO, network, ready Qs, latency, etc.,
• between application priorities
• and among business priorities.

As you can imagine, these tradeoffs aren't simple. In fact, they're between huge, conflicting forces that pull the data center in different directions - in real time, all the time.

If you think about it, a datacenter is not so different from a symphony orchestra. Unless every instrument finds its proper equilibrium with every other - in real time, with every beat - the orchestra will never achieve harmony worthy of the composer's art. That harmony is the Desired State of that orchestra at that time, and it can be fleeting.

That's why orchestra conductors are the rock stars of classical music - they create the harmony that breathes life into some of humankind's greatest art. The tradeoffs they must negotiate in creating that harmony are not so dissimilar from those you must negotiate in your datacenter.

These tradeoffs can't be solved by a collection of ad-hoc point tools working in isolation in their own silos of sizing, placement or capacity. Once the physical silos of IT were destroyed by the software-defined revolution, the old silos of IT management needed to follow. But in many ways the silos of traditional IT management have been the most resistant to the revolution VMware created.

The only way to solve the tradeoffs the software-defined world demands is with a unified, software-driven control that can see the forest for the trees. In order to do so, a data model must provide a common abstraction across all layers of the IT stack from the application all the way down to the fabric, hiding the messy details of any single tree in the managed environment - and yet expose a level of detail sufficient to control and maintain the environment as a whole in a healthy state. 

Only then can some mechanism continuously derive the Desired State from the millions of possible states in the average datacenter, and drive the actions necessary to control that environment in that state of health.

VMblog:  And if you would, talk about what's unique to the VMTurbo approach.

Kliger: We designed VMTurbo as a Software-Driven Control platform that would abstract your software-defined datacenter into a software-driven commodities market. And to do so we created a way to abstract every datacenter entity - from server to storage, memory to fabric, and now even network - into that common abstraction I just discussed, a common currency if you like, so software negotiates the tradeoffs we're all forced to make on a daily basis.

Consider the datacenter - it really is a type of market. It has entities that produce or supply resources: CPU, memory, storage, etc. And it has entities that consume or demand resources: applications, VMs, workloads, containers, etc. Supply and demand - just like a market.

Using this common abstraction, this common currency, we effectively teach producer entities how to price their valuable resources based on utilization and other factors, so that when CPU on a physical host is pinned at 85% its price of compute goes way up - not only scaring some workloads off to find cheaper, alternative supply of compute, but also causing some of the workloads already on that host to look to move as well.

That's because we also teach consumer entities how to shop around the datacenter for the best-priced resources based on their budget. Because not all consumers are created equal (a platinum app might have a higher budget to afford the compute on the hot new blade you just installed; a bronze app might have much less, and thus need to move) some workloads won't be able to afford that expensive compute when they factor in all the other resources they have to consume and stay within budget.

It's not that different from a stock market, or for that matter a free market like here in the US. No one told me where to work, or what kind of car to buy or house to live in. Not Ben Bernanke or anyone else. It was up to me to find my own desired state - which I've been able to do in New York founding VMTurbo. And I balance the cost of living there, the opportunity cost of founding a company vs. working at a company like EMC (my former employer), and everything else. Just like every other American.

So if this works for me, why then do we in IT still believe we must dictate to VMs and workloads where they must live, how big they must be, how they must be configured? They're much better at the basic data processing that this entails than humans - consider high-velocity trading in the stock market; that's done by software not humans, right? - so why are we taking some of our most valuable human resources (IT staff) and asking them to try to figure this out by themselves when computers can do this faster and better?

More importantly, why do we continue to accept the traditional IT break-fix cycle? Why is it ok to let something break first and wait for a human to figure out how to fix it - imagine if we did that in the airline industry; there would be no more airline industry - rather than keeping it from breaking in the first place?

By leveraging the market, by taking all this "big data" and giving to the machines as pricing signals they can use to figure it out for themselves rather than dumping it on humans, we can drive the datacenter to this dynamic equilibrium assuring performance while maximizing utilization - its "desired state" - and control it there so nothing breaks in the first place.

In my mind, that's what makes the VMTurbo approach unique.

VMblog:  I understand that you guys have some exciting things coming up in this next release, and the Network plays a big part in it.  Tell us, why is the network so important?

Kliger: Network is important because multi-tier architecture has become so prevalent, leading to an explosion in east-west traffic.

Consider all the benefits that n-tier architecture provides - modularity, reusability, resiliency - and then realize that by design one must tolerate some latency as data is passed between the various layers of that architecture. The key is to minimize that latency - or else you run into spinning beach balls, or worse, blue screens of death.

Latency, however, is poised to become the bane of the software-defined universe. For as more and more is abstracted into software, the less we can keep track of the physical location of anything like a workload. As those workloads migrate due to concerns about high CPU or memory congestion on a host, they may end up residing in parts of the datacenter (or with SDN, perhaps in an entire datacenter entirely) that are many hops away from those with which they must communicate in an n-tier architecture.

The result of which might not only be slow response time, but - in a world of 10 gigabit and beyond switches where a second of packet loss is larger than War and Peace on Blu-Ray - might lead to application failure. Have you ever lost a Skype call before? Imagine that with something much more mission critical.

The key to combating latency is to localize those components (or workloads or containers) that communicate the most. Keep them together underneath the same switch (ideally on the same host) and you not only minimize latency but you reduce the potential points of failure - and in an internet bursting Netflix and high-velocity trades into 10, 40 or 50 gigabit switches, port overload is going to become a bigger and bigger issue.

VMblog:  We're hearing a lot in the industry about SDN right now.  Doesn't it solve this challenge?

Kliger: No. Considering how often certain components chat with each other, depending on demand changes from minute to minute, how on earth are we supposed to keep track of chatty workloads? With a slide rule? With traditional monitors overwhelming us with data? By prayer?

SDN was designed to define networks in software, not control them in a healthy equilibrium where latency is minimized. For that you need a control solution.

VMblog:  Ok, so how does VMTurbo's solution work to overcome latency?

Kliger: We built VMTurbo to stop praying and gain control. Leveraging the market we've already built into the datacenter of over 1000 customers, we now add flow - or the stream of communication between application workloads - to this abstraction, so that your own system can find the healthy equilibrium between the right CPU, memory, storage, network (and on and on) constraints to assure performance without making your CFO scream.

In doing so, VMTurbo not only enables more efficient networks - localizing chatty workloads or containers reduces east-west traffic and top-of-the-hierarchy congestion - but makes the SDN strategy your CIO is demanding less risky. But it doesn't end there.

By bringing flow into the equation and localizing chatty components, VMTurbo helps with your hybrid cloud strategy as well. After all, the last thing you'd want to do is burst something chatty to the public cloud and introduce latency, would you?

By adding flow as one of the resource commodities amongst the workloads must buy, VMTurbo enables your own environment to self-optimize - to effectively work it out amongst themselves through millions of small, real-time negotiations over the price of CPU, storage, memory, flow or even Ready Queue, so that they can tell you where they should reside, how large they should be, how they should be configured. All a user must do is accept the recommendation by clicking yes, or set VMTurbo to automate those decisions and that user's environment will be driven to its desired state.

VMblog:  You mentioned latency in talking about network control, but it also feels connected to application issues.  Is that correct?

Kliger: Exactly. Latency is a killer in applications as well; so reducing that improves overall application performance as well. But it doesn't end there.

As we bring each new commodity into the market, as I said, it improves on the overall equilibrium. So our application control is improved by the reduction in network latency. We can now drive infrastructure to its desired state based on the demands of the application, such as QoS metrics like response time, through our new application control module and reducing latency helps reach goals like that.

In a way, we at VMTurbo are moving from Software-Driven Control to a more Application or Demand-Driven Control - where infrastructure resources are allocated to support application workloads based on goals within each application, such as a 500 ms response time, and application demand. Applications, after all, are the manifestation of any company's mission - how many companies are in the business of infrastructure? - and so it only makes sense to have them drive how the infrastructure supports them.

VMblog:  Another hot technology in the market right now is Docker.  But Linux containers have also been around for a while in the form of one technology or another.  How do you see containers disrupting the market?

Kliger: Containers could completely disrupt the whole concept of VMs (and companies like VMware), and replace them with containers. Architecturally, they are much more efficient in that there's much less redundancy being virtualized making them potentially smaller and more efficient; but imagine the sprawl with millions of containers vs. thousands of VMs. Imagine the complexity.

In many ways containers make the concept of control that we discussed earlier even more compelling.

VMblog:  I have to ask... what else does VMTurbo have cooking right now that you can share with VMblog readers?

Kliger: In the coming months you'll hear more about how we've added hybrid cloud control, VDI control, application control, even container control to our Software-Driven Control platform.

And when you see how we control infrastructure based on demand like quality of service and response time metrics from your applications, you'll begin to see the potential of Demand-Driven Control, which is more powerful than anything we've created thus far.

That's what makes me most proud of what we've designed at VMTurbo - every new entity we add to the marketplace of your environment - whether its an abstraction of network flow, application demand like heap, thread and connection pools, even containers - the better your environment will perform, and the most efficient will it become. We're the only company that understands both infrastructure supply and application demand - and just as important how each interacts and impacts the other. It's really exciting.

##

Once again, it is always great to catchup with and hear from Shmuel Kliger, founder and president of VMTurbo.  Want to hear more from him?  Watch this video interview from VMworld 2014 in San Francisco.