2 ways to keep cloud vendors at a safe distance

Last week's article on preventing cloud vendor lock-in stirred up some interesting discussion, much of it anti-cloud. "Don't go to the cloud. Keep your data and processing safe in your site," said one reader. "Simple, no?"

Another reader, JamFuse, urged a more holistic view of the vendor lock-in cycle, which ultimately makes IT managers' jobs dull and miserable. I surfaced most of JamFuse's comment below:

"Are you all bitter because you are locked in to some off-the-shelf proprietary product that gives you no interesting implementation projects, no job satisfaction, and yet still does not solve your problems?" the reader asked.

As JamFuse explained it, cloud may offer a way to get around all of this staleness:

There is a potentially a better chance to avoid vendor lock in with cloud products than there has been for many other infrastructure-based products. There are two reasons for this, and both revolve around understanding the level of abstraction in the architecture:

1. Abstraction from the cloud infrastructure vendor: "Both OpenStack and full-blown vCloud are being implemented by multiple infrastructure vendors. They may have slight quirks in implementation, but if you read the labels carefully, you should be able to move between infrastructure vendors of your chosen cloud ecosystem. Or between public and private. This sounds similar to a where you could have only two or three big eco-system players which comes close to the argument that lock-in is unavoidable except the infrastructure vendors would be offering different support packages underneath the ecosystem from fully managed 24/7 phone to no-support-diy. This will then create some choices and avoid complete lock-in."

2. Abstraction from the ecosystem: "This is where it gets more complicated, but truth is that if you do the hard work at the beginning, you will have flexibility later on. You need to get into the 'infrastructure-as-code' mentality in a big way. Get familiar with a configuration management tool like Puppet/Chef/Ansible/Salt, and write descriptions for each piece of infrastructure. The annoying bit is then having to find the right orchestrator and bootstrap tools for the ecosystems, but once done, you can affectively move between ecosystems, as a migration, as a burst, or even as failover or load balancing between datacenters."

The bottom line, JamFuse said, is pursuing this architectural approach to cloud "means actually understanding it and getting people involved to set it up properly, not just paying for the latest platform/model/product and expecting it to work perfectly for any given scenario ... If you go down this road, you could make some big wins now and give yourself an infrastructure which can move around and so save company money in the future. Plus, you might get more interesting projects to do, more job satisfaction, and generally be a bit happier!"

Well said.