What is Network-based Application Virtualization and Why Do You Need It?

Need it you do, even if know it you do not. But you will…heh. You will.

 

With all the attention being paid these days to VDI (virtual desktop infrastructure) and application virtualization and server virtualization and virtualization it’s easy to forget about network-based application virtualization. But it’s the one virtualization technique you shouldn’t forget because it is a foundational technology upon which myriad other solutions will be enabled.

WHAT IS NETWORK-BASED APPLICATION VIRTUALIZATION?

This term may not be familiar to you but that’s because since its inception oh, more than a decade ago, it’s always just been called “server virtualization”. After the turn of the century (I love saying that, by the way) it was always referred to as service virtualization in SOA and XML circles. With the rise of the likes of VMware and Citrix and Microsoft server virtualization solutions, it’s become impossible to just use the term “server virtualization” and “service virtualization” is just as ambiguous so it seems appropriate to give it a few more modifiers to make it clear that we’re talking about the network-based virtualization (aggregation) of applications.

That “aggregation” piece is important because unlike server virtualization that bifurcates servers, network-based application virtualization abstracts applications, making many instances appear to be one.

Network-based application virtualization resides in the network, in the application delivery “tier” of an architecture. This tier is normally physically deployed somewhere near the edge of the data center (the perimeter) and acts as the endpoint for user requests. In other words, a client request to http://www.example.com is answered by an application delivery controller (load balancer) which in turn communicates internally with applications that may be virtualized or not, local or in a public cloud.

Many, many, many organizations take advantage of this type of virtualization as a means to implement a scalable, load balancing based infrastructure for high-volume, high-availability applications.

Many, many, many organizations do not take advantage of network-based application virtualization for applications that are not high-volume, high-availability applications.

They should.

FOUR REASONS to USE NETWORK-BASED APPLICATION VIRTUALIZATION for EVERY APPLICATION

There are many reasons to use network-based application virtualization for every application but these four are at the top of the list.

  1. FUTURE-PROOF SCALABILITY. Right now that application may not need to be scaled but it may in the future. If it’s deployed on its own, without network-based application virtualization, you’ll have a dickens of a time rearranging your network later to enable it. Leveraging network-based application virtualization for all applications ensures that if an application ever needs to be scaled it can be done so without disruption – no downtime for it or for other applications that may be impacted by moving things around.

    This creates a scalability domain that enables the opportunity to more easily implement infrastructure scalability patterns even for applications that don’t need to scale beyond a single server/instance yet.
  2. IMPROVES PERFORMANCE. Even for a single-instance application, an application delivery controller provides value – including aiding in availability. It can offload computationally intense functions, optimize connection management, and apply acceleration policies that make even a single instance application more pleasant to use. 

    An architecture that leverages network-based application virtualization for every application also the architect to employ client-side and server-side techniques for improving performance, tweaking policies on both sides of “the stack” for optimal delivery of the application to users regardless of the device from which they access the application. The increasing demand for enterprise applications to be accessible from myriad mobile devices – iPad, Blackberry, and smart phones – can create problems with performance when application servers are optimized for LAN delivery to browsers. The ability to intelligently apply the appropriate delivery policies based on client device (part of its context-aware capabilities) can improve the performance of even a single-instance application for all users, regardless of device.
  3. STRATEGIC POINT of CONTROL. Using network-based application virtualization allows you to architect strategic points of control through which security and other policies can be applied. This include authentication, authorization, and virtual patching through web application firewall capabilities. As these policies change, they can be applied at the point of control rather than in the application. This removes the need to cycle applications through the implementation-test-deploy cycle as often as vulnerabilities and security policies change and provides flexibility in scheduling.

    Applications that may be deployed in a virtualized environment and that may “move” around the data center because they are not a priority and therefore are subject to being migrated to whatever resources may be available can do so without concern for being “lost”. Because the application delivery controller is the end-point, no matter where the application migrates it can always be accessed in the same way by end-users. Business continuity is an important challenge for organizations to address and as infrastructure continues to be virtualization and highly mobile the ability to maintain its interfaces becomes imperative in reducing the disruption to the network and applications as components are migrating around.
  4. IMPROVES VISIBILITY. One of the keys to a healthy data center is keeping an eye on things. You can’t do anything about a crashed application if you don’t know it’s crashed, and the use of network-based application virtualization allows you to implement health monitoring that can notify you before you get that desperate 2am call. In a highly virtualized or cloud computing environment, this also provides critical feedback to automation systems that may be able to take action immediately upon learning an application is unavailable for any reason. Such action might be as simple as spinning up a new instance of the application elsewhere while taking the “downed” instance off-line, making it invaluable for maintaining availability of even single instance-applications.

    When the application delivery infrastructure is the “access point” for all applications, it also becomes a collection point for performance-related data and usage patterns, better enabling operations to plan for increases in capacity based on actual use or as a means to improve performance.

To summarize, four key reasons to leverage network-based application virtualization are: visibility, performance, control, and flexibility.

APPLICATION DELIVERY INFRASTRUCTURE is a PART OF ENTERPRISE ARCHITECTURE

The inclusion of an architecture of an application delivery network as a part of a larger, holistic enterprise architecture is increasingly a “must” rather than a  “should”. Organizations must move beyond viewing application delivery as simple load balancing in order to take full advantage of the architectural strategic advantages of using network-based application virtualization for every application. The additional control and visibility alone are worth a second look at that application delivery controller that’s been distilled down to little more than a Load balancer in the data center.

The whole is greater than the sum of its parts, and load balancing is just one of the “parts” of an application delivery controller. Architects and devops should view such data center components with an eye toward how to leverage its many infrastructure services to achieve the flexibility and control necessary to move the enterprise architecture along the path of maturity toward a truly automated data center.

Your applications - even the lonely, single-instance ones – will thank you for it.


 
Published Oct 18, 2010
Version 1.0

Was this article helpful?

No CommentsBe the first to comment