Containers, not Cloud, Fulfill Mobility Promise
This message has been out there for a while; indeed, I’ve said it multiple times over the years, but it seems to get lost in the noise, so it is worth repeating.
Cloud is not application mobility, it is the opposite. If you read pundits’ writing carefully or look around your own organization, you’ll find the truth in this statement. Pundits will talk about “cloud vendor preference,” or “cloud vendor affinity.” They mean silos; often reinforced by vendor lock-in, but created because each cloud has different ways of doing things and people get used to ‘One True Way.’
And yet, organizations are throwing more applications than ever into the cloud. Which is fine if it’s the right tool for the job. But some of them are still citing mobility as their reason for going to the cloud. That’s hilarious—we all should know better at this point.
So, I’m back to beat the drum. Implement containers. Develop your entire application in a container infrastructure. Use cloud, or DC hardware or VMware or whatever you want to host the container environment. Mobility is now limited by spinning up a new container environment elsewhere and setting up network/security to access the containers. If you find that, for your app, another cloud vendor would be more affordable? Spin up an instance, load container management on the instance, move your containers over and set up networking and security. Done. Most apps can move in just a few hours from wherever it currently is to whatever platform you like. Some apps may take a day or two. We’ve certainly come a long way from, “This is never leaving the target platform.” And, in a manner that I think is very cool, the apps still don’t leave the target platform–it’s not like Linux apps are suddenly being spun up on Windows. It’s that Linux is now being spun up on Windows, and the Linux-targeted apps are coming along for the ride.
If you haven’t started with containers yet, find the staff that has (yeah, you have IT people that are using—or at least playing with—containers, I guarantee it) and have them set up an environment on hardware you own. Or VMs you own. While experimenting, don’t add in the complexity and cost of the cloud. Use whatever you have to get started. You can start with just containers on a desktop, but you will want container management for any professional use of containers, so you’re better off putting in a container management system straight away. I’m not recommending one by name here because we’ve seen serious volatility in this space over the last couple years, and we want this post to remain valid. We will just say, “not one based on a cloud vendor.” You want container management that is portable across many platforms, not one locked into a specific cloud or virtualization vendor.
Get it up and running, throw a couple of applications onto it and figure out how hard it would be to start moving your infrastructure onto it. Then, decide where you’d like a production version–for starters, at least–and start deploying. The ability to say, “This platform no longer suits our needs,” and move the entire infrastructure elsewhere is huge, and a benefit to your organization in the long run. Yes, cloud vendors offer convenient ways to do containers, and yes, their goal is to lock you in, so you have to do containers there, or pay a fortune to rework things for a move. Mobility is the customer’s friend, offering options for when, inevitably, your current platform is no longer the best choice.
If you’re in a cloud-based container environment, start moving things to a portable container environment. Not a rush, but I really think you’ll be happier in the long run. And if you’re already running a portable cloud environment, you rock. Keep kicking it. Those who follow after you will be happy when they find that their apps really are portable, as opposed to your competitors.
