Last March, I recorded my 6-year-old daughter installing Riverbed's flagship Steelhead WAN optimization appliance. You can watch that video here.
My daughter has been bugging me to do another video so I took her to my office last Saturday and recorded her demonstrating Riverbed's performance platform on Micrososoft SharePoint. This is a good way to learn how Riverbed's family of performance products is all about.
Dimension Data partners with Riverbed to deliver consultative, professional, and managed/outsourced services to multinational clients worldwide. Dimension Data’s Uptime service also provides Riverbed customers with additional value-added capabilities relating to Level 1 and Level 2 support.
Riverbed is proud to be sponsoring this week's Dimension Data Pro-Am golf event.
It looks like the course is ready. It's almost tee time!
1st Tee
18th tee
Yet again, we hear the same tired, old line that a software ADC is somehow “a lower-end solution. It's got all the functionality but it doesn't have the performance”. In a recent interview, F5 CEO John McAdam went on to assert that software offers “single-digit gigabits-per-second vs. hundreds of gigabits-per-second” for an integrated hardware solution. This simultaneously flatters F5’s own Virtual Edition (which tops out at 1 Gbps) and overstates the real-world capacity of integrated hardware appliances that depend on hardware fast paths to achieve such performance heights; layer4/7 fast-paths that preclude the use of the sophisticated ADC functionality that is often needed to support the application.
The application and infrastructure experts who take responsibility for the successful deployment and delivery of a business’s applications think differently in term of performance: page views, site visitors, number of customers, transactions per second, and service levels and page load time. These need to be measured within the context of the specific capabilities of an ADC that are required to deliver the applications effectively. Performance depends on the efficiency of the ADC software and scales with the CPU capacity of the server or appliance.
Measuring the value of an ADC solution in terms of gigabits alone is understandable when hardware is your differentiator, but it misses the value of an ADC. The value that distinguishes an ADC from a network load balancer is realized when it finds it way to the individual who understands the needs of the applications. An ADC is a tool to help deal with unexpected application problems, application security vulnerabilities, flash floods that need smart prioritization, to facilitate routine maintenance, yet so often we hear the same complaint from application owners at organizations where hardware ADCs are incumbent – frustration that the tool that might fix their problem is managed by another team who have very different goals, constraints and SLAs.
Organizational changes alone cannot resolve these difficulties. There will certainly always be a place for the hulking hardware ADC-asaurus, exiled to the edge of the datacentre to perform basic load balancing and routing with little thought, but the more challenging application delivery problems need the flexibility and scale that only an on-tap software solution can offer.
The emerging datacentre infrastructure, whether physical, virtual or cloud, shows two qualities – programmable to the needs of the business services that are delivered, and responsive to the needs of the applications that make up the services. Insisting that an ADC will always be tied to a piece of tin fails to recognise neither this trend in infrastructure, nor the needs of the new application users of advanced ADC functionality.
We’re proud to find ourselves helping customers to achieve things with their applications that they could not do with our technology. Software (ADC, web/app server, whatever), in the hands of the application experts, enables quick prototyping, rapid application release cycles, flexible and immediate test environments, and our customers know their investment in our Stingray technology can grow and move with them as their business grows with their success.
One of my duties as a Channel System Engineer is to update our partners on our new technologies and products. In the recent months after people heard that we acquired two new outstanding technologies, I was often asked why believe that the Zeus ADC now Stingray Traffic Manager is superior to other ADCs on the market.
Of course there are many different correct answers to this question. But for me one of the main reasons is its flexibility, scalability and of course the fact that it is highly customizable, making it a solution that is easy to adapt to all the customer scenarios out there.
For those who might have missed it: Stingray Traffic Manager is a high-availability, application-centric traffic management and load balancing virtual ADC. It provides control, intelligence, security and resilience for all application traffic. Stingray Traffic Manager is intended for organizations hosting valuable business-critical services, such as TCP and UDP-based services like HTTP (web) and media delivery, and XML-based services such as Web Services.
Stingray Traffic Manager’s architecture ensures it can handle large volumes of network traffic efficiently. Its scalability allows you to add more front-end traffic managers or back-end servers as the need arises. The cluster size is unlimited, and the performance of the traffic manager grows in line with the performance of the underlying hardware.
These are all amazing features Stingray TM provides for scalabilty and felxibilty, but today I would like to talk specifically about one of the capabilities of the Stingray Traffic Manager that extends the possibilities mentioned above and makes it highly adaptable beyond what would be achievable with a monolithic approach: TrafficScript.
Using the TrafficScript language you can write tailored traffic management rules to inspect, manage and route requests and responses in every imaginable way.
TrafficScript rules can be executed whenever a new connection or network request is received, and whenever it receives a response from a node. The rules you create inspect the incoming and outgoing data in the connection, and other aspects such as e.g. the remote client address, destination address and port. You can write rules that can then modify the request or response (for example, rewriting the URL or headers in an HTTP request), set session persistence parameters, or decide how to route the request or even rewrite the content of the output page.
There are many occasions when you might want to use a TrafficScript rule.:
One of the great properties of TrafficScript is that it is easy to learn and understand! Even for people with little coding experience. You don’t have to worry about having to learn an entirely new, complicated scripting language, TrafficScript will look familiar even to the untrained eye.
Here are two examples of TrafficScript rules:
1) Restricting Access Based on the Time of Day
This example only allows access to a particular service during office hours (between 9am and 6pm, Monday to Friday). It discards all connections that occur outside these times.
$dayofweek = sys.time.weekDay();
$hourofday = sys.time.hour();
# $dayofweek: Sunday is 1, Saturday is 7
# $hourofday: office hours are between 9am and 5:59pm if( $dayofweek == 1 ||
$dayofweek == 7 ||
$hourofday < 9 ||
$hourofday >= 18 ) {
log.warn( "Warning: access out of hours!" );
connection.discard();
}
2) Customer Prioritization
This example inspects the cookie in an HTTP request. It uses the value of the cookie to determine which pool to direct the request to. One pool is faster than the other because it contains machines that are reserved for premium users.
A company has a customer base divided into “gold” and “silver” membership. It wishes to give priority to the “gold” customers and has five servers, yellow, green, blue, black and purple.
Two server pools are created: standard, for the “silver” customers, containing machines yellow, green and blue; and premium, for the “gold” customers, which includes all five of the servers. Thus black and purple are only available to the “gold” customers.
The site uses a cookie login system, with the customer type encoded in the cookie. Different membership levels can be detected, and sent to the correct pool. This is the script needed to achieve this:
$cookie = http.getHeader( "cookie" );
if( string.contains( $cookie, "gold" )) {
pool.use( "premium" );
} else {
pool.use( "standard" );
}
5 short lines of code to ensure that your premium customers get the best possible service!
These two short examples show that TrafficScript is indeed a very approachable, easy to learn scripting language. The best part is: our outstanding Support Team will assist you if you have problems writing or adaptig your own TrafficScripts.
This is part of your support contract and ensures that there is someone around to help you at all times at no extra cost.
For a detailed overview and syntax to get you started, take a look at our Stingray Traffic Manager TrafficScript Guide.
Of course there is also a community of TrafficScript Users that can help you with your first (and further) steps. Visit them at http://community.riverbed.com/t5/Stingray-Family/ct-p/zeusproducts for code samples, answers to your questions and further documentation.
When is a release not really a release? When it’s a Cisco WAAS release.
Some background to help explain that cryptic opening: Cisco promised last year as part of their announcement with Citrix that a new release of WAAS with optimization for ICA was “targeted for Q4”. At the end of Q4, still no new version of WAAS.
Well, that’s not all that interesting. Lots of companies don’t quite make their targets or deadlines, especially in software development. It’s the next part that gets interesting.
The release note for WAAS 4.5.1 finally showed up on cisco.com on January 31st. I was checking pretty much every day, and I guess someone decided that one month past the end of Q4 was as late as they could manage. But already things were looking weird. For one thing, the release notes showed a date on the index page of “23/Nov/2011” which I knew wasn’t true (see screen shot below)
Reading the release note itself, it told a different lie about its release date: “November 30, 2011” (see screen shot below)
And the strangest part? The software isn’t really there. The latest release showing on the “Download Software” page even on February 8th was still 4.4.3c, and the highest release number showing under All Releases was still 4.4 (see screen shot below):
What the heck is going on here? The sort-of-explanation from Cisco appears in a support forum:
“[WAAS 4.5.1] is available internally but it was not posted publicly on CCO because Citrix deployments are still very new and thus, may require some tweaking of the configuration to operate properly.”
(see screen shot below)
Most people in the software business would say that something “available internally” that “may require some tweaking… to operate properly” is beta code, not released code. Cisco seems to want to have its cake and eat it too – they want to claim that they’ve released 4.5.1 even though something in the new features seems to be causing them challenges.
(So much for the vaunted “Citrix-Ready” certification that Cisco has been touting. Apparently WAAS 4.5.1 managed to get this badge from Citrix, even though Cisco thinks it’s not stable enough to release without babysitting. Incredible.)
I'm sure that Cisco will fix these problems. But it's interesting how the WAAS team can get itself tied into knots on something that just doesn't seem that complicated. After all, you'd expect them to have their software qualification and release processes solid by now. And I can't resist pointing out that Riverbed has been releasing RiOS versions supporting ICA optimization since February 2010 without any of this kind of weirdness.
Amazon is an excellent cloud storage partner of Riverbed Whitewater. Riverbed Whitewater gateways and Amazon Simple Storage Service (Amazon S3) are tested and proven in production environments at many mutual customers today.
While both offerings fit into the broad category of cloud storage gateway products, Whitewater is an industrial grade, optimized solution purpose built for data protection that supports all leading data protection software applications. This optimization includes substantial engineering investment around backup applications that enable Whitewater to achieve higher levels of deduplication and performance compared to general purpose iSCSI based gateways. Whitewater leverages Riverbed’s proven byte level deduplication and WAN optimization technologies that greatly reduce the size of the cloud data stored and therefore, monthly storage costs, in addition to speeding the transmission to and from the cloud.
Security is a top concern of our customers and Whitewater secures the data using strong encryption within the gateway itself and during transport to the cloud. Further, the encryption key is kept safe and under customers’ control in their data center which eliminates concerns about the cloud storage vendors’ or a rogue third party’s access to the data. Riverbed’s approach is far more secure than Amazon’s gateway where key storage and encryption are both done within the Amazon cloud.
Freedom of choice is a common request from our customers and Whitewater delivers in its support of all leading cloud storage providers. Riverbed provides this flexibility as well as the ability to deploy either virtual or physical gateway appliances. Riverbed’s industry recognized support – available 24x7 addresses the needs of the most demanding enterprises and ensures fast response should an issue arise.
We welcome Amazon’s entry into the cloud storage gateway market with their recent announcement as we feel this will accelerate the market. Customers interested in a production quality gateway for data protection will no doubt see the many advantages of Whitewater.
Dare I say it?
Ok, I’ll whisper it quietly; there is something beyond optimization and acceleration!
For a long time Riverbed have been telling the World about how to optimize, accelerate, monitor and report on network application traffic. But optimization and acceleration have a finite limit; there is only so much performance you can squeeze out of your infrastructure. At some point you are still going to reach a weight of traffic that the infrastructure is unable to cope with.
It is likely that the first things to suffer will be the web or application servers themselves, especially once you have removed the latency and bandwidth restrictions from your WAN using Steelheads. So what then? Do you just have to accept that this is the case, or deploy more resource to just sit there waiting for these high tides of traffic?
Obviously the answer is no, or I would not have started writing this blog post!
What’s required is intelligence in the data centre, to monitor application responsiveness and to take appropriate action when the performance hits thresholds set by the business. But what is the appropriate action? This is entirely down to the nature of the organisation and the applications that are critical to it.
A couple of examples:
Your organisation has an internal CRM; it is used to handle all the day to day admin required for your customers and also the payments application. On occasion at the end of a month, or more importantly at the end of a quarter, the application slows down to a nearly unusable state. The business requirement here is to ensure that the users inputting orders always get a good service, even at the cost of the users making administrative changes. Remembering that this may be the same user at different times.
Enter Stingray Traffic Manager; deployed in front of the application servers it is able in the first instance to have some impact in improving the performance. Secondly using a feature called Service Level Monitoring, it is able to recognise when the servers start responding slower than the acceptable threshold configured by the business. At this point the choices are numerous, in this particular instance it was decided that the best solution would be to start applying a Request Rate Shape to the less important traffic, slowing down the number of requests per second going into the admin side of the CRM. This frees resource on the application servers, that is then used by the payments service, increasing responsiveness.
When the high tide starts to subside, the service level monitor also picks this up and stops enforcing the rate shape on the admin users. From this point on everyone is getting a good level of service from the CRM.
The second example is of an online, Internet facing business, an eCommerce type site or similar (banking, gaming etc. they all have very familiar issues and requirements).
In this example all users are accessing the same application, and it is the type of user rather than what they are using that we wish to use as the key to our differentiation. Let’s imagine it is November and traffic to the site is starting to build up, with the peak periods causing slow-downs to the service. The business decides that they want to do two things: differentiate between people who have visited the site regularly (and spending lots of money), and those who have visited infrequently or not at all. They also want to make a decision based on what the user has in their shopping cart, which trumps whether they are a frequent visitor or not!
Here comes Stingray Traffic Manager again…
In this case we can use the same Service Level Monitor feature, to be the trigger, and also use Request Rate Shaping to apply different rates to the customers (based on a cookie placed in their browser from previous visits). But we will also have a dedicated “auto-scaling pool” of servers available for those customers who look to be spending big with us today!
Auto-Scaling is a feature that allows the Traffic Manager to communicate with a back end provisioning system and arrange for more resource to be made available. Hitting the API on vCenter, for example, and getting a second (or third, or forth etc.) web server spun up in our ESX Cluster to then spread the traffic load across.
In this case we will have two pools of servers for the Traffic Manager to select from, a normal pool with three servers in it, and an auto-scaling pool that starts with zero servers in it. When the normal pool is coping with traffic happily then all users connections are directed and load balanced to these servers. When it starts to get busy, then users with larger values in their shopping carts are directed to the “auto-scaling pool” that immediately starts to add servers as they are required (either to a limited number or until the service hits an acceptable level of responsiveness). In the other pool of servers because there is a limited number of nodes available, a rate shape is applied based on whether you are a Band A customer or a Band B, C or D. Band A being those customers with a cookie indicating they have spent over $200 this year, Band D meaning the customer has no cookie (i.e. likely to be a new user), and the B and C bands being lesser spending customers.
In both of these examples the result is that traffic/users/applications are prioritised and handled in the way the business requires them to be, based on the present circumstances and the logic put in place. This is the key to TrafficScript (the scripting language at the heart of the Stingray Traffic Manager) it is a tool to turn a business requirement, into the reality of what happens to the application traffic on the network.
So to answer the initial question, no, optimizations and acceleration are not the end game; they are extremely important steps on the way to the end game. But what is really needed is a holistic approach that uses the resource available to it’s furthest limit, but when that resource limit is reached business logic is applied to ensure the organisations objectives are reached.
[NB1]What’s the proper byline we use here?
Cisco CTO Padmasree Warrior made some comments about WAN optimization earlier last week. Naturally I was interested for competitive reasons, because it’s useful to understand how the WAN optimization market looks to someone senior at Cisco.
First, a disclaimer: the source is an article in the trade press, and it’s quite possible that Ms. Warrior was misquoted or misunderstood. So I must acknowledge that what I’m analyzing is not as solid as something that she wrote in her blog or said in a context where I could have heard it for myself.
Next, let’s review the context. Gartner recently released a new “Magic Quadrant for WAN Optimization Controllers.” If you want to read it, follow this link. Gartner is very strict about how we are allowed to refer to the content of the MQ, so I’m not going to even try to characterize the relative positions of the vendors there; but suffice it to say that Cisco fans weren’t happy. So the question to Ms. Warrior was essentially, how did she react to this situation?
A further observation of context here: Ms. Warrior is the CTO of a $40 billion (annual revenue) company, while the company’s WAN optimization product WAAS brings in only about $200 million – a mere 1/2 %. So it would have been understandable if she had deferred the question pending further research. (Even in much-smaller Riverbed, I have come to terms with the reality that I am unlikely to know everything interesting about every product.)
But instead she made two assertions: first, that WAN optimization is really just a feature to be delivered by Cisco network platforms; and second, that such integration is prompted by cloud and software-defined networks.
Those of us who’ve spent some time with WAN optimization are very familiar with the Cisco claim that WAN optimization is merely a feature of routers. Indeed, some ten days before the Riverbed IPO in September 2006, Cisco hosted a “Tech Talk for Investors” webcast by George Kurian, who was then GM in charge of Cisco WAAS. Here’s the summary from the announcement:
WAN Application Acceleration is one of the fastest growing market segments in enterprise IT infrastructure. This webcast presentation will review the key requirements of this space, and illustrate how Cisco is best positioned to take leadership in this market with the recently announced Cisco Wide Area Application Services (WAAS).
Unfortunately, that talk is no longer available on Cisco’s investor relations site (it would make for fun listening if it were) but the ideas put forward were also reflected in a number of articles in the trade press at the time. Entertainingly, among the articles reporting the 2006 Kurian pitch about network-integrated WAAS was one in the same British IT publication that also reported Ms. Warrior’s 2012 version. In that old article, we learn that Cisco’s approach is to “slot into existing IP networks and infrastructure, improving WAN performance without disrupting existing day-to-day processes and functionality.” Talk about déjà vu!
Here we are some six years later, and the underlying ideas are basically unchanged. The old wine of “network integration” is being put into new bottles labeled “cloud” and “software-defined networks” but there’s clearly no real rethinking happening. Apparently a continuing decline in market share and the less-than-thrilling Magic Quadrant showing aren’t enough to prompt people to try a different course. And WAAS as a product appears to have no future, to judge from Ms. Warrior’s view on integration. As a competitor, this is fine with me; but if I were a Cisco shareholder I might be annoyed.
What’s particularly ironic about Ms. Warrior’s reaction is how it relates to the underlying Gartner criticism that prompted the Magic Quadrant change (that in turn gave rise to the question she was asked). The MQ has two dimensions, "ability to execute" and "completeness of vision." Cisco's problems were mostly on the “completeness of vision” dimension. As the 2012 article indicates, there were specific concerns raised about the speed and quality of innovation. Cisco’s CTO inadvertently confirmed the diagnosis by being unable to say anything interesting about the future of Cisco WAN optimization.
Senior Product Marketing Manager Joe Ghory provides an introduction to Riverbed's new Steelhead WAN optimization appliance platforms.