eWEEK Senior Editor Darryl K. Taft speaks with WebappVM CEO and co-founder Issac Roth about running applications in the cloud and why the company has focused on the virtual layer, as opposed to traditional agent-based technologies.
There is no doubt that cloud computing has made its way into mainstream use.
And the demand for cloud services is only getting stronger. But as businesses
increasingly pour more resources into cloud computing, how can they ensure that
their mission-critical apps are cloud-ready? It's no mystery that deploying and
running an application in the cloud is no easy feat.
WebappVM, a startup with early backing from Marc Andreessen and Ben
Horowitz, knows this problem all too well-its founders worked at Wily Technology
managing different agents to help developers put apps in the cloud. Now,
they've developed a technology that is "agentless," meaning there's much less
hassle in getting your app up in the cloud. eWEEK Senior Editor Darryl K. Taft
spoke with WebappVM CEO and co-founder Issac
Roth about running applications in the cloud and why the company has focused on
the virtual layer, as opposed to traditional agent-based technologies.
How did the idea for WebAppVM come
about?
When I first used VMware and saw how systems management-backups, network
monitoring, systems monitoring, HA-could be executed from "underneath"
the system, the light bulb went off for me. I thought, "This is the way
application management has to work-in a layer -underneath' the run-time
platform and not using agents, which are inserted."
At the same time, I was starting to see patterns in the way customers were
deploying their applications that would allow for the insertion of this kind of
technology at the application level. This idea really cemented when I read
about VMsafe. I thought: "This is how the world is going to work."
Agents are just too complicated and painful-on configuration, on
integration, on maintenance, on interdependencies. Despite the inertia on
agent-based management, you can see what is happening in the systems world: We're
going to a layer, and people are realizing how much better it is.
You attracted early stage funding
from Marc Andreessen and Ben Horowitz. What was it about your idea that
impressed them most?
Ben and Marc started a company 10 years ago, LoudCloud, with the idea of
operating Web applications in the cloud and getting application teams out of
the "undifferentiated heavy lifting" often cited by Amazon's Werner Vogels. Through
Marc's experience with LoudCloud [now Opsware] and Ning, he understands how
much of this goes on when the application team wants to be able to add
functionality without messing up the infrastructure.
Ben was recently in charge of the application management software from HP
and is very familiar with the pain and high costs associated with the
agent-based management approach. It's clear that enterprises are moving their
applications to clouds-whether public, private, internal, external, hybrid, etc.-and
they're not going to put these applications in production without application
management. Our approach of using a layer to provide the management instead of
agents and admin servers was very easy for them to understand as a paradigm
shift that would bring a lot of value to teams operating Web applications.
We hear a lot about cloud computing's
promises. What are its pitfalls?
In the short term, IaaS [infrastructure as a service] providers are still
evolving. There are only a small number of viable cloud platforms-public,
private, external, internal-and this lack of choice is holding back adoption.
It reminds me of when Jeep was the only one making SUVs. They invented an
incredible category there, but it didn't become mainstream until the customer
had choices: an SUV from Ford, an SUV from Dodge, even now a Porsche SUV. When
all you could buy was a Grand Cherokee, if you didn't like the particular
tradeoffs they'd made, you just didn't buy an SUV. Now you have many choices,
and as a result the category expanded dramatically. We need that type of
evolution to happen with cloud platforms-more options, more differentiation.
In the long term, developers are going to have to learn how to work in the
cloud. Operating applications on a cloud is simply different. Some existing
processes, techniques and knowledge will translate, but some will not. The
advantages that cloud brings are undeniable, so the transition will occur, but
enterprises are going to need to learn new ideas, adapt processes and adopt new
technologies. There are many vendors trying to make this transition as smooth
as possible, and we think we have a terrific way to take existing applications
without modification and run them on clouds. But to think that a developer or
operator can start running their application on a cloud and not have to learn
anything new ... that won't happen.
What are the challenges of deploying
and managing applications in the cloud?
At the discipline level, they're the same challenges you've always had with
deploying and managing applications: change management, performance monitoring,
audit and compliance, security, end-user experience management, and so on. At
the technical level is where things are a little different. People deploy to a
cloud because they want the benefits: elasticity, instant provisioning of new
environments, lower cost operations. If you use all the old approaches and
tools on the cloud, they negate all the benefits of using the cloud.
So the challenge of deploying and managing applications in the cloud is to
find ways to do all the management while maintaining elasticity. That means you
need a solution that will allow you to scale the application at low cost, let
you choose different cloud providers as better options become available, that
works inside and outside the firewall, that enables you to get fully managed
environments in an instant instead of getting a virtual server in an instant
and then waiting six weeks to get management functionality on that virtual
server.
Why do you think the virtual layer is
a better delivery mechanism?
With agents, although the vendors do a decent job trying to make them insert
easily, you still have to change your application setup to insert them. It's
not so bad when you have just one, but if you get a combination of agents
(which is needed because they each have different roles-application monitoring,
system monitoring, configuration management, log management,
scaling/deployment, etc.), it really starts adding up. And remember each one is
talking back to a management server that has to be configured and sized and
scaled and maintained.
By going in as a virtual layer, there is a small upfront effort to deploy in
a different way-which you have to do anyway for cloud deployment-and then you
get a rich and growing set of management functionality for "free."
The application doesn't know anything is different. Another advantage is that
new features can be added to the management without introducing new integration
points on the agent. Sometimes you can upgrade an agent and get a couple new
features, but often to get whole new areas of functionality, you end up putting
in yet another agent. In the layer approach, new things can just show up and no
additional integration is needed. So it's a much more scalable approach. Then,
you can take the application off the layer and everything goes away. ... There's
no uninstalling of agents and reworking of startup scripts or anything like
that.
What are you hearing from developers
who have tried the virtual route?
Visibility is a big issue. The first question everyone has is whether the
hypervisor or cloud is robbing the application of something important-disk I/O,
network I/O, CPU cycles, etc. How are transactions performing in the face of
this possible robbery? The next issue is that cloning and snapshots don't turn
out to be as cool as people thought they would be. There's too much application
state that is stored outside of the code itself-it turns out that you can't
really scale up an app by cloning the VM and you can't really roll it back by
reverting to a previous snapshot. Application-aware mechanisms are still
needed. One of the most useful things is the ability to rapidly spin up new development
and test environments. That means, no more waiting for admins to rack servers!
Because of the snapshotting/cloning issue, you still have to worry about making
sure that new environment you spun up is consistent with your target
configuration, but at least you're not waiting for servers to arrive on a
loading dock.
Email
Print
