CEP Breaking News, Articles, Feature Stories and Blog Posts

CEP on Ulitzer

Subscribe to CEP on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get CEP on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


cep Authors: Tony Shan, Liz McMillan, Bob Gourley, Charles Rich, AppDynamics Blog

Related Topics: CEP on Ulitzer

cep: Blog Feed Post

The Impact of HTML 5 on Application Infrastructure

Smashing Magazine has a cool “cheat sheet” for those interested in the ongoing development of HTML 5. Of interest is what’s being excluded and what’s new, as well as the length of time it’s html5-logogoing to take before HTML 5 is completely supported:

XHTML is dead, long live HTML 5! According to W3C News Archive, XHTML 2 working group is expected to stop work end of 2009 and W3C is planning to increase resources on HTML 5 instead. And even although HTML 5 won’t be completely supported until 2022, it doesn’t mean that it won’t be widely adopted within the foreseeable future.

Part of the “completely supported” should include, if necessary, application infrastructure: load balancing, acceleration, caching, and security. Because these types of infrastructure solutions are not only aware of content but rely upon it as actionable data for decision making processes it’s important to consider early how changes to the specification might impact that application infrastructure.

One of the big changes in HTML 5 that leaps out in terms of infrastructure is that it’s getting more granular about content. Rather than being limited to the generic <object> or <embed> tags, for example, HTML 5 thus far includes <video>, <audio>, <canvas>, and <figure> to describe specific types of content more accurately. In a generic sense, this might make for easier to configure policies or, at a minimum, at least make them more readable. It’s much simpler and elegant to describe content using a meta-tag than it is to search out content types with long and often difficult to remember descriptors.

In most cases the changes thus far appear to be positive in that they would afford the infrastructure with more granular information on which to base application of policies. That’s a good thing, as it allows the infrastructure to get even smarter about how it deals with web-based applications.

The thing with HTML – and all content returned from web applications – is that it has very little impact on requests. That’s because the requests don’t include tags, it’s just a URI. The response, however, is laden with content and tags and information that can transformed and otherwise potentially optimized and sanitized before it is returned to the client. Thus any impact on infrastructure will likely be focused on the response.


LOAD BALANCING / APPLICATION SWITCHING

At first glance there really isn’t anything new in HTML 5 thus far that requires a change to load balancing or application delivery infrastructure. What it will do, however, is encourage architects to optimize application architecture. One of the most efficient means of achieving an optimized architecture is to “specialize” application servers. This is especially efficient in a virtualized architecture.

By separating out content types and optimizing the application server (virtual or physical) or that specific content type, architects can improve the performance and resource utilization of the entire application infrastructure. But in order to do that the infrastructure must be able to route requests to the correct application server. Hence the need for application switching or layer 7 load balancing rather than simple layer 4 load balancing. If the application delivery infrastructure is smart enough to route specific content types or URIs to specific servers, the entire application architecture benefits. Application infrastructure is already able to do this, but the granular tags in HTML 5 should make it even easier to configure on-demand routing via transformation (automatic replacement).

That means replacing attributes such as the href in the event there is a need to redirect the specific content to another application server or even a different data center. The ability to modify the URI on-demand will be important as cloud adoption increases and new ways of leveraging application services continue to appear. That particular ability will make it easier to implement architectures that utilize a hybrid cloud approach, i.e. multiple data centers comprising a traditional physical data center and any number of “cloud-based” data centers.


WEB ACCELERATION & CACHING

Web acceleration and caching may benefit from HTML 5 and its more granular tagging. Parsing responses should be easier because you know exactly what you’re looking for, which means instead of using redirection to content delivery networks or other intermediaries in the infrastructure you can likely transform the reference to the object on the response rather than waiting for the reply. Removing the intermediate step of redirecting improves application performance as you’re eliminating a request-response cycle from the process.

Taking that a step further, and leveraging a unified application and data delivery infrastructure, one could include global application delivery techniques with the transformation to really distribute objects across multiple data centers or clouds. As with load balancing this can be accomplished now, but it should be easier to actually do using specific tags to identify content types. 


WEB APPLICATION SECURITY

Web application security is going to get more complex and will likely be affected the most by the adoption of HTML 5. There are new content types that are certain to be exploited long before mainstream adoption. That means web application security – and browser security, too – is going to need to get up to speed quickly on securing these objects from tampering and exploitation. Tags such as: <eventsource> <source> <ruby> and even <menu> appear to be likely targets for exploitation.

Unfortunately the only tag being excluded from HTML 5 that is a good thing is <frame>, but as of today the specification keeps <iframe> so the benefits of losing the former (clickjacking, for example, relies on the use of frames) are negated by keeping the latter.


MINIMAL IMPACT on INFRASTRUCTURE

There doesn’t appear to be anything in HTML 5 right now that is worrisome or different enough from XHTML and HTML 4 that would require significant change in application infrastructure. Certainly the additional options and granularity will be a boon for management and configuration of intermediaries designed to deliver and secure web applications, but in terms of functionality that may be affected there appears to be no impact at the moment.

It would be nice to see the inclusion as standard attributes some of the Web 2.0 functionality we’ve come to depend on today, or tags to indicate dynamic requests that include standardized attributes to be used for handlers and event processing. This would alleviate the issue of cross-library compatibility and make it much easier to move from one dynamic library to another, or use them simultaneously in the same application.

But the real impact is likely to be on architecture and on the way in which infrastructure is leveraged to secure and deliver web applications. At least that’s the way it looks right now. We’ll see if that changes in the future, but the direction thus far would appear to indicate that radical change to HTML is unlikely. Unless that turns out to be false, there shouldn’t be a huge impact on application infrastructure.

 

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

Related blogs & articles:

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.