Web 2.0 style integration has become the norm with REST and SOA-based APIs – WebSockets may provide the speed and scale necessary to make it the perfect answer to infrastructure integration challenges

One of the concerns that arose early in the days of discussing Infrastructure 2.0, aka Dynamic Infrastructure, was the performance of integration methods. While collaboration across and between infrastructure components as a means to combat volatility and rapidity of change in the infrastructure made sense, what was harder to envision was a way in which such integration could be realized without compromising on performance.



Traditional data center infrastructure components were already adopting web-based integration methods – SOA, REST, etc. – but the reliance on HTTP was troubling. The synchronous nature of HTTP posed one challenge, which cascaded into more pedantic issues of idempotency, consistency, and the like.

While HTML5 WebSockets may not be wholly appropriate for public-facing web applications for a variety of reasons, it may be not only appropriate but advantageous for use in intra-data center integration. By addressing issues of synchronicity (WebSockets is asynchronous by design) as well as performance through the elimination of HTTP headers and provision for transferring data in binary formats, HTML5 WebSockets combines the simplicity of a REST or SOA-based API with higher performance.

This is particularly evident as cloud and virtualization-based architectures continue to integrate more thoroughly to streamline provisioning and management processes and automate operations. As diverse systems attempt to coordinate to enable a comprehensive application architecture deployment – complete with required infrastructure services such as acceleration and optimization as well as load balancing – the need for better performing methods of integration become necessary.

But problems abound with traditional web-based integration, especially where bi-directional communication is required. With traditional HTTP, such communication required either polling or two separate communication channels, requiring a significant investment in integration efforts on both sides of the integration.

The problem is that web-based integration is primarily one-sided; it’s used to integrate remote content into a site, and therefore the one-sided nature of such a pull of information makes HTTP appropriate for such an integration. With infrastructure integration – particularly when it’s focused on automation and orchestration of on-demand provisioning of services – is not so much pulling information as it is invoking operational tasks. Infrastructure integration is about instructing other components to execute a task, while information integration is about, well, aggregating information. The difference in goals means that traditional web-based integration methods, while preferable for its cross-platform agnosticism and ease of use, is not so desirable when the goal of the integration is part of a larger, orchestrated process.

Infrastructure integration needs a message bus. HTML5 WebSockets offers the same agnosticism and ease of use as HTTP, but with the characteristics more often associated with a message bus – a more publish and subscribe-based model than the polling one associated with HTTP and Web 2.0.

Thus, infrastructure integration will likely turn to HTML5 WebSockets to realize the high-speed intra-data center collaboration required without sacrificing the simplicity of a web-like integration paradigm.

Could SPDY provide the same benefits? Yes and no. SPDY is more geared toward accelerating and optimizing communications occurring across the web, particularly those originating over mobile networks. It does provide performance-enhancing benefits, but it does so without stripping HTTP to a bare-metal set of frames wherein data is wholly contained within frames that have no identifiable markers. That means more work for end-points – which will unduly task resource-constrained mobile devices – that may ultimately result in a net-loss of performance. SPDY maintains a balance between taking advantage of existing, optimized parsers with a reduction in content that addresses latency in transfer times. It’s simply not enough for intra-data center integration needs, but more than enough to provide a performance boost for mobile clients.

As noted in SPDY versus HTML5 WebSockets, SPDY is far more appropriate for public-facing web applications than is HTML5 WebSockets for reasons above and beyond performance. But HTML5 WebSockets is far more appropriate as an intra-data center message bus for infrastructure integration.

Round peg. Square hole. You know the idiom, and in this case, the shoe fits.

Connect with Lori:	Connect with F5:

Related blogs & articles:

• WebSockets - Basic Overview and Getting Started - HTML5 Tutorial
• SPDY versus HTML5 WebSockets
• Y U No Support SPDY Yet?
• The HTTP 2.0 War has Just Begun
• Oops! HTML5 Does It Again
• SPDY Momentum Fueled by Juggernauts
• Google SPDY Protocol Would Require Mass Change in Infrastructure
• Cloud is an Exercise in Infrastructure Integration
• Infrastructure Integration: Metadata versus API

Technorati Tags: F5,MacVittie,SPDY,HTML5,WebSockets,infrastructure,integration,Web 2.0,HTTP,SOA,cloud,performance,orchestration,automation,blog

• SPDY versus HTML5 WebSockets
• WebCast: 5 Signs You Need HTML5 WebSockets
• HTML5 Web Sockets: A Quantum Leap in Scalability for the Web