eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.