Latest News from Lori MacVittie

Silos Belong on Farms Not in Clouds

Tue, 08 Dec 2009 06:31:58 EST

Beware the danger of building out isolated network and application network infrastructures in the cloud lest we end up with silos from which it is difficult to escape.

While writing a separate post on the business value of public versus private cloud computing investments I specifically called out the fact that infrastructure – virtual or physical – provisioned in a cloud environment is applicable only to that cloud environment; it really can’t be shared within the enterprise architecture or other public cloud computing environments, for that matter.

That led to considering the impact of the cloud computing deployment model on general application architecture and how much “sharing” of provisioned resources would occur “out there”. There appears to be a very real possibility that the lack of visibility in cloud computing environments may very well lead to the creation of silos in the cloud.

ISOLATION is not always A GOOD THING

One of the alleged benefits of public cloud computing is that anyone within your organization can take advantage of it. We’ve seen the results of isolated, disconnected departmental-level architecture and development before; internal technological silos. When there is no centralized infrastructure management, each department/project is left to its own devices. This isolation and separation from a shared IT infrastructure management could easily lead to two or more different applications being provisioned with their own “copies” of infrastructure in a public cloud computing environment.

Somewhere along the line “on-demand” came to carry with it a subtext of “ad-hoc” and was applied to not only provisioning of compute resources but infrastructure resources as well. Application not performing well enough? Provision an application delivery controller with application acceleration features and solve the problem. Application needs to scale up? Provision a load balancing solution and a second or more application instance and solve the problem. Eventually, if there are enough infrastructure services available, you can see where this might lead: isolated, application-specific infrastructure architectures that unnecessarily increase the total cost of ownership for the application. Also inherent in the idea of ad-hoc provisioning of architectural components is a lack of adherence to organizational policies for security, availability, and reliability of application services.

GOVERNANCE a CRITICAL but MISSING ELEMENT

The concept of governance and its relationship to cloud computing has been discussed but those conversations tend to revolve around the need for more generalized governance. That is, a service catalog of all cloud provider offered services as well as a cloud-application service catalog for consumers. But there’s little mention of the need for architectural governance at the organizational level. The ability of an enterprise architecture group that is responsible for setting the direction of application architecture across all deployments, not just those internal to the organization.

A centralized architectural approach could eliminate the possibility of silos in public cloud computing deployments by enforcing the use of shared infrastructure services provisioned into the public cloud computing environment. Indeed, without some sharing of infrastructure the concept of Intercloud and cloud-balancing becomes inherently more difficult – nearly impossible, in fact – to implement. For example, one approach to enabling cloud-balancing is to employ the functionality of an intelligent global application delivery platform, a GSLB (global server Load balancer), to determine based on the context of a request for an application which location will best serve the specific needs of the user and request in question. Assuming the application is deployed in only one location makes this decision fairly straightforward, but the use of the GSLB provides a layer of abstraction between the consumer of the application and the actual implementation and hides its location while presenting a single, unified “presence” to the consumer. It also centralizes DNS management, which is critical when considering the implementation and deployment of DNSSEC.

Without a governance strategy, it is possible and probably likely that silo-like deployments will occur, especially as the service offerings in cloud computing providers continues to mature and expand. Fragmentation of infrastructure across multiple silos also makes it difficult to integrate into existing management systems and makes more complex troubleshooting, log aggregation, event correlation, and reporting in general.

"We were experiencing what others had warned me about. We suddenly realized ‘wow, this is an extremely complicated environment’ and when there’s a problem, you get 8 staff and 3 vendors on the phone all pointing fingers at one another. The need for cross-silo insight became absolutely critical”.

-- VP of Virtualization Operations, unnamed organization “The Virtualization "Tipping Point" in 2010”

Silos, except on farms, are just plain bad news. But without governance and a strategy with which to approach public cloud computing-based application deployments, they may pop up without intent.

CLOUD COORDINATOR

Maybe this is a job for “Cloud Coordinator”, or whatever you might want to call such a group or individual. SOA eventually came up with a similar notion, often called the “Registrar” or the “Librarian”, depending on what governance solution was being implemented. Someone or some team that is responsible for (a) understanding what services are available in the apposite cloud computing environments and (b) managing those services with an eye toward sharing or at least ensuring consistency of solutions across applications deployed in a public cloud computing environment. One thing that will greatly improve the ability to keep that consistency is the vendor-enablement of shared configurations across disparate instances. Not synchronization, necessarily, but simply sharing of configuration across devices that may or may not (most likely the latter) be paired. Better would be the ability to “share” granular configuration settings – on a per-policy or per-application basis – with other like-devices.

Avoiding the creation of silos in the cloud will be a challenge. Recognizing the need for a consistent strategy and enforceable governance policy will go a long way toward avoiding the pain of trying to extricate applications and isolated infrastructure deployments from the silos created by ignoring the ad-hoc provisioning of entire infrastructures to support each application.

Related blogs & articles:

Technorati Tags: MacVittie,F5,virtualization,cloud computing,cloud,infrastructure,application delivery,intercloud,cloud balancing,architecture,governance

The Application Delivery Spell Book: Contingency

Mon, 07 Dec 2009 06:37:15 EST

The long, lost application delivery spell compendium has been found! Its once hidden, arcane knowledge is slowly being translated for the good of all web applications. Luckily, you don’t have to be Elminster or Gandalf or <insert powerful wizard you know here> to cast this spell over your infrastructure

Contingency

School of Magic: Evocation

Components: Somatic (requires gestures), Material (requires physical component)

Saving Throw: None

Spell Resistance: No

Through the use of the contingency spell, application delivery professionals can dictate the conditions of the execution of another spell. The contingency spell and the companion spell(s) are cast at the same time, but the companion spell fires only when the conditions specified by the contingency spell are met.

The material component for this spell is a network-side scripting capable application delivery controller. The somatic component requires the caster to complete a series of mouse clicks and keyboard strokes that deploy a network-side script that fires when the specified event occurs. A verbal component is not necessary, but some casters find it satisfying to complete the invocation of contingency with some sort of joyful noise (defensive casters belonging to the InfoSec Guild tend to call out “Huzzah! Beat that!” for some reason).

The spell to be brought into effect by the contingency can be one that affects layers 2 through 7 and can either be narrow or broad in its targeting. For example, the contingency can be based upon specified triggers such as: HTTP_REQUEST, HTTP_RESPONSE, CLIENT_DATA, ASM_REQUEST_VIOLATION, SIP_RESPONSE, DNS_REQUEST, and ASM_RESPONSE_VIOLATION. Consult your player’s handbook for a complete list of possible triggers. You can use multiple contingency spells at a time, but each will fire according to the order of events specified in the player’s handbook.

Like many illusionist spells the effects of the companion spell(s) are heavily dependent upon your imagination. Existing spells that have been cast along with contingency that have been made available by their casters can be explored in the companion spell compendium.

EVENT-BASED APPLICATION DELIVERY

Network-side scripting capabilities in application delivery controllers offer a unique method of extending a wide variety of IT-related functions “into the network”. When we talk about Infrastructure 2.0 we tend to focus in on control-plane APIs that enable management and dynamism in the infrastructure but network-side scripting can be as integral to enabling an agile and extensible infrastructure as its control-plane API cousins.

“I wish it would do this when that happens” is an utterance I’m sure most of you have heard – if not muttered/exclaimed yourself. No solution is 100% perfect for your environment and needs; there’s always something you wish it could/would do that it doesn’t. In most cases there’s nothing you can do about it; it’s take it or leave it.

Network-side scripting provides the means by which you can probably make that happen when this happens. The number of that happens supported by network-side scripting capable solutions varies but in some cases is quite lengthy and spans a wide variety of infrastructure concerns. Network-side scripting enables you to say WHEN THAT_HAPPENS do THIS. It provides a framework in which you can tailor application delivery functions – security, authentication, acceleration, optimization, load balancing, routing, transformation - to your unique environment in a way that’s just not possible in a turn-key solution.

EXAMPLE: IMPROVING SECURITY-RELATED RESPONSES

One of the downsides to web application firewalls has been that the range of actions you can perform has always been somewhat limited. You can block, quarantine, log, or ignore policy violations but it’s difficult to enable custom functionality. “Contingency”, a.k.a. network-side scripting, changes that and allows developers and architects to respond to application security policy violations specifically tailored to suit organizational needs. Both inbound (request) and outbound (response) violations can be used to trigger custom responses.

Just a few of the attack types you can respond to are:

ATTACK_TYPE_TROJAN_BACKDOOR_SPYWARE
Trojan/Backdoor/Spyware
ATTACK_TYPE_DETECTION_EVASION
Detection Evasion
ATTACK_TYPE_VULNERABILITY_SCAN
Vulnerability Scan
ATTACK_TYPE_ABUSE_OF_FUNCTIONALITY
Abuse of Functionality
ATTACK_TYPE_AUTHENTICATION_AUTHORIZATION_ATTACKS
Authentication/Authorization Attacks
ATTACK_TYPE_BUFFER_OVERFLOW
Buffer Overflow
ATTACK_TYPE_PREDICTABLE_RESOURCE_LOCATION
Predictable Resource Location
ATTACK_TYPE_INFORMATION_LEAKAGE
Information Leakage
ATTACK_TYPE_DIRECTORY_INDEXING
Directory Indexing
ATTACK_TYPE_PATH_TRAVERSAL
Path Traversal
ATTACK_TYPE_XPATH_INJECTION
XPath Injection

The ability to act on specific policy violations combined with the proper context provides the means by which a web application firewall can be leveraged to enhance business value – by providing helpful information to legitimate users that can assist in resolving the problem without involving the help/support desk – as well as the overall security posture of the applications being defended. Perhaps its nothing more than a custom blocking page on which you emphatically inform the violator that you know what they’re doing or a redirection to a self-service site for users you know, because you have the proper context, are simply having a bad day and need some help.

Ultimately the purpose of this kind of flexibility is to enable a more agile infrastructure and increase visibility into application delivery. Visibility comes from information, and it is a wealth of information that can be provided by examining application security policy violation events. Even if the response is nothing more than to log the details information security pros deem important it’s improving the visibility into the application environment that can aid IT in improving web application security and related processes.

Related blogs & articles:

Technorati Tags: MacVittie,F5,application delivery,contingency,ADSB,network-side scripting,event-driven architecture,security,acceleration,load balancing,routing,D&D,iRules

Cloud Is the Gift That Keeps on Giving

Fri, 04 Dec 2009 15:45:00 EST

Brenda Michelson, Principal of Elemental Links, writes "elemental cloud computing" recently tweeted: "100k buys way more public, than private, cloud computing power" which started a short but inspiring conversation on the subject centering around the observation that "cloud is the gift that keeps on giving." That's alluding to the fact that the compute power purchased in "the cloud" is an annual expense, unlike private, cloud computing power which requires renewal at longer intervals, usually in the 3-5 year range. Still, Brenda is right at least in the short term. $100,000 purchases a lot more compute power in a public cloud computing environment than it will/would/does in a private cloud computing environment. The problem is that $100,000 in a private cloud computing environment is likely to provide more business value than would a comparable investment in a public cloud computing environment. And that's really the metric we should be using instead of CAPEX versus OPEX.

No Shirt, No Shoes, No HTTP Service

Fri, 04 Dec 2009 14:15:00 EST

But on the web, access to services is implicit in the fact that the business is offering the service. If the HTTP service is accessible, it’s implicitly allowing connections and providing service without any standard criteria for access. This results in access by more than just customers and potential customers. Bots, spiders, and miscreants are afforded the same access to business services as more desirable visitors. This can unfortunately lead to compromise, theft, and corruption of data via myriad injection and attack methods – many of them automated. While gating access to services that comes from offering a service is likely not the best solution (although it is a solution), there has to be a way to at least mitigate the automated abuse of open access to services by miscreants that leverage scripting to attack sites.

Next-Generation Management of Data Centers Should be Modeled on Social Networking

Fri, 04 Dec 2009 07:34:52 EST

Should the next generation management of network and application network devices look and act more like Facebook and Twitter? Infrastructure 2.0 could take us there.

Y ou may think I’m kidding and certainly I make this proposal with some amount of humorous intent, but there is some value, I think, in applying the concepts of Web 2.0 and social networking to network management systems (NMS).

There’s a reason it’s called social networking, after all. It’s modeled closely on networking and NMS is primarily about managing not just individual network and application network devices, but on managing the relationships between them. “Dependencies” are often included in NMS applications to better visualize and traverse the myriad relationships between network, application network, storage, and applications that make up the data center infrastructure. Understanding which devices are “friends” and which are “followers” is nothing new to NMS and IT professionals who spend their days mired inside these applications.

I occasionally see tweets and press releases regarding new versions of this NMS solution or that, but even the newer ones are all very focused on doing the same old thing with a dash of “cloud” for flavor. If we’re going to completely and potentially irrevocably change the style of computing, shouldn’t we change our methods of management, too?

Wouldn’t it be nice if you could use mechanisms similar to OAuth to connect various devices together and on a granular basis permit the exchange of configuration – relevant polices, for example? And wouldn’t it be even nicer if that exchange could be mediated automatically? When BIG-IP 003 “tweets” a configuration update – such as the launch of a new virtual instance of an application - it is picked up by its followers (including BIG-IP 002) and triggers the appropriate update on its configuration. Facebook style Walls could substitute for text-based log files and provide many of the same features as Web 2.0 and social networking sites do today: sharing with other systems, tagging, marking for later perusal, etc…

Example: you’re perusing through your Apache “Wall”. You see in the log an HTTP request that is obviously an attempt to exploit a vulnerability. You click the “SHARE” button and are presented with a list of all your “network” friends. You choose your firewall/web application firewall and options are immediately presented as to the kind of sharing you want to do. You choose “create a policy to block this IP” and WHAM! No more exploitable requests from that IP address. It’s the virtual patching that White Hat Security has been doing for years married to Facebook. Awesome powerful stuff there.

THIS is WHERE INFRASTRUCTURE 2.0 COULD TAKE US – IF WE WANTED TO GO THERE

I started out by mentioning there is some amount of humorous intent in this idea but the core concept is very serious: the collaboration and relationships that are inherent in Web 2.0 and social networking are definitely applicable to managing emerging data center models. The ability to interconnect the network, application network, storage, and applications is paramount to a successful implementation. Without that interconnection - without a dynamic control plane to support the collaboration – any next generation implementation simply adds complexity to an already complex set of systems. Efficiency and indeed agility is achieved through dynamism, and dynamism is achieved through the ability to send and receive actionable data and execute the appropriate processes without requiring human intervention. But we shouldn’t stop at the operational layer. Let’s keep going, up the “stack” and re-examine how we manage these systems. There’s no reason we can’t leverage the robust APIs available [PDF] to control and manage infrastructure solutions to build a next-generation management system that is itself dynamic and collaborative.

How this collaboration is leveraged is completely up to the implementer, which is why even though it may seem funny we certainly could see Facebook/Twitter-style functionality in our HP OpenView/CA Unicenter/IBM Tivoli/<insert NMS here> solutions. There’s no reason why, when most infrastructure 2.0 solutions are capable of SOAPy or RESTful (or both) integration that we can’t create something that’s more collaborative, more integrated, and generally makes the ability to configure and manage systems across multiple installations a bit easier.

Remember the Twitter-bots Joe and I created for BIG-IP? It wasn’t just alerting and notifications; we could command a BIG-IP remotely via Twitter. So my funny idea gets a bit more serious when you consider we’re already leveraging the collaborative capabilities of infrastructure 2.0 to find new ways to manage and interact with network, storage, and application network solutions. There’s a lot we can learn from the success and rapid adoption of social networking and Web 2.0, and primary among those lessons is that collaboration, relationships, and integration doesn’t have to painful. It can be dynamic, simple, and even at times enjoyable.

Related blogs & articles:

Technorati Tags: MacVittie,F5,infrastructure 2.0,infrastructure,network and systems management,NSM,CA,HP,IBM,Tivoli,OpenView,Unicenter,API,SOAP,REST,facebook,twitter,social networking,web 2.0

Grokking the Goodness of MapReduce and SPDY

Wed, 02 Dec 2009 12:00:00 EST

Certainly no one would seriously argue that web applications are fast enough for everyone. SPDY is one suggested solution, but what if we combine MapReduce and SPDY? Could we develop an architectural solution that leverages the best of SPDY without requiring entire infrastructure changes to support a new protocol?

More than a couple of people have mentioned Map/Reduce as a means to achieve workload-level distribution of applications in a cloud computing environment. I hadn’t looked into Map/Reduce but finally decided that if that many very smart people were thinking it was a solution, I should look into it. After reading through a few tutorials and articles on the subject, including a much referenced lecture from a UW Madison (yeah! Badgers!) professor, I began to wonder how well we could combined MapReduce with SPDY as a means to improve application delivery. [The referenced ‘illustrated’ PDF from the lecture is hard to find. You can access it here. ]

From Google’s paper on Map/Reduce:

MapReduce is a programming model and an associated implementation for processing and generating large datasets that is amenable to a broad variety of real-world tasks. Users specify the computation in terms of a map and a reduce function, and the underlying runtime system automatically parallelizes the computation across large-scale clusters of machines, handles machine failures, and schedules inter-machine communication to make efficient use of the network and disks.

Programmers find the system easy to use: more than ten thousand distinct MapReduce programs have been implemented internally at Google over the past four years, and an average of one hundred thousand MapReduce jobs are executed on Google’s clusters every day, processing a total of more than twenty petabytes of data per day.

It isn’t just the protocol (SPDY) that’s apposite to application performance and more specifically, web application performance. After looking through Map/Reduce, it would certainly appear that the combination of the “programmatic model” and SPDY would definitely provide the kind of scale and processing speed necessary to achieve a “speedier web.”

THE WAY IT WORKS TODAY

When we want to scale a web application today we need to build out an architecture that load balances requests across a pool of servers. Clients are limited in the number of connections that can be opened to any given host, but that number is now in the 6-8 range for modern browsers. The connections are synchronous, meaning that once a request is sent a reply must be received before the next request can be sent.

Each object in a page can be mapped to a request and thus the browser’s task is to distribute object requests across its available connections and then to aggregate the responses into a document that can be rendered for the user’s viewing pleasure.

In much the same way, the load balancer also distributes the requests across its pool of available resources: the application instances. The Load balancer is capable of handling much high volumes of connections, of course, and it can intelligently distribute requests based on a variety of parameters. An advanced load balancer (application delivery controller) can distribute requests based on the URI, values in HTTP headers, and on data in the actual request (payload). But it is still bound to the same synchronous request/reply pattern as the browser. In order to achieve high scalability and fast performance, the load balancer optimizes connections and uses as much information as possible when distributing requests. The latter is often a matter of configuration: even though the load balancer can use a wide variety of environmental factors upon which to base its load balancing decision it must be configured to do so and many an administrator/architect ignores these capabilities.

The result is still synchronous, with potentially multiple connections per client being utilized to return as many objects in parallel as possible. Both the browser and the load balancer are essentially parallelizing requests and responses.

WHAT IF WE COMBINE MAP/REDUCE and SPDY?

The biggest difference to note immediately is the lack of synchronous communication. SPDY is asynchronous, and thus the browser need not parallelize the requests. Using SPDY the browser could, as it was parsing the main page, simply send a request for each object it encounters back to the origin server.

Remember that SPDY allows for only one connection per browser, so all requests for component objects in a web page would need to be sent over that single connection. Aside from the synchronicity, this is not much different than would be the case is browsers were programmatically limited to a single connection per host.

Right now it appears the usage of SPDY is simulating traditional behavior; that is, the browser is still responsible for parsing out the “main page” and initiating individual requests for each component, albeit in the case of SPDY over the same connection.

If you have the capabilities afforded by Map/Reduce on the web/application server (or intermediary of some kind), could we not take advantage of that? Using Map/Reduce it certainly appears (and I may be completely off-base, but someone, I’m sure, will correct me if that’s the case) you could push the parsing (disaggregation) of the “main page” to the server/intermediary and let it “map” and “reduce” (aggregate) its component objects into a single, completed page that can then be returned to the client over that single connection. The “map” function is used to apply the same function to a large set of inputs, and all we’re doing is saying the function is “load/generate this page”, after all. The application of compression and security policies can be applied either at the component or complete page comprising all HTML required. The rest of the infrastructure need only act on a single, completed page in which all pertinent data exists, greatly simplifying processing.

It would have to be selective in that only some included content needs to be “reduced” into the main page. Some objects – navigational links, for example – can’t be included because, well, it would break the entire web. But there is a subset of objects that could be included that might result in improved performance overall. This is where SPDY (or at least its core functionality as applied to HTTP) comes into the picture, as its asynchronous nature would improve the delivery of objects that can’t be included in the core HTML for whatever reason. Distinguishing between the two could be as simple as an attribute on an anchor element such as “aggregate=true” with a default of false, just to try to maintain backward compatibility.

This would remove the need for the browser to parse the original page and subsequently issue requests, eliminating the round trip time for each object from the overall response time. While the resulting page is larger because it contains the complete HTML necessary, the browser can more effectively employ progressive rendering techniques on the complete page as soon as data begins returning.

The draft SPDY protocol, by allowing asynchronous requests, eliminates approximately half the round trip times by not requiring immediate responses, but by leveraging Map/Reduce capable systems on the server/intermediary side we can eliminate more ( #objects * RTT to be exact). We also completely eliminate the negative impact on the network (and thus application performance) from dealing with many small packets generated from many small objects.

The RTT between the server/intermediary and internal application servers is still applicable, but because this is almost always over high-speed, low-latency LAN connections (and we’re paying that price regardless) the impact on overall performance remains minimal.

AREN’T YOU ARGUING AGAINST APPLICATION DELIVERY CONTROLLERS?

If you think of application delivery controllers as nothing more than load balancers then it certainly might appear that way, wouldn’t it? But load balancing, while an integral component to an application delivery controller, is not the be-all and end-all of its capabilities or its only role in high-availability architectures. Optimization and acceleration still applies, as does security and its myriad related functions. So, too, does ability to transform requests on-demand, both ingress and egress. Context is still as important, if not more so in an architecture such as the one described, and given an application delivery controller generally sits in what is a strategic point of control in a data center architecture- traditional, virtualized, or cloud computing – it is still the best place to provide most application delivery functionality.

So no, I’m not shooting myself in the foot by postulating on a web-application architecture using SPDY and Map/Reduce (or some similar mechanism that has yet to be designed) as a core means to achieve fast and highly-scalable web applications. The use of SPDY and Map/Reduce would only speed up the internal processing and reduce the latency associated with the traditional request/reply paradigm. It does not address high-latency links, congestion, conditional network problems, or security-related issues. It doesn’t solve the problem of regulating request rates nor prioritization nor business-layer load balancing. And there are many BHQ (Big Hairy Questions) involving such a solution that would need answers before it could be useful, such as the handling of off-domain requests and credential mapping for integrated widgets/gadgets/sites.

Besides, it is somewhat interesting to note that much of the functionality described by Map/Reduce, when applied strictly to URI-based workloads (think REST and even SOA) already exists in application delivery controllers. It isn’t, after all, just about load-balancing, it’s about intelligent routing of requests based on context, like the URI. The single-session concept is something already demanded by service-providers (RADIUS, DIAMETER, SIP) and some application delivery controllers can handle this type of message-based load balancing [PDF] scenario, so all that’s left is the aggregation of the disparate components into a single page for delivery. So it’s possible that the definition of such an architecture combined with the protocol could be natively supported by application delivery controllers with relative ease. What’s necessary is to break out of the connection-oriented processing paradigm inherent in load balancing and proxies and HTTP, and in some cases we’re half-way there already.

It is definitely interesting to contemplate a new architectural solution to the problems associated with HTTP and performance. Map/Reduce is also certainly one answer to moving cloud computing out of its current instantiation toward truly on-demand resource utilization on a per-workload basis. It’s an interesting concept and one that obviously works well for Google, given the number of applications in its repertoire that apparently take advantage of the model. Thus it (or similar concepts) is certainly something to consider for potentially broader usage outside of Google’s infrastructure.

I don’t think anyone would argue that the web is “speedy” enough as it is, so exploring new concepts is something we need to do. We may find a thousand ways not to do it – and this may be one of those ‘not’ ways – but eventually someone will find a way.

Related blogs & articles:

Technorati Tags: MacVittie,F5,load balancing,SPDY,Google,MapReduce,parallelization,MBLB,message-based load balancing,architecture,infrastructure,application delivery,optimization,acceleration,security

Virtual Infrastructure in Cloud Computing Just Passes the Buck

Wed, 02 Dec 2009 11:45:00 EST

There are many good reasons to go down the virtual infrastructure road. The illusion that it’s cheaper than dedicated hardware solutions is not one of them.

I was reading an interesting predictive article on WAN optimization that contends that virtualized WAN optimization controllers (WOC) are, well, just better than sliced bread. One of the reasons why the author opined this way was presented as the great benefits of horizontal scalability (linear) in cloud computing environments.

Savings and scalability. This approach ensures that there is no need for dedicated hardware to support WAN optimization, saving on CAPEX and OPEX. Cost savings will also be realized through virtual scalability. As enterprises add more services or applications to be accessed by additional remote workers via the cloud, the virtualized WAN optimization model will be able to scale linearly.

The implication here is clear: WAN optimization via virtual solutions saves CAPEX and OPEX over dedicated hardware and additional savings are achieved through virtual scalability. But that’s ignoring that the initial investment cost is simply shifted from CAPEX to longer-term OPEX when scalability enters the picture. Not just scalability of the solution, but the impact of application and virtual infrastructure scalability on the solution as well.

VIRTUAL INFRASTRUCTURE is just PASSING the BUCK

Back in the old days we used to deploy all our infrastructure as software. As you needed more compute resources, you deployed bigger, beefier servers on which to deploy said solutions. That’s vertical scalability. Today we prefer the cloud computing model: horizontal scalability. Pay as you grow, compute resources on-demand. Whatever you want to call it the appeal is certainly in the perception that it’s easier and, perhaps more importantly, cheaper than traditional hardware-based scalability solutions. But it’s not accurate at all to equate this model with what is essentially “cheaper” scalability. The operational expenses associated with management, the cost of additional licenses, integration, and the hourly costs associated with the cloud computing environment in question all must be factored into the equation lest we fall prey to the hype that encircles cloud computing today.

One of the reasons you see cost savings in cloud computing is that the costs of the hardware – the physical servers – are shared. You only pay a “nominal” fee per hour for using that hardware. The cost of that hardware is shared across hundreds of other customers, all seeking the same reduction in operating and capital expenditures. So far, so good. Sharing the physical hardware certainly does spread the cost around and results in a cheaper operating environment – at least for the customer.

But when you start virtualizing the infrastructure (as in virtual software equivalents) you generally don’t get to share the costs of the solution and you never share the costs of management. Most of the time you just share the same costs you do for any other generic virtual image: the underlying physical hardware. You’re also forced to scale horizontally based on the capacity constraints inherent in the virtual image. The provider and/or solution vendor sets the RAM/compute resources available for the virtual instance and if you need more resources when you’ve reached the largest configuration you’ll have to start scaling horizontally. Whether you want to or not. The second image incurs the same management costs as well as the hourly fees. Likely, too, you’re paying for the licensing because virtual versions of solutions aren’t free, after all, unless you’re leveraging open source solutions that are.

You don’t share those costs with anyone. They are yours, and yours alone. The buck passes from CAPEX to OPEX. CAPEX is reduced, yes, but OPEX? Not so much. Perhaps that’s better from an accounting point of view, but from a total cost perspective it doesn’t really change much.

SCALABILITY of APPLICATIONS IMPACTS COSTS of VIRTUAL INFRASTRUCTURE

You can, of course, choose the largest image and thus avoid horizontal scalability. But that is going to increase the costs of the solution overall. Consider the virtual equivalent of an application delivery controller delivered via Amazon EC2 on its largest (quadruple large) image is $4.80 / hour (based on pricing listed by Zeus Technologies for its virtual solution on Amazon). It is unlikely you’ll have any hour in which that solution is not used. Assuming even one request handled per hour, every hour, every day you’re looking at more than $42000 per year. Don’t forget, too, you may likely have additional charges for bandwidth – both ingress and egress. Not nearly as “inexpensive” as purported. You could start smaller, but that means it’s more likely you’ll need to “upgrade” midstream. This is far easier to do with a virtual infrastructure than with hardware, at least from a physical deployment perspective, but it is just as disruptive a process and may lead to jumping onto the horizontal scalability path earlier rather than later because it is so easy to simply “add another instance” when compared to “upgrade to a new image.” Consider, too, that deploying virtual infrastructure means it is not integrated with the rest of the environment. That may not sound bad, until you realize that automatic scalability means new instances of applications – and perhaps other infrastructure solutions - may be popping up that you need to manage via the infrastructure. How is the infrastructure going to know about it? Either you are manually managing this process or you are going to be doing some integration work. That’s yet another soft-cost of “scalability” that isn’t factored into the equation when comparing hardware to virtual infrastructure.

Contrast that to a model in which services are provided via shared hardware infrastructure solutions. The cost of the hardware is not nominal. But like the rest of the physical infrastructure its costs are shared across all customers. Providing traditional network and application network solutions as services is inherently better suited to a cloud computing environment in that it allows the management costs to be shared (the provider manages the solution, not the customer) and is completely on-demand. Scalability is not the concern of the customer and generally speaking the limitations on RAM/compute resources do not exist in the same way they exist in virtual solutions. Bandwidth in both scenarios can be limited or unlimited, depending on requirements and implementation. Integration should also be taken care of by virtue of the fact that it’s a part of the cloud computing environment and the provider likely wants to ensure that they are billed properly for services rendered.

The current method of deploying a virtual infrastructure actually breaks the “shared resources, shared costs” model of cloud computing and negates the cost savings associated with the elimination of CAPEX for the hardware with the OPEX costs of management, integration, licensing, and a more constrained operating environment that ultimately leads to the need to scale out sooner than would otherwise be required. Certainly a shared model could be implemented via virtualized software solutions, but this model has the same implementation roadblocks as hardware solutions that lead to non-implementation today. Virtual infrastructure shifts many of the management and maintenance-related burdens offloaded by a public cloud computing model back onto the organization and requires more vigilance and dedication to ensuring the overall architecture is operating as expected.

VIRTUALIZED INFRASTRUCTURE is PROBABLY YOUR ONLY OPTION

Today, virtualized infrastructure may be the only option for an organization to obtain the control and choice that is currently lacking in today’s cloud computing environments. Deploying hardware solutions and associated services requires an investment on the part of the provider and additional time and investment in developing the means by which customers can take advantage of the solution via services. While most providers invest in hardware solutions without pause, they rarely take the next step in integrating its offerings as services for customers. This means that if you need specific infrastructure components – application acceleration, WAN optimization, web application security – that you’ll likely need to go the virtual infrastructure route. That’s not all bad; this path leads to control and isolation of implementation and configuration, which can be a requirement for conforming to organizational security policies. Organizations having concerns about the impact of other customers sharing infrastructure resources (they already do, but a service-based model brings this to the fore) will almost certainly want to take advantage of the isolation afforded by a virtualized infrastructure implementation.

I’m not arguing against virtual infrastructure in theory or against the control and choice they offer customers. There are challenges with such implementations, mind you, but that’s not really the point today. I’m simply arguing against the “it’s cheaper” mantra that is patently false and fails to take into consideration all the variables in the equation and instead focuses only on the most tangible ones.

There are certainly benefits realized from both deployment models and it is up to the organization to decide which model is right for them. But don’t fall into the trap of thinking virtual infrastructure is a “cheaper” solution, because when you step back and take a look at the entire cost of a solution, that’s just not the case and in fact a services-enabled infrastructure may be a much more financially advantageous solution – except for the provider.

Which may be the real reason the only option you ever have is a virtual one.

Related blogs & articles:

Technorati Tags: MacVittie,F5,WAN,WAN optimization,WOC,cloud computing,virtual infrastructure,virtualization,capex,opex

While I am AFK…

Wed, 25 Nov 2009 11:53:00 EST

With any luck I am already AFK for a visit with Don’s mother and his family for Thanksgiving. And I’m really (really, I swear) going to be AFK (away from keyboard) for the entire time.

Really. I’m serious this time, stop looking at me like that. Ever heard of “pre-publishing?”

So while I’m out, you might need something to read. And if so, you might want something you can read two or three times because, well, it was that entertaining.

If that’s the case, I highly recommend you give “BSOFH: Catering to a niche market.” a read. Or two.

And have a wonderful Thanksgiving. See you next week!

Disclaimer: If you are enjoying a beverage please put it down before visiting this link. I am not responsible for keyboards or screens damaged by the involuntary loss of beverage-type fluids due to uncontrollable laughter.

Technorati Tags: MacVittie,F5,humor,Layer 8,AFK,Thankgiving,holiday,cloud,security

WILS: Client IP or Not Client IP, SNAT Is the Question

Wed, 25 Nov 2009 10:15:00 EST

Ever wonder why requests coming through proxy-based solutions, particularly load balancers, end up with an IP address other than the real client? It’s not just a network administrator having fun at your expense. SNAT is the question – and the answer.

SNAT is the common abbreviation for Secure NAT, so-called because the configured address will not accept inbound connections and is, therefore, supposed to be secure. It is also sometimes (more accurately in the opinion of many) referred to as Source NAT, however, because it acts on source IP address instead of the destination IP address as is the case for NAT usage.

In load balancing scenarios SNAT is used to change the source IP of incoming requests to that of the Load balancer. Now you’re probably thinking this is the reason we end up having to jump through hoops like X-FORWARDED-FOR to get the real client IP address and you’d be right. But the use of SNAT for this purpose isn’t intentionally malevolent. Really. In most cases it’s used to force the return path for responses through the load balancer, which is important when network routing from the server (virtual or physical) to the client would bypass the load balancer. This is often true because servers need a way to access the Internet for various reasons including automated updates and when the application hosted on the server needs to call out to a third-party application, such as integrating with a Web 2.0 site via an API call. In these situations it is desirable for the server to bypass the load balancer because the traffic is initiated by the server, and is not usually being managed by the load balancer.

In the case of a request coming from a client the response needs to return through the load balancer because incoming requests are usually destination NAT’d in most load balancing configurations, so the traffic has to traverse the same path, in reverse, in order to undo that translation and ensure the response is delivered to the client.

Most land balancing solutions offer the ability to specify, on a per-IP address basis, the SNAT mappings as well as providing an “auto map” feature which uses the IP addresses assigned to load balancer (often called “self-ip” addresses) to perform the SNAT mappings. Advanced load balancers have additional methods of assigning SNAT mappings including assigning a “pool” of addresses to a virtual (network) server to be used automatically as well as intelligent SNAT capabilities that allow the use of network-side scripting to manipulate on a case-by-case basis the SNAT mappings. Most configurations can comfortably use the auto map feature to manage SNAT, by far the least complex of the available configurations.

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.

Related blogs & articles:

Technorati Tags: MacVittie,F5,application delivery,load balancing,SNAT,NAT,load balancer,X-FORWARDED-FOR,IP,routing,WILS

To Take Advantage of Cloud Computing You Must Unlearn, Luke

Wed, 25 Nov 2009 04:15:00 EST

One of the benefits of cloud computing is supposed to be efficiency, particularly in the utilization of compute resources. Over-provisioning of compute resources has long been one way in which IT combats the need for scalability and availability of applications but this often leaves a large percentage of compute resources unused. The utilization rule once employed as a means to ensure availability and performance of applications, i.e. no device or server should utilize more than X% of its resources at any time, is no longer acceptable as it wastes resources which in turn eats away at the bottom line.

The Application Delivery Spell Book

Tue, 24 Nov 2009 12:30:00 EST

Detect Invisible (Application) Stalkers

School of Magic: Abjuration (Protective Spells)

Components: Somatic (requires gestures), Material (requires physical component)

Casting Time: special

Range: Layers 3-7

Area: global

Duration: Until discharged

Saving Throw: Special

Spell Resistance: No

Invisible (application) stalkers are creatures native to the Internet. They sometimes serve miscreants, corporate spies, and script kiddies, who summon them to perform attacks against specific targets. A summoned invisible stalker undertakes the form of a legitimate application request, pretending to be a real user, and will tirelessly undertake whatever task the caster commands, even if the task sends packets hundreds or thousands of miles away. The creature follows a command until the task is completed and obeys only the caster.

Invisible (application) stalkers operate only at layer 7 and eschew the use of forms commonly recognized as being of evil intent. Thus an invoke firewall log spell will show only multiple requests over time from similar agents, and intrusion detection spells have no effect on the creatures. Only a detect invisible (application) stalker spell can recognize and subsequently dismiss these agents of evil.

This spell inserts into the path of the invisible (application) stalker a wall which cannot be avoided, blocking them or reporting to the caster their proximity, as determined by the caster. The material component for this spell is a web application firewall, which must be placed between the invisible (application) stalker and its intended target. The somatic component requires the caster to complete a series of mouse clicks and keyboard strokes that deploy an application security policy including the ability to prevent web scraping. The casting time for this spell varies based on the complexity of the existing environment, and how many victims are being targeted by the invisible (application) stalkers.

Once completed, the spell will last until the caster discharges it by disabling the policy created by the somatic gestures.

The invisible (application) stalker may attempt a saving throw (Will) to realize it is being blocked. If it makes the save, it may attempt to figure out how the wall is blocking it. It must then make a second Will save or discorporate immediately. If the spell is cast as a reporting only mechanism, there is no saving throw allowed and the invisible (application) stalker will never be aware it has been detected.

THE FIRST STEP IN ANY SOLUTION IS ALWAYS RECOGNIZING THERE IS A PROBLEM

There are a few attacks today that just can’t be detected by applications. Layer 7 DoS can’t be detected from within an application because the code that executes does so in the context of a single request and a DoS implies many requests from many sources. The only way for a developer to detect this attack is to be able to view the single request that is typical of an application in the context of all requests across all instances of the application – even across machines – and that’s simply not possible from within the application.

Similarly, web scraping attacks are nearly impossible for a developer to detect because there is nothing in the request that would indicate anything is out of the ordinary. Nothing. No special code, no special characters, no odd manifestations within the headers or network data. In order for the developer to detect such an attack s/he would need to be able to determine whether the client is manned by a human being or is a script/bot. And no, using User-Agent headers isn’t going to work on this one because miscreants have figured out that too many security devices are able to block their attacks based on that value and thus have learned to circumvent it by scripting real browsers or manipulating the HTTP headers such that their bots/scripts appear to be valid user-driven browsers.

But that’s what a web application firewall (WAF) was designed to do: to watch, to evaluate requests in context, across all instances and all requests. It has the visibility, it has the capability, and it can detect attacks that are not easily if at all detected from within the application. Even if the WAF isn’t blocking the attacks, it can at least tell you they are happening, which is something the developers need to know if they’re going to put in place solutions to prevent them.

“Security manager, ‘J.F. Rice,’ whose name and employer have been disguised for obvious reasons” explains his need to “see” inside connections and understand what is happening in his environment.

We’ve been blind to attacks on our Web sites

I installed a Web application firewall in my company's DMZ to tell us about active attacks that may not be identified by our other devices. I set the device up in monitor mode, though it can be set up to block attacks, because my goal was just to see what was going on. I wanted to know more about what's inside the connections to those Web servers.

What I discovered is that our Web sites are being "scraped" by other companies -- our competitors! Some of the information on our sites is valuable intellectual property. It is provided online, in a restricted manner (passwords and such), to our customers. Such restrictions aren't very difficult to overcome for the Web crawlers that our competitors are using, because webmasters usually don't know much about security. They make a token attempt to put passwords and restrictions on sensitive files, but they often don't do a very good job.

Web application security requires visibility as well as the expected defensive capabilities. A web application firewall can provide both capabilities even though you may not leverage both at the same time or at all. Using a WAF as a mechanism to determine what kind of attacks are being directed at your web applications is just as valuable a proposition as enabling its preventative capabilities.

Either way, knowing is the first step to moving forward on a strategy to address it.

Related blogs & articles:

Technorati Tags: MacVittie,F5,web application security,security,web 2.0,web scraping,ASM,web application firewall,WAF,D&D,ADSB

Scaling Security in the Cloud: Just Hit the Reset Button

Tue, 24 Nov 2009 11:15:00 EST

Today Security administrators deal with 10’s, 100’s, even 1000’s of servers but what happens when potentially tens of thousands of VM’s get spun up and they are not the same as they were an hour ago. Security assessments like Tripwire, while work, inject load and what if those servers are only up for 30 minutes? How can you be sure what was up and offering content was secure? One idea he offered was to have servers only live for 30 minutes then drop it and replace. If someone did compromise the unit, they’d only have a few moments to do anything and then it’s wiped. You can keep the logs but just replace the instance. Or, use an Open Source equivalent every other time you load, so crooks can’t get a good feel for baseline system.

WARNING: Security Device Enclosed

Thu, 19 Nov 2009 16:00:00 EST

How many times have you seen an employee wave on by a customer when the “security device enclosed” in some item – be it DVD, CD, or clothing – sets off the alarm at the doors? Just a few weeks ago I heard one young lady explain the alarm away with “it must have be the CD I bought at the last place I was at…” This apparently satisfied the young man at the doors who nodded and turned back to whatever he’d been doing.

Google SPDY Protocol Would Require Mass Change in Infrastructure

Wed, 18 Nov 2009 09:15:00 EST

Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across networks to support

ArsTechnica had an interesting article on one of Google’s latest projects, a new web protocol designed to replace HTTP called SPDY.

SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.

Having recently emerged from a trip into the world of service-providers and its associated protocols, the description of SPDY immediately brought to mind other asynchronous, message-oriented protocols such as SIP and DIAMETER. It therefore made me seriously consider the kind of massive changes that would be required to support such a protocol across all data center components: security, load balancing, acceleration, web servers, application servers, caches. Basically any network intermediary based on the premise of a strict request-reply, synchronous behavior would likely need radical changes to its core protocol handling systems.

MAJOR DIFFERENCES BETWEEN SPDY and HTTP

SPDY, as described, is asynchronous and message-oriented. Like DIAMETER, SPDY would allow multiple requests per connection, effectively turning a single connection designed to be used and then closed into a long-lived connection. This is more along the lines of a SIP connection which is initiated and held open until the session is terminated.This is very different from the HTTP model in which connections are opened and closed within fairly short time intervals and are not expected to be held open for exceedingly long periods of time. SPDY thus eliminates the overhead associated with opening and closing many connections and the negative impact that has on application performance.

The current draft of the SPDY protocol states that “from the perspective of the server business logic or application API, nothing has changed”. But from the perspective of the infrastructure that needs to process the protocol, everything changes.

KEY CHANGES TO HTTP HEADERS

The following are directly from the draft of the SPDY protocol and document the changes from HTTP to SPDY

REQUEST CHANGES

The first line of the request is unfolded into name/value pairs like other HTTP headers. The names of the first line fields are method, url, and version. These keys are required to be present. The 'url' is the fully-qualified URL, containing protocol, host, port, and path.
HTTP request headers are compressed. This is accomplished by compressing all data sent by the client with gzip encoding.
Content-length is not a valid header.
Chunked encoding is no longer valid.

RESPONSE CHANGES

The response status line is unfolded into name/value pairs like other HTTP headers. The names of the status line are status and version. These keys are required to be present
Content-length is no longer valid.
Chunked encoding is no longer valid.

These changes would have a huge impact on infrastructure solutions, many of which rely on URI or HTTP headers (custom and standardized) to perform specific actions such as blocking, scanning, persistence (server affinity), or routing. The requirement that SPDY be transported via SSL has its own, well understood impact on infrastructure and is already dealt with by most devices, but SPDY also requires that headers are compressed via gzip. This means every intermediary requiring to perform some action based on the headers will need to decompress, process, and then likely recompress the headers before sending it on to the next hop. Coupling required compression with SSL would not only require support on all relevant infrastructure but will also likely reintroduce latency that could offset some of the performance gains claimed by testing of SPDY thus far.

SINGLE-CONNECTION: LONG LIVED SESSIONS

That all communication would essentially flow between the client and server over a single connection also poses a challenge for intermediaries that perform any kind of analysis or are required to act on the data exchanged. Load balancers, for example, are not generally designed to handle switching of messages in what becomes a 1:N connection:server scenario. The protocol could likely be supported as is by most load balancing solutions on a strictly layer 4 load balancing basis but advanced features that take advantage of application-aware capabilities such as message header and payload value routing (content-based routing) as well as egress functionality like Data Leak Prevention (DLP) would be much more difficult to implement, if not impossible for some solutions. This capability actually sounds a lot like HTTP pipelining on the request side.

The single, long-lived connection would have more of an impact on the overall architecture and capacity planning. In some respects it would be easier, as there would be an easy 1:1 ratio between users and connections. But because each user is effectively being handed dedicated compute resources, this would actually change the resource consumption model on servers and make it more difficult to support high volumes of users without building out a scalable infrastructure.

ASYNCHRONOUS EXCHANGE OF MESSAGES

Further complicating the ability of infrastructure solutions to handle SPDY is its definition as asynchronous. Essentially asynchronous protocols do not enforce order of replies. That means a client could send three requests in a row without waiting for a response and the server could send back the response in a completely different order. Again, from the draft SPDY protocol:

Because TCP provides a single stream of data on which SPDY multiplexes multiple logical streams, it is important for clients and servers to interleave data messages for concurrent sessions.

This may not sound like a problem, but for infrastructure that is optimized to handle HTTP and has been built around its implicit behavior this would require changes to the core networking stacks on most devices. In a typical HTTP scenario a request is received, the infrastructure solution processes any applicable ingress policies, and then initiates a connection to the appropriate server and waits for a response. It appears that with SPDY, like DIAMETER, the infrastructure still processes any applicable ingress policies and initiates a connection but does not necessarily wait for a reply as it might need to act upon the next incoming message.

This means a single network “session” would need to carefully track multiple incoming requests and outgoing responses at the same time on a per connection basis. This is not something most infrastructure is typically prepared to handle. Combined with the possibility that different requests may need to be routed to different servers within the infrastructure, this complicates the nature of application delivery and load balancing and could have a huge impact on the costs associated with cloud computing. Long lived sessions/connections initiated on secondary or tertiary servers launched to handle temporary capacity increases could hold open those connections long enough to incur excess charges that are unnecessary.

Also similar to DIAMETER is the inclusion of a “real server push” feature. The ability of a server to act like a client and vice-versa is inherent in DIAMETER and this reverse flow of traffic is not something most infrastructure is prepared to process.

THE IMPACT ON INFRASTRUCTURE

Any infrastructure solution that is heavily focused on application layer (HTTP) processing for any purpose would likely need to make radical changes to its core networking and processing engines. Some solutions, particularly those tasked with load balancing and scaling existing message-based protocols may already be capable of supporting a protocol like SPDY. Whether the solutions that support DIAMETER and SIP load balancing and scalability could support SPDY without modification is highly dependent on whether support for the service-provider focused protocols is based on an underlying generic message-based implementation [PDF] or a protocol-specific implementation. The latter would be difficult to adapt to a new protocol while the former would be more easily extended to specifically support the requirements of new message-oriented protocols.

But that’s only load balancing and scalability. There are many other infrastructure devices that are used to secure, monitor, accelerate, and otherwise manage HTTP that would need to be updated to handle such a new protocol. The upheaval across data centers would likely be on par with the anticipated challenges associated with mass migration from IPv4 to IPv6. Like that migration, however, support for both SPDY and HTTP could be achieved through the use of translating gateways; infrastructure capable of supporting both SPDY and HTTP or able to translate between the two could be utilized to enable a smoother transition.

While it’s a fascinating and exciting notion, the introduction of a completely new protocol to replace HTTP seems more academic than realistic. More realistic would be for gradual implementation through adaptation of SPDY’s core concepts into the next generations of HTTP until HTTP is indistinguishably from a protocol such as SPDY. Making modifications and improvements to HTTP would be an evolutionary step rather than the revolutionary change implied with SPDY that would be almost too disruptive to adopt.

That said, not everything that comes out of Google Labs is adopted as an industry wide solution. It’s an experimental environment and a good one at that. What may come out of the SPDY project may well in fact be changes to HTTP rather than the presentation of a new, radically different protocol. Regardless, SDPY and Google’s efforts have people talking about what’s wrong with HTTP and how it might be fixed and that conversation is one we’ve probably needed to have for quite some time now.

You can read more about the tools Google offers and general problems with web performance at Google’s “Let’s Make the Web Faster” site.

Related blogs & articles:

Technorati Tags: MacVittie,F5,Google,SPDY,HTTP,infrastructure,DIAMETER,protocols,web,internet,IPv4,IPv6,acceleration,security,load balancing,application delivery,application security,architecture

It’s DNSSEC Not DNSSUX

Wed, 18 Nov 2009 06:44:27 EST

Whenever keys, certificates, and PKI enter into a security solution’s architecture the solution almost always becomes overly complex. DNSSEC is no exception, but it doesn’t have to be.

DNS plays a role in every application on the Internet. It is the 411 of the Internet, essentially, without which the millions of users that don’t memorize the IP addresses associated with domain names would be utterly lost. But DNS is vulnerable to exploitation and has, in fact, been exploited in the past. Like any core infrastructure upon which we depend to conduct business, communicate, and generally entertain ourselves, it needs to be protected. DNSSEC (DNS Security Extensions) is a protocol and management extension to DNS designed to guarantee the authenticity of responses. Its basic theory is sound, but putting into practice can quickly turn DNSSEC into DNSSUX, at least for DNS administrators.

It should be no surprise, then, that the difficulties inherent in such an effort are causing delays in implementation. VeriSign, for example, mentions the “size” of the zone as a reason the top level domains (TLD) are taking so long to adopt DNSSEC:

"VeriSign is moving forward with the implementation of DNSSEC across all of the Top Level Domains that we operate," VeriSign said in a statement to Network World. ".com will most likely be the last TLD to adopt DNSSEC due to the size of the zone. We anticipate full implementation of DNSSEC to be complete across all TLDs in approximately 24 months."

Given the complexity and requirements involved in a DNSSEC deployment, that’s actually no surprise.

WHAT’S SO DIFFICULT ABOUT DNSSEC?

The premise behind DNSSEC is that responses to DNS queries need to be trustable. Following the example of web-based applications, DNSSEC applies the principle of signatures via public/private key encryption as a means to achieve that trust. Essentially DNSSEC is the wrapping of the DNS infrastructure within a trusted, PKI-based superstructure that validates through certificates managed records (zones).

Deploying DNSSEC involves signing zones with public/private key encryption and returning DNS responses with signatures (new RRSIG resource record). A client's trust of those signatures is based on a chain of trust established across administrative boundaries, from parent to child zone, using new DNSKEY and DS resource records. DNSSEC also calls for "authenticated denial of existence" via NSEC (and/or NSEC3) records. And complicating the deployment is the requirement that any DNSSEC deployment must manage cryptographic keys: multiple key generation, zone signing, key swapping, key rollover and timing, and recovering from compromised keys.

Currently BIND, the most common implementation of DNS, supports DNSSEC. There are solutions that combine BIND clones with DNSSEC signing devices that sit beside the DNS infrastructure. So far there doesn't seem to be an implementation that simultaneously achieves ease of deployment, scalability, and high performance.

What’s needed is a way to reduce the complexity and the costs associated with layering this PKI infrastructure atop - or alongside - the existing DNS infrastructure while ensuring that DNSSEC is properly implemented and supported.

WE BORROWED FROM WEB APPLICATIONS FOR THE FIRST SOLUTION, WHY NOT THE SECOND?

These very same problems have been, and continue to be, felt by administrators of web applications that need to implement secure communications via HTTPS. The best answer to managing SSL implementations is to centralize them; essentially implementing a proxy-based approach to securing all web applications simultaneously using a common SSL implementation. Load balancers and later application delivery controllers have been providing this capability for years and it is practically commoditized at this point. We call it “table stakes” in product management because it’s one of the features you must support in application delivery to even get a seat at a potential customer’s table.

So why aren’t we applying that same logic to the problem of deploying and managing DNS, especially large scale DNS implementations?

Turns out that we are. But I’m guessing you knew that was coming, didn’t you?

A DNSSEC-enabled global server load balancer (GSLB) can support both a centralized, proxy-style DNSSEC implementation or it can be deployed as a stand-alone, DNSSEC-enabled DNS server a la BIND. The difference between a stand-alone deployment of a DNSSEC-enabled GSLB and a BIND + DNSSEC signing solution deployment is that the former integrates DNS and DNSSEC capabilities and does not require separate solutions to provide a workable solution. Even if you aren’t using GSLB to provide load balancing across multiple datacenters or cloud computing environments (a la cloud balancing), you can still take advantage of a DNSSEC-enabled GSLB to basically “proxy” DNS queries and centralize signing of responses through a single, centralized solution.

DNSSEC doesn’t have to be DNSSUX.

Related blogs & articles:

Technorati Tags: MacVittie,F5,DNSSEC,DNS,security,GLSB,BIND,PKI,infrastructure,unified application delivery and data services,web,internet,protocol

Data as a Service Could Drastically Impact Success of SQL Injection Attacks

Tue, 17 Nov 2009 00:00:00 EST

The question is whether that impact is positive (a reduction) or negative (an increase).

One of the biggest threats to data integrity is the introduction of malicious content via SQLi (SQL Injection) attacks. Traditional database access methods don’t provide a lot in the way of validating requests and like HTML the vagaries of SQL allow for myriad ways in which a statement can be constructed – and thus exploited.

These vagaries, of course, are one factor in the reason why SQLi continues to plague applications and sites driven by user generated content. Another factor is certainly the number of touch points in application code where attacks might slip through. With every new SQLi technique comes the need to update every one of those touch points and ensure they can properly defend against the new variation or technique.

But service enabling data sources changes the point of entry. It centralizes access down to a single point of contact.

Joe McKendrick notes in a recent blog on a related topic (data quality and SOA):

Ash [Informatica’s Ash Parikh], who has been warning the industry about the quality of data — or lack thereof — surging through SOA-based infrastructures for some time now, says SOA data services open up many new avenues for connecting SOA with enterprise data management. “It’s much more than just data access,” he points out. “It’s making sure the data that is delivered is of the greatest quality.” [emphasis added]

If we expand “quality” to include “clean, untainted, and free of malicious content” then we’re pretty much on the same page.

SECURITY AND TRADITIONAL DATA ACCESS MODELS

Using traditional methods of database access (JDBC/ODBC/ADO.NET/PHP ADAPTERS) every time a developer wants to access the database they must:

1. Obtain a connection to the database

2. Construct the appropriate query

3. Execute the query

One assumes, of course, that prior to constructing the query that any user-supplied input is validated and any potentially malicious content either stripped or outright rejected.

Most web applications today are data-driven, meaning they require a database in which to store and retrieve content. These applications – and that includes blogs, content management systems, news sites, and social networking sites – may contain multiple queries on every page, meaning there are multiple points at which malicious content may be introduced into the system. Add-on the possibility of an API through which content may be added and you’ve increased again the number of potential “holes” through which an SQLi attack might be executed.

Service-enablement, on the other hand, effectively reduces the number of potential entry points through which an attack may occur. It reduces the attack surface.

In a service-enabled database access scenario, the applications still make the same number of “connections” because each query is designed to perform a specific task , but instead of those queries going directly to the database they are actually made to a service interface instead. It is the service interface that then handles database connections, constructs the query, and executes the query on behalf of the client application.

There are two possible security outcomes to this scenario.

1. Overall security is improved. Because there are fewer interfaces to secure the process of validating and further detecting potentially malicious code will be more thorough. Reducing the number of places in which these checks must occur also reduces the potential to “miss” a touch point when implementing security processes. Protection against SQLi is shared by all applications, so if security at the interface is properly implemented it will be beneficial to all applications using the service.

2. Overall security is degraded. Because the data access service interfaces are shared across all applications, any vulnerabilities are shared by all services utilizing the interfaces. It is also possible that the use of service-enabled interfaces may introduce additional avenues of attack. Service-enablement via SOAP/HTTP brings with it all the security vulnerabilities associated with XML and SOAP. Service interfaces are also publicly accessible, so authentication and authorization are paramount to successfully securing such implementations. Weak or easily breakable authentication schemes can lead to compromise. If the services are publicly accessible this could be an even higher concern.

ENSURING THE BEST POSSIBLE OUTCOME

It certainly appears at first glance that perhaps the possibility of a negative outcome – because of the impact to multiple applications –outweighs the potential benefits of improving security. But the change in architecture affords the opportunity to provide additional security around the service (as well as scaling benefits that are not typically associated with databases) than can tip the scales of benefits versus risk to the side of improving security.

A reduction in the number of entry points at which SQL queries are constructed from user input increase the resources that can be applied to the security of those interfaces. Fewer entry points affords a tighter focus on applying secure coding practices against the OWASP Top Ten. Testing against vulnerabilities, too, becomes easier and potentially more thorough.
Adding a data service layer, usually enabled by HTTP, enables the leverage of existing technology to secure the messages and protocols between the application server and the data services. A web application firewall can provide additional security scans on the services in real time as well as provides protection against (un)intentional denial of service attacks against the service. XML-related capabilities in WAF solutions can also address the potential introduction of XML specific vulnerabilities to the architecture, as well as offering support for authentication and authorization and encryption/signing of requests.
Moving data services to its own tier separates the tiers more completely and provides better agility for development. If a new vulnerability is discovered, for example, it need only be addressed in a limited, well-known set of services rather than across all applications that may be vulnerable. This can reduce the time to fix vulnerabilities or add new functionality to the data tier.

Service-enabling data sources is an architectural change that should not be executed upon lightly. It affects all other applications that rely on the data source, and introduces another layer into the architecture that may or may not make it more complex. Moving to such an architecture can be beneficial and can drastically improve security and decrease the likelihood of a successful SQLi attack. But if not entered into with the proper motivation to ensure the services are secured, tested, and protected against other security vulnerabilities it is possible that such an architecture could degrade your overall security posture and make it more likely that an attack will succeed.

Careful consideration regarding the dedication of resources and testing of data services is required before embarking on such an initiative. Collaboration between architecture, network, and development teams is required to design the service and its supporting application infrastructure in such a way as to ensure the change is a net positive for the entire organization.

Related blogs & articles:

Technorati Tags: MacVittie,F5,application security,security,SOA,services,tiers,architecture,web application security,OWASP,database security,web

Cloud, Standards, and Pants

Fri, 13 Nov 2009 14:30:00 EST

These three things have a lot more in common than you might think and all three tend to evoke similar levels of frustration.

A very real problem women face when shopping is this: no two brands define a size the same. If you usually wear a size 8 in “Brand X” you might actually wear a size 10 or 6 in “Brand Y”, depending on how the brand decided to define its sizing. Customers, women in this case, cannot count on consistency in sizes across brands. This makes shopping annoying because every time you change brands you’re never quite sure what you need and if the size increases across brands, well, it becomes obvious that perhaps brand lock-in is in part the reasoning behind these differences in sizing.

Now, consider the differences in the definition of “The Cloud”. We have IaaS (Infrastructure as a Service). We have PaaS (Platform as a Service). We have SaaS (Software as a Service). All three have very different definitions of what makes it “a cloud” and there is very little consistency across those definitions. Oh, there are vague similarities: elasticity, automation, easy provisioning. But those are nebulous terms that are about as useful as slapping a “Size 8” on a pair of jeans and expecting a woman to know what that means. She doesn’t, and neither does the consumer of “cloud.”

Dig into “cloud computing” and “intercloud” and standards efforts and you’ll see this is true at the infrastructure layer, as well. The challenge of defining standards around intercloud computing and cloudbalancing and just collaboration within a single cloud computing environment is made infinitely more challenging because infrastructure Vendor X “size 8” doesn’t match up with Vendor Y “size 8.” Features, naming, resource models, capabilities – all different. Yet all must be able to communicate and collaborate to not only provide the basic foundation for a cloud computing environment, but to be able to migrate from one provider to another.

API versus RESOURCE MODEL

This is what’s going to make defining standards more challenging than ever: we’ve got to not only standardize protocols but common industry and market definitions as well. The former will likely turn out to be much easier than the latter because it’s more abstract; it’s about management and control without regard to implementation. It is the resource model that will be difficult to nail down.

William Vambenepe writes in Separating model from protocol in Cloud APIs:

Things become a lot more sensitive when you touch the resource model, which reflects the actual capabilities of the Cloud management infrastructure. How much flexibility in the network setup? What kind of application provisioning? What affinity/anti-affinity control level? Can I get block-level storage? Etc. Having to implement the other guy’s interface in these matters is not just a matter of glue code, it’s a major product feature. As a result, the resource model is a much more strategic control point than the protocol.

William nails the problem with his assessment of the differences between the resource model and protocols. Given his obviously intimate knowledge of web services standards and thus SOA, this is no surprise. One of the core tenets of SOA is the separation of these two very different but very vital components. The interface should be separate from the implementation. In InterCloud, we must separate resource model (data protocol implementation) from interface (command and control protocol) in order to achieve standardization.

Interestingly enough at the last Infrastructure 2.0 Working Group, which is focusing on this problem, Vint Cerf mentioned out of hand that the separation of IP from routing “in the beginning” was actually accidental. If you read the IP RFC you’ll note that it ends up being just a “resource model”; it describes the format of information being exchanged and mentions how packets should flow across internetworks, but it defines no API-style protocol for doing so. It offers only minimal guidance on the higher level interfaces that might be used to transmit and receive Internet Datagrams. That accidental omission turned out to be the best thing since sliced bread. Routing protocols have come and gone since then, but IP remains at the heart of the Internet. Basically we need to duplicate that, but at a higher layer in the stack.

Any InterCloud protocol will almost certainly be easier to develop than the resource model. While there already exists some commonality across components and concepts in the infrastructure, still there are many more resources for which every vendor has their own definition. It is that disparity that needs to be addressed independently and codified in a common set of resource models that at the same time allows for extensibility on a per vendor basis to account for uncommon resources.

This is no easy task. Consider a very simple example – persistence in load balancing solutions. Persistence is a commonly implemented feature in all load balancers that can be achieved in a number of ways. Among the most common are: source IP, destination IP, Cookie, and SSL session ID. Now take a look at the difference in definition of these - from a purely naming standpoint – between Citrix Netscaler and F5 BIG-IP:

Citrix Netscaler XML API “Size 8”	F5 BIG-IP iControl “Size 8”

Looking at both implementations – and remember this is just naming – you’ll notice that the most common methods of persistence exist in both solutions, but use very different naming conventions. Netscaler defines source IP-based persistence as “SOURCEIP” while F5 uses “PERSISTENCE_MODE_SOURCE_ADDRESS_AFFINITY”; same concept, different terminology. Once you get beyond the common methods you find even more disparity and it becomes more difficult to map between the two without a firm foundation of knowledge of both systems. For example, is the Citrix “CALLID” the same as the “PERSISTENCE_MODE_SIP” definition? Perhaps they are, perhaps they aren’t. You can imagine that at the operation level, the API, the naming conventions used there are so drastically difference that attempting to map the two would drive even the most experienced integration developer a bit insane.

STANDARDS TAKE TIME

Just as cloud computing providers continue to roll out new services over time, behaving in a manner similar to Web 2.0 applications that never quite come out of beta, so, too, will the standards of InterCloud need to evolve. It’s going to take a lot of comparisons, discussions, and mappings to figure out what is an acceptable common resource model for each infrastructure component and in the process we’re going to have to abstract quite a bit. Less challenging will be the need for a common namespace for this resource model across all infrastructure components. After all, an IP address is the same whether it’s used by a virtual machine, an IPS, a load balancer, or a firewall. But these are easier to discover and define than elements unique to a particular solution space and once we get the ball rolling one can hope that the momentum keeps it rolling.

The Internet wasn’t built in a day – really, it took the ‘founding fathers’ quite a bit of discussion and hard work to get the standards defined that allowed mass interoperability and collaboration. But I am willing to bet that we’ll see InterCloud standards long before the fashion industry decides to standardize its sizing for women.

Long before then, I’m sure.

Technorati Tags: MacVittie,F5,cloud,cloud computing,resource model,API,integration,standards,InterCloud,infrastructure 2.0,William Vambenepe,SOA,Web 2.0

Related bogs & articles:

Is Vendor Lock-In Really a Bad Thing?

Fri, 13 Nov 2009 10:30:00 EST

When you look at the success of some very proprietary solutions and the loyalty with which customers defend them, you have to wonder if vendor lock-in is really as bad a thing as we sometimes make it sound.

The subtext in the discussions around data portability and interoperability in general in cloud computing is really about vendor lock-in. Those driving efforts to come up with solutions that allow customers to pack up their data and head to another provider are primarily concerned about the dangers of being locked-in to a single vendor solution.

But given the loyalty to some brands and products that are unapologetically proprietary and inherently create a vendor lock-in situation, one has to wonder whether vendor lock-in is really a bad thing and if it is, for whom?

Take the iPhone. Really, you can take it because I don’t have one and don’t want one. But millions of people do and they are incredibly loyal to this proprietary device. Apple does not apologize at all for its business practices that support a locked-in user base, and it is unlikely that consumers even consider this to be a negative when purchasing an iPhone. Indeed, the proprietary nature of the iPhone is not what keeps me from purchasing one.

After all, it does what it does and it does it incredibly well, with an ease that makes it usable by just about anyone. What’s to complain about? Yes, your data is locked up inside the iPhone, you aren’t going to pack it up and take it to a Blackberry or the next big thing. But users don’t seem to care and certainly don’t even consider that they might one day want to change. They’re in love with their iPhone, loyal as hell, and don’t really care.

THAT’S CONSUMER-SIDE, IT IS DIFFERENT

Is it really that different on the IT side of things? The same loyalty that drives absolute obsession with iPhones is present in IT. How many times have you heard we’re a vendor-X shop? Did you stop to consider why they were a vendor-X shop and why they didn’t seem concerned that they might be locked-in to that vendor with no easy way to migrate to a new vendor’s product?

It isn’t just loyalty, it isn’t ignorance of options. Explaining all the benefits of some other product isn’t necessarily going to win the day there. Folks are loyal to a product because it (a) does what it says it does, (b) solves all their problems and (c) the company isn’t going anywhere.

It’s only when one of these is violated that you begin to hear rumblings of anger from the basement of IT. If a product can’t do something or doesn’t do it to the satisfaction of customers, then they get angry. But as long as all three conditions are met, generally speaking, IT has no good reason to migrate to another solution. They don’t seem to care that they’re locked in to the solution because it’s solving their problems. As long as the vendor appears stable and has long-term viability, it isn’t really a problem, is it?

IF IT’S NOT BROKE, DON’T FIX IT

The increasingly complex nature of data center architectures makes a migration from one product to another difficult and painful regardless of the level of “lock-in” . As with applications, the more integrated an infrastructure solution is into the architecture and business processes, the less likely it is to be replaced. If it isn’t broke, don’t fix it is probably a truism in IT more than any place else today.

Increasingly organizations do appear to be looking more closely at the possibility of vendor lock-in with any given solution, even open-source solutions that may result in vendor lock-in because of the commercialization of support by a single vendor. Cloud computing is no exception, by the way, as indicated by a CIO.com survey focused on cloud computing issues:

That's according to a new CIO.com survey of 240 IT professionals involved in technology-purchasing decisions. The June 2009 survey, "CIO On-Demand Services Survey," reveals that cloud computing fears regarding security, data management, total cost of ownership, regulatory and compliance issues, and vendor lock-in have actually increased as compared with results from a similar survey in August 2008.

The thing is you rarely see an organization worrying about vendor lock-in where standards exist to ensure the interoperability and portability. If not of the configuration and/or meta-data required, at least of the interoperation with other IT systems. Take switches and routers, for example. All utilize standards like IP and even though the configuration of a Cisco switch is very different from an HP ProCurve switch, you rarely see anyone getting up in arms about being “locked in” to the configuration specifics of either option. The most important part of choosing most infrastructure solutions, it would appear, is that there is internal standardization on a given platform. If all the switches in the organization come from one vendor, it makes management just that much easier. Sure, a forklift upgrade from one switch vendor to another may be painful in terms of the configuration necessary to achieve such a migration, but still that doesn’t seem to engender “vendor lock-in” fears. IT isn’t agonizing over the decision, paralyzed with fear. We geeks fear change, but not that much.

There are no standards around configuration, just protocol support. The maangement scripts used to automate tasks or integrate the CLI with the rest of the infrastructure and management systems (Sonoa Systems’ CEO Chet Kapoor has a great example of this kind of “lock-in” in his post “The API is more than the new CLI”) developed for switch Brand X are very unlikely to work with Brand Y. If we look at more complex solutions up the infrastructure stack, we find more and more customization available and, unforutnately, that flexibility comes with a price: with each customization it becomes more and more difficult to extricate that solution without a great deal of effort from the infrastructure.

But without that customization what do you have? You have a turnkey solution that may suit your needs today, but not tomorrow. And when tomorrow rolls around you’re left with the option of (a) solving a new problem with a new product, adding to the overall management burden and costs to maintain or (b) forklift replacing the solution with one that’s more flexible and provides the ability to adapt to new problems and technologies more easily.

STANDARDS NOT A PANACEA HERE

So organizations have come to demand flexibility and customization, but still fear (according to surveys, at least) vendor lock-in. Part of the appeal of open-source software was that organizations could have the source and modify it at will. Customers were no longer at the mercy of vendors to wait for new features. They didn’t have to worry about not being large enough to command a vendor’s attention and have every request attended to as soon as possible. They were in control.

Vendors in the infrastructure space have heard that demand and have addressed it. Juniper’s new unified operating system allows development of custom solutions to be deployed across their network infrastructure devices. Cisco provides the means by which their ISR (Integrated Services Router) can be “upgraded” with custom developed software. And F5 has long offered its network-side scripting solution, iRules, as a means to customize its unified application delivery infrastructure to support the quirks, flaws, and unique environments in which applications are deployed.

Not even standards can address this problem completely, as the customization and flexiblity of a solution is usually unique to the solution and, thus, there exist no standards to make it “easier” to back out and migrate to a different solution. You can’t run a solution developed on JunOS on a Cisco ISR, and vice versa. You can’t execute iRule logic on a Cisco ACE. These are solutions unique to the vendor that, although you may have the source code you can’t easily migrate to a new solution without work. It’s important to remember, too, that just because solutions offer the means to customize and extend does not mean it’s a requirement. You can still use a Cisco ISR without writing an extension, you can use a BIG-IP without ever writing a single iRule, and you can run a Juniper device without developing new functionality. It’s optional.

So the question becomes is the flexiblity and customization that customers have demanded for years and that inherently leads to deeper integration into the organization, making migration admittedly more difficult, worth it? Is vendor lock-in really a bad thing or is it just the fear of being locked into an emerging technology where long term viability of the vendors is in question?

Go ahead, sound off. What’s your opinion? Is any feature/option/situation that leads to vendor lock-in inherently bad? Is it sometimes acceptable? Do you really even care or is this “fear” really a competitive vendor fear and not nearly as important to the enterprise as some vendors would have us think?

Has the possibility of “vendor lock-in” ever stopped you from making a purchasing decision or is it just a “potential risk” that’s weighed in the overall decision making process?

Technorati Tags: MacVittie,F5,iPhone,Cisco,ISR,Juniper,JunOS,BIG-IP,iRules,ACE,VMware,CIO.com,cloud computing,infrastructure

Related blogs & articles:

‘Drowsy’ Networking

Wed, 11 Nov 2009 06:23:07 EST

No, not the kind you do on Facebook when you’re really, really tired but the kind defined as a means to reduce power consumption without affecting application performance or availability by eliminating non-essential processing and networking whenever possible.

An article on “Drowsy” computing as a means to reduce power consumption in data centers got me thinking about how such concepts might be applied to networking.

To summarize the concept of “drowsy” computing its basic premise is that when applications aren’t being heavily used some mechanism is used to reduce the power consumption on the physical server to its lowest levels, thereby saving costs associated with drawing power. The CEO of 1e, which offers a product to provide the mechanism by which power consumption levels on servers are manipulated, says the concept “can make a significant dent in what is currently more than $4 billion in wasted energy use every year.”

The trick is apparently differentiating between “useful” and “housekeeping” computing. Thus the trick to accomplishing similar behavior in networking would be to distinguish between the “useful” and “housekeeping” networking. But we also need to bear in mind that changes in the network or application network architecture as a means to reduce resource and power consumption should be automated lest the financial gains end up negated by the cost of manually carrying out such tasks.

Turns out there are some interesting applications of this concept, especially in the application network management arena, that fulfill both.

NETWORK HOUSEKEEPING

In application delivery, at least, there are a couple of tasks that might be good candidates for “slowing down” during periods of less frequent activity. These tasks generally consume resources on the application network components, the network and its associated components, and the web/application/database servers. For applications that are primarily business-related and for which usage is highly predictable, i.e. used only during business hours or has known patterns of use based on time of day or other events, these housekeeping tasks can be better regulated to reduce the power and usage of all the components involved across the data center.

Application Health Monitoring This is the cornerstone block in the application availability house so tread lightly in this area but definitely venture inside. For applications known to be in use only during business hours health checks should be as frequent as necessary to ensure availability and fault-tolerance during usage but after hours can be relaxed somewhat. Health checks, regardless of whether they’re simple ICMP or (as is proper) at the application layer, make use of application network, network, server, and application resources. By reducing the frequency with which these checks are made during off hours from an interval measured in seconds to one measured in perhaps minutes you can reduce the consumption of resources across the entire data center. It’s hard to measure the amount of power saved across all components and on a per-health check basis is probably minute, but over time that all adds up.
Available Server Reduction If the usage patterns of an application are fairly predictable then you know that during certain time intervals you’ll need X servers and at other times you’ll need Y. If those intervals can be measured in hours then it might be advantageous to remove servers from the pool (cluster or farm) of available servers during light usage periods. This effectively removes the health monitoring checks and ensures that no matter what load balancing algorithm is being used that requests will not be distributed across all servers. This reduces resource utilization in general and it’s a fairly simple task to add those servers back into the pool before usage increases.
Caching Caching requires that you better understand the update frequency of data being requested by applications, but if it’s the case that content is updated only once every X hours or even not at all during the evening hours then caching can drastically reduce the consumption of resources across the data center. By employing the caching capabilities of application delivery solutions you can offload requests from the network and servers. If the application delivery solution is flexible you can further modify caching policies on-demand to dynamically adapt to a schedule of caching for shorter or longer periods of time, depending on how often content is updated. You’re removing the housekeeping task of checking with the origin server to see if content “might be updated” because you know already that it hasn’t.

I’m certain there are more housekeeping tasks that can be evaluated for potential modification as a means to reduce consumption of resources. I’m also fairly certain that you won’t see a huge reduction in costs associated with such actions, but combined with other cost and power savings measures it’s a step in the right direction.

Technorati Tags: MacVittie,F5,green,green computing,application delivery,caching,acceleration,monitoring,infrastructure 2.0,drowsy networking,drowsy computing

Related blogs & articles:

Microsoft Exchange 2010: HELO New Architecture

Tue, 10 Nov 2009 07:30:00 EST

Microsoft has made some fairly substantial changes to the core architecture of Exchange 2010. Given that messaging can only be described as business critical today, it’s no surprise that many new aspects of Exchange 2010 and in particular its new architecture are designed to improve availability and management of its messaging systems.

Exchange 2010 includes many changes to its core architecture. In Exchange 2010, new features such as incremental deployment, mailbox database copies, and database availability groups work with other features such as shadow redundancy and transport dumpster to provide a new, unified platform for high availability and site resilience.^[1]

The core change in architecture will be felt not just by server and Exchange administrators, but by network and application delivery network administrators as well. With Exchange 2010 users no longer connect directly to Mailbox servers even when using Outlook in native MAPI mode; instead, all user access to e-mail, regardless of protocol, is achieved via Client Access Servers (CAS).

This specifically changes:

1. Outlook data connections go to RPC Client Access Service on CAS instead of connecting to Mailbox servers

2. Address Book Service on CAS replaces DSProxy interface and handles all Outlook Directory connections

3. Public folder connections connect directly to the Mailbox server, but through RPC Client Access Service running on backend

This may change network routing, host and domain naming, as well as the configuration of intermediaries as persistence is a requirement for Outlook, Outlook Anywhere, OWA, EAS, EWS, ECP, and Remote PowerShell. MAPI traffic over a VPN now flows along with HTTP, POP3, and other Exchange protocol traffic which may require adjustments to firewall and other security-related infrastructure configurations.

Also potentially a new requirement for network and systems’ administrators will be the need to provide load balancing for internal CAS connections given the increased load on this tier and the requirement to use CAS. This may require additional routing or changes to existing network routing architectures and will absolutely increase the load on the CAS tier as the highest volume of utilization certainly comes from internal connections. Considerations include capacity planning based on the roles of servers required for internal connections as it is likely there will be a requirement to increase the number of servers available in this tier. Microsoft offers guidance on sizing of servers based on role that will be valuable in this process. The impact of multi-role server deployments is not available at this time, although this is traditionally one of the architectural choices that has led to the use of load balancers as an integral component to a successful high-availability, well performing Exchange deployment.

This architectural change means that all traffic is available to be load balanced by an application delivery controller rather than the old model where only some traffic could be routed through the load balancer. This means all traffic can take advantage of additional functionality provided by application delivery controllers such as message security, application acceleration, and high availability configurations for increased reliability.

Example of a load balanced Exchange 2010 environment compared to a load balanced Exchange 2007 environment

Given that all client connections are now via CAS servers it is important to note that Microsoft is in the process of updating its high-availability and scalability design guide for Exchange and expects to publish it in the coming months. This paper will include more specific information on the role of hardware load-balancers for Exchange. Additionally, vendors should be updating any existing deployment guides specifically for Exchange 2010. F5 has already done so, and it is available here for your perusal [PDF].

This architectural change should have a positive impact on the cloud-based deployment of Exchange as the standardization on access via CAS servers means scalability can be more easily achieved via additional instances of CAS with granularity perhaps taking it even further by basing scaling needs on the role which the CAS server is playing in the overall architecture.

^[1] Microsoft TechNet library for Exchange Server: http://technet.microsoft.com/en-us/library/dd298026(EXCHG.140).aspx

Technorati Tags: MacVittie,F5,Microsoft Exchange,Exchange 2010,CAS,high availability,scalability,load balancing,architecture,deployment,Microsoft,new

Related blogs & articles:

Virtualization Changes Application Deployment But Not Development

Mon, 09 Nov 2009 06:57:00 EST

Cloud computing management functionality and standards are right now laser-focused on virtual machines, and most APIs include the ability to stop,start,launch,etc…at that level of the infrastructure. This is because the application is still insulated by its virtualized environment. The “depth” of management and standards efforts today stops at the hard shell of the virtualization layer and leaves the soft, chewy application center alone. This means nothing is really all that different for developers. But it could, and some might argue should, be different.

The development of a web-application for a cloud computing environment today is really no different than the development of an application destined for deployment in a traditional data center. If the developers or architects are network-savvy, they know they need to worry about a few environmental specific conditions like persistence and stateful load balancing, but other than that they don’t have to change how they develop the application.

That’s because when they complete the application and deploy it into a web-application server, the entire environment – OS, application server, and application – will be packaged up into a neat virtual image and shipping out. There’s nothing more they need to do. Nothing different than it was before cloud computing appeared on the scene.

The focus in cloud computing environments, as evinced by a perusal of APIs offered up to standards organizations by a variety of cloud computing providers – Sun, Yahoo! – and organizations like OCCI, stops at the virtualization layer. Beyond the virtual machine there is no mention of application resources, no mention of how those might be managed or provisioned or priced. It is the virtual machine layer at which the buck stops.

Virtual machines virtualize the operating system; a complete environment. They do not virtualize an application, nor even an application server environment. Indeed, one could successfully argue that web application servers have long virtualized applications through the automated provisioning and management of isolated, virtual instances of applications. At lease enterprise-class web application servers have, the story is very different when you look at scripting-based languages like ASP, PHP, and Ruby and their deployment on web-servers where isolation is not provided for nor considered.

WEB/APPLICATION SERVER AS THE NEXT FRONTIER FOR VIRTUALIZATION

It is like at the web/application server tier that virtualization could make the biggest impact and thus it is likely in the PaaS (Platform as a Service) market that we will see the greatest advances in virtualization of applications.

Consider that rather than provisioning virtual machines you provision applications. I know, quite the concept, isn’t it? But at the core of what we’re trying to do isn’t that really what we want? To deploy an application into an environment? So let’s pretend that rather than moving around and provisioning and releasing virtual machine images we are actually working at the layer that’s most important to us: at the application layer.

Image a web/application server environment that acts much as we expect virtual machines to act today: it is the application server that is responsible for metering and billing of compute resources, but because the web/application server actually knows exactly what each application has consumed providers would be able to not only claim a “pay for what you use” model but actually implement one, rather than the “well, you’re paying for how many virtual machines you use, not really how much compute power you consume.”

The web/application server performs many of the tasks we already associate with management of virtual machines: launch, stop, suspend, provision. Many web/application server platforms are already remotely manageable and provide APIs through which their management functions can be controlled. Web and application server platforms are well-suited to becoming the layer at which we manage compute resources and application management and would certainly provide much more granular control over the environment than do virtual machines.

THEN APPLICATION DEVELOPERS WOULD NEED TO LEARN NEW TRICKS

If we were truly provisioning at the application layer through cloud computing enabled web and application servers then we come to a place where developers might need to learn new tricks.

For example, today there are environment/platform specific methods of declaring web-service accessible functions. [web service] and [web method] declare to Microsoft environments that certain objects and methods will be web-service enabled. Similar methods are used in the latest versions of Java, for example @WebService indicates in a JAX-RPC 2.0 environment that a class will be service-enabled. The development environment interprets those directives and prepares the objects and methods for service-enablement, including providing the interfaces necessary for management via the application server.

Now, take that concept and apply it to virtualization. Imagine that in a development environment you know that a specific function/method/discrete block of application logic will be core to the application and heavily used. You decide that this block of code will be a bottleneck and thus it would be appropriate to scale it out. You preface the block of code with @virtualize or [virtualize] and go on with your coding. Optimally we’d like a profiling tool to be able to do this for us; to examine the code in a run-time scenario and determine where the most time and compute resources are spent and automatically suggest which workloads are good candidates for virtualization.

When the application is packaged the development environment then recognizes those directives and prepares that block of code to be “virtualized”. The directives, instructions, to the web/application server instruct it that the block of code can be virtualized which in turn means it may be deployed as a discrete workload on any capable application instance.

At run-time the application server, which is able to monitor and manage compute resource utilization, determines that load is increasing much too quickly and needs to increase capacity. Today this is accomplished by launching complete virtual machine images on other resources; the entire application is duplicated and thus requires X compute resources (and its associated costs) every time an image is launched. But in our scenario the application server recognizes the virtualizable workloads and simply indicates that additional instances of the workload should be launched, and uses mechanisms similar to RMI and CORBA and EJB naming to ensure that application requests to that workload are properly directed.

The instances of the workload require fewer compute resources than the entire application and thus should theoretically incur lower costs, which means the costs of scaling are reduced overall.

PaaS IS WHERE THIS INNOVATION WILL START

PaaS (Platform as a Service) is uniquely positioned to be the leaders in this aspect of cloud computing’s evolution. Because the platform, the application development and deployment platforms, are the focus of PaaS and PaaS providers like Microsoft (Azure) and Google (Google Apps) completely control the application servers upon which applications are deployed, they are in a unique position to take virtualization to the next level.

PaaS providers already must manage and monitor at a level lower than IaaS (Infrastructure as a Service) providers because the interface between PaaS and its customers is the application, not the virtual image. In fact, virtualization may not even be a part of the underlying PaaS architecture and in fact does not need to be involved. The “virtualization” in a PaaS can (and some might argue should) come directly from the isolation and management provided by the development and deployment platforms.

Christofer Hoff makes a similar assertion in “Incomplete Thought: Virtual Machines Are the Problem, Not the Solution…”:

So these virtualization players are making acquisitions to prepare them for this next wave — the real emergence of Platform as a Service (PaaS.)

Some like Microsoft with Azure are simply starting there. Even SaaS vendors have gone down-stack and provided PaaS offerings to further allow for connectivity, integration and security in the place they think it belongs. [emphasis added]

In the case of VMware and their acquisition of SpringSource, that piece of bloat in the middle can be seen as simply going away; whatever you call it, it’s about disintermediating the OS completely and it seems to me that the entire notion of vApps addresses this very thing. I’m sure there are a ton of other offerings that I simply didn’t get before that are going to make me go “AHA!” now.

“In the place they think it belongs.” Exactly. I don’t know that the OS will go away, and virtualization is certainly not going away as the use for it in testing and even production deployment of a full-scale infrastructure will be necessary for quite some time. For virtual appliances, virtualization is where it’s at and the management and standards folks understand that in the case of infrastructure at least, there’s more to managing the environment than just the virtual machine. They get that we have to be able to integrate, to collaborate, with the infrastructure solutions deployed in those virtual machines.

vApps: Ensuring seamless application movement and choice between clouds

VMware vSphere includes support for vApp, a logical entity comprising one or more virtual machines, which uses the industry standard Open Virtualization Format to specify and encapsulate all components of a multi-tier application as well as the operational policies and service levels associated with it.
Just like the UPC bar code contains all information about a product, the vApp gives application owners a standard way to describe operational policies for an application which the cloud OS can automatically interpret and execute.
vApps can comprise of any applications running on any OS, and provide a mechanism for customers to move their applications between internal clouds or external clouds with still the same service levels.

It’s only when we get to the applications that everything falls apart and we lose control over that layer of the environment. While VMware’s vApps takes us a step closer, its primary goal is to control the operational environment in which applications run, and does not – and really cannot – descend into the internal gooey center of the application where the real advances in application virtualization are sure to come in this continuously evolving application deployment paradigm.

Until then, nothing really changes for developers.

Technorati Tags: MacVittie,F5,virtualization,vmware,vapps,web application,server,architecture,development,soa,cloud computing,cloud,infrastructure,virtual machine,management,PaaS,google,azure,microsoft

Related blogs & articles:

TLS Man-in-the-Middle Attack Disclosed Yesterday Solved Today with Network-Side Scripting

Fri, 06 Nov 2009 15:30:09 EST

Yesterday the blogosphere, twittosphere, and other-spheres were abuzz when a new TLS renegotiation man-in-the-middle attack was disclosed.

Interestingly enough, while we were all still reading about it and figuring out all the nuances, one of our own DevCentral members was out implementing a solution.

No, he’s not a vendor with a product to worry about, he’s just a “guy” trying to defend his web site and applications from potential attacks like this one. But he’s a guy with network-side scripting in his arsenal of web application security tools, and with that and his understanding of the very well-documented vulnerability he crafted a solution.

Colin documents the iRule that addresses this vulnerability in his 20LoL post for the week, and so I won’t repost the code. You can also view the forum thread [registration required] in which “Lupo” describes and discusses the solution.

What I love about this solution is not necessarily that it solves a particular vulnerability. That’s awesome, of course, and a great thing but in the coming weeks and months we’ll see a lot of solutions that address this particular vulnerability. What I really love about this solution is the speed with which it was implemented. The vulnerability was disclosed yesterday and Lupo had a solution today, which he generously shared with thousands of others who can immediately put into use the same solution.

A lot of folks talk about agility and how solution X or Y enables organizations to respond rapidly to changing market/business conditions, but rarely do you see as solid an example as this one. From disclosure to solution in one day. That’s agility in action.

Technorati Tags: MacVittie,F5,application security,security,TLS,SSL,man in the middle,marsh ray,vulnerability,network-side scripting,iRules,solution

Related blogs & articles:

When Is More Important Than Where in Web Application Security

Fri, 06 Nov 2009 06:43:47 EST

While you spend your time arguing over where application security belongs, miscreants are taking advantage of vulnerabilities. By the time you address the problem, they’ve moved on to the next one.

Dmitry Evteev @ Positive Technologies Research has discovered (yet) another method of exploitation that allows for the injection of malicious SQL into sites and databases.

A method that I discovered today in MySQL documentation struck me with its simplicity and the fact that I haven’t noticed it before. Let me describe this method of bypassing WAF.

MySQL servers allow one to use comments of the following type:

/*!sql-code*/ and /*!12345sql-code*/

As can be noticed, SQL code will be executed from the comment in both cases! The latter construction means that "sql-code" should be executed only if the DBMS version is later than the given value.

As I have been repeatedly asserted [1,2], some WAFs skip comments during signature search. Among such WAFs, there is the latest stable assembly of Mod_Security (v. 2.5.9).

As is immediately pointed out by several folks in the comments, while this exploit may indeed get past a WAF (and through application defenses, too) for an agile web application firewall (WAF) this is not really a problem. Even for not-so-agile WAFs this should not be too much of a problem provided the detection of the /*! pattern is flexible enough to adapt in the event that /* ! and /* !, etc… are also valid exploitable patterns.

In the case of a WAF enabled not just with standard schema (input field) parameter tightening capabilities, i.e. the ability of a WAF to restrict the valid input for any given form field/element/object in a web application, but also enabled with network-side scripting exploits like this can be addressed immediately, before it can be exploited.

VICTIMS DON’T CARE ABOUT WHERE, THEY CARE ABOUT BEING PROTECTED

Now, every time one of these “avoiding the WAF” exploits is discovered or discussed it kindles the flames of the WAF vs APP security war. Why there’s a war in the first place is beyond me as the two techniques are certainly complementary and should be working together toward a common goal: the defense of web applications against exploitation.

But someone is sure to bring it up, so I’m going to ask a very valid, I think, question:

How long would it take for your developers to address this vulnerability in every application?

Remember that the time includes not only development, but testing and deployment into production where those vulnerable applications are exposed. Never mind, you don’t need to answer that. A look at the Spring 2009 Website Security Statistics Report from WhiteHat Security clearly shows that it’s too long:

Q1 2009 Key Findings

82% of websites have had a HIGH, CRITICAL, or URGENT issue

63% of websites currently have a HIGH, CRITICAL, or URGENT issue

60% vulnerability resolution rate among sample with 7,157 (out of 17,888 historical vulnerabilities) unresolved issues remaining as of 3/31/09

Vulnerability time-to-fix metrics are not changing substantively, typically requiring weeks to months to achieve resolution.

Average # of HIGH, CRITICAL, or URGENT severity vulnerabilities per website during the vulnerability assessment lifetime: 17

Average number of serious unresolved vulnerabilities per website: 7

Average number of inputs (attack surface) per website: 227

Average ratio of vulnerability count / number of inputs: 2.58%

In the 38 days it takes developers to address a new vulnerability across all web applications those same applications are vulnerable; exposed to the possibility they will be exploited, which puts not only the organization but users, customers, and partners at risk for exploitation, identity theft, and data exposure. Web application firewalls are enabled with flexible, agile methods of filtering, screening, and inspecting requests and data to ensure this very type of exploit cannot reach an application. No, the specific solution is not necessarily coded into the WAF any more than it’s coded into the application as the discovery by Dmitry clearly shows. But the web application firewall can be quickly, within hours if not less, adapted to stop an exploit in its tracks while it’s going to take much longer than that to do the same in every application for which this vulnerability might be applicable. That, too, is clearly indicated by the responses to Dmitry’s post in which several folks point out how easy it is to modify mod_security to recognize and prevent the evasion.

Are there architectural and performance advantages – and disadvantages – to employing a WAF? Of course there are. It’s give and take, like any technological solution. There are pros and cons, risks and benefits that need to be weighed. But when you’re weighing the decision based on where web application security should exist you have to factor in when it will exist and how that impacts the overall risk of the choice not to employ a WAF and trust only in developer-generated security.

No one is saying “don’t fix this in the application.” What we’re saying is stop the exploit now, before it’s used against you, while miscreants are taking advantage of the window of opportunity they know exists when a new exploit is discovered. When a vulnerability is addressed is probably much more important than where, and I’m willing to bet that users, customers, and partners don’t care one whit about how you prevent them from being exploited, they only care that you do.

Technorati Tags: MacVittie,F5,application security,security,web application security,web application firewall,waf,web 2.0,sql injection,sqli,whitehat Security,sdlc,mod_security,vulnerability

Related blogs & articles:

The API Is the New CLI

Thu, 05 Nov 2009 11:00:00 EST

Infrastructure 2.0, from a purely developmental standpoint, is about APIs. It’s about offering up the functionality and capabilities of a wide variety of infrastructure – network, storage, and application network – to be externally controlled, integrated, and leveraged for whatever purpose a developer might dream up. It enables providers and enterprises alike to turn infrastructure functionality into services. Need compression? Caching? Routing? Load balancing? Via service-enabled management APIs these can become services, provisioned and released through the invocation of a service. When expanded to include the sharing of actionable data – performance statistics, status, availability of application services (context!) – this integration becomes the mechanism through which a dynamic infrastructure is created. One that reacts to events and conditions in the network, storage, application network, and application infrastructure in real-time.

Twitter Account Lockouts Continue to Plague Users

Thu, 05 Nov 2009 06:27:31 EST

Brute force attacks by spammers seeking easy access causing frustration for users with no resolution in sight

At least once a day I see someone on Twitter broadcast that they have been “locked out of their Twitter account, temporarily.” A search for “locked out” returns thousands of tweets with a good mixture of some folks who’ve (amusingly) been locked out of apartments/houses/buildings and many that have been temporarily locked out of Twitter. The more technically savvy tweeters like Ray Valdes often mention that it is most likely the result of spammers and miscreants attempting to brute force their way into their account, but usually it’s just the beginning of rant against Twitter and how “stupid” it is to lock them out of their web account. Some of those rants are quite, shall we say, colorful and don’t need to be reproduced here. You can use your imagination, I’m sure.

WHY ACCOUNT LOCKOUTS WILL CONTINUE TO HAPPEN

Brute force attempts to gain access through users by spammers and other miscreants is a common occurrence in web applications. For Twitter, and really any Web 2.0 application providing API access through which third party applications can connect, the methods of determining what is a brute-force attack and what is simply a user who has (1) forgotten their password or (2) forgotten to change all passwords in all applications that access the application is exceedingly difficult.

Locking users out of their accounts when they are the victim of a brute force attack is a common security practice, designed to prevent compromise and, in many cases, it’s the only option to prevent continued attempts through such persistent attacks. The problem is that the application can’t take into account the subtle indicators that differentiate between a brute force attack and a user who’s simply forgotten to update one password or another, or forgotten their password entirely.

That’s because brute force attacks attempting to compromise an account are an application layer attack and there’s no good way for Twitter – or any other application – to recognize them. What indicators there are that a brute force attack is occurring require the ability to evaluate individual requests in the context of all requests. For example, a suddenly high volume of requests for “login.html” or URIs/API calls associated with the authentication process coupled with increasing load on servers is a good indicator that something is going on and that “something” is probably not good.

The application, Twitter in this case, when processing the “login” request, does not know that the same request has been attempted X times in the last second and is probably the victim of a brute force attempt. The application can’t know that there are three other servers running at 90% of their CPU capacity all trying to process “login” requests. It just knows about this single request and it evaluates it in that very limited context. A flag in the user account somewhere keeps track of failed login attempts and when it that counter hits X, the account is locked out. Period.

Locking users out after X attempts frustrates the user but does nothing to prevent subsequent attempts. The user will eventually regain access, change their password, and eventually a spammer/miscreant will try again. Nor does preventing access to one account stop the attacker from simply moving to the next one and trying again. This is one of the - albeit few - instances in which a web application firewall (WAF) is capable of providing security that an application simply can’t.

A BETTER SOLUTION

A web application firewall has access to what applications don’t: the big picture. It has the proper context in which to recognize and prevent brute force password attacks. A WAF can see the pattern of connections and requests across the entire application and can use historical request patterns to recognize when it is likely a brute force password attack is occurring. Using various mitigation techniques including limiting the maximum number of failed login attempts on a per browser-session and IP address level along with recognizing an abnormally high rate of failed login attempts, a WAF can trigger preventive mechanisms that protect an application against these types of attacks.

Brute force attacks, which can generate up to a million requests per second, can also put considerable strain on the application and its supporting infrastructure. This can lead to a degradation of performance and availability for all users, not just those under attack. Using a WAF to mitigate attacks and regulate requests relieves the application and its infrastructure of that burden and thus preserves availability and performance for all users.

Employing an intelligent solution capable of interpreting failed login attempts in a broader context leads to the recognition and prevention of brute force password attacks. An application simply does not have the historical context nor a view of the big picture required to prevent these attacks; it can’t, for example, recognize the latency between requests. The latency between login attempts of a real user versus that of a brute force script is very different. The only solution for the application is to lock users out of their accounts quickly or risk compromise. Even if we rethink thresholds for account lockouts and increase the allowed number of attempts the result will almost certainly be the same: the user is locked out. This does nothing to address the strain on the infrastructure, degrading performance of the application, and the frustration users experience when locked out of their accounts.

One thing Twitter can do now is to make users aware of why they were locked out and perhaps provide an additional message tacked onto the “too many failed login attempts” that explains the situation better. An explanation that Twitter is well aware that the user may not be the one responsible and that the account was locked to protect the user from compromise might go a long way toward relieving some of the angst users – especially the less technologically savvy ones – experience when they don’t understand why something is happening.

Technorati Tags: MacVittie,F5,Twitter,account,lock out,brute force,spammers,users,attack,web application security,security,application security,Web 2.0,web application firewall

Related blogs & articles:

Maybe Ubuntu Enterprise Cloud Makes Cloud Computing Too Easy

Wed, 04 Nov 2009 11:45:00 EST

With just a few clicks you, too, can create a cloud computing environment. But if you’re like a lot of organizations, you may not know what to do with it after that.

The latest version of Ubuntu Server (9.10) includes the Ubuntu Enterprise Cloud (UEC), which is actually powered by Eucalyptus. The ability to deploy a “cloud” on any server running Ubuntu is really quite amazing, especially given the compatibility of Eucalyptus with Amazon and the plethora of application images available for nearly immediate deployment. It supports both a public and private option, and a hybrid model, and comes replete with management tools designed to make building, deploying, and managing your own personal, private cloud a breeze.

Private clouds offer immediacy and elasticity in your own IT infrastructure. Using Ubuntu Enterprise Cloud, you can experience the benefits of cloud computing behind your firewall. Deploy workloads and have them running immediately. Grow or shrink computing capacity to meet the needs of your application.

Too awesome, right? Well, yes and no. It is, apparently, not an answer to how do I build a cloud that would-be cloud computing adopters need, but rather how do I use a cloud? Consider the following query:

I noticed while installing the new version of Ubuntu server yesterday that there is a cloud cluster and node option for deployment. I read through the tutorial on how to set up the cloud, but how does one use the cloud, private or otherwise?

The question comes from a very technically savvy network engineer who, according to a recent survey by web-hosting provider Peer 1, is not alone in asking this question. In the independent study conducted for Peer 1 39 percent of the over 200 IT decision makers surveyed said that their lack of knowledge is preventing them from adopting cloud computing. Security and lack of control also ranked high (24 and 21 percent, respectively) but still fall short of the apparent lack of knowledge regarding cloud computing as an obstacle to adoption.

USING “THE CLOUD”

The answer to the question “how does one use the cloud, private or otherwise” turns out to be both simple and complex. Perhaps at this point it would be a good idea to back up and talk generalities and concepts. Knowing what you have, after all, may help in understanding what it is one does with it.

A cloud computing environment is primarily an architectural framework for automatically managing compute resources in a way that ensures the scalability and reliability of applications. To use cloud computing anything you need to deploy an application into it. Those applications are generally packaged into “images” in a virtual machine format: AMI (Amazon Machine Image), VMWare, Xen, and Microsoft Hyper-V are all options available in general, though EUC appears to have “standardized” on AMI. (We’ll leave that discussion for another day)

It is the virtual image that is deployed into the cloud computing environment, and it is the virtual image that is managed by EUC. Inside the image your application(s) is running, and when the compute resources assigned to that image – not the application, but the image – are in danger of being completely consumed UEC (or appropriate cloud computing management framework in public implementations) will automatically start another virtual image containing your application, assuming there are available compute resources in the “cloud cluster”.

So, a cloud computing environment is comprised of nodes on which images are deployed. Each image runs one (or more, though usually one) application. End users interface with the applications and cloud computing users interface with all the nuts and bolts. It is the management of those nuts and bolts that Ubuntu makes look so easy with Ubuntu Enterprise Cloud (UEC). Mouse click easy, in fact, based on the detailed instructions offered on Ubuntu’s site. So now you’ve got a “cloud” deployed, what do you do with it?

Once the base framework is in place you deploy images of applications.In the case of UEC you either download, select, or bundle an image of an application and then push it into the cloud via the UEC management interface. From there, UEC (or any cloud computing environment really) should take care of automatically scaling that application up or down based on compute resource need. Obviously scaling up requires that you have more than one “node” in your “cloud cluster” or that you’re taking advantage of UEC’s integration with Amazon.

So one use, the primary use, is to deploy applications and ensure scalability. But you can also use cloud computing environments to deploy images of infrastructure solutions such as virtual appliances that provide security or load balancing or logging or a plethora of enterprise-focused functionality. You could use UEC or any other cloud computing environment for testing, development, design of new architectures; use it to evaluate new application products and implement proofs of concepts in an environment that closely simulates your production environment.

Cloud computing is ultimately just a new way to deploy and manage applications and their supporting infrastructure that is more efficient than traditional methods without sacrificing performance or reliability. You use “the cloud” by deploying applications into it, and letting it do the rest.

At least that’s how easy it’s supposed to be. Whether or not that’s true in practice is a completely different story…

Technorati Tags: MacVittie,F5,Ubuntu,Eucalyptus,cloud computing,cloud,Amazon,VMware,Hyper-V,xen,virtualization,application delivery,infrastructure

Related blogs & articles:

Using Network-Side Scripting to Convert Microsoft Smart Quotes to HTML Entities

Mon, 02 Nov 2009 06:03:00 EST

Dealing with Microsoft smart quotes is a fact of life for developers. Almost every developer out there has a server-side script/function they use to strip them out of user-generated content and replace them with web-friendly HTML entities instead. But handling smart quotes in application code isn’t always possible or as high a priority as other tasks. If you were looking for a way to address smart quotes once and for all, across multiple applications with one, centralized simple method then a network-side scripting solution may be the answer.

WILS: Three Ways To Better Utilize Resources In Any Data Center

Thu, 29 Oct 2009 10:30:00 EDT

Cloud computing is, at its core, about using resources in the most operational and financially efficient manner possible. It’s about spreading resources around and sharing them to achieve greater scalability with fewer investments in hardware and software. But what if you aren’t moving to cloud? Or virtualization? Or perhaps you are, but the benefits won’t be really seen until you actually get enough resources shared across your organization. Isn’t there any other way to better utilize the resources you have now to improve the bottom line?

Yes, yes, there is. And the best part is that these methods will increase the efficiency of resource utilization in any architectural model.

“Server” offload technologies are applicable to any server – physical or virtual The efficiencies gained in server resource utilization and increase in VM densities are not peculiar to a cloud environment. In fact, the offload capabilities of an application delivery controller (SSL, TCP session management, compression, caching) can benefit any “server” in any environment. Because the offload capabilities are applied at the transport protocol and application protocol layers, these benefits are universal to web and application servers whether residing in virtual machines or on physical hardware, in the cloud or in a traditional data center.

Proactive security measures Whether it’s stopping common web application attacks or SPAM from entering the network, proactive security measures can make more efficient use of resources available by preventing them from spending time on “bad” or “illegitimate” traffic. Stopping attacks and SPAM and other malicious content at the perimeter of the data center prevents resources on the network, on the servers, and in the storage systems from being used to transport, process, and store what is nothing more than garbage. This improves the efficiency of the entire infrastructure and does not require a cloud model to achieve.

Automated Storage Tiering Automated storage tiering can automatically move less frequently accessed files to less expensive storage arrays while moving more frequently accessed files to faster, more expensive storage. Automating such processes mean administrators need not manually determine which file goes where, or optimize storage based on performance and cost by pulling out a slide ruler and calculating costs per megabyte. The system automatically determines how to best utilize the storage based on cost and performance and acts on behalf of the storage administrator, like a digital storage maid service that never needs to be reminded to sweep the floor.

Technorati Tags: MacVittie,F5,cloud computing,virtualization,file virtualization,storage virtualization,storage tiering,web application security,application delivery,efficiency,WILS

Related blogs & articles:

All WILS Topics on DevCentral

DDoS Attack Hits Amazon Cloud Customer Hard

File Virtualization, The Ultimate Cloud Gateway?

Disk May Be Cheap but Storage is Not

Long Live(d) AJAX

Web Application Security at the Edge is More Efficient Than In the Application

Load Balancing on the Inside

IT Myths and Legends: Sharing Servers

Virtual Machine Density as the New Measure of IT Efficiency

Reasons You Need File Virtualization

read more

Study Says Economics Not A Driving Factor in Cloud Computing Adoption

Wed, 28 Oct 2009 19:15:00 EDT

Paul Miller, who pens Cloud of Data, had an interesting perspective during a chat this week on what effect infrastructure upgrade cycles might have on cloud computing adoption. Paul postulated that as these servers fail and organizations have to make the decision to replace or not replace them that cloud computing becomes a more viable option. That seems a reasonable assumption, especially if the primary reason organizations are evaluating cloud computing is driven by a desire to reduce costs. But in a recent post Paul posits this might not be the case, citing a recent ongoing study from Avanade in which C-level executives were asked, among other questions, how the economic climate effected their decisions regarding cloud. Interestingly “only 13% suggesting it had ‘helped’ adoption plans and 58% reporting ‘no effect.’”

In my conversations with Nick Carr and others, there’s been an underlying presumption (on my part, as well as theirs) that cost-saving arguments with respect to Cloud Computing would prove persuasive and compelling. It would appear not. This would suggest, of course, that Enterprise adopters are taking to the Cloud for reasons other than the budget sheet…

I’ll come back to this, as I’m not convinced there is a direct correlation between external economics and internal budgets, at least in this case. But let’s go with that for a moment. Assuming there are budgetary constraints on organizations what else would drive adopters to cloud computing and where are they getting the money?

Our own research on this subject found that efficiency, not reduction of costs, was the primary driver for public cloud computing adoption and that despite budgetary constraints 71% of organizations would see an increase in fund allocation for the purposes of public and private cloud computing initiatives. But a reduction in capital expenses still ranked high with 68% of respondents citing a reduction in capital expenses as a driver toward public cloud computing and 63% citing the same as a driver for private cloud computing.

ISN’T THAT CONTRADICTORY?

It seems so, doesn’t it? If organizations are interested in cloud computing as a means to reduce capital expenses then why would we be seeing an increase in spending on cloud computing initiatives, especially private cloud computing which almost certainly requires capital expenditures to achieve? After all, there’s virtualization software, improvements in infrastructure, and management systems that need to be in place for the successful implementation of a private cloud computing environment.

Perhaps the budget increases are coming at the expense of other areas in IT. Let us consider the aforementioned study on server failure:

In round numbers, the scheduled replacement of some three million servers worldwide, or about 3 percent of all servers, has been delayed, Peter Sondergaard, Gartner's global head of research, said today at the research firm's Symposium/ITxpo 2009 conference here. He added that the number of delayed replacements should reach 10 percent of all servers by 2010.

Certainly one way to reduce capital expenses is to not purchase new servers. But the servers that will begin to fail certainly have applications deployed on them that are if not critical at least important to the business, otherwise they would not have hardware dedicated to them. So where are those applications going? Virtual machines, most likely. Consolidated onto newer, more reliable hardware capable of supporting many applications contained within virtual machines. Virtualization is a primary enabler of consolidation efforts, which in turn reflects in IT budgets as reductions in capital expenditures.

Shifting the budget that would normally be allocated to acquire new hardware to virtualization and cloud computing initiatives, both public and private, would certainly explain an increase in funds available for cloud computing. This would also explain why external economic factors do not appear to be, according to Avanade’s study, a driving factor in cloud computing adoption.

COSTS STILL A FACTOR

It’s still important to remember that Avanade’s study doesn’t indicate that reducing costs isn’t a driver for cloud computing, it just says that external economics aren’t really playing a role in decision-making at this time. In fact within the study is this little nugget indicating cost savings are, in fact, an important factor in cloud computing adoption:

Companies are under equal pressure to innovate and save money and, many are turning to new technology as a way to do this. The vast majority of respondents (85 percent) report that their company’s rate of new technology adoption is either increasing or staying the same (83 percent in the United States).

But if we assume that organizations are shifting allocation of funds rather than asking for bigger budgets, then it is possible that economic constraints have little effect on adoption of cloud computing. If cloud computing initiatives required funding without reducing other existing budgets then it would be more likely that adoption rates would be slower than what is shown in both Avanade and F5 research and more folks in the Avanade research might have indicated that economics were in fact impacting their adoption plans.



Technorati Tags: MacVittie,F5,cloud computing,survey,research,Avanade,Paul Miller,economics,funding,budgets,costs,virtualization,consolidation,efficiency,web,internet,blog

Related blogs & articles:

Budget cuts could increase server failures

Avanade finds growing Enterprise enthusiasm for the Cloud

The Thing Private Clouds Can Do that Public Clouds Can’t

Paradox: When Cloud Is Both the Wrong and the Right Solution

Virtual Machine Density as the New Measure of IT Efficiency

We Don’t Know What Cloud Is But What We’re Doing It

read more

Vertical Scalability Cloud Computing Style

Tue, 27 Oct 2009 08:15:00 EDT

Vertical scalability used to require optimizations inside the application, at the code level. Cloud computing changes the nature of vertical scalability and, one hopes, will lead to a new model of scalability based on the capabilities of Infrastructure 2.0 and increasingly granular resource management capabilities.

RightScale recently offered up its own analysis of Amazon Usage Estimates and while the details they provide on Amazon usage from their vantage point is very interesting I found one of their related observations even more fascinating:

In earlier days the predominant method of scaling was by launching more servers, but we are now seeing a lot more scaling by replacing smaller servers by larger ones.

The reason I find this fascinating has to do with not so much where cloud computing is today, but where (we hope at least) it is going.

Most people are aware of the difference between vertical and horizontal scalability. Remember “Cloud Computing: Vertical Scalability is Still Your Problem” where we talked about the differences?

Horizontal scalability is the ability of an application to be scaled up to meet demand through replication and the distribution of requests across a pool or farm of servers. It's the traditional load balanced model, and it's an integral component of cloud computing environments. Vertical scalability is the ability of an application to scale under load; to maintain performance levels as the number of concurrent requests increases. While load balancing solutions can certainly assist in optimizing the environment in which an application needs to scale by reducing overhead that can negatively impact performance (such as TCP session management, SSL operations, and compression/caching functionality) it can't solve core problems that prevent vertical scalability.

While this is still correct the observation by RightScale tells me that there is now another way to vertically scale in a cloud computing environment. It’s a hack, in the traditional workaround geek-cool sense, but an ingenious one nonetheless.

WHAT’S THAT GONNA COST YA?

When an application hits the top boundaries of CPU and memory on any machine – whether virtual or physical – the traditional response to ensure scalability is to use load balancing solutions to horizontally scale the application, thus increasing concurrent user and TCP connection limits while hopefully addressing the degrading performance problems associated with high utilization.

But what appears to be happening, at least in some cases,is that rather than horizontally scale by adding new instances is that people are simply “upgrading” the virtual machine and thus increasing the limitation on CPU and memory. It’s like buying bigger hardware, only it’s a lot easier and faster and doesn’t require nearly as much preparation before deployment. In essence people have found a way to vertically scale their application by simply provisioning more CPU and memory. Sort of.

This does not address the inherent performance degradation that occurs as higher utilization rates occur, and if you check Amazon’s pricing you’ll find that it’s quite a jump from a “small” to a “large” instance, regardless of operating system or whether it’s “standard” or “high-CPU” usage. In fact in both cases it’s 4x the cost to go from small to large/medium to extra-large, which makes sense given you 4x the EC2 compute units with each “upgrade”.

It seems, at least on the surface, that even with the costs of load balancing services from Amazon ($0.025/hour per Elastic Load balancer + $0.008/GB of data transferred through an Elastic Load Balancer) that it would be financially advantageous to simply launch a second instance and take advantage of load balancing, while also benefiting from the performance improvements typically associated with load balancing.

Now granted, the small servers are, by enterprise standards, pretty small and most organizations would never deploy an application into production running on a server with 1.7GB RAM and “the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.” I’m fairly certain my digital camera has more processing power than that, so what RightScale is seeing actually makes a great deal of sense to me. It might cost a bit more but it seems more apposite to provision higher performing instances despite the possibility of overprovisioning.

But I digress (yet again) and so now let’s get back to the point of this post which is not actually a comparison of vertical and horizontal scaling technology (although that’s interesting, too) but what this unique vertical scaling solution says about where the future of cloud computing (hopefully) lies.

WHERE COMPUTE RESOURCES, NOT VIRTUAL MACHINES, ARE PROVISIONED ON-DEMAND

Really, that’s it. That’s where cloud computing should be going and that’s where cloud computing hopefully is going. Someday you won’t need to launch a bigger instance because the environment will automatically, based on specified thresholds and business needs, allocate more CPU and/or memory on-demand to your “application”. How that happens isn’t important at the moment, but that it will happen and that it will take a combination of data derived from across the infrastructure is what is important and exciting. Because what RightScale is seeing is the first step toward someone deciding you shouldn’t have to launch a separate VM, you should just be able to grow the one you have until it can’t hold any more. Until you really are paying per clock-tick, per instructions executed and bytes in memory used instead of in chunks that may or may not be enough, or may be too much. Overpaying is not what cloud computing is supposed to be about either, but right now that very well may be the case.

But not in the future. No, in the future the infrastructure sees the requests, the users, the traffic patterns, and the performance of the application; it will process the needs of the application based on the context and capabilities of the infrastructure and the business needs and then determine when an application needs more compute resources. It will further be able to signal management systems or invoke the proper methods itself that will provision the resources needed to ensure the application scales. That same infrastructure should - and hopefully will - be able to determine at what point vertical scalability is no longer ensuring application performance meets business criteria (or has met some compute ceiling) and can then decide to provision resources using horizontal scaling techniques instead.

The intelligence to interpret the technical context and measure it against business needs. The ability to connect and integrate to gather and share that technical context. The flexibility to automatically determine whether horizontal or vertical scaling is necessary to meet those business criteria. That’s a dynamic infrastructure, that’s what we’re trying to enable via Infrastructure 2.0.

That’s the future of cloud computing. That’s where we’re going. And that’s why it’s so exciting to see the beginnings of it happening with virtual images; because it is just the beginning and people are starting to really flex the boundaries of cloud computing which will lead to even more innovation and change and shift into a higher gear so we can get where it is I hope we’re going a little bit faster.



Technorati Tags: MacVittie,F5,Infrastructure 2.0,dynamic infrastructure,cloud computing,RighScale,Amazon,ELB,EC2,AWS,vertical scalability,horizontal scalability,scalability,context,integration,load balancing

Related blogs & articles:

Cloud Computing: Vertical Scalability is Still Your Problem

Incomplete Thought – Cloudanatomy: Infrastructure, Metastructure & Infostructure

The Cloud Is Not A Synonym For Cloud Computing

Amazon Elastic Load Balancing Only Simple On the Outside

Infrastructure 2.0 Is the Beginning of the Story, Not the End

Infrastructure Integration: Metadata versus API

The Infrastructure 2.0 Trifecta

Infrastructure 2.0: As a matter of fact that isn't what it means

Infrastructure 2.0: Flexibility is Key to Dynamic Infrastructure

Does a Dynamic Infrastructure Need ARP for Applications?

read more

IT Myths and Legends

Mon, 26 Oct 2009 07:09:00 EDT

There is a common myth that the reason legacy code continues to run in businesses around the world is that no one understands it; that IT and businesses are afraid to replace it because they don’t know what it does.

Once again, living in the mainframe capital of the world (the insurance industry heavy midwest), I get to talk to IT folks who deal with legacy software and hardware all the time. Do not doubt that they know exactly what that legacy software does and how it works, and perhaps frightening to proponents of change and the benefits of emerging technology those IT organizations are still developing software for those legacy platforms.

THE TIGHT-COUPLING OF SOFTWARE AND THE BUSINESS

I’m sure there are plenty of organizations out there with some legacy software running that no one understands and for which the organization has no one with the skill set to migrate to a more modern system. But I’m of the opinion that there are far more organizations out there with legacy software running that has simply become too expensive and laden with risk to migrate. Software that is core to the business, that essentially has become the business over time carries with it an exceedingly high risk – if it fails, the business fails, and in a way that’s very real and very costly. There is a high level of not only software but business integration that happens over time with critical systems and it is that integration and dependence on specific legacy systems that deters organizations from even considering a migration to a more modern system.

These IT organizations know what the legacy software does; in fact they continue to develop new functionality and systems that integrate with and depend on those systems, and they invest in human capital by specifically training new developers and architects on those systems and legacy platforms. The original developers have long since moved on and up – to project and program managers who are more than willing to evaluate new platforms and systems but who also understand the risks to the operational effectiveness of both IT and the business should something go wrong.

Legacy systems developed in the early 1970s are still being maintained because the risks outweigh the potential benefits. These decades old systems are so integral to the continued operation of IT and the business that the risk inherent in migration is simply too high to justify such an undertaking. With so much time and money invested in these systems they are as close to perfection as software gets, and any migration to new platforms runs the risk of introducing errors and new flaws that would need to be worked out over time. Too, every integrated system would need to be updated, which incurs the risk that those systems would have errors and issues. It's actually mind-boggling to consider the effort that would be required to accomplish such a Herculean task.

IF IT AIN’T BROKE, DON’T FIX IT

That’s not to say these organizations have not invested in new architectures, solutions, and platforms over time. Indeed, they have, and there are plenty of heterogeneous environments out there with a good mix of both legacy and modern software not only in production, but integrated and orchestrated together in what is a big melting pot of application development environments. Modern systems are used to interface to users and customers, but the core software upon which these businesses rely is ancient, legacy software that may never be replaced. As long as the supplier of both the hardware and the software development environments continues to support it there’s no reason for these organizations to change.

With many organizations wholly reliant on legacy software it is more likely the case that comfort levels drive continued reliance on these systems than ignorance. It is exactly because they understand and trust the systems in place that they continue to build on them, to integrate them, and rely upon them to power their businesses day in and day out.

It is hard to justify why an organization should migrate its entire business to a new platform and new software that might be error-prone and requires millions of man-hours to migrate when a comfortable system that just works already exists. The costs to train new developers and architects is by and large less of an investment than attempting to re-architect an entire ecosystem of applications while that ecosystem is evolving. Because of the time it would take to migrate such systems – and prove their correctness – there is no way to “go dark” until it’s done; it would have to be accomplished while new systems are being integrated and put into place. You’d almost need two IT organizations to get it done – one to work on and maintain the old architecture and one to work on and migrate the new one. That’s not counting the costs to invest in a completely new architecture requiring new platforms, new hardware, new software, and new developers.

SOA ENABLED CONTINUED RELIANCE

What’s ironic is that SOA was purported to provide the means by which migrations could occur but instead enabled the continued reliance on legacy systems. Organizations implemented web services interfaces to legacy systems, but never took the next step; they did not use the inherent decoupling of interface from implementation provided by SOA and its standards to replace the implementation. Instead, web services became exactly what some feared: little more than a method of integration; a bridge between two worlds. And thus it has remained, with service-enabled interfaces it is easy enough for organizations to update presentation layer and user-interface technology, to take advantage of emerging web application models without giving up the comfort and trust they have in their core systems.

Even if these organizations started a migration today it would still be years if not decades before every legacy software system was replaced with something more “modern”. That’s why it’s important amidst the hype of cloud computing and social networking and web 2.0/3.0/4.0 that we not lose sight of the fact that not every organization is simply going to rip and replace their entire architecture in favor of the latest and “greatest” new data center model. We need to continue to support internal hybrid models of application architecture as well as hybrid data center architectures. In the application delivery space this is a lot easier than it might be for some: applications are applications, protocols are protocols, and network traffic is network traffic. Application delivery platforms, at least, are capable of supporting both legacy software and modern implementations at the same time, on the same solution, without equal alacrity. Whether that enables organizations to move from legacy to modern, or offers a means by which more modern technology can be applied to legacy systems without requiring modification to those applications is up to the organization.

Legacy software isn’t going away, and whether we like it or not the number of legacy systems is growing each year because organizations can’t afford the risk to their business and can’t justify the investment to change. So even as we continue to look forward to how emerging data center and application architectural models can provide benefits and solve problems we need to continue to evaluate how to support aging technologies and provide them, as well, with the tools necessary to keep their applications secure and available.



Technorati Tags: MacVittie,F5,legacy,software,hardware,cloud computing,infrastructure,application delivery,cobol,integration,web,internet,blog

Related blogs & articles:

IT Myths and Legends: Sharing Servers

Forklifts, Rip and Replace, and Other IT Fairy Tales

Application Delivery: Loose-Coupling for Legacy Apps

Load Balancing on the Inside

The Thing Private Clouds Can Do that Public Clouds Can’t

Infrastructure 2.0 Isn’t Just For Cloud Computing

A Formula for Quantifying Productivity of Web Applications

Business-Layer Load Balancing

read more

The Cloud Is Not A Synonym For Cloud Computing

Thu, 22 Oct 2009 14:15:00 EDT

“Where are you storing your data these days,” he asked casually after trying to come up with a better opening line but failing.

“Ah, dahhling,” she drawled while gesturing in no particular direction with an almost deprecating wave of her hand. “The Cloud, where else?”

Thanks to the nearly constant misapplication of the phrase “The Cloud” and the lack of agreement on a clear definition from technical quarters I must announce that “The Cloud” is no longer a synonym for “Cloud Computing”. It can’t be. Do not be misled into trying, it will only cause you heartache and headaches. The two no longer refer to the same thing (if they ever really did) and there should be no implied – or inferred - relationship between them. “The Cloud” has, unfortunately, devolved into little more than a trendy reference for any consumer-facing application delivered over the Internet.

Cloud computing, on the other hand, specifically speaks to an architectural model; a means of deploying applications that abstracts compute, storage, network, and application network resources in order to provide uniform, on-demand scalability and reliability of application delivery.

Of similar importance is the distinction between “user” and “consumer”, and this is important enough that we need to nail this down and be particular in our usage of these terms. “Consumer” is anyone who uses a web-application to do anything. Consumers make use of applications over the Internet, but they are not “users” of cloud because they don’t interface with “cloud” any more than they interface with hosting providers; they interface with an application. Users of cloud are developers, administrators, and IT organizations that interface with a cloud computing environment with the intention of deploying an application for their consumers.

I’m really not all that concerned whether we use “application user” and “cloud user” to distinguish between the two or “consumer” and “user” or “application customer” and “cloud customer”. I am firm in the belief that we need to distinguish between the two before we go any further down this road. The lack of distinction between the two points of view continues to confuse just about everyone who isn’t knee-deep in the technology and this is partially responsible for the Chicken Little responses to application failures that may or may not be deployed atop cloud computing architectures.

“The Cloud” has lost meaning as far as cloud computing models and data center architectures are concerned and is now little more than a technical-sounding term thrown around by consumers – and others - who never really understood the use of this delightful little phrase or that there’s even a difference. Maybe that’s success, as consumers shouldn’t care about internal implementation, but it’s also failure because it’s confusing to a lot of people who are supposed to care and be able to differentiate.

CLOUD COMPUTING AND APPLICATIONS ARE NOT INTERCHANGEABLE

When you deploy an application in a cloud computing environment and something goes wrong, who does the consumer call? Not the cloud computing provider. That’s a by-product of not caring about implementation – they aren’t supposed to know that information in the first place. It’s a near certainty that BitBucket’s customers or consumers, whichever you prefer, weren’t calling Amazon when its application became unavailable due to a DDoS attack, they were e-mailing, tweeting, and calling BitBucket – the application provider. Similarly, T-Mobile customers were likely calling, well, T-Mobile after Microsoft’s spectacular failure because they are the provider as far as customers are concerned, not Microsoft.

It’s not like a customer or consumer can call 1-800-THE-CLOUD and get support for whatever problem they’re having with whatever application they may have been using. They interface with an application, they use an application, and whoever is responsible for that application (hint: that’s you) is who they’re going to call and blame in the event of an outage, or a data loss, or a security breach.

That’s why it’s important that the cloud computing user, that’s you, have some knowledge of the cloud computing provider’s implementation. You don’t need to know the nitty gritty details, but you do need to understand whether the model is appropriate to meet your business and technical needs. Automatic scalability is often assumed to be part and parcel of a cloud computing environment, but that’s not always the case. If you need that scalability you’d darn well better understand whether it’s just part of the offering or whether you have to do something special to provision it. If your application suddenly doesn’t work when it’s deployed in a cloud computing environment, maybe you didn’t verify whether the provider’s load balancing solution is sticky or not, or whether there’s something you need to configure, specify, or modify in your application to make sure it works properly.

Somewhere along the lines the lack of distinction between users of an application and users of the cloud led to the erroneous and dangerous belief that users of cloud computing don’t have to know anything about the implementation. That’s just not true and it can be detrimental to not only the success of cloud computing but more specifically and closer to home, I’m sure, to the success of your application deployment.

The way in which we describe technology can and does have a profound impact on the way we use it, understand it, and support it. So let’s be more clear about who interfaces with what, and maybe in the future more people will be less apt to put forth the notion that a failure in the cloud is the same as a failure of cloud computing.

No, I won’t hold my breath, but I can hope, can’t I?



Technorati Tags: MacVittie,F5,cloud,cloud computing,infrastructure,architecture,provider,application delivery,scalability,terminology,failure,bitbucket,amazon,microsoft,sidekick

Related blogs & articles:

T-Mobile Data Loss Falsely Reflects on Cloud Computing

Five questions you need to ask about load balancing and the cloud

Cloud Computing: The Last Definition You'll Ever Need

We Don’t Know What Cloud Is But What We’re Doing It

Get your SaaS off my cloud

Cloud is Not a Big Switch

Intercloud: The Evolution of Global Application Delivery

Cloud Balancing, Cloud Bursting, and Intercloud

The Infrastructure 2.0 Trifecta

The Context-Aware Cloud

read more

WILS: Why Does Load Balancing Improve Application Performance?

Thu, 22 Oct 2009 07:13:38 EDT

IMAGE CREDIT: DANIEL PENNEY

Everyone has surely experienced the frustration of an overloaded desktop/laptop. You’ve just got too many apps open at one time and the performance of your machine has been slowly degrading to the point where you can select an application from the toolbar, run down to the local Starbucks, stop and chat with a friend, and return to find the application still not ready for use.
The same thing happens on servers. Even though a web/application server is likely only running a few critical applications, the more connections and requests it tries to process the more compute resources it consumes and the slower it executes. That slow execution results in poor application performance.

The solution is to free up resources. That’s typically done by adding a second server and a load balancing, thereby distributing the total load across two or more servers. This means each server is doing less work, which translates into faster execution times and thus better application performance. The load balancer can also take performance into consideration when deciding which server should respond to a request. By keeping track of the response times of each application, the Load balancer can use an algorithm known as “fastest response time” to choose which server should respond. This distributes requests based on how fast a server responds and thus should improve overall application performance.

This technique runs contrary to current consolidation initiatives, however, where the goal is to reduce the total number of physical servers in an effort to reduce associated operating expenses. Load balancing still helps improve performance in this situation, even if there is only one server being used to serve an application, because it can free up resources by offloading some of the tasks typically associated with serving applications. SSL processing, cookie encryption/decryption, compression, and caching are just a few of the ways in which “load balancing” frees up resources on servers – physical or virtual – and thus reduces the burden on servers that is causing slow execution and poor application performance.

Introducing a load balancer into an architecture isn’t necessarily a panacea, but it does offers options to network and application architects looking for the means to improve application performance.

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.



Technorati Tags: MacVittie,F5,load balancer,load balancing,offload,SSL,caching,optimization,acceleration,performance,cookies,encryption,decryption,architecture,web,internet,blog,WILS

Related blogs & articles:

WILS: The Concise Guide to *-Load Balancing

WILS: Network Load Balancing versus Application Load Balancing

WILS: InfoSec Needs to Focus on Access not Protection

WILS: Applications Should Be Like Sith Lords

WILS: Cloud Changes How But Not What

WILS: Application Acceleration versus Optimization

WILS: Automation versus Orchestration

If Load Balancers Are Dead Why Do We Keep Talking About Them?

read more

Meh. It's Just Data.

Tue, 20 Oct 2009 10:15:00 EDT
There seems to suddenly be a lot of focus on “data” and the ability for users consumers to pack up their data and take it wherever they want. Except for people attached to their i-Thing. I think users of i-Things were approached about the concept but were unable to get past the revelation that there are other “i-Things” out there from other vendors in the first place. Regardless, the core concept appears a laudable goal and rational desire. After all, the data was probably created by the consumer and thus, by most people’s definitions, they own the data. It’s theirs, so they should be able to move it hither and fro at will. But what is “data”?
read more

Location, Location, Location

Mon, 19 Oct 2009 07:15:10 EDT

Mobile devices may still be somewhat awkward in terms of supporting rich, web-based applications but they are leaps and bounds ahead of most infrastructure in their ability to figure out where you are.

GeoLocation technologies used to be used by load balancing solutions to address poor application performance across high-latency connections such as intercontinental and satellite links. While this is still an important variable in assuring application performance, especially for very large sites, GeoLocation is increasingly used to comply with legal restrictions on broadcasting, export of data and applications, and to provide more relevant information to users than ever before. The accuracy of the GeoLocation technology plays a huge role in the successful application of location-based services.

For example, US law prohibits doing business with certain countries, so many organizations need to have a way to recognize where a user is coming from and block their access if necessary. Traditionally, this is done in the application, but this is complex, expensive, and insecure. Similarly, a broadcaster may have rights to stream the Olympics in one country, but needs to block access from other countries. And more near and dear to the hearts of many folks in the US this time of year, NFL football broadcast agreements require blackouts in local areas when games not sold out, but folks circumvent this restriction by going to the web. Accurate GeoLocation prevents those in the local area from accessing the broadcast but allows others.

Generally speaking GeoLocation has been promoted as a means to block access, which for many people leaves a sour taste in their mouth. It isn’t doing them any good as they aren’t trying to download, watch, or otherwise access an application that is subject to trade or export or broadcast restrictions. But GeoLocation can work for people, too, and for people who might not think it’s all that important to improve the user-experience as well as provide a measure of protection against misuse of their personal, private data and accounts.

GEOLOCATION IS FOR EVERYONE

First and foremost the use of GeoLocation for proximity based access to applications transparently helps everyone. Being directed to the application instance or web site that’s physically closest to you mitigates the effect of speed of light limitations on application performance. For organizations with very large web presences, this is also an efficient method of distributing resources as scaling out an application in New York, where there are millions of users, but not in Topeka, Kansas where there might be only a few thousand makes better use of compute resources in general. But before you can determine where to best allocate resources you have to know where users are located and that requires an accurate GeoLocation technology.

Consider the potential use of GeoLocation in real-time identity theft recognition. If you’re required to enter the credit card number and a billing zipcode and it turns out that you’re actually using the card in a completely different zipcode, a second security check could be required – perhaps you have to provide some snippet of information prearranged with the provider – before you can conclude the transaction. Inconvenient if you travel a lot, to be sure, but those few seconds of inconvenience might prevent the use of your credit card by some miscreant simply because they weren’t physically in an expected location. Fraud detection systems already perform this type of check when the transaction occurs using a physical (POS) terminal, but not necessarily when the transaction is completely web-based.

Similarly, and we’ve talked about this before, what if cloud-based applications like social networking sites were imbued with the ability to recognize that usually you access the application from location X and thus an attempt to access from location Y might mean you’re traveling, or it might mean malicious activity? And it took steps to further verify that you are you, and not some miscreant hijacking your account?

And what if other sites were smart enough to recognize where you were without you needing to change some setting somewhere, so that when you did travel and you looked up “weather.com” it automatically detected where you were and gave you the weather report for that zipcode? What about search engines? Wouldn’t it be nice if you’re out traveling and hit a search engine to find a restaurant and it ranked based on proximity to your current location, too? Searching for your favorite restaurant chain or hotel, for example, would prioritize the local locations first.

Indeed, if Intercloud and cloudbalancing is to be achieved GeoLocation will need to be a part of the implementation as location impacts performance and other application-specific content availability. Decisions about which instance of the application a user should be directed will certainly need to incorporate location as one of the variables that make up a request’s context.

Yes, I know the iPhone has an app for that – because it’s GPS-enabled and the accuracy of that information is highly trustable. But on the web it’s not always been the case that GeoLocation-based lookups were accurate enough to limit functionality or access or provide location-based services. But they’ve come of age, and location is one of the pieces of the contextual puzzle that will help “the cloud” become more aware and intelligent about decisions that could – or should – involve location.



Technorati Tags: MacVittie,F5,intercloud,cloud,cloud balancing,geolocation,gps,location,context,global application delivery,web,internet,blog

Related Blogs & Articles:

holder

Is Proximity Hosting an Elderly Concept?

Cloud Balancing, Cloud Bursting, and Intercloud

Intercloud: The Evolution of Global Application Delivery

The Context-Aware Cloud

The Infrastructure 2.0 Trifecta

Denied!

Picard and Dathon at El-Adrel

Windows Vista Performance Issue Illustrates Importance of Context

Infrastructure 2.0: As a matter of fact that isn't what it means

read more

Amazon Elastic Load Balancing Only Simple On the Outside

Fri, 16 Oct 2009 09:00:00 EDT
The notion of Elastic Load Balancing, as recently brought to public attention by Amazon’s offering of the capability, is nothing new. The basic concept is pure Infrastructure 2.0 and the functionality offered via the API has long been available on several application delivery controllers for many years. In fact, looking through the options for Amazon’s offering leaves me feeling a bit, oh, 1999. As if load balancing hasn’t evolved far beyond the very limited subset of capabilities exposed by Amazon’s API. That said, that’s just the view from the outside. Though Amazon’s ELB might be rudimentary in what it exposes to the public it is certainly anything but primitive in its use of SOA and as a prime example of the power of Infrastructure 2.0. In fact, with the exception of GoGrid’s integrated load balancing capabilities, provisioned and managed via a web-based interface, there aren’t many good, public examples of Infrastructure 2.0 in action. Not only has Amazon leveraged Infrastructure 2.0 concepts with its implementation but it has further taken advantage of SOA in the way it was meant to be used.
read more

Putting a Price on Uptime

Fri, 16 Oct 2009 06:15:00 EDT

A lack of ability in the cloud to distinguish illegitimate from legitimate requests could lead to unanticipated costs in the wake of an attack. How do you put a price on uptime and more importantly, who should pay for it?

A “Perfect Cloud”, in my opinion, would be one in which the cloud provider’s infrastructure intelligently manages availability and performance such that when it’s necessary new instances of an application are launched to ensure meeting the customer’s defined performance and availability thresholds. You know, on-demand scalability that requires no manual intervention. It just “happens” the way it should.

Several providers have all the components necessary to achieve a “perfect cloud” implementation, though at the nonce it may require that customers specifically subscribe to one or more services necessary. For example, if you combine Amazon EC2 with Amazon ELB, Cloud Watch, and Auto Scaling, you’ve pretty much got the components necessary for a perfect cloud environment: automated scalability based on real-time performance and availability of your EC2 deployed application.

Cool, right?

Absolutely. Except when something nasty happens and your application automatically scales itself up to serve…no one.

AUTOMATIC REACTIONS CAN BE GOOD – AND BAD

BitBucket’s recent experience with DDoS shows that no security infrastructure is perfect; there’s always a chance that something will sneak by the layers of defense put into place by IT whether that’s in the local data center or in a cloud environment. The difference is in how the infrastructure reacts, and what it costs the customer.

Now, a DDoS such as the one that apparently targeted BitBucket was a UDP-based attack, meaning it was designed to flood the network and infrastructure and not the application. It was trying to interrupt service by chewing up bandwidth and resources on the infrastructure. Other types of DDoS, like a Layer 7 DDoS, specifically attack the application, which could potentially consume its resources which in turn triggers the automatic scaling processes which could result in a whole lot of money being thrown out the nearest window.

Consider the scenario:

An application is deployed in the cloud. The cloud is configured to automatically scale up (launch additional instances) based on response time thresholds.

A Layer 7 DDoS is launched against the application. Layer 7 DDoS is difficult to detect and prevent, and without the proper infrastructure in place it is unlikely to be detected by the infrastructure and even less likely to be detected by the application.

The DDoS consumes all the resources on the application instance, degrading response time, so the infrastructure launches a second instance, and requests are load balanced across both application instances.

The DDoS attack now automatically targets two application instances, and continues to consume resources until the infrastructure detects degradation beyond specified thresholds and automatically triggers the launch of another instance.

Wash. Rinse. Repeat.

How many instances would need to be launched before it was noticed by a human being and it was realized that the “users” were really miscreants?

More importantly for the customer, how much would such an attack cost them?

THIS SOUNDS LIKE A JOB FOR CONTEXTUALLY-AWARE INFRASTRUCTURE

The reason the perfect cloud is potentially a danger to the customer’s budget is that it currently lacks the context necessary to distinguish good requests from bad requests. Cloud today, and most environments if we’re honest, lack the ability to examine requests in the context of the big picture. That is, it doesn’t look at a single request as part of a larger set of requests, it treats each one individually as a unique request requiring service by an application.

Without the awareness of the context in which such requests are made, the cloud infrastructure is incapable of detecting and preventing attacks that could potentially lead to customer’s incurring costs well beyond what they expected to incur. The cost of an attack in the local data center might be a loss of availability, an application might crash and require the poor guy on call to come in and deal with the situation, but in terms of monetary costs it is virtually “free” to the organization, excepting the potential loss of revenue from customers unable to buy widgets who refuse to return later.

But in the cloud, this lack of context could be financially devastating. An attack moves at the speed of the Internet, and a perfect cloud is hopefully designed to react just as quickly. Just how many instances would be launch – incurring costs to the customer – before such an attack was detected? For all the monitoring offered by providers today it’s not clear whether any of them can discern and attack scenario from a seasonal rush of traffic, and it’s further not clear what the infrastructure would do about it if it could.

And once we add in the concept of intercloud, this situation could get downright ugly. The premise is that if an application is unavailable at cloud provider X according to the customer’s defined thresholds, that requests would be directed to another instance of the application in another cloud, and maybe even a third cloud. How many cloud deployed versions of an application could potentially be affected by a single, well-executed attack? The costs and reach of such a scenario boggle the mind.

My definition of a perfect cloud, methinks, needs to be adjusted slightly. A perfect cloud, therefore, in addition to its ability to automatically scale an application to meet demand must also be able to discern between illegitimate and legitimate users and provide the means by which illegitimate requests are ignored while legitimate requests are processed and only scaling when legitimate volumes of requests require such.

PUTTING A PRICE ON UPTIME
The question I think many people have, I know I certainly do, is who pays for the resulting cost of such an attack?

It’s often been said that it’s difficult if not impossible to put a price on downtime, but what about uptime? What about the cost incurred by the launch of additional instances of an application in the face of an attack? An attack that cannot be reasonably detected by an application? An attack that is clearly the responsibility of the infrastructure to detect and prevent; the infrastructure over which the customer, by definition and design, has no control?

Who should pay for that? The customer, as a price of deploying applications in the cloud, or the provider, as a penalty for failing to provide a robust enough infrastructure to prevent it?



Technorati Tags: MacVittie,F5,application delivery,cloud,context-aware,security,web application security,scalability

Related blogs & articles:

Cloud Changes Cost of Attacks

Cloud Balancing, Cloud Bursting, and Intercloud

Intercloud: The Evolution of Global Application Delivery

The Context-Aware Cloud

The Infrastructure 2.0 Trifecta

Amazon Elastic Load Balancing Only Simple On the Outside

Web Application Security at the Edge is More Efficient Than In the Application

Layer 4 vs Layer 7 DoS Attack

An Unhackable Server is Still Vulnerable

The IT Security Flowchart

read more