The Riverbed Blog

Top Ten Reasons why Stingray is better for your environment than a legacy hardware ADC

Since joining Riverbed 3 months ago to be their Lead ADC Systems Engineer here in Australia and New Zealand, I have been overwhelmed with the interest in the Stingray offerings.  For many, they are able to see straight away how a purely software or virtual ADC offering will fit perfectly into their environment.  Some customers that are currently using other vendors ADC products have been asking me to clarify for them the key reasons that we feel the Stingray virtual ADC offerings are better than what the others are offering.  So here it is, my "Top Ten Reasons why Stingray is better for your environment than a legacy hardware ADC":

10:      Virtual / Software ADC is in our blood:

Stingray has thousands of software ADC / virtual customers globally and pioneered this market many years ago.  The Stingray family has both enterprise grade virtual appliances and pure software deployment models, serving some of the largest telco hosting providers, massive clouds and major Financial Services Industry (FSI) providers.  Stingray supports enterprise applications such as Microsoft Exchange 2010 in *massive* environments with a level of flexibility that leaves legacy physical ADCs seem like they are standing still! (No pun intended…)  Gartner reports that the virtual ADC market is growing at 3x the physical one - the world is moving to "Tidal Data Centres", Private, public, and hybrid clouds. Simply put, the last generation was about racking and stacking boxes. But in the next gen of data centers, it's software that wins the day because of its flexibility, scalability, and responsiveness.  Other vendor's ADC virtual appliances are an afterthought to their legacy hardware platforms.

9:        Simplification:

Stingray provides simplification for customers, removing another physical layer of static physical technology and leveraging the virtual server platform you have already invested in for compute power. It is one less hardware platform to manage and one less capex item to refresh every three years.

8:        Performance:

Stingray offers the full throughput – whether it be 4Gbps or 40Gbps for example – regardless of security and other L7 functionality being used.  If you are licensed for 4gbps throughput with Stingray, you will get that full throughput. All you need to do is resource the virtual instance(s) appropriately with your commodity compute.  This is a huge differentiator in any customer looking to do L7 for CPU bound actions like Web Application Firewall (WAF) or complex traffic rules.  I have seen 10Gbps hardware ADC's that could not push more than 1Gbps once the system was doing complex Layer 7 content manipulation, and 40Gbps Solutions that could only do 140Mbps of throughput once the application firewall was turned on!  I don't know about you but if I was getting a 10:1 or 285:1 *reduction* in the throughput I had paid for, I would be pretty unhappy.

7:        Product Packaging vs. Performance/Price:

Our key competitors do not do a virtual appliance higher than 1Gbps throughput.  Customers who start down the virtual ADC path with other vendors will need to move to physical ADCs, or look at a capex heavy physical chassis solution with the same cpu bound performance degradation when using L7 activities like WAF.

6:        Real L7 Application Firewall Throughput:

Stingray Web App Firewall (WAF) is an enterprise grade Application Firewall, used in large clusters by organisations with serious throughput requirements like banks and massive online content providers.  The major differences to physical WAF vendors is the scalability.  Stingray's WAF scales in a totally unique way.  Stingray WAF has 'distributed' deployment models and a solution to the major 'degradation of throughput' issue experienced with physical ADCs that are 'CPU bound in a box'.  Even if you move to carving up a large chassis physical ADC, aside from the major “Cap-Ex” heavy model, you still are performance bound to CPU within the system.

5:        Agile application development/Dev-Ops

Stingray has an all software L7 application history (as oppose to a L4 network origin), which manifests itself in the ability to run in extremely automated deployments.  Because we are software we can be provisioned dynamically the same way that all your other server / virtual servers are.  In addition to this, Stingray is unbelievably application developer friendly.  Whether it is using the built in Rule Builder or Traffic Script capacities, or leveraging existing investments by being able to call custom authentication libraries that can live on box in the built in J2EE environment.  Incidentally, Stingray is already available in Amazon EC2 for example.. How would you like your ADC by the hour?!?!

4:        L7 Acceleration

Stingray Aptimizer provides market leading L7 Web Content Optimisation for Microsoft SharePoint and websites.  There is no better reference than Microsoft themselves using this visionary technology to accelerate http://sharepoint.microsoft.com to reduce page download times.   Who else has a Web Content Optimisation solution the can scale to literally thousands of web servers?

3:        Commercial:

Stingray is either procured 1) as a perpetual license only bought once, not refreshed every 4 years like HW, and is built to provide a 30% or better cost advantage against traditional physical ADC vendors  or 2) As a monthly subscription model for utility compute in a cloud environment. Oh: and our developer licenses are free…  as in beer...

2:        Scale:

Stingray will scale right up all with incremental soft upgrades, no new plumbing, network replacement, new hardware or massive “Cap-Ex” outlay etc.  This provides an unparalleled price/performance model.  In Stingray’s unique horizontal clustering technology, all configs are synced and Stingray can scale up and out active/active to 64 active nodes.   This is how Stingray is able to scale to massive sustained throughputs for media hosting companies while performing heavy duty traffic management.

1:         Automation:

Stingray is the only ADC to provide autoscaling functionality on box to dynamically scale your back end nodes when your application needs it, both on premise and into cloud environments like Amazon EC2 and Rackspace.

Demo of Riverbed's Performance Platform

This short demo covers Riverbed's Cascade, Stingray Traffic Manager, Stingray Aptimizer, Steelhead / Akamai SaaS acceleration, and Whitewater products through the lens of Microsoft SharePoint.

 

Demonstration of Riverbed Granite Edge Virtual Server

This demonstrates the following use cases:

1.  Acceleration of file operations on a remotely mounted disk

2.  Acceleration of booting windows over a WAN

3.  Getting access to consolidated data during a WAN disruption

 

 

 

Watch my 7-year-old daughter demo Riverbed on SharePoint

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.  

 

 

Riverbed is a proud sponsor of the Dimension Data Pro-Am 2012

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

Does Telework...Work???

 

     Dear readers, my name is Boris Kilimnik and I'm the Channel Sales Engineer for Riverbed Federal.  I've decided to create this blog in order to provide my own personal perspective on Riverbed, its technology, and  ways to provide GREAT value to our customers while helping them save money, especially in todays tough economy.

     The Telework Exchange is promoting Telework Week this quarter during March 5th - 9th.  The concept sounds great…work from home during the week, which will save time, money, and the environment.  In fact, "During Telework Week 2011, nearly 40,000 pledged, saving $2,730,229 on commuting costs, gaining back 148,692 hours into their day, and removing 1,818 tons of pollutants from the air, while refraining from driving 3,764,001 miles" (http://teleworkexchange.com/teleworkweek/).  What the article fails to mention is the darker side of working from home…more specifically how much slower enterprise applications perform across the WAN compared to the LAN in the office.  Suddenly e-mail starts timing out, CIFS or file sharing becomes unusable, database performance comes to a grinding halt, you get the point…so yes, telework sounds great on paper but it does come with some serious challenges that need to be addressed in order to make "telework" a reality for the federal market.

     Obviously Riverbed is here to save the day…why else would I be writing this blog post???  However, before I tell you about our telework solution and how a large Federal customer, keep reading to find out who, is using our solution to provide optimization to over 12,000 employees working from home, I will tell you a short story about something that truly surprised me when I joined Riverbed.

     When I received my laptop during my first week at Riverbed, the first thing I noticed was a little "r" icon by the clock.  This was the Steelhead Mobile Client, which I learned is loaded on every single laptop for every employee in the company.  If you have no idea what the Steelhead Mobile Client is then PLEASE e-mail your Riverbed Rep ASAP, but essentially it is the same technology that is in every Steelhead appliance but packaged as a software that runs in the background of any Windows or Apple computer to provide WAN Optimization directly to the desktop/laptop.  At that point I realized that at Riverbed we don't just create and sell WAN Optimization technology but we use it internally and benefit from it as well.  How many of our competitors sales reps use their own mobile client on their laptops?  I guarantee you the answer is none.  At Riverbed we eat our own dog food, and that allows us to confidently go into any account and talk about the virtues of our mobile solution since we use it internally every single day.  Download WhitePaper-Riverbed_Relies_on_Riverbed  In fact, the screen shot below demonstrates the performance gains I have been able to realize with Steelhead Mobile on my own laptop…about a 67% reduction in total WAN data with a 3x capacity increase.  What this means is that on average I use 67% less bandwidth across the WAN, which really makes an impact when I'm traveling and am using either my iPhone, GoGo in the air, or a shared internet connection in a hotel.  Without Steelhead Mobile, applications such as Email sometimes don't work at all, especially when I'm traveling in remote locations…but with Steelhead Mobile, enterprise applications such as Email work just as fast as they do over my high speed link in the office.

     Going back to our federal customer…the customer is actually an agency within the Department of Commerce that issues patents and trademark registration.  In fact, there is even a personal side to this story.  Both of my next door neighbors are patent examiners at this agency.  About 3 weeks ago they were upgraded to new laptops with the Riverbed Steelhead Mobile Client running, and in their words, the performance difference was like night and day.  With Riverbed, all of their applications became significantly faster, which ultimately allowed them to be more efficient and expeditious in examining patent application, therefore increasing their performance and providing a significant ROI to this federal customer.

     Bottom line…telework is becoming a reality, and the only way your customers will be able to work as efficiently from home as they do from the office is by using the Steelhead Mobile Client technology from Riverbed!

-Boris Kilimnik

boris@riverbed.com

 

Application Delivery Controllers – it’s all about the Application

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.

Extending Stingray Traffic Manager with TrafficScript

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.:

• You can use a rule to dictate session persistence information

• Rules can be used to check the response from the server and modify it, or even retry the request (if possible) if a transient error was detected.

•  If you use various back-end systems with different presentation styles or even different protocols, rules can be used to integrate them into a single, coherent and consistent service. Incoming requests can be rewritten into the format suitable for the required service, and responses can be rewritten into a single, consistent form.  For example, HTTP requests that involve a database lookup can be rewritten into SOAP request for a Web Service; the XML response can then be transformed into a suitable HTML document to return via HTTP.

• Rules can specify custom behavior for each connection; e.g. connections to a slow resource can be given a longer response time tolerance for example.

• Security:  You can use a rule to check packets for a match with known web worms or viruses.

• Data Protection: you can write rules that ensure that sensitive data like credit card numbers or social security numbers are automatically hidden even if they were to be displayed in the output of a web page by accident.

 

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.

 

 

 

Where's WAAS 4.5.1?

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 31^st. 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 8^th 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.

Welcome to the Cloud Storage Gateway Market

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.