Crescendo's Web Application Performance Blog

• SLB -Since the appliance replaces a traditional load balancer, it has to take its basic functionality of load balancing among several servers. This is neither offload nor acceleration but is required as a legacy feature.
• TCP connection management and multiplexing—Even a strong server can be brought to its knees by making it deal with tens of thousands of TCP connections opening and closing rapidly. By handling all the myriad TCP issues on the client side and multiplexing the client requests into few well behaved TCP connections towards the server, a significant offload is achieved.
• Compression - Compressing web content is an established way of reducing bandwidth and reducing response time. Doing compression on the ADC offloads this task from the server.
• SSL - Secure Socket Layer is widely used for content encryption. Being computationally intensive, offloading it to the ADC can free up server resources.
• L7 advanced features - An advanced ADC allows the enforcement of policies such as traffic and content control based on L7 information. This allows complex data center behavior without burdening the servers.
• Caching - Most ADC’s consolidate a web caching feature in the device. This reduces load at the servers as cached content is served directly from the ADC.
• GSLB - Global Server Load Balancing allows balancing geographically separated sites based on their load.

2 weeks ago I participated in a cloud event called "Powering the Cloud". As much as it sounds like hype, the cloud is actually marching on. The most important fact that allows it to succeed is it's evolutionary nature to virtualization, not a disruptive revolution!

Virtualization has already gone mainstream where almost every IT organization is either using it or considering.

Data by Gartner suggests that via virtualization, organizations can fundamentally change their server to admin ratios - from 20-30 to 1 in the physical world to 60-100 to 1 in the virtual world. The IT world agrees.

Cloud is supposed to go one step further, achieving even more savings by allowing IT to automate processes further as well as farm out key parts of their infrastructure to 3rd parties that can achieve greater economies of scale and thus achieve even more savings.

For customers, since the step to cloud is evolutionary from their regular virtualization infrastructure, they can experiment with small projects to build confidence and test the water. This is already happening today.

A striking example was provided at the event. It involved a company that wanted a new backup redundancy system to their SAP system and compared building a new one internally to hosting one externally using cloud services. They had clearly defined goals of how much data they can lose in case of failure (less than 1 hour) and how quickly the backup system needs to be up (within 20 minutes).

Backup thus had to constantly replicate data from their systems and their servers had to be replicated at the remote hosted site. They ended up choosing the cloud implementation due to significant costs savings, but also gained additional benefits of their disaster recovery with at a remote site and savings in renewing their hardware every few years.

To me, this is a great example of small steps customers can take to test the water. It also highlighted the future is not about private cloud or public cloud but a mesh comprised of private resources where control is critical, and public resources, where possible, that can improve the internal infrastructure on many aspects and introduce additional costs savings not possible internally.

2 weeks ago I was at the Interop show in Las Vegas. The amazing conclusion from the show is that the networking world is about to be disrupted. I am still surprised by this conclusion mostly due to the fact that in the last few years, networking seems to have settled down to a steady state where things work reasonably well, people are comfortable running their networks and networks pretty much do what we expect them to do.

So why am I jumping to this conclusion? Let me explain.

The innovation pace in networking seems to have slowed in the last few years. The constant stream of new competing technologies that were part of the 90s and early 2000s has somewhat subsided. Ethernet and packet switching has overcome most technologies both in the internal networking world as well as on the WAN (remember ATM ?), it has dominated WiFi standards, and other (non-Ethernet) edge networking technologies like Bluetooth have become mainstream. Even in the datacenter, Ethernet seems to be poised to replace other fast connection technologies such as Fiber Channel.

The latest developments seem to be more incrementally driven then disruptive. Higher speeds of the same basic technology are introduced, improved reception technologies are added (802.11n standard of WiFI), and so forth. All of these developments are usually backwards compatible so rip-and-replace are not as common and deployments have become more gradual.

This year's show was abuzz with interesting announcements and initiatives. All of them were focused on Cloud Computing integrations, although no one seems to know how it will play out. Naturally, most of the talk around Cloud Computing revolved around the application layer, since the application people are the ones pushing Cloud. When confronted with the question of what it would mean for the network, they are at first astonished by the mere question and then react saying they don't really know but feel it will be an critical part to solve.

Let's look at what this means:

The premise of Cloud Computing is of providing flexible computing power which can be turned on or off according to needs and be able to flexibly run any type of workload. To work, it would require the network to respond and adapt on the fly to these changing needs. Such networks would have to play second fiddle to the applications which will mandate the needs. If it is to work at all, new networks would have to be simplified and highly automated, so things would just work when needed. Automation by definition will reduce the amount of work on the side of the networking people, creating friction between the networking groups and application groups. At the end of the day it changes the work of networking and will reduce the amount of people needed to run them.

On the networking vendor side, there are going to be fortunes created and lost based on who can address these Cloud issues better. Since we know it will be done but do not know what the exact winning formula will be, discovery will be based on trials and errors. It is thus not clear who the winners will be.

So stay tuned, we are heading into very interesting times in the network world. Times that will change the networking world as we know it...

The overall agreement on the panel was that the network part in a cloud environment is a critical enabler that just has to work. The premise of cloud computing is the ability to achieve an order of magnitude savings in running your operations and at the same time gaining greater flexibility in resource usage and deployments. The risks if not implemented correctly are disruptions to your service, downtime, unpredictable service quality, difficulty to troubleshoot events, security, and the list goes on. All of these have to be tackled on the system architecture side to be able to seamlessly work together and address well all of the possible pitfalls. The challenge in getting a successful recipe here is in orchestrating all the pieces to perform exceptionally well together.

One option to reduce the risks is to remove performance dependencies between the various layers in the system. If the network layer just works no matter what, you can focus on top performance in your application layer without having to worry about the network part. If you run into issues you have to troubleshoot, the lack of dependence between the layers makes troubleshooting each layer separately simple and significantly reduces the overall complexity. This is possible if you can build a network that responds in a highly predictable way even when network traffic conditions change. This is already achievable today when using dedicated hardware like Crescendo Networks' AppBeat DC with its ability to handle traffic under varying conditions with low variance and guaranteed SLAs.

The other challenge when going into cloud is to actually gain the operational efficiencies and cost savings it promises.

The ways to achieve this are through:

• Sharing resources between multiple services
• Spinning up and down new resources when needed and being able to use them at other times for other services
• Spending the same management time and resources on large systems as on small systems - thus enjoying economies of scale
• Growing your needed resource pool in an incremental and economical way - spend on new resources only when there is demand for them without having to pre-build your system with dormant unused capacity

At Crescendo Networks, we know these challenges are critical to the success of cloud services as well as for today's hosting service providers. To address the economical "grow as you need" requirement we are developing functionality that will allow you to grow your system over time. With it, you'll be able to purchase one of our ADCs to fit your exact demand profile today while being able to add more capacity to the same system as demand expands and new capacity is needed. Using this functionality will allow incremental and economical growing of an ADC system. It will also make redundant the demand guessing game IT managers have to do today. Instead of trying to forecast your demand, just get what you need today and worry about extra capacity only when you need it.

We call this functionality - HyperScale.

Come visit our booth #2431 at Interop 2010 in Las Vegas to see a demo of how it works.