OT:
I submitted this because, I was just looking for some open source project in WAN optimization .. and it is really hard to find something, because in google search there is only one project which is annoyingly dominates search results(my guess because of SEO).
Some of those big corps did start out as startups. It is a very hard space to play in especially if software only. With hardware based approaches you just put the boxes inline and that is it. Note that the hardware boxes also do things like have a dual ethernet port card with a relay in it. If the box loses power then the ports are joined together so it still acts as a passthrough. (Our box also had a watchdog that had to be tickled every 2ms by software otherwise the relay would also kick in.)
The network infrastructure needs to be configured to divert traffic to the boxes which is fiddly and becomes a support load very quickly. If SSL forms part of the traffic you want to accelerate then there are two approaches either of which require even more system administration (not network administration).
Once a customer is non-trivial (eg 3 or more offices) then suddenly the sales process slows down drastically as the same product has to be used everywhere and supported by the networking and software people.
What this means is that if you are competing conventionally then it is very hard against the now entrenched vendors. If you are trying to be open source then you will find a very long hard and extremely likely to be an unrewarding slog. Many of the small vendors were out proving the space when the big corps all realised they needed an offering, and did all the acquisitions. The changes of being acquired are very slim now.
> What do you think about Silver Peak virtual WANOP solution ?
No idea. However they aren't a small startup/open source solution like you were originally looking for! Pretty much everyone's solution is written as software that runs on Linux (sometimes BSD). That then gets packaged up on an hardware appliance, suitably tested, marked up and sold.
Consequently not much is needed to make a virtual appliance, although testing is harder as configurations are more diverse. In other words it is likely to be substantially in behaviour to hardware appliances (unless they deliberately exclude things to protect hardware appliance sales).
I used to work for the company that Riverbed was founded to compete with. My favourite party trick was to show new and interesting ways Riverbed could corrupt your data with their CIFS/SMB implementation.
Essentially their technical problem was they defaulted to passing commands through that there wasn't explicit code to detect (by default assume harmless). For example they claimed to support every CIFS client & server out there rather than only ones that had actually been thoroughly tested. Another example is they didn't detect the commands to zero out sections of a file so any app that did that would end up with the wrong data returned or in the file. (As a contrast we only supported actual client and server combinations that had been tested. On encountering a command not in a whitelist we immediately discarded all cached information.) One week I came up with 5 different corruptions they caused. We published one of them with Riverbed then threatening to sue claiming some violation of their user agreement!
Another example is the code had also been written by a bunch of Linux people which means they didn't work correctly with alternate data streams. These leak into the file name space and again affect caching and similar issues. http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28...
I would be ashamed to have taken the technical approach they did, and treated customer data integrity as prime importance. Riverbed wanted marketshare and took shortcuts. Of course most people on encountering file issues with Windows end up blaming Windows so they wouldn't realise their WAN optimiser is actually at fault.
In other respects they did make some good choices. They chose to only accelerate TCP instead of IP as we did, which makes setup and auto discovery considerably easier since you can treat each TCP stream in isolation from the others and put your signalling inline into the stream. They also configured their systems to have some swap available. This provides an escape valve should worst case scenarios happen. Our system was RAM based only which meant code had to be very careful to not end up in a scenario where you need more RAM. This was done by being conservative and preallocating RAM. (You have systems at either end of a connection and they will have expectations of each other - eg that data can be decompressed and already exists in a compression dictionary.)
Their marketing was excellent as they correctly realised people would be reluctant to discard something already deployed, and would instead keep adding more of the same (sunk cost issues). They rapidly built up a customer base of many small customers and that was a good foundation for growth.
The company I worked for was acquired by a large company who then mismanaged it into the ground. Riverbed are pretty much the only ones left standing. I wouldn't touch their stuff due to very different technical tastes - but that hasn't affected their customer base and YMMV.
I think you can't compare those two. at least not in fair apples vs apples way, simply because it is free/open source vs quite expensive/proprietary product.
8 comments
[ 3.1 ms ] story [ 30.1 ms ] threadAnother project: http://wanproxy.org
But still this space is heavily owned by big corps. I guess smart developers/startup could find some real market here.
The network infrastructure needs to be configured to divert traffic to the boxes which is fiddly and becomes a support load very quickly. If SSL forms part of the traffic you want to accelerate then there are two approaches either of which require even more system administration (not network administration).
Once a customer is non-trivial (eg 3 or more offices) then suddenly the sales process slows down drastically as the same product has to be used everywhere and supported by the networking and software people.
What this means is that if you are competing conventionally then it is very hard against the now entrenched vendors. If you are trying to be open source then you will find a very long hard and extremely likely to be an unrewarding slog. Many of the small vendors were out proving the space when the big corps all realised they needed an offering, and did all the acquisitions. The changes of being acquired are very slim now.
What do you think about Silver Peak virtual WANOP solution ?
No idea. However they aren't a small startup/open source solution like you were originally looking for! Pretty much everyone's solution is written as software that runs on Linux (sometimes BSD). That then gets packaged up on an hardware appliance, suitably tested, marked up and sold.
Consequently not much is needed to make a virtual appliance, although testing is harder as configurations are more diverse. In other words it is likely to be substantially in behaviour to hardware appliances (unless they deliberately exclude things to protect hardware appliance sales).
Essentially their technical problem was they defaulted to passing commands through that there wasn't explicit code to detect (by default assume harmless). For example they claimed to support every CIFS client & server out there rather than only ones that had actually been thoroughly tested. Another example is they didn't detect the commands to zero out sections of a file so any app that did that would end up with the wrong data returned or in the file. (As a contrast we only supported actual client and server combinations that had been tested. On encountering a command not in a whitelist we immediately discarded all cached information.) One week I came up with 5 different corruptions they caused. We published one of them with Riverbed then threatening to sue claiming some violation of their user agreement!
Another example is the code had also been written by a bunch of Linux people which means they didn't work correctly with alternate data streams. These leak into the file name space and again affect caching and similar issues. http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28...
I would be ashamed to have taken the technical approach they did, and treated customer data integrity as prime importance. Riverbed wanted marketshare and took shortcuts. Of course most people on encountering file issues with Windows end up blaming Windows so they wouldn't realise their WAN optimiser is actually at fault.
In other respects they did make some good choices. They chose to only accelerate TCP instead of IP as we did, which makes setup and auto discovery considerably easier since you can treat each TCP stream in isolation from the others and put your signalling inline into the stream. They also configured their systems to have some swap available. This provides an escape valve should worst case scenarios happen. Our system was RAM based only which meant code had to be very careful to not end up in a scenario where you need more RAM. This was done by being conservative and preallocating RAM. (You have systems at either end of a connection and they will have expectations of each other - eg that data can be decompressed and already exists in a compression dictionary.)
Their marketing was excellent as they correctly realised people would be reluctant to discard something already deployed, and would instead keep adding more of the same (sunk cost issues). They rapidly built up a customer base of many small customers and that was a good foundation for growth.
The company I worked for was acquired by a large company who then mismanaged it into the ground. Riverbed are pretty much the only ones left standing. I wouldn't touch their stuff due to very different technical tastes - but that hasn't affected their customer base and YMMV.