The Riverbed Blog

Riverbed Connect Podcast: Steelhead Cloud Accelerator

 

Introduction to the Riverbed Steelhead Cloud Accelerator

 

Demo of Steelhead Cloud Accelerator

 

Riverbed and Akamai Launch SaaS Acceleration

Today is truly is Super Tuesday (http://en.wikipedia.org/wiki/Super_Tuesday), because in San Francisco, Boston and throughout the world today Riverbed and Akamai introduce the worlds first product for optimizing SaaS application performance.  Software as a Service (SaaS) applications are constrained by network latency and limited bandwidth as their data is delivered to users spread around the world, typically over the public internet. The Steelhead Cloud Accelerator optimizes Microsoft® Office 365, Google Apps, and Salesforce.com® improving performance by up to 50x and reducing bandwidth utilization by over backhauled networks by up to 99%.  

The success of virtualization once made the decisions for IT leaders a question of whether to host applications locally at the edge or in a centralized data center.  Advances in cloud computing applications and services have added a viable third option for leaders considering their network topology today and in the future.  Unfortunately, just as the problems of application inefficiency and latency created by the distance between applications and users wreaked havoc on performance, cloud applications aresubject to similar constraints as well as the added problems that come fromworking outside of the carefully cultivated private networks on the public internet.  These problems can be even more debilitating across backhauled network architectures, which consolidate all access to public internet to a single location, but which add additional network hops and latency for users to contend with when trying to use cloudapplications.  To solve these problems, the Steelhead Cloud Accelerator combines the best of breed in public internet optimization with the best of breed in private wide area network (WAN) optimization. 

The Steelhead Cloud Accelerator is a first of its kind solution integrating Akamai’s globally distributed Intelligent Platform, which optimizes traffic across the public internet, with Riverbed award winning RiOS® (Riverbed Optimization System) technology to accelerate data and application protocols.  The Steelhead Cloud Accelerator delivers optimized performance up to 50x or more for SaaS applications like Microsfot Office 365, Google Apps, or Salesforce.com, regardless of whether the end user is located at the corporate headquarters or in a geographically remote branch office.  This solution is an add-on to existing Steelhead appliance deployments and does not require any changes in the way Steelhead appliances are deployed today or any changes on the SaaS provider’s infrastructure. RiOS will be installed on Akamai’s SureRoute gateways to be activated whenever a customer purchases a license. The RiOS instance on the Akamai gateway will then optimize content and applications to the Steelhead appliance deployed within the customer’s enterprise network. By hosting Riverbed RiOS technology on Akamai’s Edge Platform, the joint solution enables the seamless optimization of WAN and public networks, all the way to the front door of a SaaS application provider.   Best of all, these benefits are provided automatically and transparently to the end user, without the involvement of the SaaS provider or Akamai.  

As the number of choices for IT leaders increases, Riverbed is excited to continue to extend the benefits of optimization everywhere.  Steelhead Cloud Accelerator provides the flexibility to extend optimization to the public cloud and ensures that whatever topology an organization adopts, now or in the future, performance won’t be a concern, which I’m sure you can agree is a super any day of the week!

 

The niceties of TrafficScript

So having worked with several ADC vendors over the last few years, I have had my fare share of interaction with manipulating traffic with a rules based framework like TrafficScript.  One of the niceties of Stingray TrafficScript is that is truly has come from an applications

background rather than a "packet mangling" network appliance.  For example, the first time I had to use TrafficScript to help a customer parse a response body, I was pleasantly surprised when I read the TrafficScript Reference for the http.getResponseBody() command (nb: the interesting bit is underlined below):

http.getResponseBody( [count] )

Returns the body of the HTTP response. 
If the response has chunked transfer encoding this function will return the de-chunked body. Similarly if the response is gzip or deflate compressed the body will be returned uncompressed.
If the optional 'count' parameter is provided, http.getResponseBody() will read and return the first 'count' bytes of the response. If count is 0, http.getResponseBody() will return the entire response.

# Read the entire response body
$body = http.getResponseBody();

Now, having done similar things with both iRules on F5 BigIP and with actions on Citrix NetScaler, the fact that the Traffic manipulation language takes care of de-chunking and decompressing the body content means one simple thing:

With Stingray Traffic Manager, I can spend more time doing what I sat down to do and less time fiddling with the ADC platform...

Simple really..

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.

Is Optimization The End Game?

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's CTO on the non-future of WAAS

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.

Introducing Steelhead CX, EX, and VSP

Senior Product Marketing Manager Joe Ghory provides an introduction to Riverbed's new Steelhead WAN optimization appliance platforms.

 

 

Demonstration of Riverbed Granite

Bob Gilbert demonstrates Granite, which is Riverbed's groundbreaking edge virtual server infrastructure technology.

 

 

Introducing Riverbed Granite

Senior Product Marketing Manager Eric Carter provides an introduction to Granite, which is Riverbed's groundbreaking Edge Virtual Server Infrastructure product.

 

Riverbed Connect Podcast "Game Changer"

Bob Gilbert sits down with Senior Product Marketing Managers Eric Carter and Joe Ghory to discuss Granite, which is Riverbed's groundbreaking edge virtual server infrastructure technology.  Riverbed's new Steelhead platforms are also discussed.

 

 

Riverbed Introduces Suite of New Products and an Innovative Architectural Approach to Completely Consolidate IT

Every once in a while as a technology professional you get an opportunity to work on something disruptive.  This one is big. 

Today Riverbed introduced an architectural approach to consolidated IT known as edge virtual server infrastructure (Edge-VSI).  At the core of edge-VSI is Granite, a first of its kind edge server consolidation product.  

Edge-VSI does for edge servers outside of the data center what virtual desktop infrastructure (VDI) did for desktops:  allow IT to consolidate edge servers in the data center, without impacting application performance at the edge.  To enable this approach, Riverbed introduces Granite, which allows organizations to consolidate servers and storage from edge locations to the data center, yet project the data to the edge of the enterprise as if it were local. 

This innovation decouples storage from compute delivering the best of all worlds:  100% consolidation and control of data while delivering LAN-like performance of applications at the edge.  All at up to 50% of the costs of traditional, distributed infrastructure.

In addition to Granite, Riverbed introduced two new Steelhead product series: 

•  Steelhead CX  - a series of dedicated WAN optimization appliances for the WAN optimization enthusiast

•  Steelhead EX - an enterprise-class branch office appliance series featuring WAN optimization and a VMware virtualization hypervisor for the consolidation enthusiast

Both Steelhead CX and Steelhead EX appliances have more resources (CPU, memory) and deliver more impressive specifications (throughput, TCP connections) than previous models.  Enjoy!

Riverbed Granite In Action

"It does what...?"

I've heard this double-take question more than once as we describe what Riverbed Granite is able to do.  The innovation sometimes takes a minute to sink in.  "Separate storage from compute?  Solve the problem at the block-level? What does that mean anyway?"  What it means is that Riverbed customers have a new arrow in their consolidation quiver.  

By delivering the breakthrough of accelerating at the block-level across the WAN, Granite enables organizations to do things they couldn't do before. We sometimes have described Granite as being able to "consolidate the un-consolidatable."  And its true.  Anyone who has found themselves shackled by requirements for servers in the branch because of the need for local block-storage access should keep reading. In the remainder of this entry I will highlight examples of Granite in action.  In other words - let me give a few use cases - and hopefully if you've got anything considered "un-consolidatable" you'll see how Granite - and the new Edge-VSI approach can help you.

Consolidate and Control

Imagine a growing business - one that is generating a lot of data with custom applications that are running in global locations. You're happy to be growing, but you're left managing servers in places you never thought you'd visit. Ever. You've got valuable data "assets" in locations that lets say are a bit on the sketchy side.  But business is business. Can't strip out the servers/storage or else business can't flow - or can it?  Granite's unique capability to project block-level storage from the data center to the edge means you CAN CONTROL the data in the data center, and run virtualized instances of your branch-bound applications at the edge. Every single block of data is managed on your enterprise-class storage area network (SAN) in the data center even though it is serving the needs of far flung branches. Go and Grow - your concerns about where that data is are alleviated. You know where it is. You control it.

Consolidate and Simplify

What about management? We've heard from many customers about the cost and effort of managing the remaining infrastructure in the branch - servers, storage, backup. Granite and the concept of Edge-VSI make it possible to establish a "stateless" branch office in the sense that virtualized applications can run on compute in the branch but data stores are located within and managed from the data center. Here your business can Grow as you Go.  A site can easily connect a VM to a Granite "projected" storage LUN from the data center.  Size it for today.  Need more space in the future?  Expand the LUN at the data center and the branch gets more space - just like that.  No need to fly in to install new hard drives.  

Consolidate and Protect

Backup in the branch. It's not really your ideal scenario, but the data is there so you've mapped out how to make sure it's protected. Maybe it's a tape backup once every 24 hours - sent back to HQ - and recovery is that in reverse. Or maybe you backup over the WAN. In either case there's the added expense and worry of setting up the infrastructure, managing it - and hoping for the best. With Granite, data that was once thousands of miles away is now within your enterprise SAN - a very well qualified "offsite location". In the data center it can be protected with your mature data center data protection practices. It's much easier to move beyond once-a-day recovery points to something more frequent. Pair that with youre already-established replication between data centers and you've got full fledged enterprise-class protection for that data that was once somewhere "out there." You can restore in a number of ways. Catastrophic loss in the branch? Set up a new Granite Edge and reconnect to the data center. Or restore at a more granular level and stream back to the branch on demand. Even if your active branch doesn't quite appreciate the new level of protection, they will be very happy with faster restores.

Hopefully these use cases illuminate for you what we mean when we say that Granite enables a new architectural approach to consolidation. It is of course exciting to launch a new technology in the marketplace - and we at Riverbed are equally excited for you to try Granite for yourself to see the possibilities it can bring to your business.