Lori MacVittie’s posterous

If you're excited about the automation capabilities of cloud computing and virtualization, you are going to love this solution. In a virtualized environment where applications can ostensibly be popping up all over, and applications are no longer tied to specific servers, there is a need to automatically manage these application instances in a high-availability (load balanced) environment. What you need is the ability to automagically add and remove application instances from the application delivery controller (load balancer) so you don't have to worry about tying those applications down, which could reduce the benefits typically associated with virtualization.

If you aren't going to a fully virtualized and automated data center, you might be happy to know that you can still reap the benefits of this automated solution. Not only is this solution perfect for a virtualized environment, it's also just as great for a non-virtualized environment for automating availability of applications. Truth be told, the application and the solution doesn't care (nor should it) whether it's running in a virtual image or not; it merely "is".

In a nutshell, when an application initializes, it adds itself to the appropriate application pool on the application delivery controller. When the application is destroyed, it removes itself. This means no matter where the application instance is living - in a virtual image, in a different servlet container, on a new server - it will automatically be "discovered" and immediately become part of the high availability pool of servers.

Read the rest at DevCentral

Sometimes IT folks are tasked with coming up with the justification for purchasing technology. It's not an enjoyable task, and considering the incredible difficulty in trying to pin dollar values on soft factors like increased productivity and an improved user experience the chore can be quite painful. Technology that's become commoditized generally doesn't require ROI justification; when is the last time you were asked what the return on investment would be for a switch? Or a router? Or a server? If you've been in IT long enough the answer might be, "Oh, about 20 years or so ago." Even though load balancers are nearing commodity status, the application delivery controller is not despite the fact that the core of an ADC is load balancing. And in less than favorable economic times, the requirement to justify every purchase becomes, well, a requirement rather than a "it'd be nice to have this before you open the box, Ed."

Where's F5? Storage Decisions Sept 23-24 in New York Networld IT Roadmap Sept 23 in Dallas Oracle Open World Sept 21-25 in San Francisco Storage Networking World Oct 13-16 in Dallas Storage Expo 2008 UK Oct 15-16 in London Storage Networking World Oct 27-29 in Frankfurt

Unfortunately, even when the experts talk about how valuable an investment an application delivery controller might be right now, they rarely put numbers around it. And numbers, unfortunately, are what are necessary to justify the investment to the people who write the checks.

So let's look at a few ROI equations based on benefits of an application delivery controller that can help you justify your investment in an application delivery controller today.

Read the rest at DevCentral

No one likes to hear that they need to rewrite or re-architect an application because it doesn't scale. I'm sure no one at Twitter thought that they'd need to be overhauling their architecture because it gained popularity as quickly as it did.

Many developers, especially in the enterprise space, don't worry about the kind of scalability that sites like Twitter or LinkedIn need to concern themselves with, but they still need to be (or at least should be) concerned with scalability in general and the effects of inserting an application into a high-scalability environment, such as one fronted by a load balancer or application delivery controller.

There are some very simple things you can do in your code, when you're developing an application, that can ease the transition into a high-availability architecture and that will eventually lead to a faster, more scalable application.

Here's four things you can do now - and why - to make your application fit better into a high availability environment in the future and avoid rewriting or re-architecting your solutions.

Read the rest at DevCentral

Reuven Cohen of the Elastic Vapor blog, in this article, puts forth the notion that infrastructure is required to enable cloudbursting and then asks an excellent question:

The general premise of cloudbursting is to allow the cloud to act as overflow resources in the event your own infrastructure becomes overloaded. It's an active fail-over model, in a way, that ensures applications are available and performing well even when capacity in the local data center is exhausted.

The problem with an architecture that supports cloudbursting is that you want to be able to simultaneously leverage both the local data center and the cloud.

This keeps the cost of using the cloud at a minimum and maximizes the return on investment in your own infrastructure.

Sounds like quite a trick. But I don't think it's nearly as complicated as it originally sounds, unless I'm missing something or the sleep deprivation caused by a sick child is affecting me more than I think. 

Read the rest at DevCentral

The comparison between the power of a modern PC and a 1960's mainframe is often made in conjunction with a smug "look how far we've come" look.

But the way virtualization is headed today it's likely that mainframe holdouts will turn that smug look back on us with a blithe, "yes, you've gone all the way back to beginning."

If we're not careful, by the time we're through deploying virtual everything we're going to end up with a single PC comprising our data center. Which is pretty much like a mainframe, isn't it?

We're certainly headed that way. Virtual appliances for security, for switching, for many functions handled by network infrastructure are arriving daily. And we're lapping them up like a cat given cream.

Read the rest at DevCentral

The appeal of cloud computing is, in part, due to its obfuscated nature. The underlying delivery infrastructure is hidden in "the cloud" and can therefore largely be ignored by consumers - whether individuals or organizations.

Or can it?

Read the rest at DevCentral

Tony Bourke of the Load Balancing Digest points out that mega proxies are largely dead. Very true. He then wonders whether layer 7 persistence is really all that important today, as it was largely implemented to solve the problems associated with mega-proxies - that is, large numbers of users coming from the same IP address.

I'm going to say that layer 4 persistence would likely break a major site today. Layer 7 persistence is even more relevant today than it has been in the past for one very good reason: session coherence. Session coherence may not have the performance and availability ramifications of the mega-proxy problem, but it is essential to ensure that applications in a load-balanced environment work correctly.

Read the rest at DevCentral

Yesterday it was reported that BusinessWeek had been infected with malware via an SQL injection attack.

Read the rest at DevCentral

Ars Technica is reporting on a recent Pew study on cloud computing and privacy, specifically concerning remote data storage and the kind of data-mining performed on it by providers like Google, indicates that while consumers are concerned about the privacy of their data in the cloud, they still subject themselves to what many consider to be an invasion of privacy and misuse of data.

It's necessary, of course, that the EULA be written using the language of the courts under which it will be enforced. But there are two problems with EULAs: first, they aren't really required to be read and second, even if they were really required to be read, they can't be easily understood by the vast majority of consumers.

I'll be the first to admit I rarely read EULAs. They're long, filled with legalese speak, and they always come down to the same basic set of rules: it's our software, we don't make any guarantees, and oh, yeah, any rights not specifically listed (like the use of the data you use with our "stuff") are reserved for us. It's that last line that's the killer, by the way because just about everything falls under that particular clause in the EULA.

Caveat emptor truly applies in the world of cloudware and online services. Buyer beware! You may be agreeing to all sorts of things you didn't intend.

Read the rest at DevCentral