The Riverbed Blog

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.

Join Riverbed at AFCEA West 2012

We're making a presence at the first Federal show of the year, the West 2012 conference, which will take place January 24-26 at the San Diego Conference Center in San Diego, California. Visit the Riverbed booth (#1910) to learn about our IT performance solutions, which help defense organizations meet government mandates – to consolidate data centers, reduce costs for IT, and execute on the cloud first policy – without compromising performance.

West 2012 is co-sponsored by AFCEA International and the U.S. Naval Institute, and is the largest defense technology event on the U.S. west coast for communications, electronics, intelligence, information systems and imaging. The theme of this year’s West 2012 conference is “America’s Military at the Crossroads: What’s Out and What’s In for 2012 and Beyond?” Defense and industry leaders will discuss and debate the technologies and approaches for successful military programs this year.

For more information on the West 2012 event, visit: http://www.afcea.org/events/west/12/introduction.asp.

 

Blog Battle: Why mastering the private cloud should be your top priority

Today we are trying something different in the blog.  We are posting two articles with differing points of view.  The article below takes the position that Private Cloud is more important than the Public Cloud and should take precedent.  The other article, located here, takes the opposing viewpoint that the Public Cloud is more important should be given priority.  

We hope you will chime in with your comments and opinions in the comments.

Let the Blog Battle begin!

I hereby proclaim that the private cloud should take precedence in your hearts and minds, winning the favor of your attention and mastery!

Why? You will always have infrastructure. Unless you are a very small company that plans on staying a very small company, the chances that you will continue to have some amount of infrastructure to purchase and manage is extremely high.

Reason 1- Cost: The economics of running certain applications in the public cloud just don’t make sense (yet). Pay-by-the-hour, infinitely scalable, public cloud resources are great for certain types of applications. A huge batch job of analytics processing? Why overbuy when you can rent! A seasonal promotion? Perfect for deploying in the cloud that can support spiky workloads! But your day-to-day, predictable workloads? When you add up the service costs for month after month of cloud service fees and weigh that against the declining cost of most hardware… well sometimes it’s better to own (and get the depreciation benefit) than to rent.

Reason 2 – Human resources: To fully take advantage of cloud scalability, you have to do some rewiring of the application… and sometimes the person who wrote that application is long gone. So until you decommission the application, or decide it’s worth it to pay consultants to dig into the code, that app is staying put.

So if you’re going to have some applications remaining on premise, why not maximize the efficiency of your infrastructure by adopting private cloud practices and technologies? There’s a ton of benefit to gain from virtualizing applications and running them on consolidated infrastructure in a highly automated data center. Here are some examples:

1. You’re going to need to have a clear picture of what applications you have and how they are connected before making changes like migrating servers between locations and consolidating them into virtualized data centers. Application-aware network performance management, like Riverbed Cascade, can rapidly build application dependency maps to give you visibility into multi-tier applications. There are ongoing benefits as well, such as rapid troubleshooting capabilities from having an integrated tool for analyzing enterprise-wide flow data and drilling down into specific packets.
2. You’ll need to actually move those applications to your virtualized data center without disrupting service availability. Global load-balancing capabilities in the Riverbed Stingray Traffic Manager can allow you to rewire applications in the background while maintaining service availability.  Your private cloud will also benefit from the automation that Stingray provides in increasing application performance and reliability, and support greater server throughput for further consolidation potential.  As a virtual appliance, you can easily right-size your Stingray deployment, while taking full advantage of your virtualized infrastructure.
3. Finally, you’ll need to make sure users can still access applications running in your private cloud data center… which is probably a greater distance from your end users than local servers and data centers were before. Riverbed’s Steelhead WAN optimization technology minimizes the impact of latency – something that adding bandwidth capacity alone cannot do – so that end-users in branch offices and on mobile laptops can continue to use applications as if they were local.  As an added benefit, Steelhead appliances and mobile software can reduce bandwidth consumption by 65-95%, providing efficiency and savings that can be funneled back into the business.

So, not to rain on the whole public cloud parade, but the big party is happening over in private cloud-land. And you’re invited.

So who's right?  Which do you think is more important to your organization?  Public or private cloud?  Let us know in the comments.

Riverbed Steelhead & Whitewater Customers Featured at Gartner Conference

Gartner will kick off its 30^th Data Center Conference amongst the glitz and glamour of beautiful Caesar's Palace in Las Vegas next week. Leading Gartner analysts such as Joe Skorupa will be covering hot issues including next-stage virtualization, the impact of cloud computing, mobility, best practices in cost optimization, managing escalating energy costs, the aging infrastructure. Additionally Riverbed customers James Hardie,  a world leader in fiber cement siding, and Psomas, a Southern-Calif.-based engineering consulting firm will present on how they are leveraging Riverbed IT performance solutions to enhance its disaster recovery capabilities.

Featured at the conference is a track titled, “Twin Goals, Unique Approaches:  Improving Data Replication, Back-Up and Storage - With the Cloud, and Without”, where Riverbed customers James Hardie and Psomas will share their IT success stories with their peers. If you’re at the conference, be sure to check out the session on Wednesday, December 7 from 11:15 - 11:45 a.m.

Here’s a bit more information:

Twin Goals, Unique Approaches:  Improving Data Replication, Back-Up and Storage - With the Cloud, and Without

For James Hardie, data protection and Disaster Recovery are paramount. So SAP data replication and failover that were running a day behind and nightly data backup replication of 18 hours+ constituted an untenable situation. Deduplication alone was not enough to improve end-to-end performance. Learn how the company has deployed WAN optimization from Riverbed Technology to reduce its RPO to one hour or less, slash backup times by almost 3X and improve bandwidth utilization from 30% to nearly 100%.

For Psomas, eliminating tape and leveraging cloud based backup and recovery are an IT priority. Cost reduction, improved business continuity, freeing administrative time for more high value activities, and achieving competitive advantage were just a few of the factors motivating the change. Learn how the company has deployed Riverbed Technology’s Whitewater cloud storage gateway and Cloud Steelhead WAN optimization technology to move to a hybrid cloud model for CAD computing that best serves its highly mobile and distributed workforce.

And please stop by our booth #30 during the show. Happy Holidays!

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.

 

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?  

 

Video: Riverbed is looking for SaaS acceleration beta customers

Riverbed is looking for customers that are interested in extending their Steelhead WAN optimization to SaaS applications such as Office 365, Salesforce.com, and Google Apps.

This groundbreaking technology is a joint effort from both Riverbed and Akamai and for existing Steelhead customers, it requires no new hardware. If you are interested in participating in the SaaS acceleration beta, please email Bob Gilbert: bob@riverbed.com.

 

Stingray Traffic Manager Overview Video

Owen Garrett, Director of Product Management for Riverbed's Stingray line of asymmetric optimization products, provides an overview of the Stingray Traffic Manager.

 

 

Introducing the Stingray Product Family

Apurva Dave, Riverbed VP of Marketing, provides an introduction to Stingray, which is Riverbed's new line of asymmetric optimization products.

 

You can also read the press release here

Riverbed 101 - An introduction video to Riverbed's products

Bob Gilbert gives a high level overview of Riverbed's products.

 

 

Cloud computing for government, part 3 of 3

Today we conclude my three-part series on government cloud computing. Be sure to read part one and part two in case you missed them.

---

What’s the status of standards for the cloud? What do agencies need to keep in mind as they develop their cloud strategies?

Typically, standards lag innovation. Cloud computing is one of the IT industry’s most rapidly-evolving developments—providers add new features and services several times every month, it seems. Although standards around APIs are in their nascent stages, I’m not sure that cloud standards are mature enough yet to be a major part of the decision process for choosing a provider. More important, I think, is that a provider offer a graceful way to retrieve and remove your data and processing workloads should you ever decide to move elsewhere. Look for providers who clearly state that your data belongs to you, not to them. Avoid providers who won’t make this assurance.

What does moving to the cloud mean for an agency's IT resources? Will “regular” IT skills suffice, or is something else needed?

Technical challenges aside, the personnel issue is, in my observation, one of the biggest barriers to cloud adoption. No one ever publicly declares that they’re going to resist cloud for fear of losing their job, but I know from experience that such fears exist. IT staff will require new skills. Good IT staff will relish the opportunities—they can gain a better understanding of the agency’s business and provide greater value. Bernard Golden, CEO of Hyperstratus, regularly writes about how cloud computing will fundamentally alter the human element of IT. The entire history of technological advancement has affected every form of work ever devised. There are no more buggy-whip manufacturers in the United States; the good ones figured out how to build automobile starters.

At what point can you call a cloud-based IT project a success?

To call something a success sounds like it has to reach some kind of conclusion—a way to know that a project is finished. Not to sound evasive, but one intriguing aspect of using the cloud for IT projects is that they never truly have to be done. “Done” is a side-effect of old-style waterfall development methodologies, which began with an end state in mind. Agile development methodologies have largely replaced waterfall development, and cloud computing is the ideal platform for agile development. The cloud’s on-demand resource elasticity permits continuous updates and improvements. IT projects become iterative and can easily adapt to meet the ever evolving needs of agency business. “Done” is no longer a requirement; success comes from knowing that new functionality can be envisioned, developed, tested, and deployed quickly without disrupting existing operations.

What are going to be the major drivers in the government cloud space in the next 3-5 years? Is there anything else that could emerge that's not evident now?

I believe finding a champion to replace Vivek Kundra’s passion is absolutely essential. While on-going financial pressures could conceivably be the primary (or even sole) driver for government compute consolidation, someone who can keep prodding all agencies with a grand vision is still important at this stage. Also, as IT staff members retire, I’d suggest that agencies look for replacements with some experience developing for and managing cloud resources. Such staff will already understand how to adapt their work skills and strategies as cloud computing continues its relentless evolution. As for predicting how the cloud space itself will evolve, well, today’s reality certainly looks different than predictions from three years ago! I’m certain, though, that the explosive growth of data we’ve seen over the past few years will continue apace. All that data has to go somewhere and the cloud is the best place for that.

What will be your company's strategy for the government cloud space over the next few years?

We’ll continue to strive to make the cloud easier and faster for agencies. We work closely with our Federal customers and partners to ensure we’re building the right products and creating useful guidance. We’ll continue to pursue appropriate certifications and compliance so that agencies can rely on Riverbed’s technology to safely accelerate their move to the cloud.

Riverbed Technical Lead Steve Riley Q&A on Federal Data Protection

Thanks for tuning in for part three (of five) of the Federal IT initiatives Q&A video series with our illustrious technical leader Steve Riley. As projected by many industry research and analyst firms, data will continue to grow. This is not surprising. And as you may remember, with the Cloud First policy, agencies have a mandate to move data and applications to the cloud. So, for this week's video Q&A, we shift gears, and examine some of the considerations for agencies to protect their data in the cloud.

Steve answers the following:

1. How data is protected in the cloud.

2. What are the technical considerations and strategies for protecting data in the cloud.

3. How Riverbed, specifically, helps protect data in the cloud. Here is a hint – it has something to do with FIPS certification.

Next week, I'm taking a break from posting. But, tune in again October 11 for a Q&A video on teleworking and mobility. It would be appropriate to watch the video on a smart phone or tablet, outside of your workplace.

 

 

Cloud computing for government, part 2 of 3

Today we resume with part two of my three-part series on government cloud computing. Be sure to read part one, in case you missed it.

---

The benefits of the cloud are supposedly self-evident, but how can agencies actually measure the ROI?

Curiously, in General Alexander’s testimony [see the last question in part 1], while he praised the capabilities of cloud security, he questioned some of the promised economic benefits. Many providers publish online calculators that allow you to compare the costs of a cloud deployment to the costs of running on-premise infrastructures. Frequently these fail to account for the personnel costs of installing and maintaining on-premise equipment, so in one sense they aren’t as good as they could be. However, trying to measure cloud ROI and comparing that to traditional infrastructure ROI ignores the cloud’s most important benefit: elasticity. The cloud allows you to add and remove resources according to demand. Traditional on-premise infrastructures are either under-utilized (and thus waste resources) or over-subscribed (and thus perform poorly). Applications designed to take advantage of the cloud’s elasticity largely eliminate the guesswork associated with predicting demand. A resource availability curve that always matches your demand curve appears a lot like perfect ROI.

What does Riverbed bring to this space that sets you apart from others?

Over eight years Riverbed has built a reputation of making wide area networks feel like they’re right next door. As organizations consolidated dispersed branch office resources into fewer large data centers, our technology has helped eliminate the typical problems that arise from computing at a distance. The cloud is a natural next step for us, because in many ways the cloud is similar to a WAN. Users can be situated anywhere and we can apply the same optimization techniques to make applications feel local. With Steelheads of various flavors you can vastly accelerate the movement of data from on-premise to the cloud and back, and also between clouds—even if the providers are different. In our Whitewater appliance we’ve adapted our optimization technology to remove the drudgery from backups, allowing you to point your backup software to a target that in turn compresses, encrypts, and backs up to the cloud—no more tape. For cases where you aren’t able to deploy our flagship symmetric optimization technology, we offer application acceleration that you can add to your cloud-based applications through two recent acquisitions: Zeus and Apptimize. And soon, through our partnership with Akamai, you can accelerate third-party SaaS applications by optimizing the high-latency link between your current location and a point of presence topologically very close to your ultimate destination. Regardless of which cloud providers you choose and what technology they’re built on, we can make any cloud perform better.

Is the cloud necessarily a permanent solution? When does it make sense to use the cloud as a temporary resource?

This would seem to conflict with the “cloud first” mandate and the notion that the cloud is the new default. It can be tempting to consider the cloud as an extension of an existing data center. Unfortunately, such thinking imposes limits—you’re less free to build applications that incorporate full cloud functionality and you can’t move to a full scale-up/scale-down resource curve. Also, I think this can create a mindset where the cloud becomes that “extra” thing that ends up not being managed well, or at all.

Is moving to the cloud strictly an IT issue? What other stakeholders need to be included in the discussions, and why?

IT organizations that choose, on their own, to move production workloads to the cloud do so at their peril. Capacity planning and disaster recovery require input from the agency’s working units. Data location and portability require consultation with legal and compliance teams. Cloud provider procedures and certifications require review by internal audit groups. Budgetary changes require working with finance folks. Don’t allow cloud projects to become line items in some developer’s monthly expense report!

Agencies will need to develop applications and services for their specific needs. Does the cloud change how they do that?

There are fundamental differences in the way applications should be built to run on clouds. Probably one of the most shocking changes is that servers are now disposable horsepower. Infrastructure is code: when you need compute resources, you simply issue a few API calls and within a matter of minutes those resources are available. Vast amounts of distributed storage are also there, waiting for you to allocate and use. In many cases this storage incorporates automatic replication, so you no longer need to build that into your application. Cloud computing also simplifies the process of updating applications: you clone an existing application, add and test updates, then move users over to the new version. Cloud providers often publish detailed technical guidance for how to develop on their particular platforms.

---

Part three will follow two weeks from today.

Riverbed Technical Lead Steve Riley Q&A on Federal Cloud First Initiative

For part two of our federal IT initiatives Q&A with Steve Riley, we focus on the Cloud First policy. Now, if you do not work in the the federal IT space, the Cloud First policy is the federal government's strategy for cloud computing, which is part of the greater plan to reform federal IT. The general estimate is $20 billion of the federal government's $80 billion in IT spending could be used for cloud computing.

In the enterprise, cloud computing is a trend that has been discussed and migrated to for many years. However, the push for cloud computing in the federal IT space was kicked-off and championed by Vivek Kundra, the U.S. government's first CIO. And, although Kundra recently left his post last month, former Microsoft executive and managing director at the Federal Communications Commissions Steve VanRoekel has taken the position and reigns, and plans to use Kunrda's grand vision for IT reform as a foundation for even greater changes to federal IT. 

Grab your coffee, tea or something stronger, and watch the below Q&A, which covers what spurred the Cloud First policy (cost reductions and collaboration among agencies), considerations (safety and security), as well as how Riverbed helps agencies to execute on the Cloud First policy. 

 

Stay tuned. Next week, we'll talk about data protection. 

 

Cloud computing for government, part 1 of 3

One of Vivek Kundra's most significant contributions in his position as first CIO of the United States was to introduce a "cloud first" policy for government computing projects. Mr. Kundra's replacement, Steven VanRoekel, vows to continue this policy, which will help numerous government agencies streamline their missions and improve citizen services.

Recently I was interviewed as part of a series of technology provider perspectives on government cloud computing. I'd like to share that interview with you, our blog readers. I plan to post the questions and answers in a three-part series, the first of which follows here. As always, we welcome your thoughts and reactions.

---

Agencies are under a “cloud first” mandate for procuring IT services, so awareness of the cloud should be there. But what's the level of understanding about how agencies can benefit from it?

Cloud providers love to wax rhapsodic about the benefits of utility computing, and you can find plenty of appealing goodness on their marketing web pages. What’s missing, I think, is a way for agencies to translate the generic promises into specific benefits that they can then measure. Of course, this means you already need a fairly good understanding of what you have, what works well, and what doesn’t work well. From this you can then more easily evaluate the benefits of the cloud in general and also compare specific benefits of various providers. Unfortunately, if you don’t have a good idea of what you’re already doing, it’s difficult to truly know whether moving to the cloud will bring positive results.

Is moving to the cloud a “no brainer” for agencies, and they should just go ahead and do it? What process do they need to go through to decide if they are ready?

Assuming you can accurately translate the promises into measurable benefits, I’d say yes, agencies should adopt cloud computing as the new default deployment model for new projects and for existing projects that are planned to undergo a refresh cycle. I don’t like characterizing it as a “no brainer,” though. To wring maximum value from a cloud deployment requires a fair amount of brains: cloud architecture is fundamentally different from traditional on-premise architecture, and this is reflected in how you develop applications, where you locate data, how you plan for disaster recovery, and how you implement information security controls.

Are there any agency applications or services that should never move to the cloud, or is everything an agency does open to that move? In either case—why?

One way to influence change is to set new defaults. For example, in states where applicants for driver licenses have to opt in to organ donation, only 20% chose to do so—vastly limiting organ availability. Some states have reversed this; drivers are organ donors by default unless they opt out. 80% stick with the default, and all residents of these states benefit from the greater availability of organs. So the “cloud first” mandate along with the mental shift to cloud as default requires that an agency must obtain an exception if it wishes to deploy a project on premise. If you make the exception process sufficiently painful, this will discourage agencies from inventing convenient excuses to continue doing things the old (meaning familiar) way. Clearly there are certain exception criteria that will prevent some workloads from moving to shared infrastructures. But does each one need its own dedicated data center? Could, perhaps, all these workloads share a single private “top secret” cloud? I’d imagine so.

How can agencies decide which flavor of cloud—private, public, or hybrid—is right for them?

It doesn’t make much sense to choose a deployment model from the start and then attempt to force all workloads into that one model. Different workloads can use different models—that’s one of the neat things about cloud and emerging technologies that make it easy to port workloads between clouds. So I’d say that the decision of which deployment model to use for any particular workload is driven by the answer to the previous question and, of course, the following question.

Many potential agency users of the cloud believe it's not yet secure enough for their needs. Are they right?

Perhaps we should let General Keith Alexander, chief of the US Cyber Command, answer that one for us:

“This architecture would seem at first glance to be vulnerable to insider threats—indeed, no system that human beings use can be made immune to abuse—but we are convinced the controls and tools that will be built into the cloud will ensure that people cannot see any data beyond what they need for their jobs and will be swiftly identified if they make unauthorized attempts to access data... The idea is to reduce vulnerabilities inherent in the current architecture and to exploit the advantages of cloud computing and thin-client networks, moving the programs and the data that users need away from the thousands of desktops we now use—up to a centralized configuration that will give us wider availability of applications and data combined with tighter control over accesses and vulnerabilities and more timely mitigation of the latter.”

These are quotes from his testimony to Congress in March 2011. His statements reveal a remarkably keen understanding of where risk to information lies and how to mitigate those risks. If the world’s largest online retail company stores and retrieves its entire product catalog from the public cloud, if Treasury.gov, Recovery.gov, and NASA all use the public cloud, if major pharmaceutical manufacturers use public cloud resources for testing the protein folding sequences of trade-secret chemical compounds, if the world’s largest movie streaming/subscription service runs its whole business—front and back office plus its intellectual property—from the public cloud, then just who are these people who claim “oh, the cloud isn’t secure enough for me”? Cloud providers are under constant pressure to prevent their services from becoming attractive to bad guys and to make it exceptionally difficult for one customer to interfere with another. And they’re constantly striving to obtain ever more stringent certifications. That’s a lot of work, more work than most private or single-purpose data centers have the staff or budget to undertake. Now, having said all that, if your cloud provider refuses to be transparent about how they manage their security, I suggest you take your business elsewhere.

---

Part 2 will follow two weeks from today, and part 3 will follow two weeks after that.

Shifting Models & Lumped Circuits

Today's Guest Blogger is Mark Day, Riverbed's Chief Scientist.

Back when I was studying electrical engineering, I first learned about lumped circuit models.  In a lumped model, we considered the wires to be ideal and just focused on the behavior of the connected components (resistors, capacitors, inductors).  After we knew what we were doing (more or less) in that simplified world, we learned about transmission-line models, where we modeled the behavior of the wires.  And we learned that for certain kinds of real-world problems like managing an electrical grid, a lumped model would give you hopelessly wrong answers.

A little later, when I was in graduate school for computer science, I read an entertaining rant about ideal wires vs. the reality of building a fast parallel computer. Today that item came back to mind as I was thinking about explaining WAN issues and cloud performance to people whose frame of reference (their model, if you will) might be mostly LANs.

I was happy to find that my memory had mostly served me correctly.  Here’s a relevant excerpt from Danny Hillis’s book The Connection Machine (MIT Press, 1985):

“Fundamental to our old conception of computation was the idealized connection, the wire.  A wire, as we once imagined it, was a marvelous thing. You put in data at one end and simultaneously it appears at any number of useful places throughout the machine.  Wires are cheap, take up little room, and do not dissipate any power.

“Lately, we have become less enamored of wires. As switching components become smaller and less expensive, we begin to notice that most of our costs are in wires, most of our space is filled with wires, and most of our time is spent transmitting from one end of the wire to the other.  We are discovering that it previously appeared as if we could connect a wire to as many places as we wanted, only because we did not yet want to connect to many places.”

I think you can see that some of the same reality-check critique applies to ideas about the performance of cloud computing and distributed computing across WANs, with the network taking the place of the wire.  It sure is simple when the network’s behavior doesn’t matter, but unfortunately that isn’t always true.

At Riverbed it’s nice to have a variety of technologies that can be brought to bear on those network-related issues. One subtle problem is that because we think about it all the time, it’s easy for us to take for granted that “switch of models” that is sometimes harder for our customers.  People sometimes have to shift from assuming that everything “just works” in ideal fashion, to actually thinking about the WAN as an element of the system.

The Industrial Cloud Revolution

Does anyone else miss writing those high school history papers? You know, the ones that all start “With the Industrial Revolution came widespread change across the economic, political and social fabric of western civilization…” Blah, blah, blah. Anyone? Anyone?

Not so much, eh? Okay, it wouldn’t be the first time I’ve flown solo in the history-nerd department.

But the reason the Industrial Revolution was such a great opener for many a high-school history paper was that it really did transform the economics of production, which had wide-reaching implications for modern civilization. Production went from small-scale, localized, cottage-industry to large-scale, concentrated production centers benefiting from economies of scale and scope. Various innovations, from the flying shuttle to the assembly line, were instrumental in creating the efficiencies of industrial revolution factories, but at the end of the day, creating more products, more quickly wasn’t worth much unless you had exposure to enough customers to buy them. In other words, you had to get all those products to market.

Enter the steam engine. With a steam-powered railway infrastructure, industrialized manufacturers could get their products to more markets, faster.  Which is a good thing when you just churned out more pairs of pants in a year than everyone in a hundred mile radius could wear in their combined lifetimes.


So, why am I going off about steam engines and the Industrial Revolution? Well, here in IT land, we’re having a bit of an Industrial Revolution redux. Virtualization has enabled IT administrators to consolidate servers and gain economies of scale, and companies like Amazon, Rackspace and AT&T are beginning to offer basic IT services on-demand, passing on even GREATER economies of scale. But all the cheaper, on-demand compute and storage in the world isn’t worth much if you can’t get the product (applications) to market (users).

We need a steam engine for the cloud revolution. Oh, wait! WAN optimization has proven to accelerate network-based applications by reducing bandwidth consumption and the impact of latency. Choo-choo!! Layer on network performance monitoring (who’s keeping track of all these trains?), web content optimization (how are we loading these products on the trains?), and application delivery controllers (what train is going where, when?) and you have yourself the speed and intelligence for a high-performance cloud delivery system.

 All aboard!

Extra credit: Join Amazon Web Services Senior Evangelist, Jeff Barr, and me on August 17 for a webinar on how to optimize your cloud server deployments. Register here!

Riverbed's Optimization Solutions for the Cloud

Recently I saw a blog post on ReadWriteWeb / Cloud by David Strom where he described the roles that WAN Optimization can play in helping accelerate Cloud-based IT services.

This has long been an area of attention at Riverbed; for years now we have been helping Enterprises address and solve the challenges they've faced with business applications performing poorly across their private WANs. Riverbed's award-winning Steelhead family of WAN Optimization appliances have held a leading position in the global market for the last several years, according to several leading industry analyst firms.

Now, in the era of Cloud-based IT services, the performance problems created by the increased distance between users and their data, combined with the lack of QoS and un-guaranteed internet performance are significantly worse than those faced within a structured and well-known corporate IT environment. Thus the need for performance optimization in these cloud environments is even greater than in traditional, private corporate IT.

These requirements have prompted Riverbed to develop and offer a whole range of products and technologies, to address the vast majority of Cloud-based IT applications and environments. In his recent blog post,  David mentioned only one Riverbed product in this context, the Steelhead Appliance.  

In addition to this though Riverbed also has the following products available to address the Acceleration & Optimization needs of virtual and cloud environments :

1. Virtual Steelhead - as the name suggests, a virtual version of the Steelhead product that can be run on VMWare ESX/ESXi platforms
2. Cloud Steelhead - Steelhead WAN Optimization + simple portal-based management, On-demand instantiation, easy cloning, fliexible sizing and pricing
3. Riverbed Whitewater - a single-ended Cloud Storage Gateway that delivers speed, security, cost-efficiency and ease of use for Cloud-based storage services and of course
4. Steelhead Mobile - PC and MAC client acceleration software, so you can enjoy accelerated cloud IT services from anywhere, over any connectivity medium.

Additionally with the recent acquisition of both Zeus and Aptimize, Riverbed now also has two new Single-Ended technologies - Application Delivery Controller and Web Content Optimization - to help accelerate  both public and private cloud-based web content and applications.

So in summary, Riverbed really should be your first port of call for any cloud IT service acceleration & optimization requirements.