Imagine taking your car to the shop for major repairs and finding that the mechanic uses just one tool for everything, from changing a flat tire to replacing your transmission. He explains that he doesn't need all those expensive, special-purpose tools anymore now that he's found this one, All-Powerful Tool.
It sound ridiculous, but similar images come to mind when I hear the suggestion that network appliance vendors need to abandon their purpose-built platforms and deliver their solutions on general-purpose hardware. The argument is that raw compute power has increased to the point that specialized hardware solutions are no longer necessary. But before we write off purpose-built network solutions, let's revisit the reasons why they exist in the first place and consider how significantly they improve an enterprise's ability to deliver mission-critical applications.
Today's advanced application delivery controllers (ADCs) evolved from software-based load balancing solutions designed a decade or more ago to distribute comparatively unsophisticated applications and light user loads across low-speed physical networks. As hardware, operating systems, applications, and networks grew infinitely more sophisticated and mobile devices became pervasive, software-based load balancers couldn't keep pace and were soon moved to hardware platforms. To handle today's massive amounts of traffic and deliver mission-critical applications and data to users from virtually any location and on any device, enterprises need advanced ADC solutions they can trust to be fast, secure, and available, not to mention scalable and fault tolerant to accommodate rapidly changing business needs.
It's tough for a network vendor to deliver on these requirements and achieve the highest levels of performance with a solution that's based on a general-purpose platform. By definition, a general-purpose machine is designed to support many types of applications and workloads and specialize in nothing. And while it's true that technology advances have made today's general-purpose machines magnitudes more powerful than those of a decade or two ago, raw processing power alone doesn't equate to performance. Even if it did, it would be tough to cite that as a reason to do away with purpose-built solutions because they, too, benefit from those same technology advances.
Architecture, not raw processing power, is where performance strides can be made, and that's what gives purpose-built network solutions a distinct advantage. Because vendors of such solutions can choose not only the hardware components (such as CPUs, RAM, and networking devices) but also leverage customized hardware (such as ASIC and FPGAs) to add value, offload processing, and relieve architectural bottlenecks, they are able to provide fully integrated, high-performance, predictable, and highly reliable solutions.
Hardware accelerators integrated into such solutions are specifically designed to greatly speed certain computational processes, such as cryptographic operations. When performed on a general-purpose server, these operations can consume 30 percent or more of the server's CPU and memory cycles--and that's just one example. Acting as a proxy between client and server, a purpose-built ADC can aggregate millions of client requests into hundreds of server connections and cache them for reuse; it can intelligently manage and prioritize SSL sessions; it can apply intelligent compression to data--a task so compute-intensive when performed on a server that it can actually degrade rather than boost performance. It is these specialized hardware components, carefully integrated into the architecture, that enable purpose-built network solutions to scale to carrier-class levels of performance.
In the end, if it were feasible for network vendors to optimize these compute-intensive tasks on general-purpose platforms, don't you think they would? After all, it would certainly make these solutions easier to architect and more affordable to manufacture. When performance counts, however--and increasingly that seems to be the critical need--enterprises gain nothing by abandoning purpose-built network solutions. So when you hear such suggestions, remember why these solutions were built in the first place, not on a whim to benefit vendors, but rather to help enterprises improve efficiency, control their costs, and meet their most difficult and challenging needs: managing massive amounts of traffic in the delivery of mission-critical applications and data.
Posted by Karl Triebes on 01/18/20113 comments
Playing off the title of an earlier blog entry, "Out of Resources in the Twilight Zone," this entry explores the performance implications of moving from 1024- to 2048-bit key lengths--a recommendation by the National Institute of Standards and Technology (NIST) to increase the security of data encryption. The issue involves Secure Sockets Layer (SSL), a security protocol that uses RSA's public and private key encryption system to establish an encrypted link between a web server and browser. The protocol uses SSL certificates that currently employ 1024-bit RSA key lengths, but NIST has set January 1, 2011 as a target date for organizations to begin using 2048-bit key lengths.
More
Posted by Karl Triebes on 12/22/20100 comments
Although server virtualization is now a common deployment model in data centers, desktop virtualization hasn't caught fire as quickly. But with major vendors like VMware and Microsoft providing virtual desktop infrastructure (VDI) solutions, the
trend
is quickly moving in that direction. VDI solutions replace traditional desktop and laptop PCs with thin clients, giving users access to applications and services from centrally managed servers in the data center.
More
Posted by Karl Triebes on 11/16/20101 comments
Talk to the CIOs in virtually any organization today and they'll tell you they're drowning in data--creating, consuming, and digitizing more existing content than ever before. They're also retaining data longer because of business and regulatory requirements. Many are still dealing with flat (or nearflat) budgets, so this explosive growth in data is a daunting challenge for them. They need a strategy for creating an agile storage infrastructure that enables them to proactively manage growth and change without increasing capital and operational costs.
More
Posted by Karl Triebes on 11/02/20104 comments
Server virtualization is no longer a trend but rather a common deployment model adopted by the majority of IT organizations. Even so, virtualization is not without its deployment and management challenges. Many organizations still struggle to balance server workloads and maintain reliable application performance.
Because network appliances can affect both the performance of applications and traffic management, it's no surprise that network vendors have felt the pressure to develop virtualized versions of their physical appliances, from simple load balancers to advanced application delivery controllers. Virtual ADCs have typically been thought of as replacements for their physical counterparts (pADCs), and in some cases, replacement might be the appropriate solution. In other cases, however, replacement is clearly not the right strategy. To create the dynamic data centers IT organizations want, and to support the flexibility and scalability they need, architectural considerations must be taken into account. In the end, a hybrid architecture often turns out to be the best solution.
Who Stands to Benefit Most?
Let's start by looking at who can benefit from a vADC. In the enterprise data center, deploying a vADC in testing and QA environments can be of great benefit to network administrators and architects. For little cost, a vADC enables organizations to test and optimize new solutions before deploying them in production.
Ideally, it would be advantageous to make vADCs available to all teams involved in the application development lifecycle. Due to cost constraints, ADC technology has been largely unavailable to developers and architects--even when an application will ultimately be used in production with an ADC. With access to a vADC throughout the entire development process, architects and developers can include advanced ADC features such as acceleration, security, and optimization in the application delivery platform. Doing so can help foster collaboration among teams that, in the past, have often not worked together. And it can speed time to market and produce a better product that takes advantage of all the advanced features of application delivery controllers.
For similar reasons, independent software vendors can also benefit by deploying a vADC in their development environments. In particular, a vADC gives ISVs the opportunity to create new and innovative tools for managing and orchestrating both physical and virtual applications and network components--tools that are now in great demand, especially with the move toward cloud computing. Until effective management and orchestration tools exist, it's understandable that many organizations are reluctant to fully embrace virtualization and cloud computing solutions.
Many cloud providers have come to rely on physical ADCs to provide the flexibility and scalability that they require in these highly dynamic, virtualized environments. But, for cloud providers with many thousands of customers, it's critical that they be able to isolate components and application delivery policies for each customer, and that's where pADCs aren't so efficient. In such cases, a vADC can be an excellent fit because the cloud provider, rather than sharing its pADC among many customers, can instead enable customers to deploy their own vADCs, giving them control over their own application delivery policies.
Architectural Considerations
To create and maintain truly dynamic data centers, enterprise IT (and cloud providers as well) must not only look at who can benefit from vADCs but also at the potential effect of vADCs on characteristics such as scalability and mobility. vADCs are often thought to be the best choice for scalability because they can be deployed more quickly than pADCs and they are far less costly. But to assume that quick deployment makes vADCs less disruptive in the infrastructure is a mistake. Each is disruptive in its own way; pADCs for the obvious reasons of having to procure, install, configuration, and integrate a new device in the existing infrastructure. vADCs, on the other hand, can be disruptive because of their potential to degrade performance and application availability. One reason is that vADCs run on commodity hardware, so they can't take advantage of the specialized, optimized hardware typical of pADCs. For this reason, a vADC will never be able to achieve the same performance levels as a pADC.
Mobility is a particularly important consideration for organizations that plan to expand their operations into the cloud. Specifically, they need to consider the ease with which applications can be moved from data center to data center, and from the data center to the cloud and back again.
Organizations that rely on pADCs in their data centers will want to choose a cloud provider that does the same. But this, again, is where a vADC can be extremely applicable, if the application can be bundled with the vADC. In that case, it's far easier and more reassuring to move an application into the cloud knowing that all the configurations and policies associated with the application will move with it.
General Guidelines
Virtual network appliances have the potential to offer significant cost savings and new kinds of flexibility for IT organizations, but they also present more architectural challenges than do virtualized servers. If you're still uncertain about how best to deploy a hybrid application delivery network, deploy pADCs at key aggregation points in the infrastructure to get the benefit of server and application offloading functions (and the benefits of specialized, optimized hardware) that pADCs provide. Use pADCs to support application workloads that require high throughput, and for complex deployments that require advanced ADC functions like application security, acceleration, and access control.
vADCs are preferred for lab and QA environments, for example, when workloads require compute intensive processing. In these cases, deploy vADCs in a tier behind the pADCs that handle the server offloading functions. In the application development lifecycle, a vADC can help to enable quicker development, yield a better integrated product, reduce time to market, and encourage teamwork among network, security, and application development groups.
Posted by Karl Triebes on 10/05/20101 comments
There is a wide variety of use cases for cloud computing, many of which rely heavily upon the particular model of cloud discussed. SaaS (Software as a Service), for example, has a different usage than does IaaS (Infrastructure as a Service), particularly when leveraged in the context of a hybrid cloud data center model.
One of the first use cases for IaaS was centered on the concept of extending the data center on-demand. This was loosely coined as "cloud-bursting" and continues today to be the primary use case upon which many cloud-based solutions are built. This is primarily due to the fact that cloud-bursting -- the ability to extend capacity of existing applications by leveraging cloud-based compute resources dynamically -- requires addressing several technological challenges to become reality, many of which are applicable across the cloud computing spectrum.
The Challenge of Real-Time Migration
When offered an overview of a cloud-burstingcapable architecture, the first question that was raised--and is still often raised--is, "How do you get the application into the cloud in the first place?" Answering this question became a primary concern for solution providers because unless an application could be migrated on demand to a cloud computing provider, the value proposition for cloud-bursting was suspect. If the application had to exist prior to being "bursted" then the organization was paying for resources in the cloud all the time, which negated the proposed cost savings associated with the solution. Thus it became an imperative to address the challenge of migrating an application in real time as a means to enable cloud-bursting without negatively impacting the value proposition of cloud computing.
This process turned out to be a lot harder than anticipated. The assumptions and requirements continue to be restrictive:
- Both the data center and the cloud computing environment must utilize the same virtualization platform, or have the means by which an application can be packaged in a cloud computing environment specific container in real time.
- The networking layer in both the cloud provider's environment and data center must be bridged as to allow communication with existing infrastructure, ensuring availability and continued operation of delivery infrastructure.
- The application package must be transferred across often high-latency WAN links to the cloud computing provider as quickly as possible because limitations integral to migration capabilities of virtualization platforms will cause such a transfer to fail if not completed in a fairly narrow window.
- The existence of the new application resource in the cloud computing environment must be made known and subsequently accessible to the infrastructure responsible for directing end users to that instance of the application.
While addressing these issues it has become clear that the transfer of the application from one location to another posed the biggest obstacle to enabling a truly dynamic cloud-bursting-capable infrastructure. That's because a number of underlying technological issues--distance, size of application packaging in virtual containers, and architectural limitations on existing solutions--made it difficult the use well-understood and traditionally used methods to counter those issues.
Using Traditional Solutions in Untraditional Ways
The network--specifically, the external WAN--is at the heart of the challenge when enabling elastic applications that are capable of cloud-bursting on-demand. The very organizations that would benefit most from the cost savings associated with leveraging ondemand cloud computing resources are the same organizations whose Internet-facing network connectivity is likely to be less than optimal in terms of quality and proximity to the Internet backbone. These same network links are utilized by other applications and users as well, which makes it difficult for the organization to ensure the quality and speed necessary to successfully transfer a virtualized application from its data center to an off-premise cloud environment.
The obvious solution is to leverage accepted architectural solutions: WAN optimization technologies. The hurdle with a traditional WAN optimization solution, however, is in the network configuration and deployment, which requires specific placement in both the data center and off-premise location. This is required because WAN optimization solutions use data deduplication to address the challenge of transferring big data across small pipes. This process requires a symmetric deployment model and further requires specific placement of the solution in the network. While the former has been addressed by the virtualization of WAN optimization solutions, the latter is not. Cloud computing providers allow little to no control over topological decisions regarding the deployment of solutions in their environment, making a traditional WAN optimization solution unfeasible.
What is feasible is the use of data deduplication and other WAN-related optimization technologies to improve the conditions of the network connection and simultaneously ensure the successful migration of a virtualized application. Managing data deduplication at a strategic point of control in the architecture becomes necessary to enable the functionality of a WAN optimization solution.
An Architectural Strategy Can Achieve Where Individual Products Fail
By applying WAN delivery services within the context of holistic application delivery, a solution is capable of addressing not only the successful transfer of on-demand of virtualized applications from the data center to the cloud environment, but also the networking and application routing challenges associated with an on-demand cloud-bursting architecture.
On-demand cloud-bursting architectures have been demonstrated as feasible and capable of maintaining cost-reducing benefits with a strategic architecture that optimizes not only layers of the network but the entire process. This comprises triggering the event that initiates the process to monitoring the entire application set across environments as a means to ensure that extraneous cloud-deployed applications are in use only as long as they need be, and no longer.
By architecting a solution rather than deploying individual products to address each challenge, on-demand cloud-bursting has become not only possible but feasible. The challenges associated with leveraging cloud computing in ways that preserve its value proposition will continue to be best answered with a holistic architectural strategy rather than individual tactical product deployments. Such tactical solutions are incapable of providing the visibility, control, and flexibility needed to enable the dynamic infrastructure required to fully take advantage of a dynamic compute resource model such as underpins an on-demand, cloud-bursting solution.
Posted by Karl Triebes on 09/16/20101 comments
Every time we hop into our cars and head onto city streets or highways, we immediately become part of a complex system that, for the most part, we take for granted. Most days, we get to our destinations safely (and in a reasonable amount of time), thanks to stop signs, traffic signals, yield signs, roundabouts, merge lanes, on ramps and off ramps. These mechanisms are integrated into roads and highways at strategic locations to help control and guide the flow of traffic and keep us safe. The key words here are strategic and control. Imagine what traffic would be like if we had none of these controls on roads and highways or, worse yet, if every intersection were controlled by unsynchronized traffic signals. Chaos and gridlock would ensue. The challenge in controlling the flow of traffic and minimizing traffic jams is to implement the right mechanisms at the right locations, typically where traffic converges -- in other words, at strategic points of control.
More
Posted by Karl Triebes on 08/24/20102 comments
It's no secret that security is on the minds of most IT professionals who are considering cloud computing. In fact, some surveys show that as many as 80 percent of businesses believe that the security, availability and performance risks of cloud computing outweigh the potential benefits, such as flexibility, scalability, and lower cost--so much so that they're holding back from fully embracing cloud computing, at least, for now.
It would be a mistake, however, to assume the reason for their concern is that cloud providers are taking a cavalier attitude toward security. That assumption is an oversimplification and, more importantly, obscures the legitimate security concerns of IT organizations.
The reasons for concern have more to do with organizations losing their ability to quantify risk in the cloud. Without that ability, it's tough for them to justify taking the risk. Assuming they could quantify risk, how much control would they have in the cloud for mitigating that risk through the use of processes and technology? Today, little, if any. Organizations' hesitation to jump headlong into the cloud has more to do with these factors than a lack of confidence in cloud providers' security implementations.
In the data center, organizations typically determine their threshold for risk by considering the impact of the risk and the probability of its occurrence. As an example, take the potential impact of an outage on application availability. When an outage occurs, the monetary impact--measured by lost revenue and customers--is quantifiable. Similarly, organizations can reasonably assess the probability of a data center outage--and its impact on applications--but what about in the cloud? Today, a cloud provider's track record for uptime is more readily available than it was, say, even a year ago, making it easier to determine the chances of an outage, but uncertainty still exists.
In addition to these, there are other reasons that keep "security concerns" at or near the top of the list of barriers to cloud adoption. A significant one is that cloud computing environments don't give organizations the benefit of deploying a holistic security strategy. Organizations that are happy with their security practices in the data center have reason to be concerned about their ability to implement those same practices in the cloud. They won't have control over web application firewalls or application-specific firewall rules; they won't have data leak prevention solutions or intrusion detection/prevention systems in the cloud. They won't have any of that for the simple reason that today, the cloud is designed to deliver compute on demand. In other words, it's meant to run applications that can take advantage of that compute power. Other than load balancing, the cloud offers very few "infrastructure" services. That severely limits an organization's ability to apply internal security policies to the applications it moves to the cloud.
Many unknown variables still exist in cloud computing environments, which introduce security risks that haven't yet been quantified. Two of those variables are virtualization and cloud computing management frameworks. While virtualization may get the most attention of the two, the importance of computing management frameworks is inching forward. Exploits around virtualization have been theorized, but to date, few, if any, hypervisor "breaches" in a public cloud environment have occurred. Still, even the possibility of a breach and its potential damaging effects may pose too much risk for some organizations. And with few known vulnerabilities in hypervisor technology, it's almost a foregone conclusion that vulnerabilities will be discovered and ultimately exploited. So far, cloud APIs have not been taken over either, but the possibility of an attacker having complete control over an organizations' cloud computing deployment is frightening.
The fact that CIOs will likely continue for some time to cite security risks as a reason not to adopt cloud deployments doesn't mean they believe cloud providers are taking security concerns lightly. It just means they still have legitimate concerns about the security risks of new technologies in the cloud--concerns that haven't yet been answered to their satisfaction. They are highly sensitive to these risks, not just for their own sake but for the sake of their customers. Until they are alleviated, those risks will likely still outweigh the potential benefits of cloud computing.
Posted by Karl Triebes on 07/27/20102 comments
When organizations are choosing between hardware and virtual servers, some would argue that it doesn't make sense to purchase a hardware solution when all you really need is the software. As such, you should just acquire and deploy a virtual network appliance.
One point this argument fails to address is that we see an increase in compute power when using general purpose hardware as well as purpose-built hardware and the specialized hardware cards that provide acceleration of specific functions like compression and RSA operations (SSL). But for the purposes of this argument we'll assume that performance, in terms of RSA operations per second, are about equal between the two options.
That still leaves two very good situations in which a virtualized solution is not a good choice.
Compliance with FIPS 140
For many industries--federal government, banking, and financial services among the most common--SSL is a requirement, even internal to the organization. These industries also tend to fall under the requirement that the solution providing SSL be FIPS 140-2 or higher compliant. If you aren't familiar with FIPS or the different "levels" of security it specifies, then let me sum up: FIPS 140 Level 2 (FIPS 140-2) requires a level of physical security that is not a part of Level 1 beyond the requirement that hardware components be "production grade," which we assume covers the general purpose hardware deployed by cloud providers.
FIPS 140-2 requires specific physical security mechanisms to ensure the security of the cryptographic keys used in all SSL (RSA) operations. The private and public keys used in SSL, and its related certificates, are essentially the "keys to the kingdom." The loss of such keys is considered to be a disaster because they can be used to (a) decrypt sensitive conversations/transactions in flight and (b) masquerade as the provider by using the keys and certificates to make more authentic phishing sites. More recently keys and certificates, PKI (Public Key Infrastructure), has been an integral component of providing DNSSEC (DNS Security) as a means to prevent DNS cache poisoning and hijacking, which has bitten several well-known organizations in the past two years.
Obviously you have no way of ensuring or even knowing if the general purpose compute upon which you are deploying a virtual network appliance has the proper security mechanisms necessary to meet FIPS 140-2 compliance. Therefore, if FIPS Level 2 or higher compliance is a requirement for your organization or application, then you really don't have the option to go virtual because such solutions cannot meet the physical requirements necessary.
Resource Utilization
A second consideration, assuming performance and sustainable SSL (RSA) operations are equivalent, is the resource utilization required to sustain that level of performance. One of the advantages of purpose-built hardware that incorporates cryptographic acceleration cards is that it's like being able to dedicate CPU and memory resources just for cryptographic functions. You're essentially getting an extra CPU, it's just that the extra CPU is automatically dedicated to and used for cryptographic functions. That means that general purpose compute available for TCP connection management, application of other security and performance-related policies, is not required to perform the cryptographic functions. The utilization of general purpose CPU and memory necessary to sustain X rate of encryption and decryption will be lower on purpose-built hardware than on its virtualized counterpart.
That means while a virtual network appliance can certainly sustain the same number of cryptographic transactions it may not (likely won't) be able to do much other than that. The higher the utilization, too, the bigger the impact on performance in terms of latency introduced into the overall response time of the application.
You can generally think of cryptographic acceleration as dedicated compute resources for cryptography. That's oversimplifying a bit, but when you distill the internal architecture and how tasks are actually assigned at the operating system level, it's an accurate if not abstracted description.
Because the virtual network appliance must leverage general purpose compute for what are computationally expensive and intense operations, that means there will be less general purpose compute for other tasks, thereby lowering the overall capacity of the virtualized solution. That means in the end the costs to deploy and run the application are going to be higher in OPEX than CAPEX, while the purpose-built solution will be higher in CAPEX than in OPEX – assuming equivalent general purpose compute between the virtual network appliance and the purpose-built hardware.
Posted by Karl Triebes on 07/13/20100 comments
Infrastructure 2.0, also known as dynamic infrastructure or dynamic data center, is the next-generation data center model in which IT resources (these days, likely virtualized) are pooled and leveraged to provide flexible and scalable IT capacity on demand--whether in the data center or in the cloud. In theory, everybody wants it, but how easy will it be for enterprises to implement? And what does it take to achieve it?
Any IT organization that has struggled with enterprise application integration (EAI) knows how difficult it is to integrate disparate systems, applications, and data sources. Implementing infrastructure 2.0--a fully integrated, collaborative infrastructure--isn't any easier. At least, not yet. It will require whole new levels of integration, automation, and orchestration beyond what's required for EAI.
Many organizations have already taken steps toward automation--converting the steps required to complete management tasks (such as provisioning or deprovisioning a virtual machine) from manual to automated processes. Automation is about managing infrastructure components to provide consistency, eliminate redundant tasks, cut down on errors, and improve response times. In contrast, orchestration is about using the results of those automated processes to make intelligent decisions based on business goals. Where automation helps improve IT performance, orchestration uses that performance improvement to achieve specific business goals and initiatives. Because it enables orchestration, automation must be mastered before enterprises can even think about orchestration. (It's counterproductive to make business decisions based on processes that are not proven and reliable.)
Enterprises are not alone in their struggle to implement Infrastructure 2.0; network vendors and infrastructure providers share the same challenges as they develop solutions to help customers achieve these goals.
Ideally, the best way to achieve advanced levels of integration, automation, and orchestration is through service-enabled APIs. The problem is, most vendors have their own APIs, and no two are alike--you can't use one vendor's API to manage another vendor's network devices.
The good news is that many of today's infrastructure management solutions are API-enabled--SOAP, HTTP, REST, XML, JSON, etc. That's why many network vendors are working closely with partner/vendors that provide these solutions. Through collaborative partnerships, network vendors can tightly integrate their networking (load balancing and application delivery network) solutions with popular infrastructure management solutions such as HP Operations Orchestrator, Microsoft Virtual Machine Manager, and VMware vCenter Orchestrator. (These solutions are somewhat analogous to EAI solutions that include vendor-specific software adapters.) Through automation, these solutions greatly simplify network deployment, management, and maintenance tasks--and bring organizations one step closer to implementing the orchestration that's ultimately required to achieve a fully integrated, collaborative infrastructure.
Posted by Karl Triebes on 07/01/20100 comments
While many organizations are still trying to get their arms around cloud computing concepts and terminology, "cloud balancing" might seem like just one more piece of jargon to add to the confusion. In fact, cloud balancing is an important concept that will play a significant role in cloud deployments, opening up new possibilities for organizations with limited resources to benefit from cloud computing.
So, what is cloud balancing? Think of it as the next generation of global server load balancing; it extends into the cloud the architectural deployment model currently used in global server load balancing.
With cloud balancing, application requests are distributed across application deployments in multiple data centers and in the cloud, thereby increasing the number of available locations from which an application can be delivered.
With traditional global server load balancing, the technical goals are to deliver high availability at maximum performance. Application routing decisions are made based on variables such as application response time, application availability at a given location, current and total capacity of the data center and cloud computing environment, user location, and time of day.
Increasingly, however, customers want to make application routing decisions based on other variables, such as the cost to execute a request by location, total cost to deliver the request, regulatory requirements, and the services required to fulfill a request per SLAs. High availability and performance are still important, but they also want to deliver applications using the least amount of resources at the lowest possible cost. To do that, they need a way to supply those additional variables to the global application delivery solution. Cloud balancing itself doesn't provide the technical framework for collecting these variables; what's required is a global application delivery solution that is context-aware--one that integrates the network, application, and business variables into the decision-making process. When these additional business-driven variables are available, cloud balancing becomes a viable solution for organizations to optimally deliver applications at the lowest possible cost with the fewest amount of resources.
Challenges persist with cloud balancing, some due to the immaturity of current cloud-based offerings and will eventually correct themselves with maturity; others will inevitably call for new standards to be written:
- Finding the right cloud provider remains one of the most difficult and time-consuming challenges. With cloud computing still so new to many organizations, it's difficult for organizations to sort through the myriad services, comparing one provider's offerings to another. Compounding that problem is that offerings change as market demands change.
- Application portability ranges from difficult to impossible because there are no standards among cloud providers for migrating applications. Lack of interoperability at the application layer compounds this problem. Proprietary platforms make it difficult to incorporate local data center deployments into a cloud balancing solution. In contrast, commercial platforms potentially make it easier to implement a cloud balancing solution, but only if the virtualization platforms are the same. If not, this hurdle may prove just as challenging as that of proprietary platforms.
- Lack of integration between the global and the local application delivery solutions makes cloud balancing solutions impossible. Cloud balancing requires variables supplied by the local environment, so the global and local environments must be able to share information. One way to get this integration is to use a single vendor, but many organizations don't want to be locked in. What's needed is a dynamic, cross-environment, vendor-neutral solution, which will most likely emerge from standards-based APIs and Infrastructure 2.0 efforts. Until then, however, organizations will need to leverage existing component APIs to integrate variables.
- Architectural and operational differences between global and local application delivery solutions present similar kinds of issues. Virtual appliances are helpful, but only to a point, because many cloud computing models are based on proprietary virtualization technologies. That makes it difficult for organizations to replicate architectures across cloud deployments.
Deploying a virtual application delivery controller (vADC) along with the application in the cloud can help solve some of the architectural inconsistencies. A vADC provides the local load balancing component that's needed to implement a cloud architecture. With a vADC, an organization has the means by which to monitor and manage the health of the cloud-based deployment. A vADC also solves the integration issue, providing a way for the global application delivery controller to include the variables used in cloud balancing and choose the best location from which to serve applications.
For organizations that want to improve application performance, ensure application availability, and implement a strategic disaster recovery plan, cloud computing is a cost-effective alternative to building additional data centers. Cloud balancing extends those advantages by enabling organizations to leverage cloud deployments along with their local application delivery deployments. As a result, smaller organizations with limited resources will have the same opportunities as large organizations to optimize application delivery.
Posted by Karl Triebes on 06/18/20105 comments
You can hardly open any technology or business journal, Web site or newspaper today without hearing some commentary on cloud computing -- what it is and how it will change IT and business. Very few, if any, would argue that its impact will not continue to be felt for many years, regardless of how it all comes together in the end. At the same time, you might also begin to notice that no single definition exists of cloud computing as being talked about, planned and, even, implemented in today’s enterprise networks. Furthermore, any attempt by vendors to define cloud computing is seen as simply a marketing ploy to make their products seem more necessary.
More
Posted by Karl Triebes on 06/01/20106 comments