Lori MacVittie

Mobility Can Be a Pain in the aaS

Lori MacVittie — Tue, 16 Mar 2010 10:59:49 GMT

What does a 2-year old and cloud-based applications have in common?

The Toddler has recently decided that he can navigate the stairs by himself. Insists on it, in fact. That’s a bit nerve-wracking, especially when he decides that 2:30am is a good time to get up, have a snack, and recreate a Transformers battle in the family room.

It’s worse when you’re asleep and don’t know about it.

Oh eventually you hear him and you get up and try to convince him it’s time for sleep (see? all the grown ups are doing it) but it takes a while before he finally agrees and you can climb back into bed yourself.

Mobility. It’s a double-edged sword that can bite not only parents of Toddlers testing out their newly discovered independence but the operators and administrators trying to deal with applications that, thanks to virtualization, have also discovered they have wings – and they want to use them.

IT’S 2:30AM, DO YOU KNOW WHERE ALL YOUR APPLICATION INSTANCES ARE?

When ~~Toddlers~~ application instances auto-launch themselves at 2:30am in any cloud computing environment it’s important to know where they are. While the worst the Toddler will likely do is try to raid the refrigerator the application may be doing far worse – it may be running up charges for merely existing while not doing anything substantially beneficial for you, like responding to application requests. In that respect you could say a virtualized application is more like The Teenager than The Toddler, because it seems to absorb money without any kind of return on investment.

Applications have never been islands but their reliance on the rest of the infrastructure to provide value, to respond to requests, to execute their functions, has never been more evident than when they’re dumped virtually into a cloud computing style environment. Without integration – either from within the application or from within its controlling management systems – with the rest of the infrastructure the application really is just wracking up charges without providing any real value to you or the users for whom it was launched.

And when applications become mobile, popping up at odd hours of the day and night in response to events and demands, this integration is absolutely required to ensure that the very raison d’etre of the application instance isn’t lost in the ~~kitchen~~ myriad virtual images humming happily in the data center (wherever that may be).

ORCHESTRATION REQUIRED

This is why orchestration is so important in ensuring a smoothly running virtualized infrastructure. Without someone paying attention, governing the instances, and making sure they are integrated with the right infrastructure components at the right time the entire value proposition of cloud computing and “fluid” architectures is rendered null and void. In the enterprise data center this process can be simpler than you might think, as the application can be directly integrated with the upstream components necessary to ensure it’s included in the process of increasing capacity through elastic scalability. When you “own” the infrastructure and you have the ability to integrate through standards-based mechanisms, you can ensure that no application is ever left behind when it enters the fray.

When you don’t own the infrastructure you need to be more choosy about the environment, ensuring that there are processes in place and means by which application instances will not be “lost” and incurring charges without providing benefit. What you don’t want is a manual process that requires you to manually integrate the application into the provider’s high-availability infrastructure (or yours in a true IaaS environment). You need Infrastructure 2.0 enabled components and operational processes that allow you to automatically ensure application instances are always being utilized when they’re available and not “powered on” when they aren’t.

Efficiency is about orchestrating operational processes, about eliminating manual tasks that could – and should – be handled through operational integration within the broader cloud computing ecosystem.

If that’s not the case, then the mobility of applications really is nothing less than a giant pain in aaS.

Related blogs & articles:

Technorati Tags: MacVittie,F5,cloud computing,infrastructure 2.0,mobility,XaaS,integration,collaboration,virtualization,orchestration

Nobody Puts Baby in a Corner

Lori MacVittie — Mon, 15 Mar 2010 11:15:14 GMT

In this case “baby” is load balancing and the corner is cloud computing.

SocialCloudNow recently wrote up a pretty darn accurate (which is hard to find these days) description of “cloud computing” by walking through the components required. The author did an excellent job – especially where he dove into the relationship between orchestration and cloud computing. Loved that a lot – most folks ignore that piece of cloud computing even though it’s very, very important. But I was a bit put off (okay, a lot put off) at one statement:

An honorable mention goes out to the Load balancer – which does the obvious.

Honorable mention? It’s an afterthought that certainly one of the key enabling technologies of cloud computing does not deserve. Shortly after reading the post and debating this point with Paul Richards (the author) I came to the realization that he was looking at cloud computing from the view point of the consumer, i.e. the organization, the customer, an administrator/developer looking for a cloud in which to deploy applications. That made his statement make a lot more sense. If you’re looking at cloud services offered and trying to decide which one to jump on then perhaps a load balancer isn’t your primary concern at all (although that makes me want to say, “Inconceivable!”). But from the perspective of the definition of cloud computing and the folks who are implementing (internal/external, public/private) such environments, a load balancer is certainly a lot more than just window dressing.

So I will say that as far as cloud services go, load balancing may be – based solely on consumer need, or perception of need – worthy of only honorable mention. But as far as implementing a cloud computing environment goes, it’s a requirement.

LOAD BALANCING is in the CLOUD DNA: FROM CPU to NETWORK to APPLICATION to DATA CENTER

Let’s just get right down to brass tacks: in today’s cloud computing environments, without load balancing there is no scale. None. You can’t scale applications in the current technological environment without load balancing. Whether that load balancing comes from hardware, software, virtual ware, or a Cracker Jack box is irrelevant. What’s important is that the ability to load balance applications – to virtualize applications and services – is an absolutely essential component of cloud computing.

Until we figure out how to vertically scale resources on-demand and past the physical limitations of the hardware* (i.e. we can “reach out” to other pools of pure compute resources and expand the logical memory and CPU of the primary hardware) we are going to be wholly reliant on load balancing to implement on-demand scalability in any environment, cloud computing or traditional. Thinking about that a bit more it even in the case we break the physical barrier we need some form of load balancing. If pools of compute resources and RAM are going to be used across physical devices there needs to be a way to manage those resources as though it were…a single, aggregated set of resources.

Which is what a load balancer does.

It would certainly be a completely new form of load balancer, but it would still likely be a load balancing capable “something” nonetheless. Load balancing is a lot like CPU-scheduling, after all, and that’s been around for, well, as long as there have been CPUs. So extending the concept out into the network, using high-speed interconnects as the bus between CPUs and blocks of memory isn’t all that far-fetched. But I digress – the point here is that even scaling ‘up’ will almost certainly require load balancing of some kind. It’s just that core to scalability; it’s native at the CPU level, at the machine level, at the network level, at the application level, even at the data center level (GSLB, a.k.a. global application delivery, a.k.a. intercloud). Scale without load balancing is simply inconceivable, and one of the core identifying characteristics of cloud computing is, yes, scale.

If you remove a firewall from a cloud computing architecture does it impact the core behavior of a cloud computing environment? Nope. Not at all. It leaves it very insecure and I certainly wouldn’t build a cloud computing environment without one, but from a purely technical point of view it isn’t adding to the core behavior expected of cloud computing. Now take out the load balancer. What happens? Scalability is lost. You end up with a bunch of cloned application instances, each with their very own IP address, with no way to distribute requests to them. Removing a load balancer from a cloud computing environment breaks the cloud, ergo a load balancer is a requirement.

Note it doesn’t matter whether the load balancing is provided by software or hardware or virtualware. It is the concept of load balancing that is integral to cloud computing and elastic scalability. Taking “load balancing” out of the equation changes the behavior of the cloud computing environment such that it isn’t very elastic any more.

If we were going to write a “cloud computing RFC” the term “load balancer” would be preceded by a MUST INCLUDE and firewall would be preceded by a SHOULD INCLUDE. If we were going to write a “cloud computing RFP”, such as would be written by a customer looking to compare offerings, then these two might be juxtaposed.

*There are a couple offerings out there that actually do this – it’s some awesome stuff – but they aren’t being leveraged by most cloud providers today.

Related blogs & articles:

Technorati Tags: MacVittie,F5,cloud computing,load balancing,orchestration,load balancer,scalability

Cloud Connect 2010: Got a Question About Infrastructure Interoperability But You Can’t Attend? I Got Your Back…

Lori MacVittie — Fri, 12 Mar 2010 19:16:49 GMT

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.

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. :-)

Technorati Tags: MacVittie,F5,CloudConnect,Infrastructure 2.0,interoperability

Might As Well Face It You’re Addicted to Cloud

Lori MacVittie — Fri, 12 Mar 2010 11:30:29 GMT

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

Related blogs & articles:

Technorati Tags: MacVittie,F5,cloud computing,humor,parody

I CAN HAS DEFINISHUN of SoftADC and vADC?

Lori MacVittie — Thu, 11 Mar 2010 11:31:57 GMT

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?

ADC

An application delivery controller is a device that is typically placed in a data center between the firewall and one or more application servers (an area known as the DMZ). First- generation application delivery controllers primarily performed application acceleration and handled load balancing between servers.

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.

SOFT ADC

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.

VIRTUAL ADC (vADC)

A "vADC" is a virtualized version of an ADC. The ADC may or may not have first been a "Soft ADC", as in the case of BIG-IP which is not available as a "Soft ADC" but is available as a traditional hardware ADC or a virtual ADC. vADCs are ADCs deployed in a virtual network appliance (VNA) form factor, as an image compatible with modern virtual machines (VMware, Xen, Hyper-V).

ADC as a SERVICE

There is an additional "type" of ADC emerging mainly because of proprietary virtual image formats in clouds like Amazon, the "ADC as a service" which is offered as a provisionable service within a specific cloud computing environment that is not portable (or usable) outside the environment. In all other respects the “ADC as a service” is indistinguishable from the vADC as it, too, is deployed on commodity hardware and lacks integration with the underlying hardware platform or available acceleration chipsets.

A PLACE for EVERYTHING and EVERYTHING in its PLACE

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

“Solution”	Soft “Solution”	v”Solution”	“Solution” as a Service*
A traditional hardware-based “solution”	A traditional hardware-based solution in a software form-factor that can be deployed on an “appliance” or commodity hardware	A traditional hardware-based solution in a virtualized form-factor that can be deployed as a virtual network appliance (VNA) on a variety of virtualization platforms.	A traditional hardware-based solution in a proprietary form-factor (software or virtual) that is not usable or portable outside the environment in which it is offered.

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,ADC,application delivery controller,vADC,soft adc,ADC as a Service,virtualization,vmware,xen,hyper-v,microsoft,amazon,vna,virtual network appliance

If I Had a Hammer…

Lori MacVittie — Wed, 10 Mar 2010 11:43:06 GMT

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).

PAY ONLY for WHAT you ~~USE~~ NEED

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.

STILL CHEAPER than ROLL YOUR OWN

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,cloud computing,cost,billing,metering,provisoning

The Order of (Network) Operations

Lori MacVittie — Tue, 09 Mar 2010 11:41:38 GMT

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.

HERE COMES the ~~SCIENCE~~ MATH

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:

	Architecture #1	Architecture #2
Time to Execute	102	44
CPU cycles consumed	188	66

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.

APPLICATION DELIVERY ORDER of OPERATIONS RULES

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:

Technorati Tags: MacVittie,F5,infrastructure,architecture,performance,math,operations,network,application delivery,offload,SSL,compression

The Corollary to Hoff’s Law

Lori MacVittie — Mon, 08 Mar 2010 13:07:28 GMT

“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.

IT’S NOT ALL PUPPIES and RAINBOWS

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:

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

DISMISSING CONCERNS is a MISTAKE

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”

Related blogs & articles:

Technorati Tags: MacVittie,F5,cloud computing,infrastructure,infrastructure 2.0,security,application delivery and data services,cloudaudit,Hoff

When Everything is a Threat Nothing is a Threat

Lori MacVittie — Fri, 05 Mar 2010 11:48:17 GMT

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.

WHAT if your INFRASTRUCTURE was SMARTER than THAT?

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. By using all the available information we have a better chance at mitigating several classes of attacks, both those directed at the user and at the application or its supporting infrastructure. Leveraging a dynamic infrastructure further enables a more flexible and responsive security posture in the event that anomalies are detected as it necessarily allows infrastructure to collaborate and indicate a credible threat.

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,infrastructure 2.0,cloud computing,security,application delivery,infrastructure,architecture

The IP Address – Identity Disconnect

Lori MacVittie — Thu, 04 Mar 2010 11:54:16 GMT

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.

BUT WHAT ELSE IS THERE?

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,context-aware,infrastructure,IP,security,application security,access control,virtualization,network,application delivery,unified application delivery and data services

Microsoft Hops Into Infrastructure 2.0

Lori MacVittie — Wed, 03 Mar 2010 11:58:09 GMT

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.

HOPPING into the NETWORK

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.”

DE FACTO STANDARDS are INEVITABLE

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,infrastructure 2.0,standards,Microsoft,DDA,dynamic infrastructure,dynamic infrastructure toolkit for System Center,DIT-SC,yahoo,API,cloud computing

REST API Developers Between a Rock and a Hard Place

Lori MacVittie — Tue, 02 Mar 2010 12:04:58 GMT

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.

MOVING TARGETS

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.

GIVE it a REST

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?

Related blogs & articles:

Technorati Tags: MacVittie,F5,SOA,SOAP,REST,API,Fielding,development,standards,HTTP,HTML,XHTML,interoperability

Square Infrastructure Pegs Don’t Fit in Round Network Holes

Lori MacVittie — Mon, 01 Mar 2010 11:53:20 GMT

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.

RIGHT FORM, RIGHT PLACE, 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.

IT’S the ARCHITECTURE

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,virtualization,VNA,cloud computing,scalability,architecture,infrastructure,virtual network appliance,load balancing

Pay No Attention to the Infrastructure Behind the Cloudy Curtain

Lori MacVittie — Fri, 26 Feb 2010 11:31:02 GMT

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.

SERVICES –> COMPOSITE DATA CENTER ARCHITECTURE

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.

INFRASTRUCTURE 2.0 is the RED RUBY SLIPPERS of CLOUD COMPUTING

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:

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

Technorati Tags: MacVittie,F5,infrastructure 2.0,integration,customization,SOA,services,standards,virtualization,SOAP,REST,APIs,control plane,application delivery

May I Mambo Dogface to the Banana Patch?

Lori MacVittie — Thu, 25 Feb 2010 11:18:06 GMT

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.

WHO is in CONTROL of CLOUD COMPUTING INITIATIVES?

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,cloud computing,definition,NIST,align,investment,business,Bill Cosby,technology