There have been a lot of questions about the recent announcement of our intention to acquire Acopia Networks, with the most oft repeated question being "Why?"

I'm guessing "why not" isn't an acceptable answer. But before we dive into the why, let me tell you a little story...

The Death of a NAS

Our home network is always growing. Because Don and I both work from home and he's doing a lot of interesting integration work with Java and iControl and I like to play with interesting ways to use iRules, we have incorporated a BIG-IP into our home network. It fronts several of the websites we run off our home network, and it has saved my servers many times - including a slashdotting late last year. It's also greatly improved the performance of the AJAX applications I'm running that get used heavily on a weekly basis, and lets me do some layer 7 routing that gets around issues with having a limited number of IP addresses from my local cable provider.  

That's great for the web tier, and exactly what BIG-IP was designed to do: virtualization, application layer awareness and routing, optimization, and availability.

But we also have one huge NAS device, an Infrant, that handles a lot of the storage of content. Back in the day I went digital for all my photos and haven't looked back. So every photo I have taken in the past 8 years is on that NAS, along with a large collection of MP3s to run through my SONOS, manuscripts of books and gaming modules we've written, and every image Don serves up on his wargaming site. Because so many of our websites serve content that is stored on that NAS, it's pretty central to our architecture and our uptime, and without the NAS my ability to serve up music on-demand is pretty much nil.

Recently one of the controllers on the NAS fried. Dead. RAID has saved the data, but we're down a disk and need a new solution before we lose everything. That requires either a new NAS or a new server with similar capacity. That's easy. The actual migration, however, isn't so simple. There are a lot of laptops and desktop machines that are mapped to that NAS, as well as mount points on every web server that use storage on that NAS for backups, storage, and web content. In order to remove the need to change the mount points on every server and remap drives on all the clients, there's going to be downtime. I'm not looking forward to it.

Worrisome, too, is the issue of needing more storage in the future. The same scenario applies, as any solution to adding more storage is almost certainly going to require a migration and downtime. With the impending launch of a new MacVittie in early 08, you can bet the number of videos and pictures is going to increase dramatically. And that will eventually mean more storage.

Now, downtime for us isn't a big deal. After all, our sites and content aren't used to generate revenue. But let's extrapolate for a minute and pretend I'm running Flickr, or YouTube, or a retail shop that depends on the availability of high quality photos for e-commerce. Pretend I'm running a financial site, where FIX transactions are arriving at the rate of thousands per second, and are dropped onto a file system for processing. Pretend I'm running a content delivery network.

Pretend I'm running any revenue driven site that depends on files - PDF, MP3, video, audio, software downloads, software patches, images, spreadsheets, maps, JavaScript libraries, CSS files, static HTML, configuration, XSLT, caches.

Downtime is suddenly very important and does affect revenue. High growth use of such sites demands increases in storage as well as high volume storage transactions (reads, writes) and the possibility of losing any given piece of that storage network is not only high, but financially (and reputation) damaging.

Enter Acopia

Just as BIG-IP allows you to add a new web server or application server transparently, without interrupting the availability of a site, so Acopia's devices allow you to add additional storage or migrate to new storage without interrupting availability or changing configurations. Just as BIG-IP ensures availability even in the event of a single web or app server failure, so Acopia ensures availability in the event of a single server or device failure.

That means no downtime. That means no loss of revenue. That means less management and maintenance work.

Acopia basically does for the storage tier what F5 does for the web and application tiers. Virtualization. Availability. Optimization. Scalability. Consider the process of bringing up a new application or web server in your data center to increase capacity. Images of these standard implementations that make use of a global namespace - a common, shared storage subsystem - will make the process of deploying new instances of both application and web servers so much easier. It eliminates the need to replicate data to local disks, and practically makes a new deployment hands-off, as if it were ready to be completely virtualized and automated.

Considering Acopia has a solution that works with VMWare, that idea isn't as far-fetched as it might sound, and the concept of the BIG-IP with its complete awareness of real-time conditions of the applications it manages, well, automatic provisioning of virtualized application and web-server capacity suddenly sounds more plausible than it ever has in the past.

So my answer to "Why Acopia" is pretty fundamental to the concept of application delivery networking. It's about a layer of infrastructure residing between the network and applications that secures, optimizes, and scales access to applications - and files. All applications access data in one of two ways: databases and files. Acopia is the answer to addressing access to the latter in the application delivery networking layer. Every application needs file access at some point, whether it's to serve images, configuration files, static content, rich media, or to process arriving files and transactions. The benefits of virtualization and load balancing are already well understood, and they hold true whether we're talking about files or applications.

Acopia is a fit with F5 not because it fits nicely into the web or application tiers, but exactly because it doesn't. It fits in the storage tier, which expands the reach of the application delivery network to be a more complete solution than it is today.

If you still think of F5 as "that load balancing" company, then this acquisition is not going to make sense. Neither would the acquisition of Swan Labs that led to WANJet and WebAccelerator, or of MagniFire, which gave us Application Security Manager, or uRoam, which gave us FirePass. These products aren't about load balancing either, they're about application delivery, and so is F5 and BIG-IP. Each product brings specific value on its own, but in concert with each other they add even more value because they can work together to deliver applications - all applications - optimally.

F5 is about architecting a better solution to address the issues associated with application delivery. We're trying to optimize and make reliable all the pieces of the puzzle, not just the ones that are obvious like web and application servers. We're trying to ensure the reliability and scalability of all the touch points between the network and the application. With Acopia we've added the storage tier to the list of tiers we already cover within the application delivery network.

There are a lot of benefits to architecting an application delivery network, but that's another post. There's a lot of synergy and possible points of integration between F5 products and Acopia products. But that's just another checkmark in the "good reasons to acquire this company" column. The most basic reason why F5 would acquire Acopia is that it doesn't do you any good for your applications to be secure, fast, and available if the files they're serving up aren't. 

That's what Acopia brings to the table and to the F5 application delivery network.

Imbibing: Coffee