Posts filed under 'Software appliances'
August 23rd, 2007
If you missed Ken Novak at LinuxWorld 2007 in San Francisco, here’s a summary and the slides. Ken detailed the strengths of Software as a Service (SaaS) as a business model in “How Virtualization Enables and Threatens Saas.”
- SaaS firms tend to have shorter sale cycles.
- SaaS is a pay-as-you-go business model where customers only pay for the services used.
- SaaS providers scale as the demand scales.
- Remote access from anywhere is built in, not an after thought.
SaaS lacks the software customization and integration that are available with traditional software. The trade-off with SaaS software is updated continuously allowing for rapid customer input and improvement. Additionally, traditional software supports a single tenancy model which is simple and clean.
Virtualization is succeeding in the market place because it offers lower cost, improved software management, and streamlined operations like backup, disaster recovery and load balancing.
An interesting application of virtualization is enabling utility computing. Virtualized utility computing handles the scale up and scale down for SaaS companies. As importantly, multi-tenancy management issues are now the responsibility of the utility company: the SaaS firm’s development and release environment now looks like a simple, clean single tenancy.
Here’s the full presentation: LinuxWorld07Slides
February 19th, 2007
I’ve been a fan of John Sequeira for years. He’s a Boston-based consultant and O’Reilly author who has been way ahead of the curve on virtualization. I remember learning about x86 virtualization in 2003, and thinking about how good virtual appliances might be, when I came upon his September 2001 article that laid it all out. That article included a downloadable VMware vm with the OpenACS content management system — as far as I can tell, the first application-level virtual appliance anywhere.
So I was very interested in his posts last month discussing virtual lab management and hosted virtual machines. Again I like his train of thought. He defines lab management, and thinks about its future:
“when you have a testing environment that consists of many machines acting in tandem, and you need to build up the cluster, test it, and tear it down and restart it, many times and in many different configurations. Covering your test matrix for distributed applications/SOA is hard, and Lab Management is ridiculously easier than the alternative. Lab Management will remain inside the enterprise…”
Naturally at Replicate, where we provide hosted lab management, we think of lab management as a broader need, spreading far beyond the traditional large enterprise. We see labs and testbeds in use in system integrators and consultants, in online service providers, and in technical support groups, all of which need to work with multiple software configurations to reproduce and work around problems, to test new code, or to integrate new packages. We are finding customers that prefer to buy access to virtual labs on demand, rather than pay high startup costs for their own managed lab, plus hiring or training in-house staff to keep the lab current. And as John predicts, we do cost more than the $70/month for raw virtual machines, but not by all that much
John’s main point was to review two large-scale hosted vm offerings, Amazon’s EC2 and the just-funded Qlayer. Both aim at large-scale applications in production, while Replicate focuses on groups of 5 to 50 virtual machines in test lab environments. We’re finding traction with this focus, where our customer gets large benefits without making a big jump in their infrastructure. At least one customer is using our service as a gentle introduction to virtualization — immediate benefits for test and dev, with no fixed cost, while building the virtual machines that could move in-house or into production in the future.
One other point: John emphasizes the “composability” of the virtual machines, and the need for ”making sure all the ports/network address/authentication/file paths etc line up.” We call that meta-info the “application topology,” and modeling and applying it to virtual machines is at the heart of Replicate’s technology. More on that in a future post.
January 25th, 2007
Enter any data center and you’ll see a variety of boxes. Most are servers, and most of the rest are “network devices” that are single-function devices for translating and directing flows of bits: switches, routers, firewalls, load balancers, VPN concentrators, compression engines, access controllers, e-mail filters, multiprotocol file servers, and more. These are appliances in the classic sense: pre-defined function, closed operating system, quick installation (usually!) — the opposite in these respects to the applications that run on servers.
The simple installation and operation are clear upsides. Others have listed the downsides of hardware appliances, and they apply here as well: issues when scaling up or down, issues with spare parts and data backups, and clumsy element-by-element configuration changes. Yet for all but switches, their functions can be reproduced in servers with 2 or more network interfaces (NICs) and, usually, open source software. So it’s no surprise that they make popular virtual appliances. In fact, most of the winners of the VMware virtual appliance challenge were network-oriented devices.
A notable example of a classic network appliance going virtual is the Zeus Extensible Traffic Manager. This is a high-quality load balancer with many extra “layer 7″ functions to route, filter, and cache traffic for web and application servers. It was built on a general-purpose Linux core, and is sold as a hardware appliance. Now it has been released as a virtual appliance. We’ve talked with our prospects here, and they are intrigued: they like the flexibility of starting off with a load balancer, and doing early application testing with one, and being able to smoothy upgrade to a dedicated hardware appliance as their load grows. Other companies whose products have similar values are the Open Source Router from Vyatta, Reflex VSA for intrusion detection, LoadBalancer.org, and Proofpoint’s email filter. (If you know others, please feel free to submit the name and link in the comments to this post.)
None of these will run as fast in a vm as they will in an engineered hardware appliance, where they could conceivably achieve wire speed of 100 mbps or even 1 gbps, instead of a vm’s more typical 25-50 mbps. But then again, it’s rare that most applications ever see that much demand for their services — under 20 mbps is more typical. In fact, there are cases where the traffic from many applications are forced through a single hardware appliance “because it’s there,” when a more logical network topology would separate the traffic and give each application its own appliance. For example, firewalls sometimes have extremely complex configurations because they manage security for many different applications in a single box, when they could be more easily managed with one firewall per application. Disaggregate the traffic and you may reduce complexity and configuration errors, while lowering the traffic rates to levels more suitable for a virtual appliance. As cores become more numerous in servers, it may become more appealing to use them for network functions, replacing hardware and cabling with software.
I’ve seen some data centers where the “network guys” and the “application guys” are different tribes and hardly understand each other. The network guys generally buy and wire up boxes, while the application guys mostly buy and configure software. It’s a little like the old days, with telephone and PBX guys separated from the computer guys (though not as bad, thankfully). The new options for network functions in virtual appliances could cause another wave of convergence, both in the equipment and the staffing in the data center.