Hey there! CloudConnect is next week (already?) and while some of us are already on a plane heading to the Bay area to kick things off (Shlomo Swidler is already on his way, according to his tweets at 36,000 feet) some of us will be lounging preparing for our various workshops and panels until early next week.

That being the case, if you’re not going to be attending and thus missing the panel I’m moderating (what? How could you miss that?) but had a burning question you wanted to ask one of the panelists, let me know. Leave a comment, send a tweet, compose an e-mail, write me a letter (better hurry, Green Bay is a long way from everywhere). If we can fit it in (how many people actually ask live questions during the Q&A, right?) we’ll get it answered, and tweet or post a follow-up next week.

Come to think of it, even if you are attending and just can’t make the panel, or you’re like me and don’t like asking questions in public, send your question anyway.

I

NFRASTRUCTURE INTEROPERABILITY in a CLOUDY WORLD
Interoperability between networks has fueled the growth of applications that has in turn spurred the growth of networks and internetworking. This cycle has led to increasing strain on networks, applications, and people who manage them. The 'virtualization' of networks, servers, storage, and applications as well as cloud computing not only quickens growth rates, but changes the nature of demand placed on infrastructure. Virtualization and cloud computing ultimately require new kinds of interoperability to reduce the burdens imposed by these technologies. This panel of cloud computing vendors and users will review the challenges of dynamic infrastructure design -- infrastructure capable of sustaining growth while relieving stress -- and will suggest the types of standards necessary to make those infrastructures a reality.

Our notable panel includes (in order of the value of the bribes they sent to ensure I was nice to them*):

• Rich Miller, General Manager and Principal, Telematica Inc.
• Surendra Reddy, Vice President, Cloud Computing, Yahoo
• Glenn Dasmalchi, Technical Chief of Staff, Cisco
• Bob Grossman, Managing Partner, Open Data Group
• Apurva Dave, Vice President, Product Marketing and Alliances, Riverbed Technology

So if you’ve got a question, let me know! I’ll do my best to get it answered.

*Not really true, the order is from the panel listing on the CloudConnect site. No one has bribed me to be nice. Yet. :-)

Because it’s Friday and sometimes you just have to get it out of your head. 

Your app is slow, demand has grown
the hardware is not your own
your heart sweats, your body shakes
another clone is all it takes

Compute is cheap, it can’t be beat
there was no doubt, you’d take the leap 
your budget’s tight, exec’s decreed
another cloud is all you need

Whoa, you like to think that you’re immune to the stuff, oh Yeah
it’s closer to the truth to say you can’t get enough,
you know you’re gonna have to face it, you’re addicted to cloud 

there’s no 5 9s, but you don’t need,
the systems run at different speeds 
requests arrive in double time
another clone and you’ll be fine, a one-click mind

you can’t be saved
compute is all you crave
if there’s a need, an image new
you don’t mind if bills accrue 

whoa, you like to think that you’re immune to the stuff, oh Yeah it’s closer to the truth to say you can’t get enough, you know you’re gonna have to face it, you’re addicted to cloud Might as well face it, you’re addicted to cloud Your app’s still slow, demand has grown the hardware is not your own your heart sweats, your body shakes another clone is all it takes whoa, you like to think that you’re immune to the stuff, oh Yeah it’s closer to the truth to say you can’t get enough, you know you’re gonna have to face it, you’re addicted to cloud might as well face it, you’re addicted to cloud

Addicted to cloud? Then surely you’re attending CloudConnect next week…

With perhaps a few apologies to Robert Palmer

In the networking side of the world, vendors often seek to differentiate their solutions not just based on features and functionality, but on form-factor, as well. Using a descriptor to impart an understanding of the deployment form-factor of a particular solution has always been quite common: appliance, hardware, platform, etc… Sometimes these terms come from analysts, other times they come from vendors themselves. Regardless of where they originate, they quickly propagate and unfortunately often do so without the benefit of a clear definition.

A reader recently asked a question that reminded me that we’ve done just that as we cloud computing and virtualization creep into our vernacular. Quite simply the question was, “What’s the definition of a Soft ADC and vADC?” That’s actually an interesting question as it’s more broadly applicable than just to ADCs. For example, the last several years we’ve been hearing about “Soft WOC (WAN Optimization Controller)” in addition to just plain old WOC and the definition of Soft WOC is very similar to Soft ADC. The definitions are, if not well understood and often used, consistent across the entire application delivery realm – from WAN to LAN to cloud.

So this post is to address the question in relation to ADC more broadly, as there’s an emerging “xADC” model that should probably be mentioned as well. Let’s start with the basic definition of an Application Delivery Controller (ADC) and go from there, shall we?

The latest generation of application delivery controllers handles a much wider variety of functions, including rate shaping and SSL offloading, as well as serving as a Web application firewall.

If you said an application delivery controller was a “load balancer on steroids” (which is how I usually describe them to the uninitiated) you wouldn’t be far from the truth. The core competency of an ADC is load balancing, and from that core functionality has been derived, over time, the means by which optimization, acceleration, security, remote access, and a wealth of other functions directly related to application delivery in scalable architectures can be applied in a unified fashion. Hence the use of the term “Unified Application Delivery.”

If you prefer a gaming metaphor, an application delivery controller is like a multi-classed D&D character, probably a 3e character because many of the “extra” functions available in an ADC are more like skills or feats than class abilities.

So a "Soft ADC" then is simply an ADC in software format, deployed on commodity hardware. That hardware may or may not have additional hardware processing (like PCI-based SSL acceleration) to assist in offloading compute intense processes and the integration of the software with that hardware varies from vendor to vendor.

Soft ADCs are sometimes offered as “softpliances” (many people hate this term) or an “appliance comprised of commodity hardware pre-loaded and configured with the ADC software.” This option allows the vendor to harden and optimize the operating system on which the Soft ADC runs, which can be advantageous to the organization as it will not need to worry about upgrades and/or patches to the solution impacting the functionality of the Soft ADC. This option can also result in higher capacity and better performance for the ADC and the applications it manages, as the operating system’s network stack is often “tweaked” and “tuned” to support the application delivery functions of the Soft ADC.

In the general category of application delivery (and most networking solutions as well) we can make the following abstractions regarding these definitions:

So if we were to tackle “Soft WOC”, as well, we’d find that the general definition – traditional hardware-based solution in a software form-factor – also fits that category of solution well.

It may seem to follow logically than any version of an ADC (or network solution) is “as good” as the next given that the core functionality is almost always the same regardless of form factor. There are, however, pros and cons to each form-factor that should be taken into consideration when designing an architecture that may take advantage of an ADC. In some cases a Soft ADC or vADC will provide the best value, in others a traditional hardware ADC, and in many cases the highly-scalable and flexible architecture will take advantage of both in the appropriate places within the architecture.

*Some solutions offered “as a service” are more akin to SaaS in that they are truly web services, regardless of underlying implementation, that are “portable” because they can be accessed from anywhere, though they cannot be “moved” or integrated internally as private solutions.

Or Why Carr’s Analogy is Wrong. Again.

Nicolas Carr envisioned compute resources being delivered in a means similar to electricity. Though providers and consumers alike use the terminology to describe cloud computing billing and metering models, the reality is that we’ve just moved from a monthly server hosting model to a more granular hourly one, and the delivery model has not changed in any way as we’ve moved to this more “on-demand” model of IT resources.

There’s very little difference between choosing amongst a list of virtual “servers” and a list of physical “servers” with varying memory capacity and compute power. Instead of choosing “Brand X Server with a specific memory and CPU spec”, you’re choosing “generic image with a specific memory and CPU spec.” You are still provisioning based on a concrete set of resources, though arguably the virtual kind can be much more easily modified than its physical predecessors. Still, you are provisioning – and ultimately paying – for a defined set of resources and you’re doing so every hour that it remains active. You may provision the smallest amount of resources possible as a means to better perform capacity planning and keep costs lower, but you’re still paying for unused resources no matter how you slice it (pun intended).

The pay for what you consume concept doesn’t actually apply to cloud computing today unless you look at “use” from the application or virtual machine point of view, and even then it breaks down. True, the application is using resources as long as it is powered on, but it’s not using all the resources it is allocated (likely) and thus you aren’t paying for what you use, you’re paying for the minimum you need. The difference is significant. Bandwidth can be metered in a way similar to electricity and its delivery model is almost exactly the same as the electrical grid. You can, in fact, deliver and consume bandwidth based on the same model – pay only for what you use. We don’t, but we could. 

Compute resources, however, are not (yet) available for “delivery” or use in such a model. The granularity is at the virtual machine, not the compute resource layer, and thus you are paying for discrete chunks of compute resources, not necessarily what you use at any given time. You’re also paying on the basis of time, in intervals usually of one hour. Even if you only fired up the virtual server and served one request, using perhaps three minutes of time, you’re still paying for an entire hour. That’s not paying for what you use, it’s simply a more granular version of billing models that have always existed: you rent X capacity for Y time. Even cloud computing providers that allow on-demand resizing of virtual machines to provision more (or less) compute resources are still falling into the same bucket because the billing model doesn’t change. This kind of capability is more about elasticity than it is the billing model and while it’s an excellent example of how providers are moving forward toward an even more dynamic and fluid provisioning and capacity management system, it doesn’t change the line-items on the monthly bill.

Like cell phones, there’s a minimum cost at work here, and that minimum cost is always incurred whether you use it all or not. It’s not as granular as an electrical grid, and probably won’t be anytime in the near future.

In most cases, this is probably true. This is not an argument about whether cloud is more financially or operationally efficient, it’s just a reminder that there is overhead in a public cloud computing environment.  Considering that according to IDC analysts at Directions 2010, the primary driver for adopting cloud computing is all about “pay per use” with “monthly payments” also in the top four reasons to adopt cloud, that’s an important point to remember. If the billing model is the primary driver then it behooves organizations to understand just how “pay per use” really works. Organizations must recognize that while it will reduce total overall costs there will be overhead associated with cloud computing, just not nearly as much as is generally associated with on-premise solutions. But you don’t want to assume that a business application that’s really used during business hours isn’t incurring costs the rest of the day. Unless it’s “powered down” it’s still “using” compute resources in the form of memory and disk and that means it’s incurring costs.

The last thing you want is to get that “monthly bill” and be as surprised as parents receiving their teenager’s first cell phone bill. Cause the cloud is fluffy and probably won’t even notice the hammer.

Thought those math rules you learned in 6^thgrade were useless? Think again…some are more applicable to the architecture of your data center than you might think.

Remember back when you were in the 6^th grade, learning about the order of operations in math class? You might recall that you learned that the order in which mathematical operators were applied can have a significant impact on the result. That’s why we learned there’s an order of operations – a set of rules – that we need to follow in order to ensure that we always get the correct answer when performing mathematical equations.

Rule 1:   First perform any calculations inside parentheses.

Rule 2:   Next perform all multiplications and divisions, working from left to right.

Rule 3:   Lastly, perform all additions and subtractions, working from left to right.

Similarly, the order in which network and application delivery operations  are applied can dramatically impact the performance and efficiency of the delivery of applications – no matter where those applications reside.

Let’s do some math to prove our theory, shall we? Consider the following “table” of the time it takes to execute certain network operations. Note that these are completely arbitrary in that they do not represent actual performance statistics, though the values are relative to one another based on real metrics. The actual time to execute a given operation will be highly dependent on load and device performing the operation, thus it will be variable. However, what is static is that each operation will consume “time” on a given system to execute, and this table is designed to represent that basic truism.

Architecture #1

Let’s assume for a moment that our architecture is simple: two network devices, both will need to inspect the payload to apply security or routing policies, and an application. Assuming that the application is responsible for compression and SSL operations, this means that on the ingress (inbound) requests, both network devices must necessarily decrypt and then re-encrypt the request in order to apply policies. The application, because it is assuming it handled the SSL, also needs to decrypt.

Based on our completely arbitrary and fictitious table of operational costs, this means the time to execute on ingress is:

SSL: 25 units + Compression: 9 units + Inspection: 14 units = 48 units

and our total CPU cycle utilization is:

SSL: 50 units + Compression: 21 units + Inspection: 16 units = 87 units

On egress (outbound) our total time to execute will be:

SSL: 25 units + Compression: 15 units + Inspection: 14 units = 54 units

and total CPU cycle utilization at:

SSL: 50 units + Compression: 35 units + Inspection: 16 units = 101 units

Our total time to execute 1 transaction using this order of operations is 102 units with a total CPU cycle utilization of 188 units. Now let’s compare that with a more strict order of operations in the architecture, delegating responsibility for compression and SSL operations to Network Device #1.

Architecture #2

Let us now assume that we are moving those functions that must be repeated throughout the architecture closer to the “edge” of the flow of traffic such that we reduce the number of times the functions must be repeated due to the need to inspect data. Based on our completely arbitrary and fictitious table of operational costs, this means the time to execute using our new order of operations on ingress is:

SSL: 5 units + Compression: 3 units + Inspection: 14 units = 22 units

and our total CPU cycle utilization is:

SSL: 10 units + Compression: 7 units + Inspection: 16 units = 33 units

On egress (outbound) our total time to execute will be exactly the same:

SSL: 5 units + Compression: 3 units + Inspection: 14 units = 22 units

and our total CPU cycle utilization is:

SSL: 10 units + Compression: 7 units + Inspection: 16 units = 33 units

Our total time to execute 1 transaction using this order of operations is 44 units with a total CPU cycle utilization of 66 units. Let’s compare the two side by side:

That pretty much says it all. Note that we’re not comparing costs as the cost per “unit” to execute will vary from device to device, although it is almost certainly true that execution on the network device will cost more per “CPU cycle” than on the application server because network devices are usually more expensive. Note, however, that the time to execute and CPU cycles consumed does not reflect the fact that when executed on specialized hardware the processing is more efficient, so the total cost will likely not be too much higher because it’s offset by the reduction in number of cycles required.

Just as is true for mathematical operations the order in which capabilities are applied dramatically impacts the end result.

The point of this little exercise was twofold. First, it’s a reminder to pay attention to the application delivery architecture you are employing – no matter where it might be located. That means from point of ingress through the network to the application and back again. Every point at which packets and/or payloads must be inspected is a potential point at which the efficiency and performance of your application will be affected by the order in which application delivery security and acceleration policies are applied. Second, it’s to mathematically illustrate the impact of offloading compute intense calculations and processes such as SSL and compression to network-hosted application delivery platforms, especially those enabled with specialized hardware designed to improve the execution performance of such processes.

Now, given this data we should be able to abstract what we’ve learned into a basic set of rules regarding the application delivery network order of operations:

Rule 1:   Offload all cryptographic or obfuscating (like compression) functions to the last device in the delivery network which needs to inspect the payload to reduce the impact of redundant operations.

Well, there you have it. One simple rule takes care of the application delivery network order of operations. It’s more efficient, will be more cost effective, and in your application performance will thank you for it (because we all know your users won’t, even though they should).

Related blogs & articles: When Did Specialized Hardware Become a Dirty Word? Square Infrastructure Pegs Don’t Fit in Round Network Holes Virtual Network Infrastructure: Virtually Good Enough? I am wondering why not all websites enabling this great feature GZIP? Pay No Attention to the Infrastructure Behind the Cloudy Curtain The Devil is in the Details The Question Shouldn’t Be Where are the Network Virtual Appliances but Where is the Architecture? VM Sprawl is Bad but Network Sprawl is Badder A Green Architectural Strategy That Puts IT in the Black [PDF]

“Security” concerns continue to top every cloud computing related survey. This could be because, well, CIOs and organizations in general are concerned about security. It could be because the broader question of control over the infrastructure – including security – is never proffered as a reason for reluctance to jump into the fray known as cloud computing.

• Forty-nine percent of survey respondents from enterprises and 51 percent from small and medium-size businesses cited security and privacy concerns as their top reason for not using cloud computing. – Survey: Security Concerns Hinder Cloud Computing Adoption, NetCentric Security, December 2009
  
• In a survey of 312 IT professionals, Unisys found that just over half of them cited security and data privacy as the key concerns around cloud computing. – Security Key Concern in Cloud Computing, Unisys Survey Finds
  
• According to Forrester Research’s Cloud Computing study 2009, about 44 per cent of large enterprises are interested in building an internal cloud. “Enterprises are more attracted to private cloud compared to public, due to security concerns about mission critical applications and data,” Kumar [Sushil Kumar, Oracle’s vice president of Product Strategy and Business Development System Management Product Group] noted. -- And finally Oracle is on Cloud

Interestingly, IDC’s latest Cloud Survey (December 2009) actually seems to show that broader “control” issues are coming to light. 76% of respondents indicated that “not enough ability to customise” was a challenge in their quest to adopt cloud computing models.

Visibility, while also a concern, can also be a side-effect of control. If you have control over the infrastructure you also have visibility. It could be argued that providers could enable the means by which customers could have visibility into infrastructure, especially the network, by exposing reporting but the truth is most network infrastructure solutions are not capable of providing the isolation of data required (they are not inherently mutli-tenant) and thus it’s not as easy as it might sound.

Whether the primary concern regarding cloud computing is “security” or “visibility” or “any form of performance/availability guarantee, a.k.a. SLA”, the larger, more encompassing  concern is directly about control.

Organizations want and need to control (among other infrastructure services): 

• access to application and data
• rate of inbound requests (prevention of accidental or intentional DDoS)
• inbound content (defense against exploitation)
• outbound content (stop data leaks)
• architecture, to ensure the proper security and application delivery mechanisms that support all of the above are in place

The problem is that “cloud” doesn’t really allow much of this control at all. Not yet. That means that there is a corollary to Hoff’s Law* which states:  “If your security practices suck in the physical realm, you’ll be delighted by the surprising lack of change when you move to Cloud.” That corollary is “If your security practices don’t suck in the physical realm, you’ll be concerned by the inability to continue that practice when you move to Cloud.”

Even if an organization has – and executes upon – a good security strategy that does not mean that they’ll be able to carry all of their related tactical implementations into the cloud. Certainly if the organization is looking at IaaS (Infrastructure as a Service) and many of those tactical implementations are software or virtual appliances they will be able to carry those into the cloud with them. But if the tactical implementations are not in a form-factor deployable in the target environment, well, the organization is out of luck.

Security practices manifest themselves in most cases as the implementation of a solution. Whether that’s using SSL or a web application firewall to secure a web application, or a DLP (data leak prevention) solution to prevent customer data loss, or fine grained application access controls via an external identity store – it’s still a physical manifestation that needs either to be transportable to the cloud environment or the provider should offer similarly capable services. The organization must, in other words, be capable of customizing their deployment in the cloud computing environment to meet their various needs of scalability (mostly covered today), security, and performance. It’s the latter two that aren’t readily available today and where providers need to focus next.

To be fair to providers, vendors need to recognize the need for these solutions in the cloud and provide one of two things - ideally both:

1. A virtual appliance (if it is a solution for which this form factor makes sense)
2. A mechanism that easily allows providers to offer solution services to customers (Infrastructure 2.0 enabled, APIs, multi-tenant support, etc… )

Too many cloud cheerleaders seem overly dismissive of the concerns organizations have. Whether the concerns are real (many are) or simply perceived (some are) as a problem is irrelevant: the customer is speaking to you and they are saying they are concerned. That may be inhibiting adoption, therefore such concerns should be addressed by providers if they are to convince customers to sign on.

One would hope that providers would choose to address those concerns through service offerings or expanded partnerships with solutions’ vendors, but it could be as simple as being  more transparent and open about their own security practices and the tactical solutions the provider is using to secure its infrastructure. Hoff and some extremely talented folks have started up CloudAudit.org in an attempt to forward a model and ultimately an API that would provide customer access to just this type of information. That’s certainly a step in the right direction. The bigger question, however, is whether providers who have been reluctant to provide any visibility into their infrastructure and security practices thus far will be willing to implement and support an effort like CloudAudit once it’s complete.

Conversely, we need to stop portraying cloud computing environments as though they are sieves. Providers certainly do have security measures in place, whether we know what they are or not. It’s not as if they’re running out of a basement, after all, and they understand the need for security not just for their customers, but to protect their own infrastructure and investments. In that respect Hoff’s Law holds true: the security of applications you place in the cloud has just as much to do with your security practices as it does the providers’.

*Rational Survivability, December 2009, “Cloud Computing Public Service Announcement – Please Read”

The current threat level is … the same as it was yesterday, and the day before, and will be tomorrow.

We’ve all been in the airport before and heard the announcement. “The current threat level is orange. Blah blah blah blah yada yada whatever.” At least that’s what I hear today because I’ve become immune to the fact that “orange” means there’s a threat. There’s always a threat, it seems, and the announcement simply conveys what appears to many of us to be the “status quo.” We have effectively been desensitized to a “higher” threat level as it is now treated as nothing out of the ordinary. It is the norm, rather than something that grabs our attention. 

The same is true in the enterprise, where the threat level is always high. Although most organizations likely don’t have a “threat level announcement” the effect is the same: personnel and infrastructure alike treat this allegedly “heightened awareness” as the status quo. It’s no longer actually heightened, or more aware, it’s the way it always is. Many times this is because there’s always a credible threat to the infrastructure and applications of any organization. At any time there may be an incursion, an attempt at penetration, the exploitation of an old or newly discovered vulnerability. This forces information security teams to put into place the infrastructure and solutions, both active and monitoring, that will detect and (one hopes) prevent a successful attack. These solutions are always on alert, twenty-four by seven, three-hundred sixty-five days a year.

The problem with always being at a “heightened” state of security awareness in the infrastructure is twofold. First, real threats may go unnoticed amongst the hundreds of other “alerts” about anomalies that aren’t truly attacks. Out of the hundreds of failed log-in attempts in any given day how many of them are actually attempts at hijacking an account and how many are just attempts by legitimate users that forgot or fat-fingered their password? In many cases the determination of which is real and which is simply a case of user-error are left to a codified “process” that ends with a locked out account and, more often than not, a call to a help desk or an e-mail explaining the situation. Second, if every piece of infrastructure is always configured to be in “ultra paranoid” mode, it impacts the performance of all applications delivered through that infrastructure because the components are always expecting every packet to be “the one” that’s truly dangerous.

A dynamic infrastructure, enabled by Infrastructure 2.0, however, might resolve this problem – or at least give us the means by which we can architect an infrastructure that can.

For example, it’s nice that Facebook recognizes when a user is attempting to log in from a new location. But what if it could go further and notice that not only is it a new location  but it’s also a new device. Perhaps it’s a mobile platform or a different user agent. Wouldn’t it be nice if that triggered an increased threat level across the infrastructure specifically for traffic exchanges until it’s been deemed “safe”? Perhaps that means activating a higher logging level for that user, or scrutinizing the payload more thoroughly by enabling a specific security profile that’s a bit more aggressive than is typically used. Perhaps it means activating additional application logic that requires more proof of identity before subsequently processing a query that will write into the database. And once it’s been determined that yes, this actually is the user we thought it was, we could “stand down” and relax the security posture of the application and supporting infrastructure back to more “normal” levels.

In other words, can’t we leverage strategic points of control in the application and network infrastructure to inspect and determine then whether it is a threat or not? And if it is – or appears to be suspicious - then we could heighten the security posture, rather than assuming everything is an attack? 

In other other words, can’t we apply infrastructure 2.0 concepts to security so that it, too, can evolve along the path to being more active in differentiating legitimate from malicious? What we need is real time security; on-demand security. We need a way to inform those strategic points of control that a particular user session is “malicious” and hey, why don’t you block that access now? We need a way for infrastructure to inform the firewall on-demand that yes, that’s a UDP flood intended to DoS a particular application and no, we don’t want to process any of that traffic so go ahead, deny access won’t you? We need the solutions that sit in these strategic points in the network architecture to be more alert, more aware, and more importantly, able to share that information such that the security best able to thwart an attack is used at the right time. The firewall is the best place to stop a UDP-based DDoS. The application delivery tier is the best place to stop a TCP or HTTP-based DDoS. Leveraging the right solution at the right time may make the difference between no downtime and hours of downtime.

But we can’t leverage the best solution at the right time if we (a) don’t know there’s an attack ongoing and (b) can’t actually communicate in real-time with the solution. We talk a lot about “efficiency” when we talk about cloud computing and virtualization, but we don’t often talk about efficiency in the overall architecture. The entire architecture should be, optimally, designed to distribute all application delivery tasks to the appropriate components. Why should an application ever process requests that carry a malicious payload? Why should the application delivery tier ever see a UDP flood? Why do we let “bad” traffic past points at which a component could have stopped it? Doing so consumes bandwidth, compute resources, and storage resources that are completely unnecessary. When we architect a solution that’s more efficient we improve the overall performance of the architecture because there is less “bad” traffic crossing the entire network and fewer components processing what is already known to be “malicious.” That, in turn, improves application performance and capacity, which reduces costs to deliver and makes end-users more productive.

We certainly don’t want to relax our security posture overmuch, but we don’t want to keep it always elevated, either. Desensitizing both people and infrastructure to potential threats is dangerous because when a real threat comes along it gets lost in the mountainous packet storm of “maybe this is a threat” messages. Signal to noise ratios need to be reduced for both people and infrastructure, and one way to do this is to architect highly reactive security architectures that collaborate via Infrastructure 2.0 to automatically “scale” the threat level according to what’s really going on in the network and the application network.

The advent of virtualization brought about awareness of the need to decouple applications from IP addresses. The same holds true on the client side – perhaps even more so than in the data center.

I could quote The Prisoner, but that would be so cliché, wouldn’t it? Instead, let me ask a question: just which IP address am I? Am I the one associated with the gateway that proxies for my mobile phone web access? Or am I the one that’s currently assigned to my laptop – the one that will change tomorrow because today I am in California and tomorrow I’ll be home? Or am I the one assigned to me when I’m connected via an SSL VPN to corporate headquarters?

If you’re tying identity to IP addresses then you’d better be a psychiatrist in addition to your day job because most users have multiple IP address disorder.

IP addresses are often utilized as part of an identification process. After all, a web application needs some way to identify a user that’s not supplied by the user. There’s a level of trust inherent in the IP address that doesn’t exist with my name or any other user-supplied piece of data because, well, it’s user supplied. An IP address is assigned or handed-out dynamically by what is an unemotional, uninvolved technical process that does not generally attempt to deceive, dissemble, or trick anyone with the data. An IP address is simply a number.

But given the increasingly dynamic nature of data centers, of cloud computing, and of users accessing web-based services via multiple devices – sometimes at the same time – it seems a bad idea to base any part of identification on an IP address that could, after all, change in five minutes. IP addresses are no longer guaranteed in the data center, that’s the premise of much of the work around IF-MAP and dynamic connectivity and Infrastructure 2.0, so why do we assume it would be so on the client side? Ridonculous!

The decoupling of IP address from identity seems a foregone conclusion. It’s simply not useful anymore. Add to this the fact that IP address depletion truly is a serious problem – the NRO announced recently that less than 10% of all public IPv4 addresses are still available – and it seems an appropriate time to decouple application and infrastructure from relying on client IP addresses as a form of identification.

Cookies. Unique names. Device types. Browser. Tokens. Any combination thereof. In other words, user context. It’s not that we need to stop using IP addresses altogether, but we do need to stop using them as an authoritative source on their own. They are still, certainly, part of the equation but it’s not an idempotent one and especially when used for security purposes it should be just one more piece of information used to make the determination to deny, allow, or grade access to application and network resources. 

Developers are probably thinking “Hey, we use usernames and stuff, we don’t rely upon IP addresses anyway.” And that’s true. When I say “we” I mean primarily infrastructure, the underlying network and application delivery network solutions that provide security and acceleration and delivery functions necessary to ensure the fast, secure delivery of that application. It is the infrastructure that relies heavily on IP addresses and as virtualization becomes even more pervasive and ubiquitous across the data center, infiltrating every layer of the stack, it will become increasingly difficult to not only manage but rely upon IP address as a foundational identifier for user or application-specific policy enforcement.

Infrastructure simply has to evolve to operate on a more session or request-oriented boundary, taking advantage of the context in which requests are made, in order to properly apply the policies that will ensure security for user and organization alike. Solutions will need to become more application-aware, network-aware, and user-aware and in the event they simply can’t access certain variables necessary then it will be a requirement to collaborate with those solutions that do have that information, or use solutions that are already context-aware and have an underlying unified framework through which such information is leveraged.

Strategic points of control will continue to emerge within the data center; points at which context-aware solutions will be a requirement in order to take advantage of the necessary information from the network to the application layer to make critical decisions regarding access control to network and application resources. This is particularly true in cloud computing environments in which shared resources means shared risk, and IP address assignment is highly volatile.

Microsoft Dynamic Infrastructure Toolkit for Systems Center (DIT-SC) is hopping forward, literally, into the network. With or without established standards, this dog is going to hunt.

It takes time to develop standards, something we often overlook. When the foundational standards upon which the Internet were being developed there were (almost) no users, no broadband, and no real urgency to get something available. The adoption of disruptive, highly volatile technologies such as virtualization and cloud computing result in an environment in which today’s standards groups are not afforded the luxury of time. Organizations want, nay they need, standards now and if they aren’t forthcoming vendors and customers alike will move steadily forward with their own implementation.

The myriad “cloud APIs” submitted to various standards organization indicate this pattern of behavior has already begun and will continue until the dust settles and one (and hopefully only one) API comes out on top. Microsoft may have come “late” to the cloud computing table, but it’s certainly making up time by moving forward with its Dynamic Infrastructure Toolkit for System Center.

The Dynamic Infrastructure Toolkit for System Center is a free, partner-extensible toolkit that will enable datacenters to dynamically pool, allocate, and manage resources to enable IT as a service. Whether you’re an enterprise customer, a systems integrator, or an independent software vendor, the toolkit will help you create agile, virtualized IT infrastructures.  

-- Microsoft Cloud Computing Infrastructure solutions

What’s a bit different about Microsoft’s Dynamic Infrastructure Toolkit for System Center (DIT-SC) is that it’s not focusing on standardizing the interface to the cloud, a la Yet Another Cloud API, but rather it’s focused inward, on operations, much in the same way the cloud API of Yahoo! is highly focused on internal rather than external operations. 

The DIT-SC provides a framework – not an API but a framework – that allows partners and customers to manage resources, including infrastructure such as load balancers, firewalls, and other network-hosted services. By providing a framework Microsoft can leave the implementation up to vendors and customers which is of course cost-effective on their part but also provides the means by which those infrastructure solutions that are not yet Infrastructure 2.0 enabled can still be supported. 

Assume for a moment a device, X, does not have a standards-based control plane accessible for automation and remote control. This does not mean it cannot be automated, it simply means alternative methods of communication and control must be used. Holistic identity management systems used this technique extensively to manage accounts on operating systems and applications for which there was no programmatic interface, and administrators have used remote scripting playback to automate tasks for what seems like eons. Using PowerShell the integration of both Infrastructure 2.0 and non-enabled systems can be accomplished, resulting in unified data center management of resources via System Center. load balancing is one of the planes of control, and will be primarily enabled through the existing Infrastructure 2.0 capabilities of various vendor implementations such as F5, Citrix, and Cisco. 

Microsoft is approaching Infrastructure 2.0 and the integration of network-hosted resources in a very implementation agnostic way. Rather than simply lay the entire responsibility at the feet of individual vendors, it has taken a more “standardsy” approach in that the definition of the PowerShell interfaces to network and application delivery network infrastructure will be normalized across similar component functionality. Standardized, essentially, into a common task and model-oriented set of interfaces that can be used to basically plug-in any vendor solution in a particular data center niche. This “normalization” is very close to “standardization” and thus it is not inconceivable that in the future we may see the model and interfaces developed to support the DIT-SC framework proposed as a standard in much the same way other vendors have put forth their models and interfaces as potential “cloud” standards.

Not the framework, mind you, but rather the collection of infrastructure and resource control that result from ongoing efforts to integrate infrastructure and network and systems’ resources into a unified dynamic management system.

That’s the target of Infrastructure 2.0 standards efforts; the definition of a model and interfaces unified across the network and application delivery network as well as “interclouds.”

The problem is that there’s no one really to “blame’ for what’s almost certainly going to happen: the rise of de facto standards. Certainly some vendors and organizations are counting on that happening, and for others it’s just going to happen because, well, that’s the way things work in a rapidly evolving environment. Standards are not forthcoming fast enough at this point to address the rapid evolution of data center operational needs. Given the scope of the task at hand – developing a set of standards that will ensure interoperability of infrastructure and cloud computing environments – it’s no surprise that it’s taking some time. At least it’s no surprise if you expect that such standards will  be long-lived, well-thought out, and as future-proof as standards can be.

It may be that efforts such as DIT-SC will, in fact, be helpful to creating “accepted” standards in the future. Anyone who was involved in IT before TCP/IP rose to the top of the standards heap and became the accepted industry standard, beating out Novell’s IPX/SPX and IBM’S SNA will recall that there was a time when it was not clear which “standard” would ultimately “win”. A similar situation will almost certainly arise in the arena of cloud computing, if not at the cloud API layer, then internally, at the operational layer. By tossing the infrastructure models developed to support vendor and provider frameworks into a hat it may be that a unified set of standards can be developed that make the internal integration (collaboration) required to orchestrate IT operations and allow organizations to fully realize the benefits of virtualization and cloud computing.

In the meantime, Microsoft has (somewhat quietly) joined the Infrastructure 2.0 movement by ensuring the means by which network and application delivery network infrastructure can be automated and orchestrated through a centralized “cloud management” system with DIT-SC. That’s certainly a leap forward in the right direction.

A recent blog on EBPML.ORG entitled “REST 2010 - Where are We?” very aggressively stated: “REST is just a "NO WS-*" movement.” The arguments presented are definitely interesting but the most compelling point made is in the way that REST APIs are constructed, namely that unlike the “ideal” REST API described where HTTP methods are used to define action (verb) and the path the resource (noun), practical implementations of REST are using a strange combination of both actions (verbs) and resources (nouns) in URIs.

What this does is simulate very closely SOA services, in which the endpoint is a service (resource) upon which an action (method) is invoked. In the case of SOAP the action is declared either in the HTTP header (old skool SOAPaction) or as part of the SOAP payload. So the argument that most REST APIs, in practice, are really little more than a NO WS-* API is fairly accurate.

In “REST != HTTP “ Ted Neward very convincingly argues that the problem isn’t that most “REST” APIs aren’t REST (based on the definition and constraints set down by Fielding in the first place) but that folks are calling them REST despite the fact that they aren’t. That’s not necessarily the developer’s fault and, in the cases pointed out it’s quite possible that the decision to call the API a RESTful API was made by someone other than the developer.

The fact is that there are artificial environmental constraints that force RESTful developers into diverging from the “one true REST path” that leads to a more services-based and less structured implementation than perhaps many would like.

Here’s a few of the problems developers face:

• HTML (version 4 and lower) and XHTML 1 only support GET and POST in FORMS
  
• XHTML 2.0 will support GET, POST, PUT and DELETE  in FORMS but will almost certainly be incompatible with previous versions of HTML/XHTML
  
• HTML5 appears to support all necessary HTTP methods, but is being held up by conflicts internal to the W3C WG (Adobe versus the world)
  
• XMLHttpRequest support for GET, POST, PUT, DELETE is fairly consistent across browsers
  
• XMLHttpRequest is not compatible with cross-domain requests without server-side cooperation 
  
• In the interests of security, most web servers disable PUT and DELETE and many administrators are loathe to enable them
  
• Storing state entirely on the client would require the transmission of and local storage in inherently insecure ‘containers’ sensitive data, yet not storing state entirely on the client immediately breaks the stateless property required to be considered REST.  
  
• Implementing truly RESTful APIs would impact almost every aspect of the environment in which we deploy applications; some changes would be for the better, some not so better.

So developers are sitting between a rock (variability in standards and support) and a hard-place (regulations, risk management, security, web ops concerns). REST is a great concept, and it’s based on established, ubiquitous standards but the problem is that it’s an ideal that does not necessarily take into consideration the environment in which such an architecture would need to be implemented. So it’s no wonder developers have done what developers have always done – worked around the constraints to get the job done. Because you know as well as I do (because you’ve had these conversations, just like I have) that the conversation went something like this:

Developer: We can’t implement a REST API without PUT and DELETE support enabled on the web servers, and we’ll have to store customer information in cookies to maintain a stateless set of operations… oh, and we’re going to increase the size of data because we need self-descriptive messages so the app might run slower on mobile devices.

Info security: No way, we are NOT opening ourselves up like that. Security, you know. Risk. Prison. The CTO wouldn’t look good in blaze orange.

Web ops: What the infosec guy said. Are you kidding? Enable PUT and DELETE? And how large are these messages going to be? Will we need more bandwidth, cause the network guys say we’re already at 60% of our allowed utilization and we can’t have any more because it’s starting to interfere with success of the soft-phone rollout project. 

Business Stakeholder: We need this application and we need it on time.

Marketing: A REST API is tablestakes. We must have one.

Developer: We can’t implement a REST API any other way. REST requires certain architectural characteristics and in the end it will scale better and we’ll have better visibility and -

Business Stakeholder: [eyes glazed over] We need this application and we need it on time, surely you can do something…

Developer: Well, I suppose we could just use GET and POST and then normalize PUT and DELETE as parameters or headers instead.

Web Ops: Excellent! Sounds like you’ve got the problem in hand then, I’m out.

Developer: And we can maintain state in sessions like we always have…

Info security: Excellent! Sounds like you’ve got the problem in hand then, I’m out.

Business Stakeholder: By the way, we’d like to demo the application for user feedback at our next <trade show/user group/shareholder> meeting. Think you can get it done a few weeks early?

Developer: We’d have to work overtime and weekends so -

Business Stakeholder: Excellent! Sounds like you’ve got the problem in hand then, I’m out.

Marketing: By the way, we can still call it REST, right?

And the next thing you know there’s an API available that tries to maintain the spirit of REST while very loosely following the letter of REST. As developers, sometimes we are forced into implementing solutions that break the rules even though we’d prefer to follow them. Cause in the end developers have to serve the needs of the business while working within the constraints of reality – and that means security and regulations and audits and limited bandwidth and other architectural limitations that may force architectural compromises that result in a less than ideal architecture, but a still secure, fast, and efficient application that serves its intended purpose.

The solution is, ultimately, just to not call such APIs REST. Nor RESTful, nor even REST-like. In the same way that we shouldn’t be calling every web-based application “cloud computing” we shouldn’t be calling APIs “REST” when they really aren’t. The argument that what we’re calling today “REST APIs” are really “NO WS-* APIs” is fairly accurate. But to call them simply “web services” would certainly confuse them with their SOAPy counterparts and cause the other side of the fence to rebel just as fiercely.

So until someone comes up with a better name that sticks, we may have to fall back on the tried and true “formerly known as” formula. I propose the “Formerly Unintentionally Counterfactually Known as REST” API.

It still has REST in the name, so marketing should be happy with that, right?

Ultimately a highly-scalable, high-performance architecture will rely on choosing the right form factor in the right places at the right time.

Scale is not just about servers, and for corporate data centers and cloud computing providers looking to realize the benefits of rapid elasticity and on-demand provisioning scale simply must be one of the foundational premises upon which a dynamic data center is built. And that includes the infrastructure.

This isn’t the first time I’ve touched upon this subject, but it’s a concept that needs to be reiterated – especially with so many pundits and analysts looking for the next big virtualization wave to crash onto the infrastructure beachhead. I’m here to tell you, though, that the devil is in the details. Virtual network appliances (VNAs) are certainly one means to achieving elastic scalability of infrastructure services but just as scale is not just about servers it’s also not just about form factor. It’s about the right form factor in the right place and, ultimately, at the right time.

First consider the scalability needs of aggregation points within an architecture. These are points at which high volumes of requests/traffic are essentially directed at one infrastructure solution, i.e. a Load balancer for application traffic, a router for network traffic. At these points in your architecture it would almost certainly be a bad idea to introduce a virtual network appliance because such solutions are much more constrained in terms of capacity than their hardware counterparts. This is due to inherent limitations on the virtualization platform, the network interfaces, and the operating system (if it is in the mix).

Where a single hardware load balancer can sustain millions of TCP connections, a virtual version of the same solution will unlikely be able to reach half of that capacity. The differences between hardware and software solutions are minimal, but among those differences are the way in which the different implementations interact with the network and available bandwidth. As we discussed in another post on a similar subject, scalability also becomes problematic because deploying multiple, cloned instances of any solution as a means to achieve higher capacity limits requires the use of virtualization, a la load balancing.

These high-volume, high-capacity strategic points of control are simply not good candidates for virtualization as a means to achieve scalability. There are two options for scaling these hardware solutions – use an extensible chassis based solution that can accommodate expansion of capacity through acquisition of additional “blades” or take advantage of the fact that most are equipped with specialized “clustering” that allows multiple devices to work in parallel while still ensuring reliability through fault-tolerance mechanisms.

This makes it appear, at first glance, that there is no room for virtualized infrastructure. Au contraire, mes amis! There are several key points within the architecture where scalability through virtualization is actually an excellent method because of the inherent characteristic of virtualization that turns a “network connection” between multiple virtual instances of applications/infrastructure on single physical server into something more akin to that of a high-speed internal interconnect. Much like a bus internal to the hardware, this “virtual bus” reduces the impact of the network on communication between components.

When you deploy multiple virtual machines on the same physical hardware, they communicate through virtualized network interfaces. Those interfaces ultimate utilize underlying physical network connections and thus act in a manner similar to that of physically interconnected devices. When all the relevant components reside on the same physical machine, however, the communication never actually ends up “on the wire.” That is, the communication between web and application servers deployed as virtual instances on the same hardware never leaves the physical machine and thus does not incur any of the normal network latency associated with communication between tiers in an application architecture. Thus, deploying a virtual instance of a load balancer as the means by which the application server tier is assured availability and scale can improve application performance because no network latency is incurred during normal web transaction processing. All the communication stays on the physical server and occurs in the virtualization layers.

Obviously this architecture is particularly well-suited to the VNAs for which proxying behavior is core within a two or three-tier application architecture: load balancing, caching, and application offload services, because it eliminates the out and back traversal of the network that would otherwise be required to accomplish such tasks.

The level of scalability needed by a component is highly dependent on the location of its functionality in the overall network architecture. Aggregation points inherently require high-volume, high-capacity solutions through which massive volumes of traffic/requests can be directed. But internally, in what is essentially becoming networks within networks, scalability can be accomplished using VNA equivalents of traditional hardware solutions.

Interestingly, this style of hybrid application delivery architecture may aid in the move toward more complete packaging of “applications” between cloud computing environments and data centers. If all necessary components are packaged together and intended for deployment on a single, physical server then moving them becomes possible. This is obviously not the case with physical solutions which cannot be assured to be available in cloud computing environments and would likely be financially prohibitive to deploy in a traditional co-location style arrangement, if cloud providers allow such an arrangement (some do – by the way).

While speeds and feeds will remain important in the design of network and application delivery networks, new architectural strategies will be required to scale environments in which both server and network appliance virtualization will be used. It’s not an automatic 1:1 replacement strategy that will achieve the scalability and flexibility desired; on the contrary it will take a good understanding of the pros and cons of both virtual and hardware network appliances to determine where best each will fit in a scalable, highly performant network architecture – whether in the local data center, or in “the cloud.”

UPDATE/RESOURCE: Eric Siebert pointed out that traffic flow in and between the physical network and the virtual network is highly dependent on the configuration of multiple components. This is a great post by Eric detailing the flow of traffic based on configurations.

What is needed to customize the cloud is a pair of data center ruby slippers called Infrastructure 2.0.

Frank Gens of IDC discussed the “New IDC IT Cloud Services Survey: Top Benefits and Challenges” in his blog and what is not surprising is that security continues to top the challenges associated with cloud services. What may be surprising to some is the increasing focus on customization. It shouldn’t be. As customers continue to push at the boundaries  of the cloud computing model they will inevitably find it unable to meet some need they have, such as customization.

See, when IT professionals said they didn’t want to worry about infrastructure that didn’t necessarily mean they didn’t care about the infrastructure. What they meant was they didn’t want to bear the operational and capital expenses associated with infrastructure if they didn’t have to. That’s a very different story than not caring about the infrastructure or about their ability to provision it, manage it, and ultimately control it. Applications are never deployed in a vacuum, after all, and part of the way in which they are secured, optimized, and made highly available is through its supporting infrastructure. Many of those options are simply no longer available in “the cloud”, and this is likely to be a bullet point in the “against cloud” column for many organizations who employ a more infrastructure inclusive strategy to delivering applications.

We could easily argue that “lack of interoperability standards” (cited higher on the challenge scale at 80.2% of respondents concerned to very concerned about standards in the survey) is directly related to this lack of customization capability (76% cited this as a concern). After all, interoperability standards across infrastructure of similar ilk would, ostensibly, make it easier for cloud computing providers to offer the infrastructure services required to customize the environment.

Infrastructure 2.0 is the means by which many of these concerns will eventually be addressed.

I will now shamelessly adopt terminology generally associated with SOA because cloud computing and “self-service” customization is, at its core, about leveraging a service-oriented architecture. That’s why we call them “services”, after all. That in the case of cloud computing the architecture is focused on infrastructure is irrelevant; the same principles embraced by composite applications built from software (business) services can be equally applied to a data center architecture built from infrastructure services.

Infrastructure 2.0 capable devices, whether virtual network appliances or physical hardware implementations, are solutions enabled with some sort of control-plane, usually REST or SOAP and accessible via an HTTP-based communication channel. These control planes provide the means by which cloud computing providers – or ISVs or regular old folks in the enterprise – can integrate infrastructure services into the application deployment and delivery chain.

This is nothing new. These capabilities have actually existed for nearly a decade now. What is new is cloud computing and virtualization and the need for automation and orchestration of the application deployment and delivery chain to enable efficiency and drive down the costs associated with delivering large-scale applications through rapid elasticity and scalability.

By exposing infrastructure services to customers it allows customization in a consistent way. The interesting thing about virtualization and cloud computing is that like SOA, the service implementation can vary without changing the interface through which the service is provisioned and managed. Some services may actually reside on physical infrastructure hardware while others might require the provisioning and deployment of a virtual network appliance (VNA). The customer may care about the implementation as it could effect cost or require specific management skills to include in their “virtual infrastructure” in the cloud environment.

For example, a cloud provider is going to provide load balancing as a means of scaling applications and, likely, virtualized infrastructure services. Using infrastructure 2.0 capabilities, the APIs and SDKs that manage and control infrastructure, the provider can offer a variety of options and billing structures based on the form factor and capabilities. One service might be a basic load balancing service, via a shared hardware Load balancer, with its only options being a choice of a few load balancing algorithms. Customers requiring more intelligent load balancing algorithms might be able to choose the same service on a shared hardware load balancer, but with more options and at higher costs. Customer desiring advanced application delivery capabilities such as network-side scripting or protocol optimization or security may be offered the choice of such services via a dedicated virtual application delivery controller, at yet a different cost rate. The reason this works is because the service interface is the same regardless of whether the form factor is hardware or virtual; it’s SOA in the network; an abstraction that allows for differences in implementation internal to an environment and, eventually, across environments.

As a customer chooses services to include in the application delivery chain it becomes essentially a composite infrastructure based on a chain of individual services. This is very similar to the way in which composite SOA applications would be composed: as individual services that combine to form a complete application.

What an infrastructure 2.0, service-based model offers both sides of the cloud equation – customer and provider – is choice. Choices in deployment form factor, choices in services offered and available; the customization cited as concerning by customers exploring cloud computing environments. This is the way in which cloud providers will be able to differentiate their offerings – by providing choices to customers in the infrastructure services available.

Remember Dorothy thought she needed the Wizard of Oz to get her home. Only after she saw that the wizard actually wasn’t, that he was just a man moving levers and pushing buttons behind the covers, was it revealed that she’d always had the power to go home on her own: those red, ruby slippers. Infrastructure 2.0 are the customers red, ruby slippers; providing the means by which they can customize their cloud-based application delivery infrastructure in the way that best suits their needs, without the help of the Wizard of Cloud.

An Infrastructure 2.0 services-based model is vital to addressing several of the challenges still raised in surveys: lack of interoperability standards, ease of integration with internal applications/infrastructure, migration back to the enterprise data center. If data center architectures are based on services, and not specific hardware or virtual implementations, it will be a lot easier to migrate that architecture between cloud computing providers and the local data center (“in house”) because the over-arching orchestration, the model, is a composite of infrastructure services. It essentially becomes an architecture built on solutions, not products.

That’s not to say there aren’t challenges associated with an infrastructure 2.0 services-based data center model. Differences in service implementation right now make it difficult to migrate services between vendor implementations, something that must be addressed before complete portability is possible. But this is the next evolutionary step in cloud computing: the abstraction and normalization of infrastructure services. Without this step customers will continue to raise the same integration, portability, and customization issues as they do today, and the growth of cloud computing will eventually slow to a crawl.

Related blogs & articles: Creating a Hybrid ADN Architecture with both Virtual and Physical ADCs [PDF] Infrastructure 2.0: Squishy Name for a Squishy Concept  All Infrastructure 2.0 Topics on DevCentral  That Whole Concept is Broken The Devil is in the Details Virtual Infrastructure in Cloud Computing Just Passes the Buck Scaling Security in the Cloud: Just Hit the Reset Button Vertical Scalability Cloud Computing Style Scaling AJAX Applications is More About Architecture than Apache The Question Shouldn’t Be Where are the Network Virtual Appliances but Where is the Architecture? You’re Asking the Wrong Question About Virtual Appliances

Check out the “New Infrastructure” track at Cloud Connect, where we’ll be discussing these topics in more depth.

There’s a reason for the angst elicited by inaccurate definitions of cloud computing and it may lead to rethinking a laissez-faire view of such definitions.

Language impacts our perception and can dramatically change the way we understand – or don’t understand – ideas. Because one of the primary uses of language is to present arguments or assert propositions such as “We need to allocate X percent of our budget to a cloud computing initiative” it makes it important that everyone involved in the conversation agrees on basic meanings and definitions. This is one of the reasons I, at least, have a conniption whenever someone who is attempting to educate people on a particular technological concept completely misses the ball. If we don’t clearly articulate what is and is not cloud computing the danger is that business-stakeholders and end-users will see cloud computing as nothing all that difficult, or nothing spectacular..we are in danger of the folks who often fund such initiatives not “getting it.” Language is our common ground, or at least it’s supposed to be.

The following grossly inaccurate definition is brought to you by Reading Eagle. Its “What is cloud computing?” article asserts that “84% of Americans use cloud computing in some form.” Then goes on to explain in more depth (and I use that phrase loosely and intentionally to prove a point):

When you upload your video to YouTube, your pictures to Flickr, your status to Facebook, the cloud is where it goes.

More technically, cloud computing is the platform for delivering software, applications and information through the Internet via remote servers, banks of computers and digital storage in buildings made for the purpose.

This is a very nice, simple definition of … the Internet. Not cloud computing, but the Internet. If a business initiative owner had read this (or one of any other number of inaccurate, over-simplified definitions coming from what are allegedly trusted, reputable business sources) and then was asked to fund a cloud computing initiative, it might very well be the case that they would deny the request because from their point of view, IT already has and does cloud computing.

Bill Cosby was making a joke out of teaching children the “wrong” definitions. While funny in a hypothetical situation, in a real situation it would be, of course, disastrous for the child. Similarly, teaching business stakeholders and technological philistines the incorrect meaning of technology concepts, especially those that may have as dramatic effect on the budget and architecture of IT, is just as disastrous as it threatens the ability of IT and the business to align on the need for at least some – if not all – of the technological concepts and architectures required for cloud computing. This includes many CxOs, who are just as confused by the definition of cloud as many of their business counterparts. Just because you’re an expert in one area of technology does not mean you’re automatically an expert in all other areas of technology, and that’s especially true of emerging technologies.

It’s important to remember that IT does not exist in a vacuum; other constituents have a stake in IT and exert their influence over the direction IT takes in many ways, including the budget. Many cloud computing surveys and studies have asked about budget size and type, but very few take the extra step to ask who – or what group – actually has control and influence over those budgets, which is at least as interesting – if not more so – than the actual budget details itself.

Though IT is intrinsically a part of cloud computing, it is not the only influence over an organization’s cloud computing policies. Survey respondents claimed that IT generally controls the cloud computing budget (64 percent compared to the 13 percent each held by application development and network architects). According to respondents, the top influencers for public clouds include IT (45 percent), application development (41 percent) and LOB business stakeholders (41 percent). 

-- 2009 Cloud Computing Survey Results | F5 Networks [PDF]

How influential those line of business stakeholders are will certainly differ from organization to organization, and possibly from project to project, but they do influence budgets and ultimately how those dollars are spent. If you’re one of the 13% of organizations for whom LOB stakeholders own and control the cloud computing budget, it is even more important that everyone involved in the decision making process come to a common understanding of what cloud computing means to the organization. It is extremely difficult to justify expenditures based on the assumption of business value derived from a technology or product when that assumption is not shared across all concerned parties.

IT has to justify investments as part of its “align better with the business” directives. Justifying an investment in cloud computing – in new solutions, software, hardware, services, training, etc… – will be extremely difficult if the people who may have to approve that investment believe there’s nothing new or different about cloud computing than what exists today.

Managing a virtual machine is not the same thing as managing the stuff inside it.

I’ve been noticing a disturbing, though not unexpected, trend in the world of virtualization and cloud computing around management of infrastructure, particularly around virtual network appliances (VNAs). Specifically this trend is claiming the ability to manage virtualized infrastructure.

You’d think I’d be happy about that. I probably would - if the solutions were actually capable of managing the infrastructure.

Digging into these management solutions shows that for the most part the definition of the term “manage” is about as deep as a puddle; the buck (and control) stops at the virtual machine. What management and automation solutions promise is the ability to provision, manage, and migrate virtualized infrastructure. What they actually provide is provisioning, management, and migration of virtual machines. Whether it is infrastructure or applications running internal to the virtual machine is pretty much irrelevant; the solution is about managing virtual machines.

The ability to launch, start, stop, and decommission a virtual network appliance is not an insignificant task. These pieces of the management puzzle must be accomplished somehow in order to control the operational costs associated with the more dynamic and ultimately volatile virtual infrastructure. But managing solely at the virtual machine layer – and claiming “infrastructure management” borders on deceit. It’s glossing over reality and interpreting “management” and “infrastructure” as loosely as possible in order to imply capabilities that don’t actually exist. Actually managing virtual infrastructure requires the ability to communicate and manage the actual infrastructure solution, not just its virtual container. This is an important distinction and one that needs to made early in the evolutionary process of virtual data center management lest the inability of management solutions push organizations toward what would result in a rigid, inflexible infrastructure that requires more operational support than its physical predecessor.

Without the ability to manage the infrastructure solution, operations is left to their own devices (sorry for that one, really) to find a way to manage the virtual infrastructure. Even if the management system is capable of invoking scripts to automate the configuration and/or modification of VNAs when they are launched, the scripts are still separate entities, managed distinct from the management system, and prone to the same invocation and processing errors as they are today. What we end up doing is turning network administrators into integration specialists; responsible for overseeing the creation and management of lots of little scripts and ultimately running into the same issues with which enterprise application integration (EAI) specialists have always struggled.

These management systems may be great at determining when a VM is near or at capacity in terms of RAM and CPU utilization and thus are capable of kicking off auto-scaling processes, but scaling VNAs is not the same as scaling applications. While the latter can often be considered little more than a cloning exercise, and thus virtual machine level management will suffice, the former requires modification of not only its own configuration but quite possibly a variety of other infrastructure devices as well. When you start making changes to the network, there is often a cascading effect in which upstream and even downstream devices are impacted.

Managing virtualized infrastructure at the virtual machine layer also lacks the on-demand adaption from which so many operational benefits are realized. The integration between a Load balancer and virtual machine management systems such as VMware vSphere and Microsoft System Center allows the management system to utilize network and application network layer data when making its decisions. Auto-scaling applications isn’t just about RAM and CPU, after all. Network throughput (bandwidth) can be an important factor in the decision making process as can the rate at which new requests are being received. It is impossible for a single application instance – especially in a distributed, virtualized environment – to have visibility into the “big picture”. The load balancer, however, does have that information and can provide it – if it’s been integrated and can share the data with the management system.

Conversely, when an application instance is launched as a means to address capacity, it must be added to the load balancing solution. A management system capable of automatically launching the instance is fine, but unless it’s actually managing the load balancer itself then manual intervention will be required to add the application instance to the load balancer and ultimately increase the application’s capacity.

If a management solution is not managing the infrastructure solution, but instead is only managing the virtual machine, this integration does not happen, this automation is lost, and auto-scaling isn’t.

Management solutions touting the ability to provision and manage “virtual infrastructure” should be closely examined to understand what they’re really managing. The management of most network and application network infrastructure can be accomplished via standards-based control planes – APIs – and thus the form they take, i.e. virtual or physical, is irrelevant. A management solution should be able to provision, manage, and control Infrastructure 2.0 capable solutions regardless of form factor. If a solution is specifically using “virtualized infrastructure” in its list of capabilities, that should be a warning sign that the solution may be as deep as a puddle when it comes to actually managing infrastructure.

The ability to deploy and manage a completely virtualized architecture is indeed appealing, but it’s important to remember that managing virtual machines is not the same thing as managing the infrastructure. Managing infrastructure requires deeper integration than just interacting with the virtual machine control-plane; it’s got to get under the hood and integrate with the actual infrastructure solution.

While standards will certainly make this task easier and may, in fact, end up resembling the “adapter-style integration” of enterprise application systems, it is not impossible to achieve today via similar abstraction techniques. The integration and management of the infrastructure – not its container – is necessary if data centers are going to successfully move toward a more virtual and dynamic infrastructure.

There’s compression, and then there’s compression.

One of the most common means of improving application performance is to reduce the size of the data being exchanged as redress for inherent network protocol behavior that can cause excessive delays in delivery of application data. Compression is often enabled to achieve this goal, and because most data being delivered to applications is text-based (XML, HTML, JSON) this technique generally works quite well. Depending on the architecture of the application delivery network, however, there may be other “types” of compression that can be used in addition to the “compression” typically associated with web-application data.

• Asymmetric Compression
  Asymmetric Compression is the compression used by most web servers as well as intermediaries claiming the title “application acceleration.” Asymmetric compression is one-sided; it is applied at the server only and uses industry-standard algorithms (deflate, gzip) to compress data before delivery.
  
  Asymmetric compression is good for web application data because the pattern of data exchanges is heavily weighted on the egress (outbound, response) side of the data exchange. HTTP requests are generally small while the responses are often large and thus the asymmetric nature of this compression is well-suited to these applications.
  
• Symmetric Compression
  Symmetric Compression is what is usually implemented by WOC (WAN Optimization Controllers) and primarily works at the network-layer using data de-duplication technologies. These algorithms attempt to reduce the size of data by finding commonly repeated chunks of data and transmitting an “index” or “pointer” to that data rather than the entire data set. One WOC removes the data ,the other replaces it upon receipt. This reduces the amount of data exchanged over the WAN but requires two devices, one at each side of the WAN.
  
  Symmetric Compression is well-suited for large, repetitive data set exchanges across WAN links, such as commonly shared files/virtual images/etc… shared by multiple users at a remote location.
  
• Adaptive Symmetric Compression
  Adaptive Symmetric Compression combines industry standard compression with the network-layer compression traditionally implemented by a WOC and applies it intelligently. Rather than always using a specific algorithm, this capability chooses the algorithm on-demand based on the type of network-link being used and the type of data being exchanged. This means compression will generally not be used on data that does not compress well, such as images (JPG, for example, is already compressed and such files do not benefit from additional compression), and the “best fit” algorithm will be used for other data.
  
  Adaptive Symmetric Compression is well-suited for environments in which both web-application data and large file sets are being exchanged over the WAN, and excels in environments where more than one WAN link is used.

The “danger” with compression algorithms is two-fold. First, applying compression without consideration for the network link and the type of data can actually degrade performance by increasing response times. This is because in some situations it takes longer to apply the compression algorithm to the data than it would to transfer the raw data across the given link. Second, the location within the network where compression is applied can have a deleterious effect on other infrastructure components attempting to act on the data, because it must decompress the data, apply its policies, and then recompress the data. This is similar to the problem of end-to-end SSL encryption of data, which forces intermediaries either to abandon their function (a bad idea) or to decrypt, execute, then re-encrypt data.

Choosing the right compression strategy to fit with your architecture, data, and application needs is paramount to ensuring that the benefits of compression are realized. 

WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND.