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.
Successfully directing and controlling the flow of traffic in computer networks is not much different; it requires similar strategic points of control. Without them, IT is forced to respond to new business demands on a case-by-case basis with solutions that aren't integrated into the existing architecture. That's sort of like building a new road every time you want to travel to a new destination instead of planning a logical route using existing roads and highways.
In the context of the data center, strategic points of control are the locations at which decisions are made about how best to deliver applications and data. These often occur at aggregation points -- the points through which all traffic flows. One of the most important points of aggregation is at the network perimeter. In the same way that a drawbridge across a mote provides the only access to a castle, a network router and firewall provide the only outside access to the network. Because the router and firewall are on the network's perimeter, it's a logical place to implement and enforce access policies. (Even kings had "access policies" of sorts -- although failing to meet them might land you in the dungeon.)
Once inside the firewall, there are other strategic control points within the data center architecture. Virtualized storage, which controls access to the resources it manages and gives IT visibility into all storage resources, is a point at which IT can apply security policies. An application delivery solution is also a strategic point of control. Because all application requests and responses are funneled through it, it is a logical place where application security, acceleration and optimization can be applied.
Another strategic control point that's becoming more common in the data center is the virtual network -- it provides more efficient connectivity between virtual machines than a traditional network does. In a traditional network, communication between applications deployed on a single server with virtual machines and virtual switches might require exiting and re-entering the server's network card. In a virtual network, however, that physical path along which data travels (and the latency associated with it) no longer exists, so communication between virtual machines is more efficient. The network layer is a prime location to enforce access policies, especially in public cloud environments where multi-tenancy is a probability.
These three strategic control points -- virtualized storage, application delivery solutions and the virtualized network -- share one thing in common: They are all points at which virtualization, and by extension, aggregation, occurs. Aggregation is an example of the traditional "many-to-one" type of virtualization (typically associated with load balancers and other proxy-based solutions) that makes multiple resources appear to be a single resource. A many-to-one type of virtualization solution also provides a strategic point of control because all traffic must flow through that solution. That makes it a perfect point at which to apply access and security policies in a single, centrally managed location.
Although the many-to-one type of virtualization is not new -- it has been around since the mid 1990s -- it has evolved over the years to give IT more precise control over the data that traverses strategic points in the network. Again, "strategic" and "control" are the key terms. Any point in the network is considered strategic if it offers the opportunity to consistently and efficiently apply policies (i.e., control) to data at a single point in the data path.
Today, many IT organizations are still struggling with the static one-to-one connections between technologies that they have had for years. This forces IT to respond to new business demands with manual, one-off technology fixes (remember the idea of building a new road every time you want to go someplace new?). In contrast, having strategic points of control throughout the infrastructure gives IT the ability to add, move or redefine services on demand. In turn, IT can create, modify and scale the infrastructure in line with changing business demands -- and without compromising the organization's long-term objectives.
Posted by Karl Triebes on 08/24/2010 at 12:36 PM0 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/2010 at 4:21 PM1 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/2010 at 12:11 PM0 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/2010 at 4:08 PM0 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/2010 at 3:15 PM0 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.
While they may still disagree on whether SaaS is or isn’t cloud computing, many agree that SaaS could be -- and often is -- part of or delivered via cloud architectures, as well as the fact that it can be so much more. Enterprise customers are interested in more than simple server virtualization and consolidation, but realize the impacts of security and maintaining access control as applications and data are dispersed through the various technologies.
One of the key components is the idea that cloud computing is a “style” of computing -- an architecture. It is simply a way of combining mostly existing tools together, automating and orchestrating those processes in order to achieve specific results. What are those results? Ultimately, it is to provide a computing infrastructure that users -- and not necessarily technical users at that -- can simply plug into.
The question then, is what does this architecture look like and what is required above and beyond the standard tools we have today to qualify as a “cloud”?
An important strategic consideration is the integration of all the pieces of the infrastructure to create the style known as cloud. This includes everything from the bare metal to the users themselves and all the elements in between. In addition, it suggests different ways to view the interaction of various operations within the architecture depending on your role as a technical builder or a business manager.
In general, we see cloud computing architecture built upon several functional component blocks (e.g., compute resources or deployment environments), organized into specific layers of a pyramid whose width represents the amount of technical skills or depth of expertise required to build and/or deploy that layer. These layers are roughly synonymous with the notions of Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). At the very apex of the pyramid are the users accessing the applications built upon the cloud architecture; in the center is a block which traverses all others and provides real-time connectivity, information coordination and flow control between the blocks/layers.
We are convinced that in order to maximize the value of cloud architecture, each component must exist in some state or another. For example, dynamic control plane elements are a requirement at every layer of the cloud architecture due to the necessity for cloud environments to be operationally efficient and on-demand. This calls for a level of automation and orchestration that can only be achieved by integrating components across the architecture. Without this collaborative capability, a given cloud architecture model is not capable of enabling an organization to realize the benefits associated with the model. If any of the core components is not implemented, such collaboration will fail and ultimately a true cloud architecture cannot be achieved.
Utility Computing
Built from core components that include compute resources and management resources, the base layer of the cloud architecture requires the most technical competence to build and/or deploy. This is the very foundation upon which a cloud is built and, as suggested, is the components most often supplied by vendors who provide IaaS solutions to their customers.
Framework Computing
Many applications are built upon software platforms that run on top of infrastructure services. These platforms may be environments like Oracle, BEA or ASP.NET and provide a convenient way for businesses to build custom applications without needing to concern themselves with the details that lay beneath the platforms. While many platforms are based on standards, e.g. Java EE, others are proprietary in nature including Google AppEngine and architecture frameworks developed and deployed by enterprise architects.
Business Computing
At the top of the pyramid, we find general business computing. This is where many organizations find themselves -- especially business organizations -- with the ability to identify a business need, but without the ability to build an application or the infrastructure upon which it runs. Instead of relying on an internal IT organization to build and/or deploy infrastructure and platforms, business stakeholders simply select an application and run it. This occurs for many different reasons, but the most common theme is that the capital, operating expenses, and man-hours required to implement applications that have standardized across industries, is not financially feasible, not an efficient use of IT resources or simply beyond the capabilities of the organization.
Putting It Together
As we move from the building blocks of infrastructure to the pinnacle of the application, the skill and knowledge necessary to build the components becomes less. This is simply because each layer can be built on top of the previous without having to fully understand the layer beneath. An organization with limited infrastructure skills can readily purchase IaaSfrom a vendor and build their own platform (or several) upon that infrastructure without needing the expertise to completely build the infrastructure from scratch. This has been happening for years in the managed hosting business. The organization does not have to be hardware or networking experts and therefore, as an organization, they require less technical expertise of the entire picture.
One of the most exciting, and possibly frightening, aspects of cloud computing architecture is that it finally brings the dynamism of business aligned IT to a workable model. IT organizations build IT systems; Business units deploy solutions to their business problem, which often involve the use of IT systems.
Posted by Karl Triebes on 06/01/2010 at 1:23 PM0 comments
There is a growing conflict surrounding virtualization that has nothing to do with its relationship with cloud computing. While IT strives for higher virtual machine density to improve TCO and ROI that increase can cause depletion of compute resources at a much faster rate. This effectively decreases efficiency of the data center and tanks the TCO and ROI that made virtualization attractive in the first place.
Perhaps worse for users and those responsible for resolving application performance issues is that the depletion of resources has a direct impact on application performance and, ultimately, availability. I/O intensive operations end up bogged down in the virtualization translation layer while saturation of the network card and software switches turn the network into a bottleneck, reducing available bandwidth, increasing latency, and degrading application performance.
IT staff end up caught between budgetary demands and unhappy users, with virtually nowhere to turn. You’ve been here, I’m sure. It’s like you’re in the Twilight Zone, transported back to the situation you were in before you started your virtualization venture. You’re out of resources.
There is a solution: Offload the most intense processing to external solutions. Doing so consumes fewer resources on the servers which makes the virtual machines more efficient. The result is sustainable availability and performance levels.
Offloading the most compute intensive processes to a purpose-built application delivery controller (ADC) is a virtually non-disruptive process requiring no modification to applications or virtual machines. The ADC virtualizes the applications and presents itself to the client as a broker; mediating between client and server. As requests and responses are received the ADC performs the most intense processing– TCP termination, SSL processing, compression, caching – leaving VM resources focused on the tasks it performs best. In addition, since the ADC is managing all of the application traffic virtualized application can be spread across multiple physical servers providing additional benefits in scalability, performance and availability.
Because the processing performed by the ADC is hardware accelerated and the ADC can determine what content will benefit -- and what will not -- from such assistance, application performance is not only restored but generally improved.
Offloading intense processes also removes the network as a bottleneck by decreasing the amount of data transferred. The encryption associated with SSL necessarily increases the size of data. Moving this processing off the VM reduces the amount of data needing to be handled which improves network performance.
So before you throw your hands up in frustration because the consolidation you hoped would come from virtualization didn’t, think about using an ADC to recover resources.
Posted by Karl Triebes on 05/26/2010 at 1:14 PM0 comments