What does a 2-year old and cloud-based applications have in common?

The Toddler has recently decided that he can navigate the stairs by himself. Insists on it, in fact. That’s a bit nerve-wracking, especially when he decides that 2:30am is a good time to get up, have a snack, and recreate a Transformers battle in the family room.

It’s worse when you’re asleep and don’t know about it.

Oh eventually you hear him and you get up and try to convince him it’s time for sleep (see? all the grown ups are doing it) but it takes a while before he finally agrees and you can climb back into bed yourself.

Mobility. It’s a double-edged sword that can bite not only parents of Toddlers testing out their newly discovered independence but the operators and administrators trying to deal with applications that, thanks to virtualization, have also discovered they have wings – and they want to use them.

When Toddlers application instances auto-launch themselves at 2:30am in any cloud computing environment it’s important to know where they are. While the worst the Toddler will likely do is try to raid the refrigerator the application may be doing far worse – it may be running up charges for merely existing while not doing anything substantially beneficial for you, like responding to application requests. In that respect you could say a virtualized application is more like The Teenager than The Toddler, because it seems to absorb money without any kind of return on investment.

Applications have never been islands but their reliance on the rest of the infrastructure to provide value, to respond to requests, to execute their functions, has never been more evident than when they’re dumped virtually into a cloud computing style environment. Without integration – either from within the application or from within its controlling management systems – with the rest of the infrastructure the application really is just wracking up charges without providing any real value to you or the users for whom it was launched.

And when applications become mobile, popping up at odd hours of the day and night in response to events and demands, this integration is absolutely required to ensure that the very raison d’etre of the application instance isn’t lost in the kitchen myriad virtual images humming happily in the data center (wherever that may be).

This is why orchestration is so important in ensuring a smoothly running virtualized infrastructure. Without someone paying attention, governing the instances, and making sure they are integrated with the right infrastructure components at the right time the entire value proposition of cloud computing and “fluid” architectures is rendered null and void. In the enterprise data center this process can be simpler than you might think, as the application can be directly integrated with the upstream components necessary to ensure it’s included in the process of increasing capacity through elastic scalability. When you “own” the infrastructure and you have the ability to integrate through standards-based mechanisms, you can ensure that no application is ever left behind when it enters the fray.

When you don’t own the infrastructure you need to be more choosy about the environment, ensuring that there are processes in place and means by which application instances will not be “lost” and incurring charges without providing benefit. What you don’t want is a manual process that requires you to manually integrate the application into the provider’s high-availability infrastructure (or yours in a true IaaS environment). You need Infrastructure 2.0 enabled components and operational processes that allow you to automatically ensure application instances are always being utilized when they’re available and not “powered on” when they aren’t.

Efficiency is about orchestrating operational processes, about eliminating manual tasks that could – and should – be handled through operational integration within the broader cloud computing ecosystem.

If that’s not the case, then the mobility of applications really is nothing less than a giant pain in aaS.