WILS: A Good Hall Monitor Actually Checks the Hall Pass
Are you monitoring the network, servers, stack, or the application? The answer may mean the difference between your application being available or not. devcentral.f5.com
Random Postings on Application Delivery, Development, and SOA
Lori is a Technical Marketing Manager at F5 Networks, an experienced software developer, author, and technology editor, a geek, a mom, a wife, and an avid RPG gamer.
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.
Comments [0]
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?
With
virtualization in general all the rage right now, it's easy to get people
excited over the concept of virtualizing their desktop. The question is, why
would someone want to do such a thing to their desktop and to themselves? Are
they some kind of masochist? Do they hate themselves? Do they want to be less
productive? Do they need an excuse to take a coffee break while 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.
|
Lori MacVittie | Technical Marketing Manager, Application Services |
||
|
F5 Networks |
P 206.272.5555 |
F 206.272.5556 |
|
D 920.499.5165 |
M 920.819.5067 |
|
 |
||
Comments [0]
ROI Justification(s) for Application Delivery Controllers
|
|
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.
Comments [0]
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.
Comments [0]
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.
Comments [0]
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.
Comments [0]
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 |
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?
Comments [0]
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.
Comments [0]
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." |
Comments [0]
Comments [0]