Latest News from Don MacVittie

It's Time to Consider Human Capital Again

Tue, 15 May 2012 15:57:00 EDT

Throughout history there has been a cycle that ebbs and flows where new technology makes production more efficient and reduces the need for manpower in a particular space, thus forcing those in charge into the difficult position of deciding who stays and who goes. This is normally replaced by an uptake in needs for employees elsewhere, and eventually by expansion of the original vertical market, a return to labor-heavy workloads. This cycle has existed (in a variety of forms) for ages. With a crossbow, less skill and more bodies were needed to field an army. With early guns, more skill and less bodies were needed. The cycle goes around again. The same is true of any marketplace where technology can help improve efficiencies. In the case of farming, fewer small farms and an increasing number of massive farms with staff no larger than the small farms whose land the large ones take up. The reason being technology improving the rate of all the jobs that are required on a farm.

New Communications = Multiplexification

Wed, 02 May 2012 17:35:44 EDT

I wrote a good while back about the need to translate all the various storage protocols into one that could take root and simplify the lives of IT. None of the ones currently being hawked seem to be making huge inroads in the datacenter, all have some uses, none is unifying. Those peddling the latest, greatest thing of course want to sell you on their protocol because they hope to be The One, but it’s not about selling, it’s about useful. At the time FCoE was the new thing. I don’t get much chance to follow storage like I used to, but I haven’t heard of anything new since the furor over FCoE started to calm down, so presume the market is still sitting there, with NAS split between two, and block storage split between many.

There is a similar fragmentation trend going on in networking at the moment too. There have always been a zillion transport standards, and as long as the upper layers can be uniform, working out how to fit your cool new satellite link into Ethernet is a simple problem from the IT perspective. Either the vendor solves the issue or they fail due to lack of usefulness. But higher layers are starting to see fragmentation. In the form of SPDY, Speed + mobility, etc. In both of these cases, HTTP is being supplanted by something that requires configuration differences and is not universally supported by clients. And yet the benefits are such that IT is paying attention. IPv6 is causing similar issues at the lower layers, and it is worth mentioning here for a reason.

The key, as Lori and I have both written, is that IT cannot afford to rework everything at once to support these new standards, but feels an imperative (for IP address space from IPv6, for web app performance for the http layer changes) to implement them whenever possible. The best solution to these problems – where upgrading has its costs and failing to upgrade has other costs – is to implement a gateway. F5s IPv6 Gateway is one solution (other vendors have them too - I’ll talk about the one I know here, but assume it applies to the others and verify that with your vendor) that’s easy to talk about because it is being utilized in IT shops to do just that. With the gateway implemented, sitting in front of your DC, it translates from IPv6 to IPv4, meaning that the datacenter can be converted at a sane pace, and support for IPv4 is not a separate stack that must be maintained while client adoption catches up. If a connection comes in to the gateway, if it is IPv4 and the server speaks IPv4, the connection is passed through. The same occurs if both client and server support IPv6. If the client and server have a mismatch, the gateway translates between them. That means you get support the day a gateway is deployed, and over time can transfer your systems while maintaining support for all clients.

This type of solution works handily for protocols like SPDY too – offering the ability to say a server supports SPDY when in fact it doesn’t, the gateway does and translates between SPDY and HTTP. Deploying a SPDY gateway gives instant SPDY support to web (and application) servers behind the gateway, buying IT time to reconfigure those web servers to actually support SPDY. SPDY accelerates everything on the client side, and http is only used on the faster server side where the network is dedicated. Faster has an asterisk by it though. What if the app or web server is at a remote site? You’re going right back out onto the Internet and using HTTP unoptimized.

In those cases – and other cases where network response time is slow - something is needed on the backend to keep those performance gains without finding the next bottleneck as soon as the SPDY gateway is deployed. F5 uses several technologies to improve backend communications performance, and other vendors have similar solutions (though ours are better – biased though I may be). For F5’s part, secure tunnels, WAN optimization, and a very relevant feature of BIG-IP LTM called OneConnect all work together to minimize backend traffic.

OneConnect is a cool little feature that minimizes the connections from the BIG-IP to the backend server by pooling and reusing them. This process does several things, but importantly, it takes setup and teardown time for connections out of the picture. So if a (non-SPDY) client makes four connections to get its data, the BIG-IP merges them with other requests to the same server and essentially multiplexes them. Funny thing is, this is one of the features of SPDY on the other side, with the primary difference that SPDY is client focused (merges connections from the client), and OneConnect is server focused (merges connections to the server). The client side is “all connections from this client”, while the server side is “all connections to this server (regardless of client)”, but otherwise they are very similar.

This enters interesting territory, because now we’re essentially multi-multi-plexing. But we’re not. Here’s a simple diagram utilizing only a couple of clients and generic server/application farm to try and show the sequence of events:

1. SPDY comes into a gateway as a single stream from the client

2. The gateway translates into HTTP’s multiple streams

3. BIG-IP identifies the server the request is for

4. If a connection exists to the server, BIG-IP passes the request through the existing connection

5. When responses are sent, this process is handled in reverse. Responses come in over OneConnect and go out SPDY encoded.

There is only a brief period of time where native HTTP is being communicated, and presumably the SPDY gateway and the BIG-IP are in very close proximity.

The result is application communications that are optimized end-to-end, but the only changes to your application architecture are configuring the SPDY Gateway and OneConnect. Not too bad for a problem that normally requires modification of each web and application servers that will support SPDY. As alluded to above, if the application servers are remote from the SPDY Gateway, the benefits are even more pronounced, just due to latency on the back end.

All the benefits of both SPDY and OneConnect, and you will be done before lunch. Far better than loading modules into every webserver or upgrading every app server.

Alternatively, you could continue to support only HTTP, but watching the list of clients that transparently support SPDY, the net result of doing so is very likely to be that customers gravitate to your competitors whose websites seem to be faster.

Technorati Tags: Application Deployment,Application Delivery Optimization,Standards,SPDY,Automation,F5 BIG-IP,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

The Four V’s of Big Data
The “All of the Above” Approach to Improving Application Performance

Google SPDY Accelerates Mobile Web

Mobile Apps. New Game, New (and Old) Rules

Tue, 24 Apr 2012 16:54:55 EDT

For my regular readers: Sorry about the long break, thought I’d start back with a hard look at a seemingly minor infrastructure elements, and the history of repeating history in IT.

In the history of all things, technological and methodological improvements seem to dramatically change the rules, only in the fullness of time to fall back into the old set of rules with some adjustment for the new aspects.

Military history has more of this type of “accommodation” than it has “revolutionary” changes. While many people see nuclear weapons as revolutionary, many of the worlds’ largest cities were devastated by aerial bombardment in the years immediately preceding the drop of the first nuclear weapon, for example. Hamburg, Tokyo, Berlin, Osaka, the list goes on and on. Nuclear weapons were not required for the level of devastation that strategic planners felt necessary. This does not change the hazards of the atomic bomb itself, and I am not making light of those hazards, but from a strategic, war winning viewpoint, it was not a revolutionary weapon. Though scientifically and societally the atomic bomb certainly had a major impact across the globe and across time, from a warfare viewpoint, strategic bombing was already destroying military production capability by destroying cities, the atomic bomb was just more efficient. The same is true of the invention of rifled cannons. With the increased range and accuracy of rifled guns, it was believed that the warship had met its match, and while protection of ships went through fundamental changes, in the end rifled cannons increased the range of engagement but did not significantly tip the balance of power. Though in the in-between times, from when rifled cannons became commonplace and when armor plating became strong enough, there was a protection problem for ships and crews.

And the most obvious example, the tank, forced military planners and strategists to rethink everything. But in the end, World War II as a whole was decided in the same manner other continental or globe spanning conflicts have throughout history – with hoards of soldiers fighting over possession of land and destruction of the enemy. Tanks were a tool that often lead to stunning victories, but in the cases of North Africa and Russia, it can be seen that many of those victories were illusory at best. Soldiers, well supplied and with sufficient morale, had to hold those gains, just like in any other war, or the gains were as vapor.

Technology – High Tech as we like to call it – is the other area with stunning numbers of “This changes everything” comparisons that just don’t pan out the way the soothsayers claim it will. Largely because the changes are not so revolutionary from a technology perspective as evolutionary. The personal computer may have revolutionized a lot of things in the world – I did just hop out to Google, search for wartime pictures of Osaka, find one on Wikipedia, and insert it into my blog in less time than it would have taken me to write the National Archives requesting such a picture after all – but since the revolution of the Internet we’ve had a string of “this changes everything” predictions that haven’t been true. I’ve mentioned some of them (like XML eliminating programmers) before, I’ll stick to ones that I haven’t mentioned by way of example. Saas is perhaps the best example that I haven’t touched on in my blog (to my memory at least). When SaaS came along, there would be no need for an IT department. None. They would be going away, because everything would be SaaS driven. Or at least made tiny. If there was an IT version of mythbusters, they would have fun with that one, because now we have a (sometimes separate) staff responsible for maintaining the integration of SaaS offerings into our still-growing datacenters.

Osaka Bomb Damage – source Wikipedia

The newest version of the “everything is different! Look how it’s changed!” mantra is cell network access to applications. People talk about how the old systems are not good enough and we must do things differently, etc. And as always, in some areas they are absolutely right. If you’ve ever hit a website that was designed without thought for a phone-sized screen, you know that applications need to take target screen size into account, something we haven’t had to worry about since shortly after the browser came along. But in terms of performance of applications on cellular clients, there is a lot we’ve done in the past that is relevant today.

Originally, a lot of technology on networks focused on improving performance. The thing is that the performance of a PC over a wired (or wireless) network has been up and down over the years as technology has shifted the sands under app developers’ feet. Network performance becomes the bottleneck and a lot of cool new stuff is created to get around that, only to find that now the CPU, or memory, or disk is the bottleneck, and resources are thrown that way to resolve problems.

I would be the last to claim that cellular networks are the same as Ethernet or wireless Ethernet networks (I worked at the packet layer on CDMA smartphones long ago), but at a 50,000 foot view, they are “on the network” and they’re access applications served the same way as any other client. While some of the performance issues with these devices are being addressed by new cellular standards, some of them are the same issues we’ve had with other clients in the past. Too many round trips, too much data for the connection available, repeated downloads of the same data…

All of these things are relative. Of course they’re not the only problems, but they’re the ones we already have fixes for.

Take NTLM authentication for example, back when wireless networks were slow, companies like F5 came up with tools to either proxy for, or reduce the number of round trips required for authentication to multiple servers or applications. Those tools are still around, and are even turned on in many devices being used today. Want to improve performance for an employee that works on remote devices? Check your installed products and with your vendor to find out if this type of functionality can be turned on.

How about image caching on the client? While less useful in the age of “Bring You Own Device”, BYOD is not yet, and may never be, the standard. Setting image (or object) caching rules that make sense for the client on devices that IT controls can help a lot. Every time a user hits a webpage with the corporate logo on it, the image really doesn’t need to be downloaded if it has been once. Lots of web app developers take care of this within the HTML of their pages, but some don’t, so again, see if you can manage this on the network somewhere. For F5 Application Acceleration products you can, I cannot speak for other vendors.

The list goes on and on. Anyone with five or ten years in the industry knows what hoops were jumped through the last time we went around this merry go round, use that knowledge while assessing other, newer technologies that will also help. The wheel doesn’t need to be reinvented, just reinforce – an evolutionary change from a wooden spoke device to a steel rim, maybe with chrome.

While everyone is holding out for broad 4G deployments to ease the cellular device performance issue, specialists in the field are already saying that the rate of adoption of new cellular devices indicates that 4G will be overburdened relatively quickly, so this problem isn’t going anywhere, time to look at solutions both old and new to make your applications perform on employee and customer cellular devices.

F5 participates in the Application Acceleration market. I do try to write my blogs such that it’s clear there are other options, but of course I think ours are the best.

And there are a LOT more ways to accelerate applications than can fit into one blog, I assure you. A simple laundry list of tools, configuration options, and features available on F5 products alone is the topic for a tome, not a blog.

Now for the subliminal messaging: Buy our stuff, you’ll be happier. How was that? Italics and all.

</disclaimer>

If you can flick a configuration switch on gear you’ve already paid for, do a little testing, and help employees and/or customers who are having performance problems quickly while other options are explored, then it is worth taking a few minutes to check into, right?

Technorati Tags: Web Application Acceleration,Wireless,Mobile Performance,F5 WebAccelerator,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

The Encrypted Elephant in the Cloud Room
Stripping EXIF From Images as a Security Measure
F5 Friday: Workload Optimization with F5 and IBM PureSystems
Secure VDI Sign On: From a Factor of Four, to One
The Four V’s of Big Data

Web App Performance: Think 1990s.

Fri, 16 Mar 2012 17:33:48 EDT

As I’ve mentioned before, I am intrigued by the never-ending cycle of repetition that High Tech seems to be trapped in. Mainframe->Network->Distributed->Virtualized->Cloud, which while different, shares a lot of characteristics with a mainframe environment. The same is true with disks, after several completely different iterations, performance relative to CPUs and Application needs are really not that different from 20 years ago. The big difference is that 20 years ago we as users had a lot more tolerance for delays than they do today. One of my co-workers was talking about an article he recently read that said users are now annoyed literally “in the blink of an eye” at page load times.

Right now, web applications are going through one of those phases in the performance space, and it’s something we need to be talking about. Not that delivery to the desktop is a problem, network speeds, application development improvements (both developers learning tricks and app tools getting better), and processing power have all combined to overcome performance issues in most applications, in fact, we’re kind of in a state of nirvana. Unless you have a localized problem, application performance is pretty darned good. Doubt me? Consider even trying to use something like YouTube in the 90s. Yeah, that’s a good reminder of how far we’ve come.

But the world is evolving again. It’s no longer about web application performance to PCs, because right about the time a problem gets resolved in computer-land, someone changes the game. Now it’s about phones. To some extent it is about tablets, and they certainly need their love too, but when it comes to application delivery, it’s about phones, because they’re the slowest ship in the ocean. And according to a recent Gartner report, that won’t change soon. Gartner speculates that new phones are being added so fast that 4G will be overtaken relatively quickly, even though it is far and away better performance-wise than 3G. And there’s always the latency that phones have, which at this point in history is much more than wired connections – or even WLAN connections.

The Louis CK video where he makes like a cell phone user going “it.. it’s not working!” when their request doesn’t come back right away is funny because it is accurate. And that’s bad news for IT trying to deliver the corporate interface to these devices. You need to make certain you have a method of delivering applications fast. Really fast. If the latency numbers are in the hundreds of milliseconds, then you have no time to waste – not with excess packets, not with stray requests.

Yes of course F5 offers solutions that will help you a lot, that’s the reason I am looking into this topic, but if you’re not an F5 customer, and for any reason can’t/won’t be, there are still things you can do, they’re just not quite as effective and take a lot more man-hours. Going back through your applications to reduce the amount of data being transferred to the client (HTML can be overly verbose, and it’s not the worst offender), go through and create uber-reduced versions of images for display on a phone (or buy a tool that does this for you), consider SPDY support, since Google is opening it to the world. No doubt there are other steps you can take. They’re not as thorough as purchasing a complete solution designed around application performance that supports cell phones, but these steps will certainly help, if you have the man-hours to implement them.

Note that only one in three human beings are considered online today. Imagine in five years what performance needs will be. I think that number is actually inflated. I personally own seven devices that get online, and more than one of them is turned on at a time… Considering that Lori has the same number, and that doesn’t count our servers, I’ll assume their math over-estimates the number of actual people online. Which means there’s a great big world out there waiting to receive the benefits of your optimized apps. If you can get them delivered in the blink of an eye.

Technorati Tags: Application Delivery,Optimization,Compression,Deduplication,Mobile,3G,4G,F5 WebAccelerator,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

It’s Not Just Tech, It’s People Too.

Tue, 13 Mar 2012 18:42:26 EDT

What does a military unit that faced annihilation have to do with enterprise productivity. A lot more than you would think.

Last week I packed up my carry-on sized bags and headed off on economy to spend the week in Seattle, attending meetings with coworkers from several different parts of my company. Business Development, Sales, and Marketing mostly. But most of the people I spent time with were from the geek side of these establishments, with backgrounds in enterprise IT or software development. Most of them could still write some fine systems, and at least for the Sales Engineers I met with, most of them know more about architecture and enterprise IT than your average IT person.

And that is something I’ve found over the years. While we don’t often have time to just pop off and socialize with people from another group, if you make the time, be they business people or IT staff from another area, or HR reps, you will generally find that there are some smart folks in your organization that can and will help you when you need it. I’m a geek. The kind of geek that at thirteen knew he wanted to program computers for a living. That kind of implies I’m not a terribly social person. But taking the effort to get to know the strengths (and weaknesses) of fellow employees has always paid off. If for no other reason that you are consistently reminded of how smart the team you have working with you is.

It’s easy to assume that your average employee isn’t a rock star, but I’ll bet money that if your organization is successful, they are. There are two reasons I say that. First, to become successful you have to have smart people doing what needs doing in the marketplace. Second, once a company is successful, smart people want to come work for the organization. But if you don’t get to know your coworkers you’ll not see that and be reminded of it. I’m not a fan of the back-slapping, fun loving type of interaction, and my experience is that most geeks aren’t, but a sit down for ten minutes talking personably about what they’re doing that’s cool, and what you’re doing that’s cool, not only increases opportunities for you to identify places you can help each other, it builds respect and trust, both of which make for a stronger organization. If you ask any military unit from any country how they survived a tough spot, they’ll all tell you the same exact thing “Because we implicitly trusted each other”. The same is true for any group trying to achieve, the higher the level of trust, the more the group will band together to fend off emergencies and dangers.

If your organization is larger than eight or ten people, there is a pretty good chance there are people you’d rather not spend a break chatting with in it. Let’s face it, you get Cisco sized and there is a near zero chance that you will like everyone in the organization. Heck there is near zero chance you will meet everyone in the organization. But that’s not the point. If you chat with everyone else, you’re doing the same thing… Building trust and cohesiveness.

Canadian Soldiers in France, WWII.

“Isn’t that… networking?” many of you will ask at this point. I suppose you could call it that, but networking has a much more base goal in my opinion. Networking is so that you can forward your career at some point. This might well forward your career, but is more likely to develop understandings that allow you to go “I really don’t want to work extra this week, but HR/Accounting/Whoever really needs this project to come in on time”. And them to go “I really don’t want to lose this feature, but I trust my IT guy, if we have to drop it to make deadlines, we’ll schedule it for right after release.” This type of give-and-take works far better than rooms full of managers hashing things out, and is far less confrontational. Good for everyone, good for the organization.

While I wouldn’t spend a ton of time each week doing this, I would make the effort. It can pay off in many ways, but the biggest payoff, in my experience, is inn stress reduction. If there is a level of trust built over months or years, then the bad news about project X is more palatable to whichever side has to receive it.

You’re not soldiers in a battle for their very lives, you are employees pursuing a livelihood. I’m not claiming the stressors are the same, I am saying there is much that could be learned from tight-knit military units that fell into hard times. They sacrifice for each other, they protect each other, and they gather together to do the seemingly impossible. Misunderstandings are quickly glossed over and failures do not begin with recriminations. Most enterprises could learn something from that, but it has to start with you, chatting with people you don’t normally work with, just chatting about work, when you’re not working together.

If you want actual networking (not the geek kind) advice, see this video: Peyton Manning Farewell. I am not a football fan in any way (shhhh, don’t tell anyone here in Green Bay Wisconsin that, they tend to get pretty upset if you’re not a Packers fan), but this is the way you should exit an organization. They fired him, over an injury he received doing the job they assigned him. And he lets everyone know there is no bad blood. Maybe you don’t want to go as far as he did – he hugs the man that let him go – but the experience and knowledge you gained at an employer has a hard-to-quantify value that you can be grateful for, even if you really didn’t enjoy the job. Seriously, this is a classy exit, and I wish him luck.

But don’t go looking for an excuse to practice a Manning-style farewell. If you are in the company of smart people, it is presumed that you belong there. I write pretty, so they let me hang out with geeks that can describe DNS at a level I didn’t think existed, or draw multinational corporations’ IT networks on a whiteboard at the level of specifity you want on-demand. If you ever get the opportunity to work with an F5 Field Sales Engineer, you’ll get what I mean. Bright folks, and they’re typical of the quality of people we have across the company.

Peyton Manning

And no, if you’re in management or HR at your organization, this is not an invitation for you to poach our astounding staff, I just like to remind them that they are some of the best once in a while.

Technorati Tags: IT Management,Staffing,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Multiple Stream Protocols, eBooks, And You.

Thu, 01 Mar 2012 18:13:47 EST

EBook readers are an astounding thing, if you really stop and think about it. Prior to their creation, how could you reasonably have hundreds or thousands of books in one place, all the notes you took and highlighting you wanted to do, and your current page in each book all stored together in one easy to use place? We have a room that is a library. It has shelf upon shelf of books. We have other bookshelves throughout our house with more books. And do you think where you last left off in those books is remembered? Sure, some of them will retain bookmarks, but not automatically, you have to take steps to put the bookmark physically into the book and then hope that no one else messes with it. Lori and I have very similar tastes in reading, and we share almost 100% of the books in the house, which means inevitably someone’s page or a quote marker or something gets lost. Not with eBooks. We use Kindles, and all the books I read show up in her archive to read, all the books she reads show up in mine. My notes are mine, her notes are hers. All at the same time. No confusion at all.

The revolution in reading that eBook readers have enabled is not on the “uber-fast” pace that I would have expected, just because of the cost of entry. Buy a book to read today for $8 USD, or scrounge $100 to $500 USD to purchase a reader? For lots of people tight on cash, there is no choice there. The big-name publishers themselves haven’t helped any either. I’m not going to pay book price for a book I already own, just for the right to put it on my eReader, I’ll just pick up the paper copy, thanks. But it’s still moving along at a rapid pace because demand for one small tablet device to contain tons of books was unknown until it was real, but now that it’s real, demand is growing.

The same is true for stream protocols. That is protocols that bundle streams together into a single connection. From Java to VDI, these protocols are growing because they encapsulate the entire communications thread and can optimize strictly based upon whatever it is they’re transporting. In the case of Amazon’s SPDY or VDI, they’re transporting an awful lot, and often in two-way communications. And yet, like eBook readers, technology has come far enough that they do so pretty darned well. The real difference between these protocols and TCP or HTTP is that they allow multiple message streams within a single connection. Always remembering where each is, detecting lost data and which streams it impacts… Much like an eBook remembering your notes.

One corner of our library

And they’re growing in popularity. For Virtual Desktop Infrastructure, shared protocols are standard. For Amazon, SPDY capability is assumed on the server (or SPDY wouldn’t be an option), though it won’t be used if the client can’t support it. For Java, support of the IETF Stream Control Transmission Protocol (SCTP) is completely optional… For the developer. Since these protocols don’t impact the end user in any noticeable way, they will continue to gain popularity to multiplex several related functions over a single connection.

And you should be aware of that, because if you do any load balancing or own any tool that uses packet inspection for anything, you'll want to check with your vendor about what they do/intend to support. It’s passingly difficult, for example, to load balance SPDY unless the load balancer has special features to do so. The reason is simple, the current world of TCP and HTTP has a source and a target, but under SPDY you have a source and targets. If your device doesn’t know how to crack open SPDY and see what it’s trying to do, the device can’t very well route it to the best server to handle the request.

That is true of all of the multiple stream protocols, and as they gain in popularity, or when you start supporting one on your servers, you’ll want to make sure your infrastructure can deal with them intelligently. Much like back seven or so years ago, when content based routing hit the “what about encryption?” snag, you will see similar issues pop up with these protocols. If you’re using QoS functionality, for example, what if you limited video bandwidth to make certain your remote backup could complete in a timely manner, but users are streaming video over SPDY? How do you account for that without limiting all of SPDY? Well you don’t, unless your device is smart enough to handle the protocol. That doesn’t even touch the potential for prioritization that SPDY allows… If your device can parse it.

My Kindle currently holds more books than those shelves.

So pay attention to what’s happening in the space – when you have time – and perk up your ears for the impact on your infrastructure if someone wants to bring a product in-house that utilizes one of these protocols. They’re very cool, but don’t get caught unaware. Of course now that I’ve equated them to eBook readers, perhaps you’ll think of them whenever you read . And just like my kindle holds as many books as we have in our large library (my Kindle is around 500 right now, no idea how many are in the library, but 500 is a big number), those Multiple Stream Protocols could hold more connections than your other servers are seeing.

On the bright side, at least today, IT has to make a positive decision to use a product that requires these protocols, so you’ll get a chance to do some homework.

Technorati Tags: SPDY,SCTP,Protocols,QoS,Multiple Stream,F5 Networks,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

F5 Friday: Doing VDI, Only Better

Oops! HTML5 Does It Again

The Conspecific Hybrid Cloud

F5 and vCloud Director: A Yellow Bricks How-to

SPDY Wikipedia entry

SCTP RFC

Microsoft RDP description

Block Attack Vectors, Not Attackers

Wed, 29 Feb 2012 17:33:47 EST

When an army is configuring defenses, it is not merely the placement of troops and equipment that must be considered, but the likely avenues of attack, directions the attack could develop if it is successful, the terrain around the avenues of attack – because the most likely avenues of attack will be those most favorable to the attacker – and emplacements. Emplacements include such things as barricades, bunkers, barbed wire, tank traps, and land mines. While the long term effects of land mines on civilian populations has recently become evident, there is no denying that they hinder an enemy, and will continue to be used for the foreseeable future. That is because the emplacement category has several things, land mines being one of the primary ones, known as “force multipliers”.

I’ve mentioned force multipliers before, but those of you who are new to my blog and those who missed that entry might want a quick refresh. Force multipliers swell the effect of your troops (as if multiplying the number of troops) by impacting the enemy or making your troops more powerful. While the term is relatively recent, the idea has been around for a while. Limit the number of attackers that can actually participate in an attack, and you have a force multiplier because you can bring more defenses to bear than the attacker can overcome. Land mines are a force multiplier because they channel attackers away from themselves and into areas more suited to defense. They can also slow down attackers and leave them in a pre-determined field of fire longer than would have been their choice. No one likes to stand in a field full of bombs, picking their way through, while the enemy is raining fire down upon them.

A study of the North African campaign in World War II gives a good understanding of ways that force multipliers can be employed to astounding effect. By cutting off avenues of attack and channeling attackers to where they wanted, the defenders of Tobruk – mostly from the Australian 9th Infantry Division - for example, held off repeated, determined attacks because the avenues left open for attacks were tightly controlled by the defenders.

And that is possibly the most effective form of defense that IT Security has also. It is not enough to detect that you’re being attacked and then try to block it any more. The sophistication of attackers means that if they can get to your web application from the Internet, they can attack application and OS in a very rapid succession looking for known vulnerabilities. While “script kiddie” is a phrase of scorn in the hacker community, the fact is that running a scripted attack to see if there are any easy penetrations is simple these days, and script kiddies are as real a threat as full on high skill hackers. Particularly if you don’t patch on the day a vulnerability is announced for any reason.

Picture courtesy of Wikipedia

Let’s start talking about detecting malevolent connections before they touch your server, about asking for login credentials before they can footprint what OS you are running, and sending those who are not trusted off to a completely different server, isolated from the core datacenter network. While we’re at it, let’s start talking about an interface to the public Internet that can withstand huge DDoS and 3DoS attacks without failing, so not only is the attack averted, it never actually makes it to the server it was intended for, and is shunted off to a different location and/or dropped. Just like force multipliers in the military world, these channel traffic the way you want, stop it before the attack gets rolling, and leaves your servers and security staff free to worry about other things. Like serving legitimate customers.

It really is easy as a security professional to get cynical. After all, it is the information security professional’s job to deal with ne’er-do-wells all of the time. And to play the bad cop whenever the business or IT has a “great new idea”. Between the two it could drag you down. But if you have these two force multipliers in place, more of those great ideas can get past you because you have a solid wall of protection in place. In fact, add in a Web Acceleration Firewall (WAF) for added protection at the application layer, and you’ve got a solid architecture that will allow you to be more flexible when a “great idea” really sounds like one. And it might just return some optimism, because the bad guys will have fewer avenues of attack, and you’ll feel just that bit ahead of them.

If information technology is undervalued in the organization, information security is really undervalued. But from someone who knows, thank you. It’s a tough job that has to be approached from a “we stopped them today” perspective, and you’re keeping us safe – from the bad guys, and often from ourselves. I’ve done it, and I’m glad you’re doing it. Hopefully technological advances will force you to do less that resembles this picture.

DISCLAIMER: Yes, F5 makes products that vaguely fill all of the spaces I mention above. That doesn’t mean no one else does. For some of the spaces anyway. This blog was inspired by a whitepaper I’m working on, so no surprise the areas top-of-mind while writing it are things we do. Doesn’t make them bad ideas, in fact I would argue the opposite. It makes them better ideas than fluff thrown out there to attract you with no solutions available.

Technorati Tags: Security,DDoS,3DoS,Web Application Firewall,Internet Data Center Firewall,Application Delivery Controller,F5 Networks,Don MacVittie,blog

PS: Trying out a new “Related Articles and Blogs” plug-in that Lori found. Let me know if you like the results better.

Connect with Don:	Connect with F5:

Related Articles and Blogs:

F5 at RSA: Multilayer Security without Compromise
Making Security Understandable: A New Approach to Internet Security
Committing to Overhead: Proceed With Caution.
F5 Enables Mobile Device Management Security On-Demand
RSA 2012 - Interview with Jeremiah Grossman
RSA 2012 - BIG-IP Data Center Firewall Solution
RSA 2012 - F5 MDM Solutions
The Conspecific Hybrid Cloud

Why BYOD Doesn't Always Work In Healthcare
Federal Cybersecurity Guidelines Now Cover Cloud, Mobility

Committing to Overhead: Proceed with Caution

Wed, 29 Feb 2012 03:00:00 EST

Back when SaaS was making its debut in the enterprise, I was a mid-level IT manager with a boss that was smart. It was a great experience working for him overall, and if not for external pressures, I might still be working on his team. One of the SaaS conversations we had was pretty relevant to today’s rush to public cloud. He looked around the room and asked “Why are we getting rid of our mainframes?” There was the standard joking about old dogs and new tricks, and then the more serious cost analysis. Finally he said “No, we’re getting rid of our mainframes because a couple of decades ago, someone in my position said ‘we’ll sign these contracts that create overhead for ever, and future IT managers will have to deal with it. We won’t consider what happens when the market turns and the overhead is fixed even though the organization is making less, we won’t consider that this overhead will cost millions over the years. We’ll take the route we like, and everyone moving forward will have to deal with it.” We all pondered, it was a pretty cynical way to look at a process that chose the only viable solution back in the day, but it had a kernel of truth in it. He waited a bit, then finished.

Support for NIST 800-53?

Fri, 24 Feb 2012 12:30:00 EST

#f5friday There’s an iApp for that!

NIST publication 800-53 is a standard defined to help government agencies (and increasingly enterprises) rein in sprawling security requirements while maintaining a solid grip on the lockdown lever. It defines the concept of a “security control” that ranges from physical security to AAA, and then subdivides controls into “common” – those used frequently across an organization, “custom” – those defined explicitly for use by a single application or device, and “hybrid” – those that start with a common control and then customize it for the needs of a specific application or device. The standard lists literally hundreds of controls, their purpose, and when they’re needed. When these controls are “common”, they can be reused by multiple applications or devices.

For government entities and their contractors, this standard is not optional, but there is a lot of good in here for everyone else also. Of course external access to applications should be considered, allowed or not, and if allowed, locked down to only those who absolutely need it. That is the type of thing you’ll find in the common controls, and any enterprise could benefit from studying and understanding the standard.

For applications, using this standard and the ones it is based off of, IT can develop a security checklist. The thing is that for hardware devices, support is very difficult from the outside. It is far better if the device – particularly networking devices that run outside of the application context – implement the information security portions internally.

And F5 BIG-IP does. With an iApp. No doubt you’ve heard us talk about how great we think iApps are, well now we have a solid example to point out, where we use it to configure the objects that allow access to our own device. Since iApps are excellent at manipulating data heading for an application, the fact that BIG-IP UI is a web application should make it easy to understand how we quickly built support for 800-53 through development of an iApp that configures all of the right objects/settings for you, if you but answer a few questions.

800-53 is a big standard, and iApps were written with the intent that they configure objects that BIG-IP manipulates more than the BIG-IP configuration objects themselves, so there are a couple of caveats in the free downloadable iApp – check the help section after you install and before you configure the iApp. But even if the caveats affect you, they are not show-stoppers that invalidate compliance with the standard, so the iApp is still useful for you.

One of my co-workers was kind enough to give me a couple of enhanced screenshots to share with you, if you already know you need to support this standard in your organization, these will show you the type of support we’ve built. If you’re not sure whether you’ll be supporting 800-53, they’re still pretty information-packed and you’ll get why I say this stuff is useful for any organization.

The thing is that this iApp is not designed as a “Yes, now you can check that box” solution, it aims to actually give you control over who has access to the BIG-IP system and how they have access, from where, while utilizing the language and format of the standard. All of these things can be done without the iApp, but this tool makes it far easier to implement and maintain compliance because under the covers it changes several necessary settings for you, and you do not have to search down each individual object and configure it by hand.

The iApp is free. iApp support is built into BIG-IP. If you need to comply with the standard for regulatory reasons, or have decided as an organization to comply, download it and install. Then run the iApp and off you go to configuration land.

Note that this iApp makes changes to the configuration of your BIG-IP. It should be used by knowledgeable staff that are aware of how their choices will impact the existing BIG-IP configuration.

Technorati Tags: F5 Friday,iApps,NIST 800-53,F5 BIG-IP,Security,F5 Networks,Don MacVittie,Blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Committing to Overhead: Proceed With Caution.

Thu, 23 Feb 2012 13:01:10 EST

One of the SaaS conversations we had was pretty relevant to today’s rush to public cloud. He looked around the room and asked “Why are we getting rid of our mainframes?” There was the standard joking about old dogs and new tricks, and then the more serious cost analysis. Finally he said “No, we’re getting rid of our mainframes because a couple of decades ago, someone in my position said ‘we’ll sign these contracts that create overhead for ever, and future IT managers will have to deal with it. We won’t consider what happens when the market turns and the overhead is fixed even though the organization is making less, we won’t consider that this overhead will cost millions over the years. We’ll take the route we like, and everyone moving forward will have to deal with it.” We all pondered, it was a pretty cynical way to look at a process that chose the only viable solution back in the day, but it had a kernel of truth in it. He waited a bit, then finished.

“And that’s why we will not be using SaaS unless we have an exit strategy that covers all of the bases. We will not sign future IT managers on to overhead that we cannot determine is onerous or not. If we have a way to get our data into the system, a way to get our data out of the system, and proof that it is as secure as it is on our premises, then we will utilize SaaS to the maximum.”

That was good reasoning then, it’s good reasoning now. Though cloud is much more forgiving in terms of getting your data in and out, his point about committing the future to a fixed overhead holds today. When you own the systems, delaying upgrades or consolidating servers is an option. Dropping support to save money is an option. There are all sorts of fiscal flexibility issues that cloud takes away from management when times get tough.

Typical mainframe – the early years.

Compliments of ComputerScienceLab.Com

That’s not to say “public cloud is a bad thing”, it is to say that the needs of an enterprise are not the same as those of a start-up or small business. There are even valid reasons that international corporations have chosen not to take email to the cloud, though cloud based email is appealing to an organization that would need servers in multiple datacenters and administrators with extreme email chops. As with everything, consider the options and do what’s best for your organization. The buzz words are not why we all have jobs, solving problems for business is.

Even if you feel about cloud as my boss did about SaaS, you still have cloud opportunities. Replication is a good one if the replication tool handles encryption and compression. Testing is a no-brainer if your test data is scrubbed first. And capacity planning is a big one. If you deploy a pilot to the cloud and get a reasonable estimation of what kind of throughput, server utilization, etc. the application will require, then you can move it in-house and right-size the environment based upon projections from the pilot. It won’t be perfect, but it’s better than many of the capacity planning systems out there today, particularly the “let’s turn it on, and then worry about capacity” model some of you are using.

And for some organizations, tasks like email really can be shipped to the cloud (or a SaaS provider that claims to be a cloud), it just depends upon the legal and accountability standards your organization must or has chosen to implement. Though looking ahead, make a plan for getting out. It’s not about distrusting your provider, it is about risk management. Even if you love your provider today, they’re one purchase or upper management change away from being the biggest PITA you have to deal with every day.

The best system is if you’re actually doing cloud, replicate your VMs back to HQ on a regular basis. This process is easy and gives you a fall-back. You don’t have to “get your data out of the cloud”, it will already be out if you need it.

And like I’ve said elsewhere, for many of the compliance/security concerns, extend your existing infrastructure to the cloud where you can. No sense implementing two separate access control systems when you really only need one, only geographic location separates them.

Just some things to keep in mind when moving. Sure it’s cheaper this month, and maybe even cheaper in the long haul (the vote is still very much out on that one), but it will cost you some financial flexibility, fix more of your budget into immobility. If that trade-off is good for you, then just make sure you have an exit plan, because sooner or later, keeping a cloud service will no longer be your first choice, or you’ll have moved on and it will be someone else’s.

Technorati Tags: Management,SaaS,Cloud,IT Budgets,Mainframe,replication,F5 Networks,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

Network Virtualization Reality Check

Wed, 22 Feb 2012 09:00:00 EST

There are quite a few pundits out there that would like to convince you that a purely virtual infrastructure is the wave of the future. Most of them have a bias to drive them to this conclusion, and they’re hoping you’ll overlook it. Others just want to see everything virtualized because they’re aware of the massive benefits server and even in most cases desktop virtualization has brought to the enterprise. But there’s always a caveat with people who look ahead and see One True Way. The current state of high tech rarely allows for a single architectural solution to emerge, if for no other reason than the existence of a preponderance of legacy code, devices, etc. Ask anyone in storage networking about that. There have been several attempts at One True Way to access your storage. Unfortunately for those who propound them, the market continues to purchase what’s best for its needs, and that varies greatly based upon the needs of an organization – or even an application within an organization.

Network Virtualization Reality Check.

Tue, 21 Feb 2012 16:43:38 EST

But there’s always a caveat with people who look ahead and see One True Way. The current state of high tech rarely allows for a single architectural solution to emerge, if for no other reason than the existence of a preponderance of legacy code, devices, etc. Ask anyone in storage networking about that. There have been several attempts at One True Way to access your storage. Unfortunately for those who propound them, the market continues to purchase what’s best for its needs, and that varies greatly based upon the needs of an organization – or even an application within an organization.

Network appliances – software running on Commercial Off The Shelf (COTS) server hardware – have been around forever. F5 BIG-IP devices used to fall into this category, and like most networking companies that survive their first few years, we eventually created purpose-built hardware to handle the networking speeds required of a high-performance device. The software IP stacks available weren’t fast enough, and truth be told, the other built-in bottlenecks of commodity hardware were causing performance problems too.

And that, in a nutshell, is why network virtualization everywhere will not be the future. There are certainly places where virtualized networking gear makes sense – like in the cloud, where you don’t have physical hardware deployed. But there are places – like your primary datacenter – where it does not. The volume that has to be supported on a VM which will have at least two functional operating systems (the VM host and the VM client) between the code and the hardware, and physical hardware that is more than likely shared with other client images, is just not feasible in many situations.

You can scale out, that is truth, but how many VMs equals a physical box? Because it’s not just the cost of the VMs, the server they’re residing on costs money to acquire and maintain too, and as you scale out it takes more and more of them. Placing a second instance of a VM on the server to alleviate a problem with network throughput would be… Counterproductive, after all.

Image Courtesy of iPadWalls.com

So there are plenty of reasons to make use of a hybrid environment in networking architecture, and those reasons aren’t going away any time soon. So as I often say, treat pundits who are trying to tell you there is only one wave of the future with a bit of skepticism, they normally have a vested interest in seeing a particular solution be the One True Way.

Just like in the storage networking space, ignore those voices that don’t suit your needs, choose solutions that are going to address your architecture and solve your problems. And they’ll eventually stop trying to tell you what to do, because they’ll realize the futility of doing so. And you’ll still be rocking the house, because in the end it is about you, serving the needs of the business, in the manner that is most efficient.

*** Disclaimer: yes, F5 sells both physical and virtual ADCs, which are in the category “network infrastructure”, but I don’t feel that creates a bias in my views, it simply seems odd to me to claim that all solutions are best served by one or the other. Rather I think that F5 in general, like me in particular, sees the need for both types of solutions and is fulfilling that need.

Think of it like this… I reject One True Way in my Roleplaying, and I reject it in my technology. The two things I most enjoy, so working at F5 isn’t the cause of my belief, just a happy coincidence.

Technorati Tags: Virtualization,Cloud,Network,Infrastructure,Appliances,Application Delivery Controller,IT Management,F5 BIG-IP,F5 Networks,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

F5 Friday. IT Brand Pulse Awards

Fri, 17 Feb 2012 18:07:26 EST

IT Brand Pulse carries a series of reports based upon surveys conducted amongst IT professionals that attempt to ferret out the impression that those working in IT have of the various vendors in any given market space. Their free sample of such a report is the November 2010 FCoE Switch Market Leader Report and it is an interesting read, though I admit it made me want to paw through some more long-form answers from the participants to see what shaped these perceptions. The fun part is trying to read between the lines, since this is aimed at the perceived leader, you have to ask how much boost Cisco and Brocade received in the FCoE space just because they’re the FC vendors of choice. But of course, no one source of information is ever a complete picture, and this does give you some information about how your peers feel – whether that impression is real or not – about the various vendors out there.

It’s not the same as taking some peers to lunch, but it does give you an idea of the overall perceptions of the industry in one handy set of charts.

This February, F5 was honored by those who responded to their Load Balancer Market Leader Report with wins in three separate categories of Load Balancing – price, performance, and innovation, and took the overall title of “Market Leader” in load balancing.

We, of course, prefer to call ourselves an Application Delivery Controller (ADC), but when you break out the different needs of users, doing a survey on load balancing is fair enough. After all, BIG-IP Local Traffic Manager (LTM) has its roots in load balancing, and we think it’s tops.

IT Brand Pulse is an analyst firm that provides a variety of services to help vendors and IT staff make intelligent decisions. While F5 is not, to my knowledge, an IT Brand Pulse customer, I (personally) worked with the CEO, Frank Berry while he was at QLogic and I was writing for Network Computing. Frank has a long history in the high tech industry and a clue what is going on, so I do trust his company’s reports more than I trust most analyst firms.

We at F5 are pleased to have this validation to place next to the large array of other awards, recognition, and customer satisfaction we have earned, and intend to keep working hard to earn more such awards. It is definitely our customers that place us so highly, and for that we are very grateful. Because in the end it is about what customers do with our gear that matters. And we’ll continue to innovate to meet customer needs, while keeping our commitment to quality.

Technorati Tags: Load Balancing,Application Delivery Controller,IT Brand Pulse,Market Leader,F5 Networks,F5 Friday,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

F5 Friday. IT Brand Pulse Awards

Fri, 17 Feb 2012 16:07:26 EST

It’s not the same as taking some peers to lunch, but it does give you an idea of the overall perceptions of the industry in one handy set of charts.

Technorati Tags: Load Balancing,Application Delivery Controller,IT Brand Pulse,Market Leader,F5 Networks,F5 Friday,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Advanced Load Balancing for Developers

Mon, 06 Feb 2012 09:45:00 EST

It has been a while since I wrote an installment of Load Balancing for Developers, and now I think it has been too long, but never fear, this is the grad-daddy of Load Balancing for Developers blogs, covering a useful bit of information about Application Delivery Controllers that you might want to take advantage of. For those who have joined us since my last installment, feel free to check out the entire list of blog entries (along with related blog entries) here, though I assure you that this installment, like most of the others, does not require you to have read those that went before.

ZapNGo! Is still a growing enterprise, now with several dozen complex applications and a high availability architecture that spans datacenters and the cloud. While the organization relies upon its web properties to generate revenue, those properties have been going along fine with your Application Delivery Controller (ADC) architecture.

Now though, you’re seeing a need to centralize administration of a whole lot of functions. What worked fine separately for one or two applications is no longer working so well now that you have several development teams and several dozen applications, and you need to find a way to bring the growing inter-relationships under control before maintenance and hidden dependencies swamp you in a cascading mess of disruption.

With maintenance taking a growing portion of your application development manhours, and a reasonably well positioned test environment configured with a virtual ADC to mimic your production environment, all you need now is a way to cut those maintenance manhours and reduce the amount of repetitive work required to create or update an application. Particularly update an application, because that is a constant problem, where creating is less frequent.

With many of the threats that your ZapNGo application will be known as ZapNGone eliminated, now it is efficiencies you are after. And believe it or not, these too are available in an ADC. Not all ADC’s are created equal, but this discussion will stay on topics that most ADCs can handle, and I’ll mention it when I stray from generic into specific – which I will do in one case because only one vendor supports one of the tools you can use, but all of the others should be supported by whatever ADC vendor you have, though as always, check with your vendor directly first, since I’m not an expert in the inner workings of every one.

There is a lot that many organizations do for themselves, and the array of possibilities is long – from implementing load balancing in source code to security checks in the application, the boundaries of what is expected of developers are shaped by an organization, its history, and its chosen future direction. At ZapNGo, the team has implemented a virtual test environment that as close as possible mirrors production, so that code can be implemented and tested in the way it will be used. They use an ADC for load balancing, so that they don’t have to rewrite the same code over and over, and they have a policy of utilizing a familiar subset of ADC functionality on all applications that face the public.

The company is successful and growing, but as always happens in companies in that situation, the pressures upon them are changing just by virtue of their growth. There are more new people who don’t yet have intimate knowledge of the code base, network topology, security policies, whatever their area of expertise is. There are more lines of code to maintain, while new projects are being brought up at a more rapid pace and with higher priorities (I’ve twice lived through the “Everything is high priority? Well this is highest priority!” syndrome while working in IT. Thankfully, most companies grow out of that fast when it’s pointed out that if everything is priority #1, nothing is). Timelines to complete projects – be they new development, bug fixes, or enhancements are stretching longer and longer as the percentage of gurus in the company is down and the complexity of the code and the architecture it runs on is up.

So what is a development manager to do to increase productivity? Teaming newer developers with people who’ve been around since the beginning is helping, but those seasoned developers are a smaller and smaller percentage of the workforce, while the volume of work has slowly removed them from some of the many products now under management. Adopting coding standards and standardized libraries helps increase experience portability between projects, but doesn’t do enough.

Enter offloading to the ADC. Some things just don’t have to be done in code, and if they don’t have to be, at this stage in the company’s growth, IT management at ZapNGo (that’s you!) decides they won’t be. There just isn’t time for non-essential development anymore.

Utilizing a policy management tool and/or an Application Firewall on the ADC can improve security without increasing the code base, for example. And that shaves hours off of maintenance projects, while standardizing on one or a few implementations that are simply selected on the ADC. Implementing Web Application Acceleration protocols on the ADC means that less in-code optimization has to occur. Performance is no longer purely the role of developers (but of course it is still a concern. No Web Application Acceleration tool can make a loop that runs for five minutes run faster), they can allow the Web Application Acceleration tool to shrink the amount of data being sent to the users’ browser for you. Utilizing a WAN Optimization ADC tool to improve the performance of bulk copies or backups to a remote datacenter or cloud storage… The list goes on and on.

The key is that the ADC enables a lot of opportunities for App Dev to be more responsive to the needs of the organization by moving repetitive tasks to the ADC and standardizing them. And a heaping bonus is that it also does that for operations with a different subset of functionality, meaning one toolset gives both App Dev and Operations a bit more time out of their day for servicing important organizational needs. Some would say this is all part of DevOps, some would say it is not. I leave those discussions to others, all I care is that it can make your apps more secure, fast, and available, while cutting down on workload.

And if your ADC supports an SSL VPN, your developers can work from home when necessary. Or more likely, if your code is your IP, a subset of your developers can. Making ZapNGo more responsive, easier to maintain, and more adaptable to the changes coming next week/month/year. That’s what ADCs do. And they’re pretty darned good at it.

That brings us to the one bit that I have to caveat with F5 only, and that is iApps. An iApp is a constructed configuration tool that asks a few questions and then deploys all the bits necessary to set up an ADC for a particular application. Why do I mention it here? Well if you have dozens of applications with similar characteristics, you can create an iApp Template and use it to rapidly bring new applications or new instances of applications online. And since it is abstracted, these iApp templates can be designed such that AppDev, or even the business owner, is able to operate them Meaning less time worrying about what network resources will be available, how they’re configured, and waiting for operations to have time to implement them (in an advanced ADC that is being utilized to its maximum in a complex application environment, this can be hundreds of networking objects to configure – all encapsulated into a form). Less time on the project timeline, more time for the next project. Or for the post deployment party. One of the two. That’s it for the F5 only bit.

And knowing that all of these items are standardized means less things to get mis-configured, more surety that it will all work right the first time. As with all of these articles, that offers you the most important benefit… A good night’s sleep.

Technorati Tags: Application Delivery Controllers,VPN,Security,Applicaiton Development,Acceleration,WAN Optimization,Encryption,F5 Networks,Load Balancing For Developers,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

Advanced Load Balancing For Developers. The Network Dev Tool

Fri, 03 Feb 2012 15:54:59 EST

Technorati Tags: Application Delivery Controllers,VPN,Security,Applicaiton Development,Acceleration,WAN Optimization,Encryption,F5 Networks,Load Balancing For Developers,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

Like Cars on a Highway

Thu, 02 Feb 2012 10:00:00 EST

Every once in a while, as the number of people following me grows (thank you, each and every one), I like to revisit something that is fundamental to the high-tech industry but is often overlooked or not given the attention it deserves. This is one of those times, and the many-faceted nature of any application infrastructure is the topic. While much has changed since I last touched on this topic, much has not, leaving us in an odd inflection point. When referring to movies that involve a lot of CGI, my oldest son called it “the valley of expectations”, that point where you know what you’d like to see and you’re so very close to it, but the current offerings fall flat. He specifically said that the Final Fantasy movie was just such a production. The movie came so close to realism that it was disappointing because you could still tell the characters were all animations. I thought it was insightful, but still enjoyed the movie.

Like Cars on a Highway.

Tue, 31 Jan 2012 18:31:38 EST

It is common to use the “weakest link in the chain” analogy whenever we discuss hardware, because you have parts sold by several vendors that include parts manufactured by several more vendors, making the entire infrastructure start to sound like the “weakest link” problem. Whether you’re discussing individual servers and their performance bottlenecks (which vary from year to year, depending upon what was most recently improved upon), or network infrastructures, which vary with a wide variety of factors including that server and its bottlenecks.

I think a better analogy is a busy freeway. My reasoning is simple, you have to worry about the manufacture and operation of each vehicle (device) on the road, the road (wire) itself, interchanges, road conditions, and toll booths. There is a lot going on in your infrastructure, and “weakest link in the chain” is not a detailed enough comparison.

In fact, if you’re of a mathematical bent, then the performance of your overall architecture could be summarized by the following equation:

Where n is the number of infrastructure elements required for the application to function correctly and deliver information to the end user. From databases to Internet connections to client bandwidth, it’s all jumbled up in there. Even this equation isn’t perfect, simply because some performance degradation is so bad that it drags down the entire system, and other issues are not obvious until the worst offender is fixed. This is the case in the iterative improvement of servers… Today the memory is the bottleneck, once it is fixed, then the next bottleneck is disk, once it is improved, the next bottleneck is network I/O… on and on it goes, and with each iteration we get faster overall servers.

And interestingly enough, security is very much the same equation, with the caveat that a subset of infrastructure elements is likely to be looked at for security, just because not everything is exposed to the outside world – for example, the database only need be considered if you allow users to enter data into forms that will power a DB query directly.

So what is my point? well simply put, when you are budgeting, items that impact more than one element – from a security or performance perspective – or more than one application, should be prioritized over things that are specific to one element or one application. The goal of improving the overall architecture should trump the needs of individual pieces or applications, because IT – indeed, the business – is built upon the overall application delivery architecture, not just a single application. Even though one application may indeed be more relevant to the business (I can’t imagine that eBay has any application more important than their web presence, for example, since it is their revenue generation tool), overall improvements will help that application and your other applications.

Of course you should fix those terribly glaring issues with either of these topics that are slowing the entire system down or compromising overall security, but you should also consider solutions that will net you more than a single-item fix.

<blatant marketing>Yes, I think an advanced ADC product like F5’s BIG-IP is one of these multi-solution products, but it goes well beyond F5 into areas like SSDs for database caches and such. </blatant marketing>

So keep it in mind. Sometimes the solution to making application X faster or more secure is to make the entire infrastructure faster or more secure. And if you look at it right, availability fits into this space too. Pretty easily in fact.

Technorati Tags: Performance,Security,Architecture,Server,F5 BIG-IP,F5 Networks,Don MacVittie,Blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Blitzkrieg and VDI Edge Protection

Mon, 30 Jan 2012 13:00:00 EST

By now, everyone even vaguely familiar with information security knows the military maxim of blitzkrieg – burst through the hardened defense at a single point and then rush pell-mell to the rear where the soft underbelly of any static army lies. It is a good military strategy, provided you have the resources to break through the defenses and follow up with a rapid advance into the rear areas. While there are variants of this plan, and a lot of discussion about how/when it is strategically worth the risk, historically speaking it has been a smashing success. Germany did it to France and the Low Countries in 1940, to Russia in 1941, Russia returned the favor in 1943, and the western allies joined used it successfully at Normandy in late 1944. Sherman’s March to the Sea in the American Civil War was just such a ploy (though Sherman was more willing to hit civilian targets than a 20th century general would have been, it was still a rush to the soft rear), and the first Gulf War had the coalition forces doing much the same. These are just the large-scale instances of this theory in operation, but you have to admit it works. The risk is high though, as the Germans found out at Prokhorovka, and that alone makes generals cautious that they have the resources and intelligence reports to burst through in the first place.

Blitzkrieg and VDI Edge Protection.

Thu, 26 Jan 2012 18:19:26 EST

The difference between the military maxim and the theory that information security should follow it is an important one. In military theory, you only harden behind the lines if there is a high likelihood that the enemy forces will find a weak spot in your lines and exploit it to get at the rear areas. The conundrum for the defensive leader finding themselves in such a situation is that every combat soldier placed to the rear is one less combat soldier on the front, increasing the likelihood that there will be a breakthrough. In information security, the problem is that the resources of the attacker are theoretically unlimited. Unless they are apprehended by the authorities in their home country, there is no penalty for attacking over and over and over. The limiting factor for the attacker – that they might smash themselves upon their opponent – does not exist at this time in Internet parlance. An attack fails, that merely means the attacker marshals the same exact set of resources and tries again.

The defense, on the other hand, still has a limited number of resources (dollars and staff hours) to defend themselves with. And they must make the most of them. Defense in depth is an absolute necessity, simply because the attacker can continue ad-infinitum to try attacking, and the number of attackers is unknown but large. That leaves a heavy burden on information security staff, who have settled into the glum belief that it is “not if, but when” they will be defeated. While the ultimate solution to this problem rests outside the purview of corporate security, in the interim, it is necessary to do what can be done to simplify and strengthen the fortifications that are between ne’er do wells and corporate resources.

Just to add fuel to the fire, this is all happening at the same time that organizations are facing increasing pressure to expose more and more of their internal architecture to the Internet so that users can access their applications from essentially anywhere. So to put it into military terms, there are numerous hostile entities, an ever increasing front length, and a static number of defenders and resources. That is not a recipe for success in most scenarios.

So what is the serious information security professional to do? Well the first steps have already been taken. Defense in depth is just a fact that most organizations live with, down to firewalls between departments for some organizations. Anti-virus tools and encryption are the norm, not the exception, and external access is generally protected by a VPN. But new technologies bring new challenges, or more frequently make old but low likelihood challenges into higher priority issues.

As we deploy VDI – and we are deploying VDI at a faster rate than I’d expected – the issue of edge security becomes more and more of an issue. If you expose VDI desktops to the world so that your workers can log in at any hour and get some work done, or an employee who’s sick can stay home to avoid infecting others but is well enough to work can do so, you will have to find a way to lock that interface to the world down so that users can get in, but hackers cannot. This is more important than most interfaces because the interface sits in front of user desktops, and they generally have more access than a server.

While there are a variety of ways to attack such an inlet, DDoS – to keep employees from working remotely – and Trojans are the two most likely to be successful. What you’ll want on this inlet is a way to check that the client – be it PC or iPad or whatever – complies with security policy that includes at least rudimentary virus checking (since the client device is outside your network and possibly not even a corporate resource), and a way to resist DDoS attacks. A network level tool that shunts detected DDoS attacks off to neverland, like F5’s own BIG-IP is going to be the best solution, since traditional firewalls are aimed at detecting more traditional attacks and can become victims of a DDoS. Regardless of what you choose to protect against this type of attack, it should be something you can guarantee will stay standing when hit with thousands of dropped connections a second.

And you’ll want to be able to apply more generally corporate security policies. That’s a tough call in a VDI environment. While a product like BIG-IP can be set up to use your corporate security policies for access and authentication purposes, it is difficult – both legally and technologically - to force corporate security policy on employee-owned devices. Legally you can limit access based upon the status of the machine requesting it, the user name, and the geographic location, but you can’t insure that the device meets with the same stringent policies you would require on your internal network. And that’s a problem, because VDI is your internal network. Time will tell how large this threat looms, but I wouldn’t ignore it, since we know it’s a threat. Legally you can ask employees to agree to be bound by corporate security policy when accessing the corporate network from a home machine, but I honestly don’t know of anyone doing that today – and I am not a lawyer, so maybe there’s a good legal reason I haven’t heard of anyone doing just that.

In the end, the benefits of allowing some or all users to access their desktop remotely is a huge benefit, but be careful out there, the number of attackers isn’t going down, and while we’re working all of this out is their opportunity to take advantage of weaknesses. So protect yourself. I’d recommend F5 products, but there are other ways to try and resist the hoards should they come knocking at your public VDI interface. Whatever you choose, just make certain it is implemented well.

Technorati Tags: Information Security,VDI,Defense In Depth,DDoS,iPad,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Marchitecture 101

Thu, 26 Jan 2012 04:15:00 EST

There was an interesting discussion on one of the table-top wargame lists I belong to (Two Hour Wargames if you follow the hobby) about the “production value” of a given set of printed products. While it devolved (as web conversations often seem to) to a comparison with Hollywood, the point was valid. The original reviewer that caused the thread to get started was more interested in how pretty the books were than the quality of the contents. I, personally, don’t care how ugly or mal-produced a wargames ruleset is if the rules are consistent and provide many hours of enjoyable play. Since most wargames use a lot of charts, I prefer those to be easy to find also, but that’s not “quality of paper, binding, pretty pictures…” which is what the topic of the thread was.

It seems that every field of human endeavor suffers from this malady these days. A toy isn’t a toy until it is placed in a shiny box and sold for more than the toy should reasonably command. The same is true of smartphones, a field wherein huge advertising dollars are spent to spur your interest, even though those doing the advertising seem to know that word of (Internet) mouth drives sales as much as anything. In high tech, our shiny boxes and million dollar advertisement equivalent is Marchitecture. In marchitecture, the goal is to show you a solution that you want, whether the solution is implementable by reasonable people or not. And most often, a marchitecture can be implemented by reasonable IT folks, but has nothing special in it. You get everything you need to implement it when you buy the product, but the marchitecture brings the functionality together and puts it in a shiny wrapping.

Full Disclosure: My title is Technical Marketing Manager, though F5 is not the kind of company that forces me into marchitecture discussions unless they’re actually something of use – still, felt it worthwhile to mention for those of you who read this on one of its many syndicated locations. In short, I like to put the emphasis on the technical part, but thought you should know the marketing part.

The thing is, when you’re talking to your sales rep, you need to cut through the marchitecture discussion to figure out if the solution is real, reasonable, and supported. You will be sold something half-baked in your career, in my experience, most of the time you know it’s half-baked when you buy it. Several times I have been in meetings where the response to “function X is weak” is “but everything else is here, and X will get better.” And that’s okay, as long as you know that X is a problem going into the purchase. It’s those times when you’re told a product can do something and not given the 5000 line list of caveats that is a problem.

The point of marchitecture, like the point of the shiny packaging for a game like Skylanders is to pique your interest. The company wants to be involved in conversations with you. In a (sometimes misguided) attempt to speak to you on your terms, they offer something to pique your interest. The key is to find out early whether what they’re selling has legs. Ask for references, then when they bring them, ask for different references (I can find three people to support anything, but when you ask for a different set, then they have to scurry), dig into the technology, and though our sales staff may dislike my suggestion of lengthening the sales cycle, it is certainly in your best interests to do a trial of any major new product you’re considering before you offer up any money. Though if your “trial” must be big because the solution playground is, maybe you should just do testing of the features you need, and make your decisions off of that.

And don’t make the mistake of assuming that just because something is dressed up like marchitecture it is not useful. F5’s deployment guides (and more recently iApps in the same vein) are an example where we have put the product through its paces, configured it correctly, and tested it thoroughly. They exist to help you get quick use out of the product, and strictly speaking I wouldn’t call them marchitecture because they’re full of good, tested, configuration information, while marchitecture is usually at the 10,000 foot level. But they do, in a sense, pique your interest. When we have a configuration for VMWare and NetApp to do VMotion outside the metro area, well we certainly didn’t configure and test that scenario because we had nothing better to do – our customers and prospects told us they needed it.

Know what you’re buying. Know how it helps the project at hand, but also know how it can help you in other projects, now and in the future. Sure, the NUTS! book pictured above is not the best quality book I’ve ever bought, but the rules are solid and have served me (and many others) for years. The same should be true of your major IT purchases. Why buy something of limited use or tied to a specific project if you have a need across several projects, or could see a benefit to using something for several projects?

Anyway, time to climb off my soapbox. Keep kicking rear and making your company hum along without realizing they’d be lost without you.

And yeah, Skylanders and NUTS! are both a lot of fun to play, when you have the time to invest. The difference in packaging quality doesn’t matter much after purchase.

Technorati Tags: marchitecture,Skylanders,IT Management,Infrastructure,iApps,NUTS!,Two Hour Wargames,Activision,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

Marchitecture 101

Tue, 24 Jan 2012 15:47:06 EST

Anyway, time to climb off my soapbox. Keep kicking rear and making your company hum along without realizing they’d be lost without you.

And yeah, Skylanders and NUTS! are both a lot of fun to play, when you have the time to invest. The difference in packaging quality doesn’t matter much after purchase.

Technorati Tags: marchitecture,Skylanders,IT Management,Infrastructure,iApps,NUTS!,Two Hour Wargames,Activision,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

What's in Your Datacenter

Fri, 13 Jan 2012 09:45:00 EST

There is a series of advertisements for Capital One aired in the US featuring Vikings talking about “more points” from their credit cards that asks “What’s in your wallet?” While they’re entertaining, I never understood what Vikings had to do with a credit card, other than perhaps both like to plunder unsuspecting innocents. Though in fairness, credit card issuers tend to just increase rates, while the Vikings enjoyed wholesale slaughter when they plundered, and took literally everything not nailed down. But the question is valid in the modern day. Most people have enough credit cards, and read little of what is sent to them relating to those cards, that if you are like most people, you probably don’t know for certain what is in your wallet. What are the interest rates, current balances, and limits on all the cards you own? A surprising number of people cannot answer those questions – either because they have more cards than are readily memorized, or because they threw out all the paper that came with their billing statements that described changes to some or all of the above.

What’s In Your Datacenter

Thu, 12 Jan 2012 16:00:22 EST

There is a series of advertisements for Capital One aired in the US featuring Vikings talking about “more points” from their credit cards that asks “What’s in your wallet?” While they’re entertaining, I never understood what Vikings had to do with a credit card, other than perhaps both like to plunder unsuspecting innocents. Though in fairness, credit card issuers tend to just increase rates, while the Vikings enjoyed wholesale slaughter when they plundered, and took literally everything not nailed down.

But the question is valid in the modern day. Most people have enough credit cards, and read little of what is sent to them relating to those cards, that if you are like most people, you probably don’t know for certain what is in your wallet. What are the interest rates, current balances, and limits on all the cards you own? A surprising number of people cannot answer those questions – either because they have more cards than are readily memorized, or because they threw out all the paper that came with their billing statements that described changes to some or all of the above.

The author, with Lori and a collection of friends

This problem is very much true for modern IT departments also. I’ve talked in the past about getting the most out of the gear you have… Utilizing F5 BIG-IP LTM for load balancing, for example, is good since that’s where its roots are, but as a full-blown ADC, there is much more it can do that might save you the time and expense of buying another product. But there’s more. Some of the gear in your DC is redundant, some came in with a product, and you have never considered extending its use or eliminating it entirely. And that just might be costing your organization. It could be costing the organization a lot.

Let’s say you implemented a Virtual Desktop Infrastructure (VDI), for example, and the vendor that sold it to you sold a “preferred” ADC solution to go with it. While VDI is a heavy network use architecture, it should not use all the available resources on said ADC. So the question is “have you considered using it more broadly, and have you considered the use of other products that are deployed more broadly to solve the VDI ADC issues?” If every architectural solution you deploy comes with its own set of network components, you will soon have a network more complex than the minotaur's maze, and harder for operations staff to navigate. And seriously in the VDI case, if you’re virtualizing servers too, then getting specialized hardware just for VDI seems… Really very redundant (and why I picked VDI for an example, though other markets do the same thing).

We have steadily moved away from dedicated hardware for servers – particularly in cases where the servers were under-utilized – so purchasing different solutions for a single project or product seems like going backward. Network resources can be centralized and utilized across the organization – indeed, for a very long time they were. Only recently have some vendors started to delude themselves into believing that their product or solution is so special it needs its very own set of network resources. Consider for a moment the implications of “pay for the product, then pay us for this redundant infrastructure too” on your bottom line. Not pretty. And even if they give it to you free (I can think of a couple of vendors that have done this in the past either to increase apparent market share or to mask the cost of the infrastructure), you’re still paying for it one way or another. Nothing is free.

So if you have hardware sitting around that was sold as “special purpose”, and you’re using it just for one segment of your architecture, look around. Either you could use it more, or (more likely) you could use something else that does more than just the single task. Why pay repeatedly and introduce a bunch of different hardware/vendors into your growing network, when you can re-use or extend one set of gear to meet multiple needs. K.I.S.S. for those who recall that acronym.

So pay attention. Don’t settle for less because a software vendor is selling you hardware. Don’t purchase a solution you know could be used more globally unless you actually can use it more globally, and make sure that whatever hardware is in your datacenter is being utilized as much as you can/need to. And when evaluating new products, look at how you could fulfill needs from tools already in place or heterogeneous solutions before you go to buy special purpose. Save the budget. Waste not, want not and all.

Technorati Tags: VDI,Virtualization,IT Management,F5 BIG-IP LTM,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

New Year, Fewer Predictions

Wed, 11 Jan 2012 10:00:00 EST

After a couple of weeks of vacation, some minor oral surgery, a birthday, and my five year anniversary at F5 Networks (has it really been that long?), I’m back to annoy or please you some more. Our holidays were acceptable, and here’s hoping all of you had an enjoyable time also. One thing I noticed is either that I was out of touch over vacation, or there were far fewer “tech predictions for 2012” type articles than has been the case in the past. I think that’s a good thing. Let’s just deal with things as they come, shall we? We’ve got a ton of new technology covering everything from Security to Storage and every vertical you can think of, and there needs to be a bit of a breather while it’s all figured out.

From Point A to Point B

Wed, 14 Dec 2011 12:15:00 EST

The complexities of life often escape a young child. The Little Man asked me the other day why I had to go work, which was both a compliment to wanting to spend time with me and an unintended backhand slap at Lori, who was going to hang out with him while I took care of business. The answer was the usual stuff, that working paid the bills, and work has its own rewards… It did not include “and I like my job”, though I do, simply because I didn’t want to imply “more than hanging out with you” to a three year old. But children boil everything down to simplicity. The picture over there is said son, wearing a picklehaube with a Transformers shirt and (yes really) proclaiming he was an autobot because of the helmet. We adults, on the other hand, tend to layer complexity upon complexity until we’re not certain we’re getting value anymore, but we’re proud of whatever it is we have done/built/know. IT is like that sometimes. What is “the network” – in tweet length, for example?

The Key to IT Success Is Simple. Listen More

Fri, 09 Dec 2011 10:00:00 EST

Ever try to explain something to a three year old that they don’t want to hear? It’s a chore. They change the subject, try to ignore you, turn away, and as a last defense, start asking “why?” a lot. It is amusing that IT often suffers the same issues. Really. We’re adults, but at the root of the problem, they’re basically the same. When a customer says “We need fluff!” IT often responds with “We don’t support fluff, try some cotton balls instead”. The other situation that I find massive parallels in is the guy that simply knows everything. When you try to talk to him, he’s so excited to get his point across that he’ll talk over you, rambling on about the topic – or more often a tangent of the topic – and never hear you. IT does that too. A lot.

From a Network Perspective, What Is VDI, Really?

Wed, 07 Dec 2011 09:30:00 EST

We at F5 – like most collectives of geeks - are constantly discussing the wide array of IT boondoggles that are out there, looking at which ones hold water and which are just passing fads. Often we’re debating which are passing fads. Today I received an email to a small group asking if any of us had tried out the augmented reality stuff out there. I haven’t, but that gives you an idea of the edge that is sometimes taken. image And it is that time of year where every pundit and their uncle is making predictions about what will happen in high-tech next year. It is easy to forget that high-tech has long suffered under the “this year is the year of X!” syndrome when each year we hear it in forecasts and predictions as if it was the gospel truth, even if anyone practicing the craft on a regular basis knows that the prediction is wrong. I can recall years when Disk was Dead (almost every one since the turn of the century, in fact), years when iSCSI would eliminate Fiber Channel (abused so much that when iSCSI + NAS finally does, no one will notice), years when ISDN was going to take over the world (and two decades later, It Still Does Nothing), and predictions that in 2010, hardware load balancers would disappear. Funny, I still work for a rather successful company that makes them.

Is It Time For IT Role Reorgs?

Thu, 01 Dec 2011 10:50:01 EST

When I was hired in to a utility to head an Automated Meter Reading project that was just getting organized – R&D was largely done, but implementation was not started – the team was set up in a rather odd manner. We had our own datacenter, we had our own networking, we had our own well, everything. And that was a conscious choice on the part of management. As it was presented to me, they didn’t want the early phases of the project mired in “we can’t set up load balancing for our app, you have to go talk to the network team” type issues. The long-term plan would make a complete mirror of IT for this project – operations, networking, appdev. Again, as presented to me, the point was to have a group of people completely knowledgeable in the ins-and-outs of the applications and networking (including power line carrier, phone lines, cell towers, and satellite) that tied it all together. The project was huge, and by the time I left for another part of the company, had grown to be the largest I’ve ever been involved in – in terms of staff, dollars, however you want to measure. And my team knew those systems in ways that most IT projects never have to, largely because of the initial design.

Traditionally, the issues that concern network staff are not the issues that keep systems admins up at night. Generally speaking, the application people worry about whatever is bothering these other two groups plus whatever is wrong with the application. In a highly complex environment – like nearly every datacenter is these days – it can be downright painful to track all of the pain points from the moment a user logs in to the culmination of application usage.

The traditional silos – particularly around appdev, whose managers tend to jealously hoard their time as if the next rev of the application is always the most important thing in the future of the company – make it difficult to get a clear view of the application. The ecosystem in which a given application lives is massive. Really very massive. And there are a lot of places where improvements could be made… If the right group is available and that group has statistics on that bit, and, and, and.

So across the board performance reporting is needed. The type that can track how long it took ADS to respond to the login request, and how long it took to get a response from the database, and how responsive overall the application is… How much CPU is being utilized on both the virtual and physical machines, how much disk usage the entire system is overseeing, and if that’s a bottleneck…

We’re getting there. ADCs can manage load across multiple servers and report on responsiveness, VMWare VCenter, for example, can help with system resource usage monitoring from a more holistic point of view, and now F5 products support iApps reporting to get detailed reporting on a wide variety of app and server metrics. No doubt (if they can) our competitors will implement similar functionality. It returns managing an app to being a discussion about the app, rather than a bunch of disjoint discussions about generic resources.

So what’s next? As the title implies, it just might be time to rethink silos. Now some of you will strongly disagree, and I’m good with that – but consider the possibilities along the lines of that AMR project I worked on.

VCenter offers management at the physical machine level, but views into the application (actually the VM) itself. iApps offers management at the network level, but views into the overall impact of the network on a specific applications’ performance. Network hardware still exists and has to be maintained, servers still exist and need to be maintained, but much of that maintenance has been moved into an arena that allows less specialized staff to interface with it. Thus, you will still need a router jockey, but most of your resources could be realigned to focus on the application itself. Call them “Application Management Engineers”, and give them knowledge about the application. This only works well for some big and not-likely-to-go-anywhere applications like Oracle DBMS, or Microsoft Exchange, but that’s a lot of staff time that can be moved over. And conveniently, iApps has customized templates for most of the really big applications out there, from VDI to Exchange to Oracle to Sharepoint. Of course it can work for smaller applications, you’ll just need people to juggle a whole collection of applications at once.

Less hardware management staff and more application management staff. That’s what I’m thinking. Add that to my last post about making developers more involved in operations, and you start to look like a different organization. The focus having been shifted dramatically from hardware bits to overall application health.

These types of shifts always have some issues though – we all know that if you specialize a bunch of people in Sharepoint, then you lose some synergies with similar networking applications. But then you have a group that does Sharepoint-like applications. Essentially all web based information sharing across the organization. For small orgs this type of organization would not be feasible, but that’s true of today’s organization too – how many shops don’t have dedicated security or storage staff because they just don’t have the people for it. Then people simply take on multiple responsibilities.

The benefit is a stronger focus on the only thing your users (be they internal or external) care about – the application. Because in the end, it is (or should be) about the apps.

Technorati Tags: IT Management,Virtualization,VMWare View,Application-Centric,F5 iApps,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

DevOps. It's in the Culture, Not Tech

Wed, 30 Nov 2011 09:30:00 EST

It is entertaining to read all that is currently being written about DevOps. Having been a developer, a development manager, an operations manager, and even a CTO, I can attest to the fact that the “throw it over the wall” syndrome is real, and causes real problems for everyone involved. That is about where my agreement with the current round of pundits ends. The thing is that they talk like there is some fundamental technological reason why DevOps isn’t happening. That’s just not true. For those a little behind in your jargon, DevOps is making operations prevalent in the decisions of your development organization. We’ll take the discussion a little bit at a time. We have virtualization. We have astoundingly good virtualization from VMWare, Microsoft, RedHat, et al. So many of the concerns about development and ops go away immediately. “Developers test in the environment their tools run in!'” is oft-heard in the DevOps conversations. But that’s just not an issue. They can run three different OS’s to test with, and as many browsers in each OS as you want to support – all with a single set of hardware. So make testing in your operational environment mandatory. In fact, for most tools, they’re developing on whatever OS is being targeted anyway, because there are subtle differences – or no support at all – in other OSs.

He Who Defends Everything Defends Nothing... Right?

Sat, 26 Nov 2011 13:00:00 EST

There has been much made in Information Technology about the military quote: “He Who Defends Everything Defends Nothing” – Originally uttered by Frederick The Great of Prussia. He has some other great quotes, check them out when you have a moment. The thing is that he was absolutely correct in a military or political context. You cannot defend every inch of ground or even the extent of a very long front with a limited supply of troops. You also cannot refuse to negotiate on all points in the political arena. The nature of modern representative government is such that the important things must be defended and the less important offered up in trade for getting other things you want or need. In both situations, demanding that everything be saved results in nothing being saved. Militarily because you will be defeated piecemeal with your troops spread out, and politically because your opponent has no reason to negotiate with you if you are not willing to give on any issue at all.

There's Growth, and Then There's Growth

Fri, 18 Nov 2011 09:00:00 EST

At our annual sales conference, Lori and I sat in on a great presentation by coworker Dawn Parzych that talked about the Internet, usage, and patterns. There are two interesting statistics that she presented, and I’ve munged them to generate a combined statistic. Dawn is our Product Manager for acceleration, but the statistics I’m pulling out of her presentation are generic informational statistics. She mentioned her source, but alas, I didn’t write it down. Drop me a line if you simply must have it, and I’ll bug her for it. The numbers she quoted were 36 million in 1995 and 2.1 billion in 2011. Note that the graphs used in this post are all mine, so I bear responsibility if they don’t match the text description.

Making Chili and Managing Network Resources

Wed, 16 Nov 2011 10:15:00 EST

I don’t usually talk a lot about F5 specific solutions, but since we’re the only ones doing this (so far), the contents of this blog are F5 specific. Though this needs to be industry standard. So, you’re yearning for some chili. That’s understandable, this time of year is when those of us from the US midwest think of chili, because it’s good hunting season food, and it both fills you and warms you up. So grab a handful of hamburger and stuff it in your mouth, then grab a handful of dried kidney beans and stuff those in there too, no, don’t worry, we’re about to get to the cayenne pepper… No? Okay, okay, you want it to actually be mixed before it gets to your stomach. I suppose that’s understandable too. So toss a bunch of hamburger into a pot, throw in some dried kidney beans – don’t forget the water – some chili powder, some cayenne pepper, whatever other spices you like, some tomato sauce, that’ll about do it. Got all of that? Okay, so next you cook it. In all that other stuff, it’ll take a good long while for the hamburger to cook, but since we didn’t soak the beans, they’ll need a good long while anyway… What? That’s not it either?

Remember When Hand Carts Were State of the Art? Me Either

Fri, 04 Nov 2011 08:45:00 EDT

Funny thing about the advancement of technology, in most of the modern world we enshrine it, spend massive amounts of money to find “the next big thing”, and act as if change is not only inevitable, but rapid. The truth is that change is inevitable, but not necessarily rapid, and sometimes, it’s about necessity. Sometimes it is about productivity. Sometimes, it just plain isn’t about either. Handcarts are still used for serious purposes in parts of the world, by people who are happy to have them, and think a motorized vehicle would be a waste of resources. Think on that for a moment. What high-tech tool that was around 20 years ago are you still using? Let alone 200 years ago. The replacement of handcarts as a medium for transport not only wasn’t instant, it’s still going on 100 years after cars were mass produced.

RIP WinXP. Now, to the Future!

Wed, 02 Nov 2011 11:15:00 EDT

Last week, InformationWeek quoted a Microsoft manager as saying there was “No chance” Windows XP would get another stay of execution. This really shouldn’t be a surprise to anyone, it was only the backlash from enterprises that kept Microsoft from ending support for XP over the last several years. So now that Windows XP support will no longer be available, it is time for even the most recalcitrant enterprises to consider their options. All of their options. The world is changing on us yet again, and the needs of tomorrow might not be the needs of the future. Or even the needs of today. As always, I’ll preface this investigation with it’s your IT department, you know it best. Do what is best for your business. With that said, now I’ll tell you what I think you ought to consider – either now or in the near future.

The Past Is History, The Future A Chance To Do It Right.

Thu, 27 Oct 2011 14:57:31 EDT

There are many things in the history of high technology that are downright conundrums. One of the obvious ones is: given the formats and media currently used to distribute text, music, and video, for example, how do we protect the rights of both legal users and the creators of content? Of course we want people to be able to make a living of creating content, which does imply it is not given away at the whim of anyone with a copy, but we also (at least in most modern countries) want to protect the rights of people who have purchased (oh fine, licensed if you prefer) the software/book/music/movie to use their purchase/license freely. There isn’t an easy answer to this problem, because people disagree on the nature of the problem, and existing technology doesn’t support a reasonably sound mechanism for determining on-the-fly if the usage is legal.

We suffer a similar conundrum in InfoSec. We need to prevent unauthorized access to an application while not unduly inhibiting authorized access. The problem lies in the definition of “unauthorized”, which changes with every given application, and is wildly different between two points on the Internet. For some government websites, for example, “unauthorized” is, well, nearly everyone in the world. For other government websites, “unauthorized” is either a tiny subset of the world population, or only those who are set on disrupting the website’s normal function. The rest of the problem lies with the definition of “unduly inhibiting”. For most websites, “unduly inhibiting” is anything beyond a simple login. Indeed, for most websites out there, even logging in is delayed as long as possible. You can fill a cart in most web stores and only log in when going to check out, for example. But for some websites, again going to the government for examples (though there are plenty in the commercial world also), a physical security token with a login and a verification of ID are not “unduly inhibiting”, because the nature of the information to be found on the site is that sensitive.

We have traditionally protected our networks with firewalls, utilizing rules of these stalwart protectors between your application and the world to limit who can even get to an application. But firewalls were never a perfect solution. Logging in, for example, is not a function of a firewall for a given application, the application must handle this process. For known vulnerabilities, firewalls with advanced features are able to protect your application in the manner that all others are protected. They do a stand-up job of keeping malcontents at bay, in the generic 90% sense of “stand-up job”. But even modern “Application Layer” firewalls are not “Application Aware”. When they say “Application Layer”, they mean in the network stack, which is standards like TCP and HTTP, not actual Application needs.

But every application has its oddities. Be they the login process or the networks you want to allow connectivity to, be they protecting sensitive data from traversing the Internet unencrypted, or protecting a given field on a web page from various attacks that you know it is vulnerable to. And firewalls aren’t real good at most of these issues if they are issues for only your one application. Indeed, since firewalls are centralized to make management easier, most firewall products become unruly if you do use them to protect for the application-specific things that you know are out there.

A wonderful thing about history though, is that we write it forward. The future is coming, and we have the opportunity to make up for the shortcomings of traditional firewalls. We can “fill the gaps” so-to-speak with Web Application Firewalls. These tools are designed to protect your application and your application specifically from attacks that are more specific than the firewall would normally prevent. Utilizing application profiles (or templates, or whatever your vendor of choice calls them), you can start with generic settings for applications of the category yours is – or in many purchased-product cases the specific product. MS Exchange has enough organizations utilizing OWA for example, that most web application firewalls offer a canned OWA solution that you can then customize. Giving you protection specific to the application is a far site better than the generic protections you’ve gotten in the past. Many places have put Web Application Firewalls into place, but aren’t really using them for anything other than to check the box that says “requires a web application firewall” in a standard or regulation. That’s not making efficient usage of the tools at hand.

And there’s another reason that focusing security on applications is going to be important in the future. One you really do need to think about if you aren’t already pursuing this approach. Due to the nature of cloud computing, as I’ve mentioned before, your firewall, and all of your rules created over years of experience, is not going to run in a cloud. At least not right now. Some cloud vendors offer firewall services, but if you have a product like F5’s Application Security Manager (ASM), you can use the same rules in the physical version inside your datacenter and in the virtual edition running in a cloud environment. That’s a big bonus, as it allows you to copy your existing configuration, and with minimal changes to reflect the change in infrastructure, apply them to the virtual edition in the cloud. Your application receives the same exact protection, regardless of where future needs direct you to deploy it.

At least with InfoSec, we are making progress toward solving the problems. Now if only we could do so in the piracy space. Perhaps one day, we’ll have a way, and all agree on what is reasonable. Or at least most of us. Billions of people are highly unlikely to all agree.

Connect with Don:	Connect with F5:

Related Articles and Blogs

SSDs, Velocity and the Rate of Change

Fri, 21 Oct 2011 08:45:00 EDT

The rate of change in a mathematical equation can vary immensely based upon the equation and the inputs to the equation. Certainly the rate of change for f(x) = x^2 is a far different picture than the rate of change for f(x)=2x, for example. The old adage “the only constant is change” is absolutely true in high tech. The definition of “high” in tech changes every time something becomes mainstream. You’re working with tools and systems that even ten years ago were hardly imaginable. You’re carrying a phone that Alexander Graham Bell would not recognize – or know how to use. You have tablets with the power that was not so long ago only held by mainframes. But that change did not occur overnight. Apologies to iPhone fans, but all the bits Apple put together to produce the iPhone had existed before, Apple merely had the foresight to see how they could be put together in a way customers would love.

Even the Best-Written Code Has a Weakness

Wed, 19 Oct 2011 10:15:00 EDT

Developers are a great lot of folks, people who spend their day trying to do the impossible with bits for a customer base that is, by and large, impossible to satisfy. When the bits all line up correctly, the last line of code has been checked in, and the nightly compile accepted for deployment, then they get to sit back, relax for five minutes, and start over again. If this makes you think it’s not a great life, then you should live it. Developing gives instant feedback. No matter how unhappy users can be, fixing that nagging bug you’ve been chasing for hours is a rush, and starting with a blank source code file is like looking across a wide-open plain. You can see what might be, and you get to go figure out how to do it.

The Need For Speed. SSDs in the Enterprise.

Fri, 14 Oct 2011 07:00:00 EDT

#F5Friday SSDs speed more than just disk I/O on your servers.

If you’re one of those geeks (or gamers) that squeezes every last ounce of performance out of their personal computing equipment, then you’re well aware that the performance of Solid State Drives (SSDs) is far and away better than the performance of traditional Hard Disk Drives (HDDs). Simply put, because the disk does not have to spin up, the arm does not have to seek, and the head doesn’t have to wait for the correct sector to pass under it, SSDs are faster. The ability to just look up a storage location in a manner very similar to how your computer looks in RAM and return values through a conventional hard disk interface means they will likely always be faster than HDD technology. They’re more expensive though, and the bigger the drive, the bigger the cost difference per gigabyte. And even though SSDs have gone down in price since their introduction, HDDs have too, maintaining the disparity in prices.

But that doesn’t mean they’re unobtainable, or even significantly limit their uses where the enterprise is concerned. For systems that truly need SDDs, the cost differential is warranted. If you have the cache on your database read/writing from SSD for example, your database performance will go up significantly, making the ROI worthwhile for many organizations.

And the same is very much true for other caching environments that require high-speed throughput. The ability to write out to disk at two or three times the rate of an HDD can greatly improve performance of high-throughput systems.

SSD and HDD, Courtesy of MSystems and Wikipedia

That is why we at F5 recently introduced an SSD option for our new F5 BIG-IP 11000 platform. With the optional SSD drives, you can speed processing for such disk-intensive operations as encryption, compression, and if you have BIG-IP WOM installed, de-duplication. These processes are commonly offloaded to BIG-IP systems for the purpose of lightening the load on servers, and now SSDs can speed the processing on the BIG-IP. To be sure, many organizations don’t need SSD drives, that’s why they are optional in our configurations. Should your organization be one of those that does, however, now you have a solution. By speeding these processes – that occur in-line during transport – you speed overall communications on whatever network you are utilizing, be that a WAN replication scenario or an internal LAN Web Services request.

And that’s important. When you are shipping information over the public Internet, encrypting it on the way out preserves server CPU cycles for the application, and SSDs stretch just how much can be offloaded, because performance is increased. If your network is overloaded, having compression and/or de-duplication is also a major bonus, but only if the device doing the work is fast enough to keep up. For those organizations with so much throughput that encryption, compression, and/or de-duplication are causing unwanted latency, SSDs in their BIG-IP is the answer.

Another solution from our broad selection of tools, all aimed at helping you deliver solid solutions to meet the needs of your business, and keeping the network secure, fast, and available.

Technorati Tags: F5 Friday,BIG-IP 11000,Automation,SSL Offload,HDD,SSD,IT Management,Blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

Take a Peer to Lunch. Regularly

Thu, 13 Oct 2011 14:41:00 EDT

In many industries, it is all about word of mouth. I’m not talking about tech-savvy industries that have just rediscovered this truth since Social Media made it impossible for them to ignore, I’m talking about industries for whom it has always been about word of mouth… Take lawn care, child care, and household maintenance for example. In all three cases, most people will hesitate to invite a stranger into their home (or give them access to their children) without a recommendation of someone they trust. This has always been the case, and savvy business people in these markets tend to know that. Once you get into a social circle, it can do good things for your business, if you do a good job. We don’t hesitate to share our likes and dislikes with our friends – offline – and in case you missed it, we don’t hesitate to share some of our likes and dislikes online.

IT Is Not À La Carte; Or Is It?

Thu, 13 Oct 2011 10:00:00 EDT

There has been a lot written about “IT Democratization” and how it will change the world. To some extent that is true, and I’ve previously encouraged IT management to support the process. But listening to those who see a “Bright new future” makes me realize that while we agree in principal, as always, the devil is in the details. In high school, we could take the standard lunch for a set fee or eat à la carte, which was essentially a short-order grill. Others could bring their own lunch, whatever they (or their parents) could pack into a bag or box. In the case of à la carte’, the school had to plan ahead, make facilities ready, and be prepared to serve up quality food at affordable prices that would meet the whims of hundreds of high-school kids on any given day. A work of art that surely deserved more recognition than we gave it. In the case of bag lunches, well, the school provided nothing but tables. If the food was bad, ill-prepared, not suitable for human consumption, or otherwise not correct, this was not the school’s problem in any way.

In the End, You Have to Clean

Fri, 07 Oct 2011 07:45:00 EDT

I haven’t been in IT management for a while, but if I were right now, I’d get the storage guys to build me a pie-chart showing who owns how much data, then gather a couple of outrageous examples of wasted space (a PowerPoint that is more than five years old is good, better than the football pool for marketing from ten years ago, because PowerPoint uses a ton more disk space), and then talk with business leaders about the savings they can bring the company by cleaning up.

When The Walls Come Tumbling Down

Mon, 03 Oct 2011 13:15:00 EDT

When horrid disasters strike and both people and corporations are put on notice that they suddenly have a lot more important things to do, will you be ready? It is a testament to man’s optimism that with very few exceptions we really don’t, not at the personal level, not at the corporate level. I’ve worked a lot of places, and none of them had a complete, ready to rock DR plan. The insurance company I worked at was the closest – they had an entire duplicate datacenter sitting dark in a location very remote from HQ, awaiting need. Every few years they would refresh it to make certain that the standby DC had the correct equipment to take over, but they counted on relocating staff from what would be a ravaged area in the event of a catastrophe, and were going to restore thousands of systems from backups before the remote DC could start running. At the time it was a good plan. Today it sounds quaint. And it wasn’t that long ago.

Automation Is Not Your Enemy.

Mon, 03 Oct 2011 07:00:00 EDT

Sun Tzu wrote that you cannot win if you do not know your enemy and yourself. In his sense, he was talking about knowing your army and its capabilities, but this rule seriously applies to nearly every endeavor, and certainly every competitive endeavor. Knowing your own strengths and weaknesses - In our case the strengths and weaknesses of IT staff and architecture – is imperative if you are to meet the challenges that your IT department faces every day. It is not enough to know that you must do X, you must know how X fits (or doesn’t!) into your architecture, and how easily your staff will be able to absorb the knowledge necessary to implement X.

Take RSS feeds for example. RSS is largely automated. But if you receive a requirement to implement RSS in the corporate intranet or web portal, the first question is “can the system handle it?” If the answer is no, the next question is “can staff today implement it?” If the answer is no, the next question is “do we buy something to do this for us, or train staff to implement a solution?” Remember this is all hypothetical. Unless you had very specific needs, I would not recommend training staff to write an RSS parser. At best I’d say get a library and train them to use calls to it… Which does indicate a corollary to this point of Sun Tzu’s… Know the terrain (in this case the RSS ecosystem) in which you will meet your enemies.

Sun Tzu, courtesy of Wikipedia

By extension, knowing the terrain implies “have some R&D time in normal workloads”. I’ve said that before, but it’s worth saying over and over. Sure, some employees might waste that R&D time. Some won’t. Ask Google. It doesn’t have to be some huge percentage, just don’t ask your staff to be up-to-date on things they don’t have time to go research. But I digress.

As virtualization and cloud grow in importance, so too does the ability to automate some functionality. As end user computing starts to utilize a growing breadth of devices, automation starts to gain even more imperative. Seriously, on my team alone we have Android, Blackberry, and Apple tablets, Apple and Blackberry phones… And we’re all hitting websites originally designed for Windows. The ability to serve all of these devices intelligently is facilitated by the ability to detect and route them to the correct location – and to be able to monitor usage and switch infrastructure resources to the place that they’re most needed.

Some IT staff reasonably worry that automation is going to negatively impact their job prospects. Network Admins in particular have seen many jobs other than theirs shipped off-shore or automated out of existence, and don’t want to end up doing the same. But there are two types of automation advancement, those that eliminate or minimize the need for people – as factory automation often does to keep expenses down – and the type that frees people up to handle greater volumes or more complex tasks – as virtualization did. Virtualization reduced the time to bring up a new server to near zero. That eliminated approximately zero systems admin jobs. The reason is that there was a pent up demand for more servers, and once IT wasn’t holding requests up with cost and timing bottlenecks, demand exploded. Also, admins had more responsibilities – now there were the host systems and dozens of resident VMs.

The same will be true of increasing network automation. Yes, some of the tasks regularly done by network admins will get automated out of existence, but in return, managing the system that automates those tasks will fall upon the shoulders of the very administrators that have more time. And the complexity of networks in the age of cloud and virtualization is headed up, meaning the specialized knowledge required to keep these networks not just working, but performing well will end up with the network admins.

Making network automation an opportunity, not a risk. An opportunity to better serve customers, an opportunity to learn new things, an opportunity to take on greater responsibility. And make things happen that need to happen at 2am, without the dreaded on-call phone call.

We at F5 have been calling it “ABLE infrastructure” to reference our network automation efforts, and that’s really what it boils down to – make the network ABLE to do what network admins have been doing, so they can do the next step, integrating WAN and cloud as if it was on the LAN, and dealing with the ever-growing number of VMs requesting IP addresses. And some R&D. After all, once automation is in place, another “must have” project will come along. They always do, and for most of us in IT, that’s a good thing.

Technorati Tags: Automation,Blog,Cloud Computing,IT Management,Virtualization,F5 BIG-IP,F5 BIG-IP LTM VE,ABLE infrastructure,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

Once Again, It Really IS About the Applications

Tue, 20 Sep 2011 10:33:00 EDT

(Booming voiceover voice); Are you running the same tired old network tools? Does your network staff have to administer security and load balancing for each and every application? Do you find application analysts and owners show a growing frustration with the network team’s response times due to overloading? Well get in there and fix that network! Get the tools that you need to make your network more application friendly, reduce fatigue amongst your network staff, and give application owners more control of their applications!

Forget Performance IN the Cloud, What About Performance TO the Cloud?

Thu, 15 Sep 2011 16:40:02 EDT

In an N-Tiered architecture, the network connection between tiers becomes a truly important part of the overall application performance equation. This is a fact we have known for a couple of decades now. If your network performance is down for some reason (from mis-wiring to hardware mis-configuration to over utilization), your application performance will, by definition, suffer. I ran a test once while writing for Network Computing where the last person to use the lab had programmed the ports I was using to shunt bandwidth over threshold X onto a different VLAN. It took weeks and the help of one of the vendors under test – Juniper – to help me figure out exactly what was going wrong. Only after they observed that it was topping out and then dropping packets were we able to track down the one changed configuration setting. The funny thing is that this particular change would not have impacted the vast majority of testing that we did in the lab, I was just unlucky enough to pick the wrong ports for a test that purposefully overloaded the network. Until the Juniper crew said “no, that’s not right, we’ve done this test before”, I was blaming the products for the failures under high load… A symptom of the fact that when network performance degrades, systems appear to degrade. Thankfully, we caught the problem and I did not go to print with misinformation.

But it does highlight the need for network performance to be top-notch if your application performance is to be top-notch. And we’re starting to head into uncharted territory where this fact is concerned. The problem is that enterprises don’t generally throw a whole bunch of data over the WAN, and if they do, they have specially provisioned ways to do so – because they’re going to a remote datacenter or partner network that is known and data volumes can be calculated for.

But as we approach cloud computing we need to be more aware of the network performance aspects than we would be either in the datacenter or transferring between two datacenters. The reasons for this are manifold. First, you don’t have control of the connection to the cloud provider. You own one end, and with the right tools (skipping plug for F5 WOM here, look it up if you have a need) you can “control” both ends of the connection, but you don’t really have control of what is in-between. The volume of traffic, the size of the pipes, etc. are all dictated by outside forces. For some DC-to-DC connections this is true also, but unlike cloud, DC-to-DC is point-to-point. If you are dealing with one of the major cloud vendors, you can’t even be certain what country your app resides in at the moment, let alone the route to that application.

Some of this concern is automatically mitigated. If the platform provider is large enough to have datacenters in multiple countries, they have pipes bigger than New York sewers connected to those datacenters. Some of it can be mitigated by those same “right tools” that help at the ends of the connection, because they can create tunnels or p2p connections to handle communications, and offer bandwidth reduction capabilities to make certain you are only sending smaller amounts of data, reducing the impact of the network by having less round trips across it.

In cloud storage, you have a bigger issue because the whole point is to send massive amounts of data across the WAN. While the right products will reduce the footprint of that data with compression (skipping plug for F5 ARX, look it up if you have a need), you still are sending a lot, or you wouldn’t have to go to a cloud platform, you’d just store it locally. So the question becomes how to make certain that performance to the cloud storage vendor is optimal when you don’t own both ends of the connection? That’s a tricky question, because it is not just a question for today, it is a question forever. You see, the more you store in a cloud storage providers’ space, the less likely you are to want to change providers. But the more business a cloud storage provider receives, the more companies are cramming huge volumes of data in and out of their DC. Which could cause performance problems for you… Unless you have SLAs that are rock-solid and you’re willing to enforce.

The long and the short of this post is some advice. Get tools to reduce the amount you’re sending over the wire, and make certain you have an SLA that will cover you if your usage (or the other people using the providers’ usage) jumps. And yeah, if your vendor charges by the megabit or megabyte, check out some products that might reduce your throughput. I might have mentioned a couple here, but there are more out there.

Connect with Don:	Connect with F5:

Related Articles and Blogs:

From Fort to Trade Network - IT Exposure Issues

Wed, 14 Sep 2011 12:15:00 EDT

In most fantasy RPGs and in historical context, a fort is a well built defensive position that allows you to detect attacks and funnel them to places where they can be defeated. It's well constructed, has restricted points of entry, and has defense in depth. A trade network on the other hand is a lengthy line of trails and/or roads with little protection and lots of wide open spaces that allow enemies to attack at a point of their choosing. IT is in a state of transformation that these two definitions fit rather well. It started with CDNs, continued with SaaS, and has been evolving ever since.

Toll Booths and Dams, and Strategic Points of Control

Fri, 09 Sep 2011 09:00:00 EDT

An interesting thing about toll booths, they provide a point at which all sorts of things can happen. When you are stopped to pay a toll, it smooths the flow of imagetraffic by letting a finite number of vehicles through per minute, reducing congestion by naturally spacing things out. Dams are much the same, holding water back on a river and letting it flow through at a rate determined by the operators of the dam. The really interesting bit is the other things that these two points introduce. When necessary, toll booths have been used to find and stop suspected criminals. They have also been used as advertising and information transmission points. None of the above are things toll booths were created for. They were created to collect tolls. And yet by nature of where they sit in the highway system, can be utilized for much more. The same is true of a dam. Dams today almost always generate electricity. Often they function as bridges over the very water they’re controlling. They control the migration of fish, and operate as a check on predatory invasive species. Again, none of these things is the primary reason dams were originally invented, but the nature of their location allows them to be utilized effectively in all of these roles.

You Say Tomato, I Say Network Service Bus

Wed, 07 Sep 2011 09:15:00 EDT

It’s interesting to watch the evolution of IT over time. I have repeatedly been told “you people, we were doing that with X, back before you had a name for it!” And likely, the speaker is telling the truth, as far as it goes. Seriously, while the mechanisms may be different, putting a ton of commodity servers behind a load balancer and tweaking for performance looks an awful lot like having LPARs that can shrink and grow. You put “dynamic cloud” into the conversation and the similarities become more pronounced. The biggest difference is how much you’re paying for hardware and licensing.

Why Developers Should Demand Web App Firewalls

Fri, 02 Sep 2011 12:30:00 EDT

The Web Application Firewall debate has been raging for a very long time, and we keep hearing the same comments going back and forth. Many organizations have implemented them as a fast-track to compliance, primarily compliance with PCI-DSS, but the developer community is still hesitant to embrace them as a solution to their problems. And that’s because like so many things out there, they are seen as an “either-or” proposition. Either they can relieve a developer of the need to write security code, or they can’t. If they can’t, then why have them? I’m a developer by trade, and I get the sentiment. It’s tough to say “spend all this money, and I’ll keep spending my time”, could almost seem to make no sense.