An underappreciated aspect of the Steelhead product line is that it has a diverse set of form factors and – crucially – those different packages all use the same optimization architecture, and thus interoperate. What does that mean for a customer? It gives tremendous flexibility to adapt to changes in how data and users are distributed, without needing to cause ripple effects elsewhere in the infrastructure. Let’s consider a simple (and common) example first before we move on to looking at the larger implications.
Organizations often have some branch offices that are very small. For the very smallest offices and individual users, it’s usually not hard to decide that the right solution is to use Steelhead Mobile on a laptop or workstation. And when you get to 10-12 people in an office, both the technology and the ROI arguments for a Steelhead appliance (physical or virtual) are pretty easy to make. But there’s an area in the middle, around 5-6 users, where there’s enough overlap of capabilities that either approach could work. Add to this that a given office may grow or shrink enough so that the original configuration in the office may need to be replaced with a different one.
Using the Steelhead family, these choices and changes at the branch can be accommodated with no additional impact on the data center side. For a given workload from a given set of users, it just doesn’t matter whether they’re coming from a Steelhead appliance or Steelhead Mobile.
Now, if you’re only familiar with Riverbed, at this point your reaction is probably something like “so what? Big deal!” But let’s look at just this one scenario with the #2 vendor: their mobile client doesn’t use the same technology as their appliance, so you have to have two separate data-center infrastructures to support the branches if you have a mixture of the technologies. And as you migrate a given branch from appliance to mobile or vice-versa, you’re changing the load on the corresponding data-center pieces.
That divided-technology approach means that it’s easy with the #2 vendor to be in a situation where an apparently-straightforward change at a branch gets tripped up because it exceeds the capacity of some piece of data center infrastructure. Another layer of complexity comes from the fact that these two different technologies have different network characteristics: their appliance uses an autodiscovery mechanism somewhat like the way that Steelheads work, while their mobile client needs an explicit connection set up to its data-center counterpart. Their appliance marketing repeatedly insists on the necessity of transparency and the avoidance of tunnels, while the mobile client uses a tunnel-based system – so it’s possible that a particular branch network configuration that works with one of the technologies simply won’t work with the other.
It’s tempting to say that the divided-technology problem of the #2 vendor is just a typical lapse by a very large company, and that smaller competitors would have a better approach. So we look at the #3 vendor in our space, which is a private company that prides itself on only doing WAN optimization. But they don’t have any mobile client at all! So their theory is that you should just pretend that you don’t need WAN optimization when you’re out on the road and dealing with networks in coffee shops and hotels – exactly the opposite of most real-world experience. And apparently when your branch is too small to support an appliance or virtual appliance, you should just stop using WAN optimization. (All of a sudden, the #2 vendor looks really good by comparison.)
Before we leave this topic, it’s worth noting that the preceding comparison actually understates the Riverbed advantage. A further advantage comes from the fact that Steelhead Mobile and a Steelhead appliance (physical or virtual) can cooperate via branch warming. In branch warming, Steelhead Mobile and a local Steelhead appliance work together: each time a piece of "optimization vocabulary" is used by the machine running Steelhead Mobile, the mobile client and the appliance coordinate so that both have a copy. As the mobile client is used in the branch office, their vocabularies will tend to converge.
Without spending too much time on the details of how it works, let’s talk about where it’s useful: Sometimes there are enough people in an office to justify an appliance, but the nature of the work means that some or all of them have a significant need for mobility – often because they are salespeople, hands-on repair technicians, or field supervisors. They can use Steelhead Mobile when they are on the road, but they stop needing a mobile license when they’re in the office, and they take the benefits of their office work (newly learned optimizations) back on the road with them when they leave.
Now let’s talk about the bigger picture of why this matters. After all, your organization may not have small branches or mobile users, so that set of examples might not impress you. But the same general principle of agility through a common architecture is more broadly useful, and almost certainly can make a difference to your organization now or in a future configuration.
A way of getting a handle on this is to list out the different “packages” of Steelhead technology:
- Physical appliance
- Virtual appliance
- Cluster of appliances (physical and/or virtual)
- Software client
- Cloud-integrated service
- “Blade” for HP switch
All of these interoperate with each other – so it’s easy to go “physical to virtual” or vice-versa without needing to disrupt the other side of the application. Likewise it’s easy to have a set of services growing beyond the capacity of a single appliance, or migrating into (or out of) a cloud service, without prompting a redesign or redeployment of the client side.
Again, a comparison with the #2 vendor is illuminating. A casual examination of their WAN optimization product line would suggest a similar kind of breadth and agility. They have a variety of packages of WAN optimization technology. But it turns out that the commonality is more marketecture than architecture. That is, they use a common branding for what are actually 3 very-different classes of products: what we might call “main”, “mobile”, and “express.” The “mobile” products can’t interoperate at all with “main” products or with “express” products. The “main” products and “express” products can interoperate, but only at the lower level of function supported by the “express” products. So actually trying to use the #2 vendor products for Riverbed-like agility can lead to all sorts of unpleasant surprises, as WAN optimization functionality either doesn’t work at all (mobile/main and mobile/express combinations) or works with sharply reduced functionality and performance (main/express combinations).
IT organizations need agility and flexibility to meet changing circumstances and demands. The Riverbed single common architecture approach for WAN optimization helps ensure that Steelhead technology can help meet that need.
The Riverbed Blog (testing) 