Lori MacVittie’s posterous

Random Postings on Application Delivery, Development, and SOA
September 30, 2008

How to instrument your Java EE applications for virtualization

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

 

 

 

Comments [0]



September 24, 2008

The day of the virtual desktop has come...and gone

Desktop virtualization. Virtual desktops. Application streaming. Whatever you want to call it makes no nevermind to me because the problem driving the entire concept is gone. Eradicated. Made irrelevant by the cloud. Made irrelevant by cloudware, SaaS (Software as a Service), and the ubiquitous browser.

I cannot count the number of times I've heard complaints about some form of desktop virtualization/application streaming in the past. It's slow. The server died in the middle of my exam. It's slow. There are no more licenses left. It's slow today (why do you add "today", it's slow every day!). Sensing a theme?

Microsoft Word loads from the network, obfuscated by layers of virtualization and licensing, slowed to a crawl by unnecessary technology?

Virtualization in the data center makes sense. It's about consolidation and efficiency. But there's nothing efficient about desktop virtualization or application streaming and in an age where browser-based applications are as rich and robust as their fat desktop-residing predecessors it just doesn't make any sense to clutter up the data center with an extra layer of application infrastructure that needs to be licensed, managed, maintained, patched, and upgraded.

Desktop virtualization never really made much sense to me, but now it really doesn't make any sense. The number of cloudware alternatives to traditional fat desktop applications is constantly growing and provide more than adequate functionality for the majority of business folks. For the privacy and security sensitive, locally hosted web-based alternatives to other constant companions like Outlook (Outlook Web Access, anyone?) have long been available to address the issue of desktop maintenance and management, and its rare to find an enterprise application today that isn't web-based, or at least web-enabled.

We're willing to run our entire businesses from a mobile device like an iPhone or a BlackBerry but for some reason we're still clinging to the notion that we need fat desktop apps when we're in the office. Balderdash, I say. Poppycock.

Read the rest at DevCentral

 

 

 

 

Lori MacVittie  |  Technical Marketing Manager, Application Services

F5 Networks 

  P 206.272.5555 

 F 206.272.5556

www.f5.com 

  D 920.499.5165 

 M 920.819.5067

 

 

Comments [0]



September 22, 2008

ROI Justification(s) for Application Delivery Controllers

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?


    

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

 

 

   

Click here to download:
ROI_Justifications_for_Applica.zip (3 KB)

Comments [0]



September 19, 2008

4 things you can do in your code now to make it more scalable later

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

 

Comments [0]



September 18, 2008

Building a Cloudbursting Capable Infrastructure

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:

To truly enable a capable cloudbursting infrastructure, I feel there needs to be a common consensus on how this may be archived and by what means. So the question in the short term is: what are some of the practical approaches, technologies and architectures needed to make this kind of hybrid cloud infrastructure feasible?

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

 

 

 

Comments [0]



September 18, 2008

Virtualization: Just how far are we wiling to take it?

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

 

Comments [0]



September 17, 2008

The Three "Itys" of Cloud Computing

Everyone's talking about cloud computing and cloudware (applications in the cloud) services and pointing to the hiccups of several major cloud providers already this year. Reliability, availability, and security are still major concerns, and yet some reports indicate these three "itys" aren't impeding adoption of cloud computing models at all.

Applications, whether in the cloud or in the corporate data center, are still delivered via a network. It is more often than not that the network is at the heart of both the successful and the unsuccessful deployment of applications.

Cloud Computing Adoption Grows Despite Concerns

Cloudware and Information Privacy: TANSTAAFL

Bursting the Cloud

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

Comments [0]



September 16, 2008

Why you still need layer 7 persistence

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.

Layer 7 persistence is still applicable to situations where you may have multiple users coming from a single IP address (such as a small client base coming from a handful of offices, with each office using on public IP address), but I wonder what doing Layer 4 persistence would do to a major site these days.  I’m thinking, not much.

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

 

 

Comments [0]



September 16, 2008

BusinessWeek takes viral advertising a bit too seriously

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

[begin Mom lecture]

Remember when we talked about PCI DSS being a good idea for everyone, even though it's just a requirement for the payment card industry? If I've told you once, I've told you a million times: safer is better, more protection never hurts.

[end Mom lecture]

The coolest thing about the web is that, unlike being a mom with one teenager left in the house, I don't have to actually repeat myself. I can just link to it again...and again...and again.

Interestingly, the aforementioned report indicates that "Sophos informed BusinessWeek of the infection last week, although at the time of writing the hackers' scripts are still present and active on their site."

Read the rest at DevCentral

 

 

Comments [0]



September 15, 2008

Cloudware and information privacy: TANSTAAFL

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.

68 percent of respondents who said they'd used cloud services declared that they would be "very" concerned, and another 19 percent at least "somewhat" concerned, if their personal data were analyzed to provide targeted advertising.  This, of course, is precisely what many Web mail services, such as Google's own Gmail, do—which implies that at least some of those who profess to be "very" concerned about the practice are probably nevertheless subjecting themselves to it.

One wonders why those who profess to be very concerned about privacy and data-mining tactics used by cloudware providers would continue to use those services?

One answer might lie in the confusing legalese of the EULA (end user license agreement) presented by corporations.

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

 

 

Comments [0]