From Peeling the Onion to Dicing it: Welcome to the ABLE Network

In case you missed it, F5 released version 11 of TMOS this week, and working up some collateral for the release, I had an interesting epiphany. High availability, highly adaptable networks are about to change. Again. There has been a steady evolution of networking technology over the last couple of decades, that includes everything from TCP optimizations to application security have grown out of the need to improve something about the network.

The thing is that advanced Application Delivery Controller (ADC) functionality is still relatively new to the marketplace. The products are mature and server up a ton of data each day, solving performance and security problems for the world’s largest organizations, but they’re still evolving.

Up until this week, if you wanted to move some load off of your existing ADC, you had to scale out – adding ADCs (in redundant pairs where high availability is a concern) to provide a location for that load to be moved to. Failover of HA pairs was all-or-nothing. You could shift all of the load from the active ADC to the standby ADC, or you could not shift any of the load.

The network presents itself to IT as layers, with TCP networking at the bottom, and advanced application security or web client acceleration near the top. IT can optimize some or all of this network, with load balancing being core to the functionality of an ADC, and pretty close to the center of the network. Until this week you could work on different layers – say application security or network security – but you couldn’t chop those layers up – say working on application security for a given application and then moving that application about the network.

But what I found coolest about our announcement, is that it would seem to point the industry in that direction. With version 11 of TMOS, you can keep an active/active pair and shift load between them to keep either from being a bottleneck in normal operations, but still have redundancy should the worst happen. so you can shift load around – between blades, between BIG-IP devices… Currently only for a redundant pair. No doubt our competition will be working hard to implement the same type of thing – either in technology or market-speak – in the coming days.

But like I said, it’s the implication for the future. It’s cool that I can move the three busiest apps off what used to be the primary and service them off of the second in the active/active pair, but what the implication is (or should be – I’m not talking about F5 direction here, I’m talking about where I personally think it points the entire industry) that one day you’ll be able to shift ADC functionality – be it Web Application Acceleration or Load Balancing or Application Security – in much the same way that VMotion plus Long Distance VMotion will move your VMs around. As long as there’s an ADC at the receiving end, the policies, templates, iRules, what have you could be moved to the destination. Then a little bit of automation would get you to the truly mobile workload. Need to shift App X to the cloud before that next burst of users buries your Internet connection? Shift the VMS, shift the ADC functionality, and go to lunch.

You can do this today, but you’ll be skipping the “go to lunch”  step as you move configs and set the destination Application Delivery Controller correctly. So fully automated would be mondo cool…

Which gets me to wondering if you could do it on F5 gear today with iControl. Hrmmm. I’ll have to look into that. You can get and set most settings with iControl, I’ve written command-line systems to allow business owners to manage applications under BIG-IP. This is not that far a cry from it, the problem would be completeness – including all of the settings possible for all of the modules possible, comparing the source and target BIG-IP for the required modules… But it is doable. I think. Will have to do some research though – particularly since I haven’t looked into the v.11 iControl interfaces yet.

But push-button application mobility is one of the things that will be a hallmark of the future datacenter. The ability to move to the cloud, to a remote datacenter, particularly if that datacenter is a consolidation target – is intriguing to me. Put the app where it makes the most sense today, because you can move it easily if circumstances change tomorrow.

Dicing the onion sure seems a better plan than peeling it, and leaving applications sitting where they are because your infrastructure is not able to move it. For now, you have movement within a cluster, but watch this space, I’m looking into it.