In the data center of the future, you are going to need to be able to bring up new instances of an application, have them fully functional without any user intervention, and when they’re no longer needed they  should clean up after themselves and quietly go away. Five years ago this was fantasy talk, two years ago it was coming to the fore, and today we can see clearly that such adaptable infrastructure is going to be mandatory for any installation/application that has a highly variable rate of throughput.

The drivers for this need for adaptability are varied, but the core ones that we have all heard an earful of are cloud – where you are charged for your usage, and leaving apps running when not needed is tantamount to throwing money away – and a highly virtualized environment where there are a lot of virtuals running per physical server and keeping an instance running that you do not need is tantamount to throwing CPU cycles away. Okay, the alliteration was good, but it really IS throwing CPU cycles away, nothing tantamount about it.

The problem is/has been that there are a lot of complex pieces to put together when making such a system work. It is difficult to say “spin up an instance, give it access to all the resources it needs, and make it play well with the other instances of the same application while directing traffic to it.”

Yet all of this stuff exists – you provision servers and virtual servers and integrate them into your environment today – it just wasn’t designed with automation in mind. Which is kind of amusing if you think for a second about what computers are, at their heart. How we missed an opportunity to design for automation is a fun point to ponder.

Over the last couple of years, things have come a long way. VMWare has thin provisioning for disk, developers have gotten smarter about developing applications that automatically play nice with multiple instances of the same app running, and load balancers have APIs to help with automation. F5’s API is pretty thorough and allows you to do just about any automation task – indeed, I myself helped develop a complete automation system in Java with iControl that ran from Linux shell apps. You can check out some similar functionality in my iC2I series of Tech Tips from 2008. Here’s the one that shows how to create a Virtual IP from code with a minimum of information available iC2I: Creating a Virtual Simplified. The process isn’t simple because the architecture and assumptions – like the existence of a pool of servers to service the Virtual IP, monitors to check health, etc. – aren’t simple, but since you only create this code once, and this is the basis of a Java implementation to manage the Virtual IP creation process, it’s not too overly burdensome either. The flip side of this one (and I believe another installment in the iC2I series) is removing a node from a pool – deprovisioning from the Virtual IP perspective. I haven’t looked into the VCenter functionality to stop an instance, but likely it is there also.

When I wrote the iC2I series, TMSH did not yet exist. Now that it does, much of the functionality that was done in that series with Java could be done with command line scripts, though automation and coordination is admittedly easier to do from a Java application that can be run anywhere, it is another option to make the datacenter more dynamic.

This is the part where I normally say “and you can do this stuff with other vendors too…” You’ll note that this time I’m not. You can. It’s not so easy.

At this point in this blog, many of you will question how close we are to cloud computing without a ton of excess overhead. Lori and I were discussing that very topic and came to the conclusion that while this is data center automation, it is a long way from cloud computing. Suffice it to say that you can manage to bring things up and down, but the Business Process Automation portion – self-service provisioning, checking the health of the overall Virtual IP before harvesting a little-used instance, projecting needed usage into the future (to keep from harvesting a virtual machine that is likely to be needed in five minutes even if it is idle now) is all missing.

That doesn’t stop this functionality from being extremely useful in the data center of today or tomorrow though. The ability to spin up new instances and work them into the overall architecture at a whim (remember that by being behind a BIG-IP under a Virtual IP, you don’t have to worry about firewall or other infrastructure issues, and through VMWare VCenter you can set up disk and other per-instance tasks) is huge and has implications for your ability to sleep peacefully at night.

Using iSessions you can even distribute load to a completely separate data center (or cloud provider) and make the instances appear to the BIG-IP (and all connections running through it) to be coming from the current location. That allows you to automate not just the data center, but also shift load to a backup location that might normally only come online during downtime. Multiple data centers, one connection point, automation… Now we’re getting somewhere, no?

The picture at the right could be any BIG-IP arrangement (or most load balancers for that matter), except that “pool” could be in this data center, in the cloud, in a datacenter on the other side of the globe… It really doesn’t matter with iSessions, as long as you can build a reliable Internet connection to the location and there is a BIG-IP there also.

The point is that we’ve arrived at true data center automation and I  have seen it in action. It takes a time investment to get things going at first, but once they’re up, you can even hand out scripts (or point at a web interface) for IT application owners that allow them to add virtual machines on-demand by running a command line or clicking on a web page.

Once again, we see the power of the future coming to fruition, and the future appears to be a very cool place. Moving forward, perhaps the other pieces of cloud will fall as nicely into place, but this level of dynamism allows you to offer up the apps your business customers want, when they want them, where they want them, for as long as they want them… Without the overhead of spinning up machines yourself, or leaving dead instances running on your servers. And that doesn’t even touch on VMotion…