DevCentral Weblogs

Acceleration ABCs - S is for Security

Dawn Parzych — Thu, 20 Nov 2008 11:32:08 GMT

Sometimes putting security solutions in place will undo all the work that has been done to accelerate an application. I'm not saying throw security out the window as acceleration is more important, both are equally important and can work together. Let's look at three scenarios SSL, SSL VPNs and web application firewalls.

SSL

SSL is critical when sending secure or private data across the Internet, however when providing content over SSL often times the performance of the application is degraded as additional work is created for the servers. Fortunately SSL can be offloaded to an application delivery controller reducing or eliminating the performance hit. The offloading of SSL frees up resources on the server and can accelerate the application delivery by providing SSL in hardware.

SSL VPNs

Here's the dilemma with SSL VPNs

SSL VPNS are designed so that remote users can access corporate resources from anywhere home offices, airports, or hotels.
Remote users are precisely the ones that need acceleration technologies the most.
SSL VPNs like Firepass have settings that will overwrite the cache-control headers provided by the server or WebAccelerator reducing or eliminating the acceleration gains.

Be aware of the settings on the VPN to make sure they aren't counteracting the acceleration policies in place and make sure the acceleration policy is not set to cache highly confidential information. In all likelihood the images from the corporate portal can be cached by the client the pages however shouldn't be.

Web Application Firewalls

With PCI compliance directives many companies have deployed web application firewalls however they still want to provide application acceleration. A web application firewall and acceleration solutions can be deployed together so you can get all the benefits of acceleration and still maintain a high level of security. Say your application security policy contains a rule that says users are not able to access a document unless they are logged in and have a valid cookie, if the document is accessed without this cookie the user should be presented with a login page. This document is static can easily be served from a shared cache but first the presence of the cookie needs to be confirmed. A rule in the acceleration policy would be defined to say if the cookie is absent proxy the request to the server (or in this case it would be the web application firewall) the rules from the security policy would then fire and the user would be presented with a screen to logon. You're still maintaining the security rules but also offloading the server from having to serve the static document.

Technorati Tags: acceleration,security,WebAccelerator,Firepass,SSL,web application firewall

As a Service: The many faces of the cloud

Lori MacVittie — Thu, 20 Nov 2008 11:12:05 GMT

Last month I happened across this amusing, and ironic, poem describing the dichotomy that exists in trying to define cloud computing. Go ahead and read it, I'll wait, it's worth the time. Seriously.

I am not going to define cloud computing again. I've done that already and the point of this discussion is not what is cloud computing but rather how the cloud is beginning to separate into distinct models, each serving a different set of needs. The common theme between these models is "as a service". Some "thing" traditionally relegated to the local IT data center is being offered in the cloud, as a service. The list is growing, but it appears that we'll likely end up with three service models for the cloud: software, infrastructure, and platforms.

SOFTWARE AS A SERVICE (SaaS)

Software as a Service (SaaS) was pioneered and proven as a successful model by salesforce.com, and has since been duplicated successfully by myriad other vendors. The SaaS model works on the assumption that all enterprises need is the ability to customize and integrate software (which is, for the most part, true of a wide variety of software offerings) and need not (a) reinvent the wheel or (b) worry about the actual implementation/deployment details.

SaaS is a good choice when:

You need software to support common business processes like customer relationship management
You need some customization but it is primarily at the data level and not at the application logic level
The software in question needs to support a geographically diverse pool of employees

PLATFORM AS A SERVICE (PaaS)

Platform as a Service (PaaS) is a somewhat emerging concept that is gaining traction for several reasons. PaaS is based on the premise that you want or need a development and deployment platform in the cloud and are willing to essentially outsource the platform to a cloud computing provider because you want to ultimately deploy the application you are developing in the cloud. PaaS moves the development and deployment platform "into the cloud". For a good example of a PaaS, check out Bungee or Google App Engine.

PaaS is a good choice when:

You want to deploy an application into the cloud but aren't interested in dealing with a virtualized infrastructure
You want to try out an application to test adoption or interest but don't have the budget to invest in the necessary infrastructure
You would otherwise build a departmental level applications that would traditionally be served from an unmanaged server hiding under someone's desk
You're a startup whose offering will be a web based application

INFRASTRUCTURE AS A SERVICE (IaaS)

Lastly, we have Infrastructure as a Service (IaaS). IaaS is what most people think of when they hear the term "cloud computing". This model essentially leases out infrastructure resources on which applications are deployed. The applications are then able to scale up and down as necessary, on-demand, using the provider's infrastructure - saving the organization a lot of capital expenditures and operating expenses in acquiring, deploying, configuring, and managing the infrastructure.

IaaS often takes the form of virtualized computing environments, leveraging virtual images to alleviate the typical problems associated with remote hosting of applications in aligning operating systems, application servers, hardware, and other application specific details with the needs of the customer. Virtualized computing environments allow the customer to configure and deploy the application in a virtual image locally and then execute it within a remote environment without worrying about the underlying server and network infrastructure.

BlueLock and Amazon EC2 are good examples of IaaS providers.

IaaS is a good choice when:

You need a second data center for disaster recovery only but the investment in land, building, and infrastructure is too costly
You have a need for seasonal capacity but the revenue generated during those times would be diluted or erased by investing in the infrastructure to support the rushes
You want to leverage geographical based global load balancing to better serve international visitors but wish to avoid the investment in multiple data centers or hassle of co-locating servers around the globe
You want to use the cloud to host bandwidth or storage intense resources (video, images) and integrate them with your applications to offset the cost of more bandwidth or a new storage infrastructure.

Yes, cloud computing is very much part of the buzzword bingo game today (I failed to win, as you can see, but I'll try harder next time), but there are real benefits and valid reasons for looking into it right now. Don't let the hype surrounding cloud computing distract you from the potential benefits, but don't drink the kool aid too deeply, either, and commit to a model that isn't a good fit for you and your needs.

Technorati Tags: MacVittie,F5,cloud computing,infrastructure,virtualization,Google,Amazon,BlueLock,Bungee,IaaS,SaaS,PaaS,platform,software,models,buzzword bingo,internet,application,web,blog

Calling all Conversations

Pete Silva — Wed, 19 Nov 2008 16:33:24 GMT

With Social Media exploding, F5 solutions supporting Web 2.0 applications and many experts saying 'Get On the Social Bus or Get Lost,' we've been exploring ways to introduce & extend the F5 brand into those communities. Of course, learning, conversing and understanding the challenges in the marketplace and how best to solve them is also part of the venture. Up front, I want to say these are not replacements to our groundbreaking Social Site, DevCentral but extensions of F5 in places we've never been. DevCentral will always be our primary community with exclusive content all with the purpose of serving and sharing with you all the awesomeness of BIG-IP. We also understand, however, that folks like yourselves get content and information from a varity of sources whether it be for entertainment, technical knowledge or both.

To that end, we'd like to share with you our current active social sites and ask, if you so desire, to join, become friends and participate in these communities just as you do here. It'll be a little different but still fun. I also thought I'd chronicle, at times, some of our Social Media experiences here - successes, mistakes, experiences and other anecdotal stories to share. I even have one now! At first we went out and signed up/created a bunch of sites but then I saw this article on the 7 deadly sins of social media and realized Gluttony was creeping in. We needed to focus on a few. So, for your social pleasure here are a few of our most active Social Media sites.

MySpace: www.myspace.com/f5networks

Facebook: http://www.facebook.com/profile.php?id=1564450374

YouTube: http://www.youtube.com/user/f5networksinc

Twitter: http://twitter.com/f5networks

We'll start with those and add as new ones emerge. Also, if you have social sites where you'd like to see F5, please let us know! This medium is about listening. As Homer (Mr. Plow) says, 'Now we play the waiting game. OK the waiting game sucks, let's play Hungry, Hungry Hippos!'

Acceleration ABCs - R is for Remote Offices

Dawn Parzych — Wed, 19 Nov 2008 11:49:41 GMT

When you have a number of large remote offices that are downloading large documents or have limited bandwidth instead of looking at an asymmetric deployment you may want to consider a symmetric deployment. A symmetric deployment positions the data closer to the user minimizing the effects of latency and reducing bandwidth. The benefits of symmetric deployments include but are not limited to:

Compression
Data De-duplication
TCP Optimizations
Web Object Caching
Non-Web Object Caching

For more information on symmetric acceleration see the Acceleration 102 White-paper.

Technorati Tags: acceleration,symmetric

Cloud Computing: Is your cloud sticky? It should be.

Lori MacVittie — Wed, 19 Nov 2008 11:40:02 GMT

Load balancing an application should, by now, be a fairly routine scaling exercise. But too often when an application is moved into a load balanced architecture it breaks. The reason? Application sessions are often specific to an application server instance. The solution? Persistence, also known as sticky connections.

The use of sessions on application servers to add state to web (HTTP) applications is a common practice. In fact, it's one of the greatest "hacks" in the history of the web. It's an excellent solution to the problem of using a stateless application protocol to build applications for which state is important. But sessions are peculiar to the application server instance on which they were created, and in general are not shared across multiple instances unless you've specifically achitected the application infrastructure to do so. Inserting applications into a load balanced environment often ignores this requirement, as load balancing decisions are often made based on server and application load and not on application specific parameters.

THE PROBLEM

When a client connects the first time, it's directed to Server A and a session is created. Data specific to the application that needs to be persisted over the session of the application, like shopping carts or search parameters, are stored in that session. When a client makes subsequent requests, however, the load balancer doesn't automatically understand this, and may direct the client to Server B, effectively losing the data in the session and hence breaking the application.

This affects cloud computing initiatives because an integral part of cloud computing is load balancing to provide horizontal scalability and integral part of applications is session management. Deploying an application that works properly in a test environment into the cloud may break that application because the load balancing solution utilized by the cloud computing provider isn't aware of the importance of that session to the application and, too often, the session variables are unique to the application and the provider's static network infrastructure isn't capable of adapting to those unique needs.

THE SOLUTION

When choosing a cloud provider, it is imperative that the load balancing solution used by the provider support sticky connections (persistence) so that developers don’t have to rewrite or re-architect applications for cloud deployment. "Sticky connections", or persistence in the networking vernacular, ensure that client requests are load balanced to the appropriate server on which their application session resides. This maintains the availability of the session and means applications don't "break" when deployed into the cloud or inserted into a load balanced environment.

Sticky (persistent) connections are often implemented in load balancers (application delivery controllers) by using application server session IDs to help make the decision on where requests should be sent. This results in consistent behavior and a well behaved application. The most common method of implementing sticky (persistent) connections is the use of cookie persistence. Cookie persistence inserts a cookie into the response that is later used to properly direct requests. The cookie often contains the JSESSIONID or PHPSESSIONID or ASPSESSIONID, but can actually contain any data that would allow the load balancer (application delivery controller) to identify the right application server for any given request.

ACTION ITEMS

If you are deploying applications into the cloud, or planning on doing so, and those applications are session sensitive, it is important that you determine before you deploy into the cloud whether or not your provider's solution supports sticky (persistent) connections, and how that persistence is implemented. Some solutions are not very flexible and will only provide persistence based on a limited array of variables and you will need to instrument your application to support the proper variables. Other solutions provide network-side scripting capabilities that will allow the provider - and you - to support persistence on any variable you deem unique enough to identify the proper application server instance.

Note that server FQDN (fully qualified domain name) or IP address will likely not be adequate in a cloud computing environment as these variables may not be guaranteed to be static. The unique variable should ostensibly be something application specific, as this is likely the only variables you will have control over in the cloud and the only variables guaranteed to be consistent across instances as they are brought on and off-line in response to changes in demand.

If you're currently examining the possibility of deploying applications in the cloud, make sure the cloud you choose is sticky to avoid the possibility that you'll need to rearchitect your application to get it to work properly.

Technorati Tags: MacVittie,F5,cloud computing,infrastructure,architecture,application delivery,application server,session,state,HTTP,cookie,persistence,sticky connections,server affinity,internet,web,blog,load balancing

Acceleration ABCs - Q is for Quickly

Dawn Parzych — Tue, 18 Nov 2008 11:41:16 GMT

I'm sorry to say that sometimes acceleration does not come about quickly, it frequently takes time to fine tune the system. While you can quickly set up a virtual server and pool on an application delivery controller there are many items that can be tuned to enhance performance. Settings within the virtual server like OneConnect and Nagle's Algorithm can be enabled via a quick selection, while other options take a little more time like WebAccelerator.

To set up the base configuration of WebAccelerator with a library policy takes about 5 minutes. Not too bad and this provides some quick performance improvements, however there are some advanced options such as invalidations and configuring rules for dynamic caching which enable you to accelerate more of the site but this takes time to set up. The majority of the time is spent in the planning and testing phase. Without proper planning and testing unexpected behaviours might be encountered - you may end up inadvertently diminishing the quality of the user experience. Don't rush the process and the results will be worth it in the end.

Technorati Tags: acceleration,Nagle's algorithm,test

Why routers should route and switches should switch

Lori MacVittie — Tue, 18 Nov 2008 11:38:21 GMT

Michael Vizard over at eWEEK makes an interesting prediction about the future of application acceleration: "Some day the whole concept of application acceleration will be baked into the core routers and switches we have in place."

I disagree. Routers and switches are packet-based. They focus on getting a single packet from here to there based on layer 2/3 information. Application acceleration solutions require action higher in the stack, usually layer 4 through 7; they are flow or connection based, and are often specific to the application (think CIFS, SAMBA, HTTP, etc..). The information necessary for application acceleration solutions to improve the performance of applications is just not available at the layers of the stack at which routers and switches operate.

While in the case of HTTP it is generally possible that some application acceleration features can be employed, such as manipulation of cache-oriented headers, simply because they are contained within a single packet, routers and switches don't have the awareness of that layer to be acting upon it.

But, you say, Michael is postulating that they will, someday.

Again, I'm going to disagree with that prediction. We've already tried to apply application performance-oriented functionality in routers and switches. The TOS (Terms of Service) bits (which have been redefined in recent years as Differentiated Services Code Point (DSCP)) in an ethernet header can easily carry basic information regarding the quality of service desired for a particular packet. This was initially used by routers (and still is in many implementations of WAN optimization solutions) to determine prioritization and handling of individual packets.

"Coloring TOS bits" was a euphemism used nearly ten years ago to describe the common scenario of prioritizing packets based on customer service level (gold, silver, bronze) by flipping TOS bits in the ethernet header. Problem was that most routers and switches didn't honor TOS bits, and there was no way to enforce the quality of assurance indicated by the TOS bits once the packet hit the Internet. Some routers simply didn't interpret TOS bits and ignored them.

An entire market of products arose out of the need for QoS solutions that actually worked. Bandwidth management products like Sitara and Packeteer rose from obscurity and quickly saw the need for more application specific prioritization and immediately "'moved up the stack" into layer 7 in order to provide that functionality. TOS bits were discarded by the market as a whole for being unable to provide the level of specificity required to manage applications. TOS bits have made a bit of a comeback with the advent of WAN optimization as a hot technology, but I suspect that it, too, will go the same route (sorry, no pun intended) as its forerunners earlier this century in application acceleration.

Application acceleration in a router or switch would require that the router or switch become layer 7 aware, and flow-based. If they were to attempt to apply application acceleration to XML-based data, they would have to go one step further and become a full proxy. They would have to become an application switch rather than an L2/3 device.

This is a bad idea for several reasons. First, there already exist a plethora of application switches that more than ably perform the task of application acceleration. Second, the core packet-processing hardware and software of switches and routers is optimized to pass packets, and would need to be completely reworked in order to provide application acceleration functionality. This would drive the cost of core infrastructure higher and unnecessarily add cost for enterprises who certainly only need application functionality at specific points in their architecture, not in every wiring closet on their campus. Third, the process of packet aggregation required to act upon application data rather than individual packets necessarily adds latency. In many cases it's barely noticeable at any given hop, but when it happens at every point device through which a packet must travel it adds up and will certainly be noticeable to the end-user.

Routers and switches are the core of the network, of the infrastructure that makes networks and the Internet "just work". Adding unnecessary functionality that requires a dramatic change in the architecture of these devices is simply a bad idea, financially and functionally. Routers should route, switches should switch, and application acceleration should be left to solutions specifically engineered to provide such functionality.

Technorati Tags: MacVittie,F5,router,switch,application switch,application acceleration,TOS,DSCP,packet processing,flow-based,application delivery,Sitara,Packeteer,bandwidth management,WAN optimization,WAN acceleration,internet,network,blog,eWeek,Michael Vizard

The Jaguar Can't Quite Catch The Roadrunner

Joe Pruitt — Mon, 17 Nov 2008 20:11:18 GMT

It's fairly common knowledge that the Coyote has had trouble catching the Road Runner. Good old Wile E. has tried since 1948 and has yet to capture his elusive pray but unfortunately for the Road Runner, there's a new predator close on his tail.

For those who don't know, Top500.org is a project that was established in 1993 to assemble and maintain a list of the 500 most powerful computer systems in the world. They have been compiling a list twice a year since their inception with the help of high-performance computer experts, computational scientists, manufacturers, and the Internet community in general.

Since November 2005, the Jaguar, housed at Oak Ridge National Laboratory, has been in the top ten and has since slowly been shooting for the top position. But, by the June 2008 report, a new kid has hit the top of the charts and aims to hold onto that spot and not let anyone else catch him, especially the Jaguar.

The new kid on the block, is The RoadRunner. Straight out of the cartoons, this behemoth beast is a marvel of computing power. It was built by IBM and in June was the first system ever to break the peatflop/s Linpack barrier. Since then, it has been slightly enlarged and has reached a peak 1.105 petaflop/s. It is based on the IBM QS22 blades which are built with advanced versions of the processor that is in the Sony PlayStation 3. All of the nodes are connected together with a commodity infiniBand network.

The Jaguar is a XT5 system manufactured by Cray and is close behind RoadRunner at 1.059 petaflop/s and is expected to pass the RoadRunner in the near future.

We'll see if the Jaguar can do what Wile E. Coyote could not and get him some RoadRunner for lunch. I'm not counting on it though...

-Joe

Technorati Tags: F5, DevCentral, Top500, RoadRunner, Jaguar, IBM, Cray, Supercomputer, Joe Pruitt

Acceleration ABCs - P is for Performance Metrics

Dawn Parzych — Mon, 17 Nov 2008 14:47:27 GMT

Performance may sound like a no-brainer when it comes to talking about acceleration however people look at different metrics when it comes to determining the performance improvements an acceleration solution will provide. Last week I met with two different customers to determine the performance improvements that WebAccelerator would provide. Customer 1 was mostly interested in end user response times, they have a number of branch offices around the world with latency ranging from 0 to 400ms. The speed with which Sharepoint pages and documents would download at various speeds and latencies was the critical performance metric. I am happy to report that the performance testing revealed roughly a 50% reduction in document download times. Customer 2 was interested in measuring the hits per second the back could process to gauge the performance improvement. In this instance the hits per second increased from about 200 to 2000.

Will customer 1 see an increase in hits per second and will customer 2 see a reduction in page and document download times - probably however this isn't what is driving their need for an acceleration solution. The metric used to determine performance gains is going to vary based on what is driving the need. Are customers complaining about slow download times? Have you recently acquired a new company resulting in more people accessing an already loaded application? The choice of the performance metric is yours. The trickier part comes in determining how much improvement is good enough.

It helps to have a quantitative as opposed to a qualitative target. When asked what the goal of testing should be one customer replied "I want my customers to be happy." While it is noble to want happiness it unfortunately isn't a valid performance metric. Once you have a quantitative metric make sure it is realistic and achievable, if the page is taking less than 1 second to download wanting a 50% reduction in response time may not be realistic.

Technorati Tags: acceleration,Sharepoint,performance

Important Information Regarding BIG-IP Support

Lori MacVittie — Mon, 17 Nov 2008 13:22:49 GMT

If you're an F5 customer running BIG-IP v4.x it's time to consider migrating to newer platforms. I know, why in the world would you want to upgrade when your BIG-IP has been running just fine for years?

Probably the most important reason is that F5 is ending the life of the 4.x release and will no longer focus resources on improving it. That means all the new improvements and innovation will continue to be put into the 9.x branch and without migrating you'll miss out on a lot of great opportunities to support new protocols, deploy new functionality and features, and take advantage of the benefits of the full proxy architecture of the 9.x release. With the fast pace at which new concepts such as cloud computing and virtualization are emerging, you'll need the most flexible, powerful, intelligent platform to keep up. That platform is 9.x.

If you haven't been considering migration of your 4.x platforms, here's just a few good reasons why you should seriously consider it now:

Improves server efficiency. Features in 9.x like TCP Express and myriad TCP optimizations drastically improve the efficiency of your infrastructure, enabling consolidation that helps with virtualization and Green IT initiatives.
New protocol support. Support for current protocols like XML and SIP is not available on the 4.x platforms, but is in the 9.x release.
Enables agility. iRules were re-architected in the 9.x release, providing greater flexibility and ability to provide unique, innovate solutions that meet the needs of your unique environment and business.
Innovative solutions. New solutions like e-mail and protocol security are available only on the 9.x platform.
Lower TCO. Newer hardware platforms are more efficient and take advantage of multi-core processors to provide even greater performance per watt but these new platforms require the 9.x release.
Broader community support. There are many more community members on DevCentral taking advantage of 9.x than 4.x.

There are many more reasons to upgrade, and you can find them at our 4.x Migration HQ. If you're still not convinced, head on over and check out some of the resources available to you that should help convince you that it's time to migrate to a new version of BIG-IP.

Your applications (and users) will thank you for it.

Technorati Tags: MacVittie,BIG-IP,migration,4.x,9.x,F5 Networks

Cloud Computing: Achieving full interconnectedness

Lori MacVittie — Mon, 17 Nov 2008 12:45:43 GMT

The saying goes that to forget (or in some cases blatantly ignore) the mistakes of the past is to be doomed to repeat them.

ODBC. BPEL. JDBC.

All three are extensible standards in the software industry that cause no end of headaches and increased management overhead for folks attempting to deal with them. None of them are interoperable; you can't use the ODBC driver for Oracle to hook up to a SQL Server database, nor you can use the same BPEL produced by one BPM solution as within another. Because they're "extensible" and that extensibility leads, almost unilaterally, to interoperability issues.

Extensibility ostensibly provides a mechanism through which vendors can offer value-added features and functionality to products making use of these "open" standards. Like SIP (Session Initiation Protocol) for VoIP (Voice over IP) solutions like Skype. Vendors and even providers of VoIP services extend SIP with proprietary, "value added" data that destroys the standard's interoperability with other SIP-enabled products.

It's like trying to shove a square peg into a round hole. You can do it, but not well, and it isn't easy.

Oh, it's great news for folks like F5 that support network-side scripting for a programmable application delivery platform that can ease the pain of trying to get two disparately SIP-enabled products to work together, like a client and the server, but it's bad in general for the industry because it inhibits adoption of standards that could, if actually standardized, become ubiquitous enough to launch new and exciting ways to leverage the technology.

That's one of the reasons when we start talking about Infrastructure 2.0 and coordination and orchestration that we have to be very careful to consider the potential ramifications. While standards are obviously a good thing, standards that result in inoperable products - from infrastructure vendors or third parties - would only make the situation worse. Proprietary extensions to "open" standards result in not only vendor lock in, but inoperable products that only serve to make more complex the already complex web of management we're suffering from today.

As Greg Ness points out in "Static Networks meet Billowing Expectations"

Connectivity intelligence enables real-time tracking and interconnectedness between networks, applications and endpoints. The lack of connectivity intelligence has driven up networking costs and heightened pressures on already tight budgets.

That interconnectedness cannot be achieved without communication first at the people layer, or layer 8 as it is often referred to. And what has to come out of that communication is consensus; consensus that any "extensible" standard must be interoperable at the core, with proprietary extensions being just that: extensions, options, add-ons, but never, never requirements for interoperability or, as Greg puts it, interconnectedness.

But as often as we mention standards at the infrastructure layer, there's another aspect of cloud computing that will eventually require standards: deployment. Even though two cloud computing providers may both be built upon a virtual computing model, that does not mean that the mechanisms used by customers to deploy those virtual images are the same. Web services might be used by one, a Web 2.0 style REST API by another, and a proprietary mechanism by a third. Without some standard for deploying applications into the cloud, customers today risk vendor lock in. Processes must be built around and using those proprietary deployment models, which results in lock-in similar to that experienced by many organizations with EAI (enterprise application integration) solutions before the advent of SOA and the ESB (enterprise service bus).

A standardized method of deploying virtual images into cloud computing environments would have additional benefits to customers if they, too, took advantage of such standards when implementing their own, private cloud computing environment. Leveraging standard methods of deployment internally means a much smoother move into the cloud if it becomes required as well as a more seamless experience when expanding from a purely private implementation to a hybrid architecture employing the use of both internal and external clouds.

And despite the fact that standards often remove vendor lock-in that providers might count on, consider this: providers, if standardized, could not only provide services to those interested in leveraging the cloud to deliver applications and services, but to other providers, as well. Leasing out unused compute cycles in much the same way as large telcos have always leased their core network to local and smaller providers.

It's a win-win-win scenario, in which everyone can benefit if we can gather consensus that it's necessary, communicate with one another to make it happen, and keep them open without proprietary extensions getting in the way.

Technorati Tags: MacVittie,F5,cloud computing infrastructure,cloud computing,virtualization,standards,SIP,ODBC,JDBC,interoperability,infrastructure 2.0,EAI,APIs,deployment,management,internet,web,blog

Doing More With Less - The Extreme Version

Don MacVittie — Fri, 14 Nov 2008 21:45:20 GMT

Nine things you can do to weather the storm.

We've known for quite a while that you would be asked to do more with less budget next year - the credit crunch if nothing else was going to make your organization cautious about large infrastructure investments when money in the bank is a good idea.

But starting relatively recently - it gelled yesterday, but actually started several weeks ago - tech companies and IT departments started making staff cuts. That means not only will you be asked to do more with less, but you'll be asked to do more with no growth in gear and negative growth in headcount.

That's a tough order. Necessary in most cases, but still tough.

Likely you've been scraping by for a while, which makes it even harder - the incremental gains of things like server virtualization and disk-based backups are probably in place already or on their way, and that means you've got a harder road to hoe to provide the level of support your business will require - and that level is likely to be a higher level of support as companies try harder to compete for those few dollars being spent.

Luckily, there are some things you can do - some take a little money but provide bigger benefits - that might help a bit.

First and foremost, invest in a storage virtualization product like our ARX (no, I won't name competitors, we are all competing harder for those few dollars being spent, remember ;-)). In terms of backup window, file maintenance, disk costs, and tape costs, you will reap many times the benefits of the cost of such a product. We've got a presentation coming about our partnership with Data Domain that delves into the financial and operational benefits - watch for it, you'll get why I list this option first. It certainly was an eye-opener for me cost/benefit-wise.
Second, IBM's green advertisements are largely right. Anything you can do to reduce power consumption reduces costs year after year. That's huge when you think of your company five years or twenty five years down the line. Be green to save some, and the benefits you can reap are huge because they're more long term than not buying that server. Indeed, they're every bit as long term as not hiring that employee you need so badly.
"No one ever got fired for buying X" may well be changing for the next few years. That phrase is always trotted out to address the relative expense in terms of licensing or maintenance of Microsoft, IBM, or Oracle. The day is here when if it costs 10x the competition, you're darned well going to have to justify that expense. "We've always done that" won't be a valid justification either. You can try for the "It'll cost 10 bazillion dollars to retrain..." line, but outsourcing is a good answer to that kind of mentality, so I'd just shut up and figure out how to use alternative products as a matter of business. If your staff isn't learning new stuff every day then you're not keeping the best people anyway, set them out figuring out how you really CAN do more with less.
Look around your data center. Okay, now build a list of what's there. Seriously, I'm getting to the point, humor me. Now ask yourself honestly "how many functions/capabilities does this product have that I don't even know about, let alone know how to use?" The answer is that a whole lot of your gear and software does much more than you think. Our products are often significantly underutilized, and users jump on some functionality once they know what's possible. If you bought BIG-IP LTM as a load balancer way back in the day, and have never modified how you use it, look at it again. It's a whole lot more than a load balancer these days, even if you don't buy any of our add-on modules, and the same is true for other vendors. Oracle has bought and innovated so many things that I think there's a little-known function in 11g that makes coffee for the CEO and delivers it at the desired temperature to his desk. So ask your staff to start looking into the capabilities of products you already own. Even if sometimes you have to upgrade, if it saves buying and maintaining another piece of hardware, it should be a no-brainer.
When you're busier, as I suspect you're about to be, time spent surfing suffers. You need to make certain your staff knows that it's important to the organization that they hit sites that talk about products you use every day. This will help the last point, but in general it helps them learn from what other users are doing. Great sites for this type of functionality include F5's DevCentral and Oracle's TechNet. You can share and learn about making the most of your investment with just a couple of man-hours a week, as long as you're open to listening when someone comes with a new idea. This also helps retain the best people because they're learning, and most organizations freeze hires before they lay people off, so hanging on to the good employees is about to become very important.
Put off that upgrade. Seriously. Upgrades are tedious and painful to begin with, but in an environment where money is tight, spending money for something you may not need is insane. Justify each upgrade and put a timeline on it. Just because "everyone" is performing the upgrade in November, do you need to spend the cash then? Think of it this way, if your upgrade is going to cost $60K, how much can your organization earn in interest if you put it off six months? Is there anything you must have in the upgrade? Doing this evaluation with every upgrade will quickly add up in cost savings, just make certain you're not being so assiduous at it that you're losing even more in efficiency.
Get rid of the dead weight before hiring is frozen. Most large organizations have people who are massively under-performing. It is painful, time consuming, and legally risky to fire these individuals unless they violate a zero-tolerance policy. But imagine yourself five years from now, when things are all working great again, are you better off for having kept these people? Not bloody likely. Take the time and effort to document the problems, and move them along. If you have to lose someone, don't let the layoff genie decide when you know who it would be given absolute choice based upon performance.
Sanity check your organization. We all have things that don't make sense, the bigger the organization the more of these things there are. If you have a 10 gig internal backbone and two 1.5 gig external lines, ask yourself if you need 7 gig internally, and if not, if there's a better solution. Likewise, if you have one application that is the only thing running on vendor X's database or OS, and that database or OS costs money every year, it's time to consider moving the application. I'm not a fan of "we only use Oracle" because vendors often tie your hands in that space - if a vendor's vertical solution only runs only on SQL Server and they're the best product for the business, then "we only use Oracle" is more roadblock than help... But there are two sides to every coin. Complete capitulation to software anarchy isn't a great idea either. See where you can consolidate to reduce costs, even if there is a minor up-front cost.
Before upgrading your Internet connectivity, look into a Web Acceleration product. Traffic to business sites is not likely to grow at this time, so don't commit your organization to hundreds or thousands of dollars more bandwidth a year without considering something like our WAM. If you can answer the problem without agreeing to monthly fees, you're saving money in the long run, even though initial outlay for a web accelerator may (but this is not certain) be more.

Think of the next few months/years as a time you have to get through. The changes in the market are something the business will have to deal with, but the above ideas and other great ones floating about will help you contribute to your organization's success in a trying time.

Me? I'll be here, with the rest of my team, helping you figure out how your F5 gear can help, and pushing the envelope on the possible. Drop by on occasion.

Share this post :

Technorati Tags: Economy, IT Management, IT consolidation, virtualization, web acceleration, Oracle, F5 Networks, DevCentral, Don MacVittie

Don.

A client is still a client even when it's on the space station

Lori MacVittie — Fri, 14 Nov 2008 11:08:28 GMT

While I was at SD Best Practices in Boston last month I got to talk to a lot of engineers, developers, and architects about their environments and about what F5 does for application delivery.

One of the developers glibly told me he wasn't sure we could help him out because his environment was the international space station.

Yeah, how cool is that? Now that's cloud computing.

Another architect, who turned out to be a friend of a friend who I've conversed with but never met in person said the same thing, but his environment was nuclear submarines.

The Internet, she is everywhere.

There are certainly challenges with developing and delivering applications for such unique environments, but in the end a client is a client and a network is a network, even if it's over satellite links - which is most certainly the case for locations that cannot be wired or take advantage of wireless technology. What's awesome about application delivery solutions is that they are primarily asymmetric, they are a proxy to the core network that is almost always physically located in a data center somewhere on, well, earth. And on dry land.

An application delivery platform mediates, and it is physically located at the edge of the physical network. If there's a client on the space station or a nuclear submarine or a cruise ship or airplane that can communicate via a network, then an application delivery solution can indeed help the performance, security, and availability of the applications being delivered to those very remote locations.

Asymmetric solutions, of which a reverse proxy is almost always one, do not require deployment of client-side software. They are one sided, hence the use of the term asymmetric. All you need is the application delivery solution to be deployed at the edge of the physical network and voila! You can begin taking advantage of acceleration features like caching, compression, and protocol optimizations. The application delivery platform is aware of the network across which applications must traverse to reach the client, but it doesn't require that it be a certain speed, or a certain type, or anything, really. As long as it's operating on standards-based network protocols like IP, you can take advantage of the features of an application delivery solution for your environment.

In fact, an application delivery solution is perfect for address many of the problems inherent in low speed, high latency links like those used to communicate with uber remote locations like the space station or a nuclear sub because it has the intelligence to understand the network conditions unique to each link and adapt in real-time to provide the best performance possible for users accessing data and applications over that link.

And because the application delivery platform mediates between clients and applications, it can provide availability services to clients regardless of their location. In fact, because most application delivery platforms are full-proxy solutions, they are particularly adept at managing each side of the equation individually, simultaneously improving data center efficiency, reliability, and performance while adjusting proactively to the conditions currently being experienced by the client.

Being contextually aware of the unique environment from which clients access applications over a network is part of the secret sauce of application delivery solutions. By being able to understand and adapt to conditions on a per-request basis it can optimize delivery of applications for everyone - whether they are at home, at the office, on the international space station, or 20,000 leagues under the sea.

Technorati Tags: MacVittie,F5,SD best practices,development,architecture,infrastructure,application delivery,context-aware,network,client,proxy,acceleration,security,internet,satellite,space station,submarine,adapt,performance,blog

Acceleration ABCs - O is for Outages (Otherwise Known as Oops)

Dawn Parzych — Thu, 13 Nov 2008 21:11:10 GMT

Having a site unavailable is probably worse than having a slow loading page. Outages can occur for multiple reasons such as an overloaded back end server, an upgrade that didn't go as planned, or a power outage at the data centre. Whatever the reason the end result is the same dissatisfied customers (some which may never come back) and lost revenue. Nobody is immune to outages there have been some fairly high profile sites that have had outages over the last year including Amazon, Twitter, and Facebook - just do a search for outages and you'll find many more that have occurred over the years.

With the evolution of social media news of an outage spreads rapidly and reaches a far broader audience than previously as addressed by Stephen Pierzchala in his Newest Industry blog:

"I became aware of both of these outages through a combination of FriendFeed and Twitter within minutes of them starting. This information spread quickly. And, due to the nature of these new technologies, people were able to comment on the outages, and theorize about the cause of the problems these large online firms faced."

Gone are the days when you can fix the problem and get your site back on-line before anyone realizes there was a problem.

Luckily there are solutions available to mitigate the risk of outages. A global traffic manager can direct users to a secondary data centre if a power outage occurs at the primary data centre. An application delivery controller can be used to mark a node or server as down if it fails to respond and an F5 Networks iRule can be used to redirect users to an "Under Construction" or "Site Unavailable" page as highlighted in this DevCentral forum post. But is presenting a "Site Unavailable" page really the best option or what happens if you have a single application server that goes down and no secondary data centre available to fail over to? The solution: a little known feature in WebAccelerator called stand-in.

The stand-in feature allows WebAccelerator to continue serving cached content for a period of time after it has expired from cache. Typically the first request after content has expired will result in a conditional GET being issued to the server to revalidate the content if an error is received that would then be passed onto the customer. With the stand-in feature enabled if an error message is received WebAccelerator will continue serving content for a configurable amount of time. Isn't it better to serve some stale or expired content rather than no content at all?

Technorati Tags: Acceleration,outage,application delivery controller,Twitter,Facebook,Amazon,Internet,F5,iRule. DevCentral

Image courtesy of Leia.