How to Slide Into Cloud

The most difficult step in any organization’s journey to the cloud is the first one: where do you start? You’ve watched the industry slowly adopt cloud computing over the last decade, but when you look at your on-premises data center, you can’t conceptualize how to break out. You’ve built your own technology prison, and you’re the prisoner. You might have a traditional three-tier application, and the thought of moving the whole stack to the cloud induces anxiety. You won’t control the hardware, and you won’t know who has access to the hardware. You won’t know where your data is, or who has access to it. It’s the unending un-knowing of cloud that makes so many of us retreat to the cold aisle, lean against the KVM, and clutch our tile pullers a little tighter. Then you consider the notorious migration methods you’ve read about online. Lift-and-shift cloud migrations are harrowing events that we should all experience at least once, and should never, ever experience more than once. Refactoring is often an exercise in futility, unless you have a crystal-clear understanding of what the resulting product will look like. So how do you ease into cloud computing if lift-and-shift and refactoring aren’t practical for you? You start considering a cloud-based solution for every new project that comes your way. For example, I’ve recently been in discussions with an application team to improve the resiliency of their database solution. The usual solutions were kicked around: a same-site cluster for HA, a multi-site cluster for HA and DR, or an active-active same-site cluster for HA and FT. Of course, in each case, there’s excess hardware capacity that will sit idle until a failure event. The costs associated with these three solutions would inspire any savvy product manager to think, “there’s got to be a better way.” And there is. It’s a cloud-native database service with an SLA for performance and availability, infinite elasticity, and bottomless storage. (Yes, I’m exaggerating a bit here, but look at the tech specs for Google CloudSQL or Amazon RDS; infinite is only a mild stretch.) You pay for the service based on consumption, which means all those idle cycles that would otherwise consume power and cooling are poof, gone. You’ll need to sort out the connectivity and determine the right way for your enterprise to connect with your cloud services, but that’s certainly easier than designing, implementing, and procuring the hardware and licenses for your on-prem HA solutions. Your application team gets the service they want without investing in bare metal that would only serve to make your data center chillers work a little harder. And more importantly, you’ve taken your first step in the journey to the cloud. A successful migration can spark interest in cloud as a solution for other components. The same application team, realizing now that their data is in the cloud and their app servers aren’t, might express an interest in deploying an instance group of VMs into the same cloud to be close to their data. They’ll want to learn about auto-scaling next. They’ll want to learn about costs savings by moving web servers to Debian. They’ll want to know more about how to set up firewall rules and cloud load balancers. They’ll develop an appetite for all that cloud has to offer. And while you may not be able to indulge all their cloud fantasies, you’ll find that moving to the cloud is a much simpler and enjoyable effort when you’re working in partnership with your application team. That’s the secret to embracing not just cloud, but any new technology: let your business problems lead you to a solution.