rPath, the software appliance company and the creators of conary, rBuilder and rPath GNU/Linux. rPath lets you build VMware or XenSource virtual software appliances

When a company builds a web site in the real world, they assemble servers, routers, switches, load balancers and firewalls, wire them up, configure them and go live. But when that application moves into a cloud environment, things change. In a cloud model, the customer isn’t dealing with physical equipment. So who handles all the wiring? And more importantly, how do networking vendors get paid?
Many operational clouds still require their customers to corral their own machines, however virtual. Amazon Web Services is a good example of this. To build an application, the operator still needs to do what they do in the real world — assemble servers, routers and switches to make a data center — only this time, they’re configuring virtual servers instead of real ones.
On the other hand, development clouds like Salesforce.com or Google’s App Engine hide the underlying machines, and handle all the networking equipment — virtual and real — on behalf of their customers.
Either model means a big transition for the makers of traditional networking equipment.
Option 1: Virtual appliances
In a cloud world, the routers, firewalls, and load balancers run inside “virtual appliances” — virtual machines pre-configured to route, block or distribute traffic. Cloud users still have to configure and provision them.
Open-source software dominates the virtual appliance world. For load balancing, Pound is one open-source alternative. For firewalling, there’s IPChains; for routing, Xorp. Some clouds already include these components: Cloud builder 3Tera, for example, offers users a catalog of data center components, including many open-source elements, in its default configurations.
Some vendors stand to gain from a move towards virtual appliances. If you want the kind of service and support you’d get from a vendor, Vyatta does for networking what Red Hat did for servers and MySQL did for databases. And while Checkpoint makes equipment, its software-based firewalls are more easily deployed in a virtual environment than many of its appliance-only competitors. The pendulum swings back to software.
If equipment vendors want to target this market, they need to convert their equipment and licensing models to virtual appliances and differentiate themselves based on software functionality rather than on box color or port density. Companies like rPath and jumpbox both specialize in turning traditional software into virtual appliances.
Option 2: Sell to the cloud operator
But what if the cloud handles the network equipment? This is the case if you’re using a development cloud like Salesforce.com or Google’s App Engine, or if you rely on a turnkey cloud like Joyent or Heroku. The networking equipment vendor sells to the cloud operator.
Which is No Fun At All.
Selling to a utility is notoriously challenging. Carrier sales cycles take months or even years, during which margins get squeezed razor-thin. At the same time, the list of requirements grows dramatically. Because clouds buy tremendous amounts of equipment, they have strong negotiating power. And they often build their own management tools, removing the differentiation a vendor’s software provides.
To make matters worse, clouds may need different equipment. Vendors are innovating, of course: Cisco’s new high-end switching platform, the Nexus 7000, seems well suited to this task. Further, the company has had strong carrier sales since its acquisition of Stratacom in 1996.
Some clouds may even find they have the expertise and economies of scale to build their own equipment. By buying directly from chipset manufacturers and using open-source libraries, they can bypass equipment manufacturers entirely.
One way or another, it won’t happen overnight. While the advent of utility computing is sure to change the networking industry, it will be some time before the trend puts a dent in enterprise IT equipment revenues. Less than 2 percent of CIOs surveyed by Goldman Sachs considered cloud computing a priority.
But someday soon, that load balancer you deploy may be a virtual one. That means two big changes for equipment vendors. One, selling licenses instead of boxes; and two, repositioning their sales forces to sell to telcos and utilities.

User:jeyrb: jey's network's del.icio.us bookmarks
packaging
virtualization
cloud
rpath
virtualappliances
User:jeyrb
There are many changes on the horizon for rPath Documentation.
One of the things that team docs here has known for a while is that the rPath wiki is a fantastic tool to leverage for documentation. It’s quick. It’s easy. It allows engineers to contribute directly to the wiki. It allows community members to contribute to to the wiki.
We’ve also known for a while that this tool has a major caveat...and that is that versioned documentation is costly. For example, if we had say version 1.0 documentation of a project at wiki.rpath.com/v1/productname and version 2.0 came out, we’d have to maintain 2 separate documents with the same information in two different URI’s and 2 different name spaces. With each addition of namespace and project version, updates would be more costly and time consuming.
It’s also a bad thing that a user can search the wiki...and have the possibility of getting results from versions that they are not using...possibly information and behavior of products that no longer applies.
Here at rPath we use our own Mediawiki appliance for documentation (what is a software appliance?). While this is an excellent way of getting things documented quickly (as wiki's are) it is NOT a great place for community based questions to influx nor a good place for knowledgebase questions to be stored. Often, the discussion tab on wiki's go ignored with issue tracking systems replacing problems users have.
The problem with issue tracking systems is they have workflows of their own and often are impartial where they don't need to be
. Wouldn't it be nice if there was a place where like users of software could come together to ask questions and help each other reach conclusive answers? Hence, the rPath Forum was born.
Stef created the Simple Machines Forum Appliance, which you can install and run in various formats such as VMWare, Xen, ISO, RAW, and even a LiveCD (in x86 and x86_64 bit flavors!). What a wonderful concept...to be able to quickly download and deploy a forum using nothing but a virtualized environment ![]()
As some of you know, I've chose Simple Machines in the past at MyPCLinuxOS and PCLinuxOS proper to power those communities. Stef and I are excited to power the rPath community with this same wonderful software.
If you are a packager, appliance developer, Foresight Linux user, or are just interested in our products and technologies such as Conary and rMake...come on over to the rPath Forum and register. Drop us a line and say hello ![]()