The role of "application delivery expert" is really coming into its own of late, along with the understanding that the traditional siloed approach to management of applications in IT no longer makes sense.

TechTarget :: How networking professionals can prove their worth

Jim Metzler [vice president of Ashton, Metzler & Associates] recently worked with NetQoS to survey more than 175 NOC and non-NOC IT professionals about how the evolving role of the NOC affects both network and IT professionals.

Metzler moderated several sessions at Interop that had a single unifying theme: Application delivery is now an issue of critical importance for IT (and consequently network) staff, and successful application delivery depends upon the ability of that staff to transcend technology and organisational silos or "stovepipes."

He found that most NOC staff spend the majority of their time on application delivery and the WAN. "The network operations center is a lot more than networks," Metzler said in a phone interview. "In fact, I think it's a misnomer to use the phrase NOC or 'network' manager or 'network' engineer because the majority of their time is spent on other things."

This odd couple marriage between networking and applications has long been the focus of F5 and is the underlying foundation of solutions such as its Application Ready Networks.

I could write on and on about application delivery and why Mr. Metzler is so very right, but instead you might prefer listening to Forrester analyst Rob Whiteley and F5's Erik Giesa in this 37 minute webcast define Application Delivery Networking and how it solves critical deployment issues, including breaking out of those silos.

Imbibing: Mountain Dew

According to a recent ComputerWorld article, most retailers aren't ready for the forthcoming June deadline for PCI DSS compliance.

From ComputerWorld :: Few expected to make June 30 PCI deadline for Web application security

Most retailers will not meet the June 30 deadline for complying with new Payment Card Industry Data Security Standard (PCI-DSS) requirements for securing web applications. Companies can achieve compliance with either a specialized firewall or web application software code review, which entails finding vulnerabilities and fixing them. Many retailers appear to be opting for firewalls, which are "quick fixes," according to Gartner analyst Aviva Litan. "Application firewalls are a reactive measure. You have a lot of vulnerable applications that still need to be fixed," she added, and noted that scanning for vulnerabilities and fixing them should take precedence over firewalls, and that firewalls should be used in addition to scanning, not instead of it.

PCI DSS affects retailers more than any other business owing to their acceptance of credit cards online for purchases.

The quote in question references section 6.6, a somewhat controversial requirement that allows for vulnerability scans and code review or the implementation of a web application firewall as a means of meeting compliance.

There are several good reasons for implementing a web application firewall aside from meeting PCI DSS compliance. I agree with Aviva's assessment that both vulnerability scanning and web application firewalls together are a good idea, but disagree that firewalls are simply reactive measures and "quick fixes". This perception seems to assume that we're looking at the problem from the viewpoint of a new application, not one that is running in production right now.

Web application firewalls are your first line of defense against new and existing web application threats. They are generally capable of preventing even emerging attacks, and are quickly updated when new threats are discovered. Those deployed in conjunction with or on an extensible application delivery platform provide additional value in the capability to dynamically create policies to address emerging threats or custom threats against your application.

They can CYA (cover your apps) while you find and fix the vulnerabilities, a process that requires development, testing, and redeployment. And while you're going through that process - what's going on with your application? Have you taken it offline because it's vulnerable? Were you aware of the specific attack vector when you developed the application?

No, you probably haven't, especially not if you're in the retail business because if your application is down then you are losing revenue and that's not acceptable. And no, you probably weren't aware of that attack when the app was developed because it hadn't been discovered yet.

But if you've got a web application firewall (WAF) you are likely able to continue running your application, secure in the knowledge that the WAF is going to be able to thwart a wide variety of known attacks while you scan, find, and fix the vulnerabilities in your application whether those are emerging threats or existing ones.

Deploying a WAF doesn't make an organization short-sighted or imply that they aren't going to address any vulnerabilities found in their applications. On the contrary, it implies that an organization is realistic; that it understands that no matter how many vulnerabilities their application is secure against today that a new one is going to appear. Maybe not tomorrow or next week or even next month, but it will appear. And they know their application is not likely to be protected against that brand new attack, neither will they likely be able to address that new attack fast enough to protect their application. They know that a WAF, however,  is likely to updated very quickly, or at least have the means by which a fix can be put into place while they go about updating their application.

Deploying a WAF isn't reactive, it is proactive defense against existing and future threats. It isn't replacing the security sought through vulnerability scanning, it's augmenting and enabling that process while protecting the business' investment in its web presence. That's risk management and proactive security.

Imbibing: Coffee

At Web 2.0 Expo Microsoft essentially stole the show with the introduction of its Live Mesh platform. Live Mesh is, essentially, an integration hub that incorporates and manages Internet connected devices that today are unrelated and managed individually using open standards.

Microsoft might not like the term "integration hub", but that's basically what it is. Yes, on the surface it's a platform that enables inter-device communication and seamless access to a variety of services, but under the hood it's got to be doing some pretty complex integration work. While Microsoft plans on using open standards, that doesn't mean that those standards allow devices to communicate directly. My Blackberry, Outlook, and storage devices don't use the same interface, after all; in order to communicate and share data across disparate device there must be some kind of integration (i.e. translation of data formats) going on.

Now that sounds cool. Who wouldn't be interested in being able to copy data from remote or local storage over to their digital picture frame? Or from their camera to their picture frame and their remote storage for backup?

This is one heck of an initiative, and it sounds hella cool. But (and there's always a but) it's going to take a massively resilient and flexible infrastructure to ensure that all the disparate points in the mesh are always available, secure, and perform up to consumer expectations. Microsoft is right in that consumers, because this is the market at which Live Mesh is targeted, do just want things to work.

The danger in these kinds of initiatives is the same danger that's always existed: if you fail to ensure that your infrastructure can handle a new application you may be faced with a massive, hurried "fix-it" project after the fact. First impressions are the most important, and if you got it wrong the first time it's very difficult to change that and convince potential customers you got it right the next time.

This is where things are going to get ugly. Microsoft can certainly ensure that its services are available, secure, and fast within the mesh. But if this platform is successful customers will want to include other services from other vendors in their mesh (which is what Microsoft anticipates, that's all good) and that means other services - over which Microsoft does not have control - may negatively impact consumer perception of mesh. Which means that Microsoft will need to impose some kind of service level agreements on service providers who wish to make their services available in "the mesh" and that service providers are going to have to ensure that their application delivery infrastructure can provide fast, secure, and always available access for its services.

Acceleration, security, optimization, intelligent routing...all these capabilities will be necessary to ensure that every service in the mesh is available, secure, and fast as well as highly scalable. How about secure remote access so you can access your "devices" at work while you're at home, and vice versa? The possibilities here are endless, but they are going to require a lot of infrastructure support to make them all reality.

If - and I do mean if - this takes off as well as Microsoft hopes, it certainly could be the killer-app for application delivery.

Imbibing: Coffee

Anyone who's listened to Bob Rivers' Twisted The Twelve Pains of Christmas can probably relate to the angry husband screaming, "When one light goes out they all go out!" because, yeah, we've all been there.

Imagine now, if you will, a data center. A data center filled with servers humming along, each running three or four applications in virtual machines a la VMWare. Imagine now - it shouldn't be hard at all - that one of those servers suddenly just stops working. Let's say the drive crashes.

After the blue smoke dissipates and the screams of "When one component crashes they all crash" fade away, it's time to consider what just happened. (Yeah, the analogy here is a stretch, but try to go with it this morning, okay?)

Yes, OS virtualization has its benefits, there's no doubt about that. But like SOA and the challenges associated with composition-based application development, there are some interesting challenges associated with virtualizing the data center using OS virtualization. This challenge is particularly frustrating because aside from ensuring that the underlying hardware and OS upon which the virtualization solution is installed are stable and redundant, there isn't anything you can do to prevent this scenario from taking down not one but all the applications running within virtual containers on that server.

Even if it isn't a crash that causes the downtime, maintenance, upgrades, and patches will require the server be shutdown or rebooted, which means all the applications running within virtual containers on that server are going down.

You may recall that I walked through a BEA TCO analysis of virtualization and ended up with some controversial results. This subject is no different in that regard.

You'll notice that the blue in the stacked graph here represents "unplanned downtime". Now, I'm not sure what the definition of unplanned downtime is, but I assume that it's downtime that wasn't planned. :-) Seriously, I make the assumption that this category includes downtime resulting from things like hardware component failure, emergency patches, etc...

I find it interesting that the non-virtualized environment has more unplanned downtime than the virtualized OS. Presumably this is because there are fewer hardware servers and thus fewer things that can go wrong to cause the downtime in the first place.

What bothers me is that the cost of unplanned downtime must necessarily include things like lost revenue and productivity, and this is likely to be higher in a virtualized OS architecture because if one server crashes multiple applications are likely going to be affected. Imagine if it was SOA services and processes deployed across a virtualized OS architecture. Talk about a ripple effect.

Regardless of whether its SOA or traditional web-applications deployed on a non-virtualized or virtualized OS architecture, you need some kind of assurance of availability and resiliency. That kind of assurance comes from an application delivery network.

So if you're trying to mitigate the risk associated with downtime in either environment an application delivery network is going to be your best option. Even though you can bring new instances of your applications on-line in the event of a failure - extremely quickly and painlessly in the case of a virtualized OS architecture - you still have to make sure clients and customers can actually reach the new instance, and that means some sort of intelligent routing capability - the kind of intelligence you get with an application delivery controller as part of an application delivery network.

Imbibing: Coffee

There's a lot of things that BIG-IP can do to improve the reliability, scalability, and performance of Web 2.0 applications. But there are always two sides to every story, and so it is with BIG-IP and Web 2.0, or specifically, AJAX.

This latest article, Getting Started with iControl and AJAX, offers advice and code to get you started building a custom AJAX-based dashboard for BIG-IP.

Imbibing: Coffee

I'm working on something else that's sort of related to this subject and noticed that rpaan polished the PHP code for this article on using PHP and iControl. It's nice. Great stuff, rpaan, and THANKS!

Imbibing: Water

This is an interesting article from Network World about how CIOs in Australia and New Zealand perceive security as being easier than reducing costs.

The IDC Annual Forecast for Management report surveyed 363 IT executives from Australia (254 respondents) and New Zealand (109 respondents) across industries including finance, distribution, leisure and the public sector.

CIO Challenges
Application layer threats	36%
Spyware	16%
Information Security	Bottom of the stack

The CIOs top priority for the next 12 months was reducing costs and addressing a lack of resources.

Okay,  here's a RADICAL idea. Let's reduce costs and address a lack of resources while dealing with application layer threats - all at the same time. 

Not kidding. A web application firewall (WAF) can address application layer threats. Because the WAF is performing an ever-vigilant watch over the applications, developers and security professionals can concentrate on other things - freeing up resources and reducing costs.

What's also interesting is that if the WAF is paired with an intelligent application delivery controller, capable of fully inspecting and manipulating requests and responses, you can also address that information security concern with the ability to dynamically adjust security policies when/if necessary to address emerging or newly discovered threats. While the CIO may not be so concerned about information security, I can't imagine that the guys in the trenches would put that concern at the bottom of the stack. They aren't called "Information Security Professionals" for nothing, after all.

Aren't convinced that a WAF is the right way to go? Well, the PCI Security Standards Council believes in WAF capabilities enough to make it one of two options in PCI DSS, specifically requirement 6.6. That's non trivial.

Also consider this analyst report from Stratecast, or this discussion on some of the benefits of centralizing application security.

Imbibing: Mountain Dew

Tech Republic blogger Toni Bowers discusses five high-tech skills that are waning as far as ability to command high salaries according to a recent Network World article. At the top of the list? HTML.

Denise Dubie writes in the Network World article:

As companies embrace Web 2.0 technologies such AJAX, demand for skills in HTML programming are taking a back seat. According to Foote Partners, pay for skills in technologies such as Ajax and XML increased by 12.5% in the last six months of 2007, while IT managers say they don’t see a demand for technology predecessors such as HTML. "I’m not seeing requirements for general Web 1.0 skills -- HTML programming skills," says Debbie Joy, lead solution architect for CSC in Phoenix.

Dude, wait? What?

I hate to be the one to break this news, but HTML is still very necessary in a Web 2.0 world. All the AJAX in the world isn't going to be very useful to clients if it can't be displayed and guess how that happens? Yes, good old HTML.

While it's true that in a Web 2.0 world the HTML is predominantly programmatically generated, but it's still HTML whether it's spit out by a server-side script/application like ASP or PHP or patched together using JavaScript and XML.

Someone still has to understand HTML and generate it and it isn't likely that the use of HTML is going to decline any time in the future. In fact, I wouldn't hire a "web application developer" who didn't know HTML. That'd be full of all kinds of fail. 

Now I've never been a fan of calling HTML "programming", because it's demeaning to code monkeys everywhere. (That's called irony, folks) The ability to write HTML makes you a programmer like banging out "chopsticks" makes you a concert pianist. And I think that the decreasing emphasis on HTML is related directly to the explosion of HTML "programmers" during the dot.com days, when anyone who understood how to write the markup for a table could get a fairly well paying gig doing just that. Today's web is built dynamically, and that requires "real" - or at least more real - programming skills because the languages through which HTML is generated are actual programming languages, requiring a basic understanding of conditional logic, variable manipulation, and parameters. That's not something that the HTML "programmers" of the dot.com era are going to be able to pick up out of an HTML reference guide.

So this article seems to be a bit misleading. HTML skills are - or at least should be - a requirement for web application developers because they are going to need to generate HTML. But the article is right in that the ability to slap together HTML isn't likely to help developers command a high salary, because understanding HTML in a Web 2.0 world is merely tablestakes. Trying to bank on your HTML skills today would be like trying to negotiate a higher salary because you can write a linked list¹. Yeah, go ahead and try it, I dare you.

HTML skillz may no longer be considered 1337, but they are still required and just as important - if not more so - as they have ever been.

Imbibing: Coffee

With apologies to the writers of Amadeus

MOZART [The fresh SOA Architect]

But it's new, it's entirely new. It's so new, people will go mad for it. For example, I have an activity in the second step - it requires calls to two services in parallel. Then a third service is called to verify the name of the customer, and a fourth to perform some security checks. Then a logging service makes five and so on. On and on, six, seven, eight! How long do you think I can sustain that?

JOSEPH [The jaded IT Manager]

I have no idea.

MOZART

Guess! Guess, Majesty. Imagine the highest number of services that could be orchestrated this way, then double it.

JOSEPH

Well, six or seven! Maybe eight!

MOZART

Twenty, sire! How about twenty?

Sire, only SOA can do this. In a traditional web application, if more than one service is called at the same time, it's just chaos.  No one can manage the flow. But with SOA, with SOA you can have twenty services all executing, and it's not chaos- it's a perfect orchestration. Isn't that marvelous?

The response that Joseph should give Mozart at this point is, "It is. Now answer me a question. How long do you think the customer will wait? Guess! Guess, Mozart! Imagine the longest time a customer would wait, then halve it. Will this new architecture be able to do that?"

The process of building out a SOA is a lot like composing an opera. There's a story(the architecture), an orchestra (the infrastructure), and a bunch of services (the singers). All three must be coordinated carefully in order to create perfect harmony.

You can't ignore any one of the pieces or you risk a lackluster performance that leaves no one satisfied and everyone wondering why they bought tickets in the first place.

A great composer like Mozart knew what melodies should be duplicated and by what instrument as well as how important the supporting harmonies were in creating the perfectly balanced musical score.

A great SOA architect also understands that the supporting harmonies (infrastructure) is just as important as the melodies (services) in building out a successful SOA.

Just as some melodies need to be duplicated by several instruments, so, too, do some services need to be duplicated in order to support service level agreements and to meet capacity demands. And just as counterpart harmonies support those duplicated melodies, balancing them, so too does a strong infrastructure support the duplication of services.

Whether you're just building out your first SOA or trying to improve an existing implementation, remember to consider the impact of infrastructure on its overall balance. It could be the difference between composing music that will live on for centuries (an architecture that will support the business for many years to come) and composing a song that you can't even give away free on the Internet (an architecture you'll replace in 2-3 years).

For more on the impact of infrastructure on SOA and performance, check out these resources:

SOA + WOA = NOA

SOA Delivery

The Role of the Adaptive Network in SOA

Centralized Authorization and SOA

SOA & Web 2.0: The Connection Management Challenge

SOA Performance: Round II

SOA and Performance

Imbibing: Mountain Dew

File virtualization and storage are gaining a lot of mindshare lately, probably because the longer a business runs the more data they have to store. And with compliance regulations, sometimes that means not only more data to store (like all your e-mail) but storing it for a very long time.

And then there's building out large farms of servers to support high volume sites. File virtualization makes a lot of sense when you're trying to manage large numbers of servers, especially if they're essentially clones.

And let's not ignore the other kinds of virtualization; if you're set on OS virtualization you're going to need to store - and potentially share - those images somewhere, and what better way to accomplish that then by using file virtualization?

What? You're not really up on file virtualization and its benefits? Then have I got some good news for you. F5 Acopia Data Solutions will be hosting a free webinar on May 22 on file virtualization. Learn how it works, how to reap the benefits, and get a copy of File Virtualization For Dummies®, hot off the presses.

You can find more information and details as well as register for the webinar here.

Imbibing: Coffee

The Green Tech Blog on CNET News postulates that the next green trend will be to s l o w down the innertubes, or more accurately, the flow of data. Now that slow down is apparently measured in terms of milliseconds, and is "not enough for Web surfers to notice" according to researchers.

But as we recently discussed, milliseconds at every hop can potentially add up to seconds, and seconds will certainly be noticeable by Web surfers - particularly those who might be engaged in sensitive financial transactions like selling and buying stocks. And we won't even discuss the effect on real-time communications like SIP from the potential jitter arising out of such a theory. Suggesting that routers can delay traffic for even milliseconds and then measuring only the effect on Web traffic is short sighted. This is Web 2.0, baby. We're converged, now, integrated. Routers don't generally distinguish between SIP and HTTP and RTSP. It's all just bits and bytes, forwarded on to the next hop. Delay one you delay them all.

I think there's a better way to go green, and it actually improves performance rather than degrades it. Why put the onus on network devices when a better solution - one that makes everyone happy - is to build out an architecture that's capable of improving performance, ensuring uptime, adding security, and will decrease the overall consumption of power?

Yeah, I don't get it either.

Imbibing: Mountain Dew

a.k.a The morning Lori was wrong

I got an e-mail newsletter yesterday with a link to BEA's Virtualization TCO calculator. As my team is engaged in a lively debate regarding virtualization and its alleged benefits (you can tell which side of the fence I'm on at the moment) I visited the calculator to see what it would say. Then I sent the following results to the team, a smug smile on my face because the virtualized OS environment turned out to be more expensive than the non-virtualized environment.

Someone, of course, pointed out that the power and cooling costs didn't quite jive. My thought was that maybe it does. After all, while you are reducing the number of servers in a virtualized architecture, you're also increasing the average utilization of those servers. That ought to even out in the end. But I didn't want to leave it to simply theory, I wanted some concrete proof.

So I did some research and found some real data¹ with which I thought I could back up my theory, then plugged that data into a spreadsheet. I thought "Ha! I'll show you that this isn't the rosy picture so many virtualization supporters like to paint."

So here's where I get to admit I was wrong. Yeah, I know - hard to believe, but it's true. And here's the data behind that startling epiphany. Each grouping of data is based on consolidation of 10 servers with average CPU utilization of 40%, 65%, and 80% respectively. The resulting number of servers is the number required to maintain the same load overall, but at 95% utilization per server.

It appears, then, that although there is a diminishing return on the amount of energy saved by consolidating physical servers and virtualizing the environment, still there is a return. Fewer servers == less power, even given that modern servers draw variable power based on utilization. Turns out that OS virtualization may indeed be more energy efficient in the long run.

Hmmmph. Well, there's still the issue of increased licensing and administrative costs.

The debate, I'm sure, will rage on.

¹ Power consumption data based on HP DL360 G5 servers using HP's Power Calculator

Imbibing: Coffee

According to a recent CIO article and survey data, the top challenge to virtualization success today is balancing server workloads and maintaining application service levels.  That makes sense; if you're going to create 3 or 4 or 99 virtual servers you need to be sure that the workload isn't going to suck dry the resources available on any particular machine. And, too, you'll probably need some solution to load balance those applications across virtual instances.

That part, at least, seems easy: get thee a load balancer, pronto. Turns out that the concern regarding balancing server workloads is more complex than most likely realize. A load balancer will, in fact, distribute server workloads across virtual instances. It likely won't, however, do so in an intelligent way and it almost certainly won't do much to ensure that service levels are maintained.

Top Challenges to Virtualization Success

(Respondents chose up to three)

SOURCE: CIO research

Application delivery will, however, address both those challenges in an easy, consolidated, green, efficient (have I hit all the buzzwords yet?) and flexible way. Seriously, an application delivery fabric is the best way to address this type of challenge and it does provide all benefits in one way or another.  

You see, an intelligent application delivery controller understands the load on the server and can decide - in real-time - whether any given request should go to one server or another based on that understanding. So if Virtual Server A on Real Server 1 super busy at the moment, an application delivery controller can send the request to Virtual Server B , instead. Virtual Server B might be on Real Server 1, or it might be on Real Server 2. It really doesn't matter, unless you want to start factoring in both the current application performance within a virtual server AND the resources available on the real server. Regardless of what factors you want to consider, an intelligent application delivery controller can take them into consideration and balance server workload across instances in a way that maintains application service levels.

Want to take it further? Do you want to automatically provision those servers to get the most out of your resources? Consider an application delivery network that can integrate with popular virtualization technology like VMWare. Such integration takes solves the problem of balancing server workload by dynamically increasing or decreasing the available server instances in real-time, according to current network, server, and user conditions.

So if you're struggling with balancing the load across servers - virtual or not - check out an application delivery network so you can move on to the next challenge: IT organizational politics.

Sorry, I wouldn't touch that one with a 10 foot patch cable.

Imbibing: Coffee

There's more than one way to go green with application delivery networks

The past few months have seen a high volume in the number of "green" products announced, many of them in the application delivery realm. Almost universally these announcements have focused on the products themselves as a method of reducing power consumption both in power required to run the device and in lessening the amount of heat generated that requires cooling.

But there's another way to "go green" with application delivery, one that doesn't necessarily rely on the application delivery controller being "green" itself.

The Three "R"s

We've long heard of the three "R"s (reduce, reuse, recycle) as a means by which we, as consumers, can reduce the sheer volume of crap that must be disposed of on a yearly basis. You may not be aware that this concept applies to efforts to go "green" in technology and, in particular, to the benefits provided by application delivery networks.

Application delivery networks can offload SSL termination from servers, which can reduce by up to 30% the resources required on a web or application server. By moving SSL termination and management onto servers, the freed resources - memory and processing power - can be used by the web or application server. This increases the capacity of your existing servers, which obviates the need to purchase additional hardware. The result? Less power consumed to serve your applications. On top of this, SSL operations are generally hardware accelerated in application delivery networks, meaning not only will you reduce the resources required for your applications, you'll improve their performance as well.

Application delivery networks are also capable of providing TCP multiplexing. TCP multiplexing can reduce the burden on web and application servers by reusing existing TCP connections, which translates into fewer resources. Much like SSL offload, TCP multiplexing reduces the number of servers you need to power your applications and thus saves grass and cash. This not only has a positive impact on the environment, but on your IT budget as well.

Our third "R", recycle, is not nearly as obvious as the first two. Recycling takes the form of caching in an application delivery network. By caching static content - and dynamic content that is generated by dynamic mechanisms - an application delivery network recycles content. In doing so, it reduces the resources needed from web and application servers and increases their capacity, again resulting in less power consumed, less heat generated, and a greener (grass and cash) effect. You may also be able to reduce the number of servers you need or, at a minimum, hold off on purchasing additional servers that would otherwise be needed to increase capacity, but would also up your power consumption.

If you really want to reduce your total carbon footprint, consider an SSL VPN for remote access and let your employees telecommute, either permanently or even just one day a week. By removing the need for employees to commute you reduce the amount of emissions they generate by driving as well as the volume of difficult to degrade plastic containers that come from stopping to grab a coffee on the way to work.

So if you're truly interested in going green - whether in terms of grass, cash, or both - consider the benefits of an application delivery network. Going green isn't just about devices and their power consumption, it's about how much more efficient and green it can make the rest of your infrastructure, as well as your employees.

Imbibing: Water