Blog

A nice video that introduces Riverbed

 

What is this Stingray Traffic Manager, anyway? Part 7: High Availability

Stingray Developer Alex Gosse discusses some of the High Availability features found in Stingray Traffic Manager.  If you lose sites, servers, or other critical services, Stingray Traffic Manager can help your web presence keep right on going.

 

Request Rate Shaping – applying limits with fine-grained control

Setting the scene

Imagine you’re part of a team that oversees and manages the web applications in support of a website and service. At certain times of the year, the website and service experiences an overload of visitors looking for information or wishing to purchase products or services.

Unfortunately at this point a huge volume of requests start building up which have a detrimental effect on the performance of the website and service a visitor experiences. The response times for requests become unacceptably slow and visitors get frustrated.

This situation can be made worse if you have limited scalability in the back-end infrastructure, which cannot be scaled up to meet these demands. At this point you may wish to restrict the rate at which requests are received by the back-end servers and applications.

Applying limits with fine grained control

Allow me to suggest an approach that might help you to limit these requests in an elegant way.

One approach would be to measure the performance of the infrastructure and services with Riverbed Stingray Traffic Manager's Service Level Monitoring. If Service Level Monitoring indicates that the service's response time rises above a certain threshold, that's a strong indicator that the infrastructure performance level has dropped. Taking action at this point is all very well, but how do you know which type of users of the service to apply this to?  So, before any action is taken, you need to classify the users of the service in some way as to differentiate between them. You will then be able to decide which users of the service you would want to rate limit. Because of the unique way that Stingray Traffic Manager inspects client requests you will be able to determine the location, content or frequency of the request and then classify the user accordingly.

So, you might wish to classify those visitors that are simply browsing the site and are not actively purchasing products or services, e.g. they don’t have anything in their ‘shopping cart’, as low priority during periods when the infrastructure is under strain.

Once you have decided on when to apply a rate-shaping class and which users it will affect, next you apply the rate shaping class. So, when the service and infrastructure starts to become overloaded you would limit the users in the class to a particular level of service. The result of this action is that ‘high priority’ users of the service – those actively engaged in the ‘shopping cart’ process will continue to receive the same high quality of service despite the infrastructure being overloaded.

This is just one example of how Riverbed's request rate shaping might be applied in a real world situation. See Tickets, a current Riverbed customer, is an example of how request rate shaping and Trafficscript has been used to ensure its website is always online and fast, even during extreme-peaks in traffic, so valued customers receive an excellent online service. Read the full case study.

If you who would like to get a more detailed insight into our request rate shaping capabilities, the following white paper will be of interest: Traffic Valuation and Prioritization with Stingray Traffic Manager.

Image sources: Systrax, funk:tion

What is this Stingray Traffic Manager, anyway? Part 6: Ultimate Control

The Riverbed Blog will be taking a couple of days off to enjoy turkey with its family.  The blog will return on Monday, November 28.  Happy Thanksgiving to all of our US-based friends and colleagues, and to anyone else who celebrates.

Developer Alex Gosse demonstrates the flexibility of some of the Stingray Traffic Manager features. He shows how you can modify application traffic as it moves through, through rules management.

 

What is this Stingray Traffic Manager, anyway? Part 5: Deployment

In today's video, Owen looks at the variety of ways that Stingray Traffic Manager can be deployed, and how easy that deployment is.

 

On the importance of secure software layers

Writing high quality software is difficult. Writing secure high quality software is even more difficult. Perhaps because software is still a relatively young discipline, certain aspects present real challenges:

• Its specification languages allow for a broader interpretation of procedures and tasks
• Its product attracts a disproportionate number of attackers
• Its behavior is difficult to predict when its environment or use patterns extend beyond design assumptions

Let's compare software engineering to civil engineering. Humans have been building bridges for a few thousand years. If you follow the specifications for building a bridge, what do you get? Why, a bridge, of course. No tiny unsuspected houses emerge hanging from one side, for example.

How many rivets are in the Golden Gate Bridge? (Answer.) If you selected two dozen at random and removed them, would the bridge spectacularly collapse into the San Francisco Bay? Of course not. Aside from a few notable failures, bridges are well-understood constructions. We can predict how a bridge will behave according to its specifications, we can predict how a damaged bridge will behave in the face of local failures, and we can predict how a deteriorating bridge will continue to function before certain repairs are required.

How many lines of code are in Debian 5.0? (Answer.) If you randomly commented two dozen lines and recompiled the code, can you predict how it would behave? Not a chance. It might run for days, weeks, even years -- or it might crash immediately. Can you fully predict how any particular installation will behave, given the vast possibilities of how the individual components might be (mis-)configured? Not during your natural lifetime.

Imagine you're writing a program, and consider the illustration below. The green circle represents your expected behavior; the blue circle represents your program's actual behavior:

All code has bugs, of course. Traditional bugs we can find and eliminate because they become obvious through testing: we expect certain behavior but instead we notice something wrong, so we re-examine the code, find the mistake, and fix it. Traditional bugs manifest themselves when we don't see what we expect to see.

Security bugs are almost always the opposite: non-obvious behavior that has somehow crept into our code, behavior that we don't know is there and don't really know to test for very well. Security bugs manifest themselves when we see what we don't expect to see. And people who specialize in attacking software are very, very good at seeking out the unexpected.

Earlier this summer my teenage son enrolled in a week-long summer camp to learn Java programming. On demonstration day, at the end of the course, parents were invited to view the projects their children had worked on during the week. My son created a simple text-based blackjack game. As I examined the code, I noticed well-formed structure and concise comments throughout. When I executed the program, it greeted me with this prompt:

Welcome to Blackjack!
Please select (1) to play or (2) to end:

Well, what do you think I did? As any proud parent would, I violated the instructions and entered "4." The program immediately crashed and dumped me into a debugger. My son couldn't figure out why I ignored the prompt! "Four isn't a choice, why didn't you pick one or two?" he asked. "Not everyone operates your software in only the ways you'd expect, you know," I replied. "Who would ever do that?" Heh. On the way home we discussed the importance of input validation and exception handling. You have to learn how to think like a bad guy if you don't want bad guys breaking your code.

Foundationally, there's no substitute for writing secure, resilient software -- software that expects to be abused, defends itself when under attack, and fails safely. Ross Anderson's book Security Engineering belongs on every developer's bookshelf, e- or otherwise. Build Security In is another excellent source for materials that can help you incorporate improved security coding practices into your software development programs.

On top of this critical foundation, additional layers help increase your defense. Because so much of today's software runs on the web, attacks against web applications outpace all others. Specific tools like our Stingray Application Firewall can help protect web applications from several attack vectors. Exploits of common vulnerabilities often present in third-party software can be detected and blocked. Path restriction and request/reply validation rules can thwart attempts to force web applications to misbehave. And over time, execution heuristics can suggest additional protective measures.

Software is under tremendous attack. Whether it's attacks against availability (denial of service), attacks against confidentiality (eavesdropping and interception), or attacks against integrity (malicious modification), the volume and impact show no signs of abating. Fortunately, the tools we have to defend ourselves against attack exhibit a wide diversity of detection and defensive capabilities, with increasing effectiveness and sophistication.

Catching up on Storytellers Contest Winners

We have fallen behind in announcing the winners of our Storytellers contest, and we apologize for that.  Over the next few weeks, we plan to get caught up. 

We start by going all the way back to July.  For the first time in one of our contests, our winner is a Riverbed Partner.  Daniel Thomson, who works for one of our partners, Teneo wrote a very compelling and interesting story.  Teneo is a reseller who has been partnered with Riverbed since 2004.  They have offices in Virginia as well as in London and Manchester in the UK, with over 1500 customers worldwide.

The customer that Daniel wrote about is a London-based media company, who needed to optimize their partners’ and customers’ ability to upload and download large media files, some as large as 500mb, from the road with unreliable and slow Internet access, and from different locations throughout the Asia Pacific region.  And they are doing these large and challenging uploads and downloads against tight advertising deadlines.

Teneo promotes the Riverbed Steelhead technology for a whole host of TCP applications and other services and partnerships that use the Riverbed Services Platform (RSP). In order to do this well, they have to gain a good understanding of their customers’ pain points and requirements.  Since 2004, they have used Riverbed products to help their customers resolve issues with bandwidth limitations, transport protocol and application and latency inefficiencies.

As for the story Daniel told in his winning entry:

• We are seeing 91% data reduction for media data sent and received over the public internet: 1.7GB of media data reduced to just 141MB across the Internet with a Mac Client
• 12.4x capacity increase over the Internet.

I love stories like that.  91% data reduction, and 12x the capacity.  You can get that too; if you did, would you still need to upgrade that WAN connection?

What is this Stingray Traffic Manager, anyway? (Part 4)

In today's Stingray Traffic Manager video, developer Alex Gosse discusses some of the visualization and traffic analysis features that are part of the Multi-Site Manager within Stingray Traffic Manager.

 

 

Technical Overview of Riverbed's Cascade

I have been getting a lot of questions recently from folks interested in learning more about the technical details of Riverbed's Cascade family of network performance management products.  Hopefully this blog post will answer many of those questions.

Cascade is an enterprise-wide network performance management solution, providing visibility into all your data centers, offices, and mobile users. It uses network flow data, supplemented with packet-based performance metrics, to discover applications, network dependencies, and monitor performance. It uses advanced behavioral analytics to track performance over time and alert you to any deviations from normal behavior. That way you can resolve problems before end-users are impacted.

Below is a look at the Cascade architecture.

 

Cascade consists of the following components:

Cascade Profiler

Provides centralized reporting and analysis of the data collected by other Cascade appliances (i.e., Gateway, Sensor, and Shark) and Steelhead products on a single user interface. It offers performance analytics, security analytics and proactive alerts for delivering application-aware monitoring and troubleshooting for your network. It combines all network data into a single data set with in-depth views that support flexible analysis of the information.

Cascade Gateway

Collects flow data from routers, switches and other network devices. It supports all standard flow types (NetFlow, sFlow, J-Flow, IPFIX, etc.). Cascade Gateway also collects Riverbed’s proprietary CascadeFlow, which is an enhanced version of NetFlow. CascadeFlow is exported by Steelhead appliances, and lets Cascade understand which interface(s) are WAN vs. LAN connected, identifies TCP retransmission counts, and determines the network round trip time for connections being optimized by Steelhead.For processed flow data destined for Cascade Profiler, Cascade Gateway aggregates, compresses, and encrypts the flow data, and then sends it to Cascade Profiler through Riverbed’s multi-purpose network management protocol (MNMP) on port TCP/41017. Cascade Gateway can transmit processed flow data to up to five Cascade Profiler or Cascade Express appliances in addition to sending the flow data it receives in an unprocessed manner to up to five other third-party devices. It can be deployed in the same location as the Profiler or regionally if topography requires.

Cascade Sensor

Passively inspects packets from SPAN ports or taps. It provides Layer 7 application classification and sends performance information, including end user experience metrics, to Cascade Profiler via Riverbed’s multi-purpose network management protocol (MNMP). It is typically deployed in data centers. A virtual edition, Sensor-VE, can be deployed as a Riverbed Services Platform (RSP) package on Steelhead appliances. Sensor-VE provides cost-effective visibility into branch office usage. It provides of many of the same capabilities of the Sensor appliance, with the exception of Layer 7 application classification.

Cascade Shark

Is a high-performance (1 GbE or 10 GbE) continuous packet capture, storage and analysis appliance. It is used for fast indexing and storage of multi-terabyte network traffic recordings so that a record of the traffic is available for retrospective analysis. Cascade Shark also provides micro-flow metrics to Cascade Profiler through MNMP. Micro-flow metrics enable the seamless integration from flow-level data to packet-level dataCascade Pilot seamlessly and securely integrates with remote Cascade Shark appliances to deliver a complete and feature-rich distributed network analysis solution.

Cascade Pilot

Is the only tool on the market to be fully integrated with Wireshark, the world’s most popular open source network protocol analyzer. While Cascade Profiler can provide visibility to all flows across the network, Cascade Pilot provides an in-depth view into problems requiring deep packet analysis. Cascade Pilot uses Riverbed’s unique XML-based protocol on top of an HTTPS connection to communicate with Cascade Shark.

Don't miss us at Autodesk University 2011

November 29 through December 1st I will be at Autodesk University at the Venetian Hotel in Las Vegas showcasing Riverbed's stellar results with Autodesk Vault. It has been an absolute pleasure collaborating with the Vault team.

Autodesk Vault is a data management tool which integrates with popular Autodesk products such as Inventor and AutoCAD. It provides a means for tracking files for management as well as version control for various Autodesk formats (dwg, revit) as well as non-Autodesk files (doc, xls). Vault server uses an SQL database backend and the client-server communication is done over HTTP.

Riverbed's HTTP optimization blade fits right into the Vault model providing huge benefits for client-server communication. In addition, we saw some great results in SQL performance over the WAN.

I highly encourage anyone attending the sessions to check out the 'Go Big or Go Home! Part3 - Extending Autodesk Vault to the Enterprise' class taught by Ross Tanner. Ross's class provides some great insights into:

• Configuring Sharepoint for extending Vault data to the enterprise
• Configuring Vault for the enterprise
• Impact of WAN acceleration for Vault optimization
• Describe what the new SharePoint integration can do for your organization

The schedule for Riverbed related talks are

Title	Date	Time	Presenter	Location
Riverbed Technologies – Breaking the WAN performance barrier	Tuesday, Nov 29th 2011	8:10pm	Avinash Shetty	Theater
Go Big or Go Home! Part 3 – Extending Autodesk® Vault to the Enterprise	Wednesday, Nov 30th 2011	10:15am	Ross Tanner	TBA
Riverbed Technologies – Breaking the WAN performance barrier	Wednesday, Nov 30th 2011	12:40pm	Avinash Shetty	Theater

Riverbed is a proud sponsor of the Autodesk University, one of only a handful of companies to do so. Please come by the Presentation Theater where I will be presenting the results of our latest study and a live demo. See you there.

Update 12/1/2011:

The Vault-Riverbed whitepaper is now live on the Autodesk website. We had a great AU2011.

What is this Stingray Traffic Manager, anyway? (Part 3)

In the third installment of our introduction to the Stingray Traffic Manager, developer Alex Gosse discusses how STM can be used to balance web site load between multiple physical locations, regardless of how far apart they are.

 

As we go through this multi-part series, if you have questions or want specific information about Stingray Trafffic Manager (or any other Riverbed products), please ask your questions in the comments, and we'll respond there.

A Day that Goes to Eleven

So today is November 11, 2011.  It's the 88th anniversary of Kurt Vonnegut's birth.  It's Veterans Day in the  US. (The original Armstice Day commemorated the end of World War I, and the documents were officially signed at 11am on November 11, 1918.)

But as a guy who works with numbers, I've been thinking about the numeric form  of today's date, which for a change works in both the US and the UK... 11/11/11.  I've been thinking about 11s and how they appear in our culture.  My favorite 11 of recent times is the 11 that Nigel Tufnel's amp goes up to in "This is Spinal Tap," the wonderful 1984 movie.  There's also Apollo 11 (the first spacecraft to land men on the moon, in 1969), the 7-Eleven convenience stores, and so many more.  There's even a current horror movie called 11-11-11.  Elevens are all around us.

The trick, of course, as I put this blog article together was to come up with a clever way to tie all that stuff into Riverbed.  Normally we look for the Riverbed tie-in before we choose the topic.  Not so much today. 

Very (VERY) late one night last week, one of my colleagues pointed out to me that the binary form of the ASCII space character is 01010101, and since one of the things that our Steelhead Appliances do so well is remove the empty spaces in your network traffic, you can think of that 01010101 as simply 1111 after it's been optimized down. That's it. That's all I've got today.  No videos, no nothing.  We'll get back to that stuff on Monday.

Well, I didn't promise anything especially profound today.  It's really a totally made up event anyway, as the dates and numbers on the calendar are almost totally arbitrary. 

Hoping that you take a few minutes to enjoy Elevenses today...

What is this Stingray Traffic Manager, anyway? (Part 2)

In this, our second in a series of videos on the Riverbed Stingray Traffic Manager, Developer Alex Gosse talks about its ability to both balance traffic and monitor traffic loads per service or per user.

 

Riverbed at Akamai Government Forum; Steve Riley to Present on Hybrid Cloud

With initiatives, mandates and reforms in place aimed at bringing efficiencies to government IT, it should be no surprise that over the last few months you’ve seen a lot of Riverbed at government IT conferences and events. After all, our IT performance solutions help government agencies meet initiatives, mandates and reforms – from enabling data center consolidation, to helping reduce costs for IT, and executing on the cloud first policy.

On November 16, Riverbed will be at the Akamai Government Forum, taking place at the Grand Hyatt Washington in Washington, D.C. The second annual Akamai Government Forum will focus on the latest solutions for scaling the Internet infrastructure for local, state and federal government agencies. Visit the Riverbed station to see demos and learn about our cloud performance solutions, including Steelhead WAN optimization, Stingray application delivery and Web content optimization, Cascade application-aware network performance management for traffic visibility, and Whitewater cloud storage gateways for data protection.

And, because you can’t get enough of him, Riverbed technical leader, cloud expert and aficionado Steve Riley will deliver the cloud track discussion on hybrid cloud from 3:00 to 4:00 p.m. ET.

In his presentation, Steve will highlight how the performance problems associated with distance computing can be mitigated with optimization techniques designed for multiple layers: application, transport, network and storage.

Here is the teaser:

No longer just the fluff of airplane magazine articles, cloud computing is here to stay. The architectures envisioned for large public cloud providers are revolutionizing on-premises data centers, too. Hybrid clouds – clouds that utilize both public and private resources – allow agencies to spread workloads across multiple locations to satisfy distinct policy, regulatory, security and financial requirements. Hybrid clouds, like their individual counterparts, involve adding distance between users and their data. In most cases, the particular distance at any point in time is unpredictable, which will lead to inconsistent user experiences. Applications deployed in hybrid clouds often move large amounts of data across multiple internal and external providers; long waits for data transfer will affect productivity and availability.

Stop by; learn everything you need to know about optimization, acceleration and performance to meet the government IT mandates; and tell us what you thought of the conference.

 

What is this Stingray Traffic Manager, anyway?

We've been talking a lot over the last couple of weeks about the Stingray Traffic Manager.  Starting today, we'll be irregularly running a series of brief videos (none longer than five minutes) that discuss what it is and what it can do for you.  Some of the videos are hosted by Owen Garrett, the Product Manager for the Stingray Traffic Manager (like this one), and the rest are hosted by Alex Gosse, one of the senior developers.  These videos have taught me quite a lot about it, and I believe they will help you to get a good understanding.

As always, comments are encouraged.

First up, an Introduction to the Stingray Traffic Manager:

 

Clouds and cables: a pair of useful websites

Occasionally I encounter fascinating websites that collect lots of neat data and present it in useful ways. I'd like to share a couple of my favorites with you this morning. And yes, they both relate to the topic of computer networking!

CloudSleuth: analyze cloud performance

CloudSleuth.net, produced by CompuWare (and with whom we partner), provides a application that displays near real-time cloud performance metrics. The Global Provider View displays the results of measuring a sample application running on multiple public clouds. You can choose response time or availability metrics, a time window between six hours and 30 days, and four separate geographic areas (or the whole world). You can navigate through a map with clickable city nodes, a line chart that graphs the last six hours, or a table listing the raw data. You can narrow the view to specific providers and cities. Scroll the page down to read a thorough description of the measurement methodology, including the design of the sample application.

Greg's Cable Map: explore the undersea backbone

When I first discovered this site, a couple hours of my day flew by :) Greg's Cable Map mashes data from Wikipedia, fishermen's charts, marketing materials, and other sources onto a Google map of the world to reveal the millions of kilometers of telecommunications cables that ring the planet. When you hover over a cable, a box at the bottom of the browser window displays the cable's name, number of landings, length, and bandwidth. When you click the cable, additional data appears to the right, including in-service date and landing locations. There are some truly curious entries: for example, a 5 Tbps cable between Svalbard and Norway! Why so much bandwidth in such a remote place? Polar orbiters have to dump their data somewhere.

Your favorites

Do you have some favorite data visualization websites? Feel free to share in the comments. We seven billion Earthlings are awash in data; visual displays can help us to interpret it better, reveal otherwise subtle yet important trends, and make the information more interesting

Riverbed Customer Video - Energy Future Holdings

Michael Taccino, VP of IT & Infrastructure, Energy Future Holdings shares his experience with Riverbed's Steelhead WAN optimization and Cascade visibility products.

 

The importance of agility

 An underappreciated aspect of the Steelhead product line is that it has a diverse set of form factors and – crucially – those different packages all use the same optimization architecture, and thus interoperate. What does that mean for a customer?  It gives tremendous flexibility to adapt to changes in how data and users are distributed, without needing to cause ripple effects elsewhere in the infrastructure.  Let’s consider a simple (and common) example first before we move on to looking at the larger implications. 

Organizations often have some branch offices that are very small.  For the very smallest offices and individual users, it’s usually not hard to decide that the right solution is to use Steelhead Mobile on a laptop or workstation.  And when you get to  10-12 people in an office, both the technology and the ROI arguments for a Steelhead appliance (physical or virtual) are pretty easy to make.  But there’s an area in the middle, around 5-6 users, where there’s enough overlap of capabilities that either approach could work.  Add to this that a given office may grow or shrink enough so that the original configuration in the office may need to be replaced with a different one.

 Using the Steelhead family, these choices and changes at the branch can be accommodated with no additional impact on the data center side.  For a given workload from a given set of users, it just doesn’t matter whether they’re coming from a Steelhead appliance or Steelhead Mobile. 

 Now, if you’re only familiar with Riverbed, at this point your reaction is probably something like “so what?  Big deal!”  But let’s look at just this one scenario with the #2 vendor: their mobile client doesn’t use the same technology as their appliance, so you have to have two separate data-center infrastructures to support the branches if you have a mixture of the technologies.  And as you migrate a given branch from appliance to mobile or vice-versa, you’re changing the load on the corresponding data-center pieces. 

 That divided-technology approach means that it’s easy with the #2 vendor to be in a situation where an apparently-straightforward change at a branch gets tripped up because it exceeds the capacity of some piece of data center infrastructure.  Another layer of complexity comes from the fact that these two different technologies have different network characteristics: their appliance uses an autodiscovery mechanism somewhat like the way that Steelheads work, while their mobile client needs an explicit connection set up to its data-center counterpart.  Their appliance marketing repeatedly insists on the necessity of transparency and the avoidance of tunnels, while the mobile client uses a tunnel-based system – so it’s possible that a particular branch network configuration that works with one of the technologies simply won’t work with the other.

 It’s tempting to say that the divided-technology problem of the #2 vendor is just a typical lapse by a very large company, and that smaller competitors would have a better approach. So we look at the #3 vendor in our space, which is a private company that prides itself on only doing WAN optimization.  But they don’t have any mobile client at all!  So their theory is that you should just pretend that you don’t need WAN optimization when you’re out on the road and dealing with networks in coffee shops and hotels – exactly the opposite of most real-world experience.  And apparently when your branch is too small to support an appliance or virtual appliance, you should just stop using WAN optimization.  (All of a sudden, the #2 vendor looks really good by comparison.)

Before we leave this topic, it’s worth noting that the preceding comparison actually understates the Riverbed advantage. A further advantage comes from the fact that Steelhead Mobile and a Steelhead appliance (physical or virtual) can cooperate via branch warming. In branch warming, Steelhead Mobile and a local Steelhead appliance work together: each time a piece of "optimization vocabulary" is used by the machine running Steelhead Mobile, the mobile client and the appliance coordinate so that both have a copy.  As the mobile client is used in the branch office, their vocabularies will tend to converge.

Without spending too much time on the details of how it works, let’s talk about where it’s useful:  Sometimes there are enough people in an office to justify an appliance, but the nature of the work means that some or all of them have a significant need for mobility – often because they are salespeople, hands-on repair technicians, or field supervisors.  They can use Steelhead Mobile when they are on the road, but they stop needing a mobile license when they’re in the office, and they take the benefits of their office work (newly learned optimizations) back on the road with them when they leave. 

 Now let’s talk about the bigger picture of why this matters.  After all, your organization may not have small branches or mobile users, so that set of examples might not impress you. But the same general principle of agility through a common architecture is more broadly useful, and almost certainly can make a difference to your organization now or in a future configuration.

 A way of getting a handle on this is to list out the different “packages” of Steelhead technology:

• Physical appliance
• Virtual appliance
• Cluster of appliances (physical and/or virtual)
• Software client
• Cloud-integrated service
• “Blade” for HP switch

 All of these interoperate with each other – so it’s easy to go “physical to virtual” or vice-versa without needing to disrupt the other side of the application.  Likewise it’s easy to have a set of services growing beyond the capacity of a single appliance, or migrating into (or out of) a cloud service, without prompting a redesign or redeployment of the client side.

 Again, a comparison with the #2 vendor is illuminating. A casual examination of their WAN optimization product line would suggest a similar kind of breadth and agility. They have a variety of packages of WAN optimization technology. But it turns out that the commonality is more marketecture than architecture.  That is, they use a common branding for what are actually 3 very-different classes of products: what we might call “main”, “mobile”, and “express.”  The “mobile” products can’t interoperate at all with “main” products or with “express” products.  The “main” products and “express” products can interoperate, but only at the lower level of function supported by the “express” products.  So actually trying to use the #2 vendor products for Riverbed-like agility can lead to all sorts of unpleasant surprises, as WAN optimization functionality either doesn’t work at all (mobile/main and mobile/express combinations) or works with sharply reduced functionality and performance (main/express combinations).

IT organizations need agility and flexibility to meet changing circumstances and demands.  The Riverbed single common architecture approach for WAN optimization helps ensure that Steelhead technology can help meet that need.

Video: Application Performance in the Cloud

Bob Gilbert sits down with Zeus Kerravala from the Yankee Group to discuss application performance in the cloud.

 

 

Riverbed Technical Leader Steve Riley Q&A on Distributed Recentralization

Thank you for tuning in to the Federal IT Q&A series with Steve Riley, our friend for all things cloud. With this episode, we're wrapping up the series with one question and one answer. 

The question: what does the Federal Data Center Consolidation Initiative, Cloud First policy, data protection, mobility and telework, and desktop virtualization, have in common?

The answer: Distributed recentralization. In the below video, Steve provides a history on the computing models we've experienced (i.e., mainframe, client-server and centralized computing), and talks about the direction we're moving towards - distributed recentralization. The trend is that we're moving to fewer but larger data centers. And, compared to centralized computing (creation, access and process happening in one place), with distributed decentralization, access and creation are happening in one place, and processing and storage are happening in another place. Also, with fewer data centers, these two activities are occurring at even greater distances in the past ten years. 

This is why adding a layer of intelligence to networks is critical.

 

Actually, there is one more question. What topics — within the realm of IT performance — would you like to see from us?