Only a handful of us at Microsoft hold coveted treasures like a 5¼ Windows NT release boot disk or a full set of long, shiny hair displayed on a 90’s Microsoft badge. But as exciting as those early computing times (and hairstyles) were, I’m finding more invigorating the remarkable odyssey my team and I have recently embarked on as we move from on-premises datacenters into the cloud.
Welcome to our blog series Operationalizing the cloud. My team is the primary horizontal infrastructure group and we’re responsible for ensuring our internal customers have servers, storage, databases—all the hard-crunchy bits of hosting—to run the critical applications that make Microsoft operate internally.
Who are you? You’re me, only working for another company (and probably with the full set of hair that I no longer have). You’re a decision maker or technical subject matter expert—or both—who has either been thinking about moving your company to the cloud, or been given the direction by management to get into the cloud, while ensuring everything runs as smoothly, or better than before. Maybe you’ve already started kicking the tires with cloud, you’ve got some production running and are ramping it up, or maybe you’re just starting to consider all the overwhelming intricacies that a cloud infrastructure involves. You’re wondering what the heck that’s going to mean for your operations, the various roles for your team, and what sort of issues you’re going to encounter that you haven’t even thought of yet.
That’s where I come in. For the last 5+ years we’ve been working on this—going from zero resources in Azure to nearly 80 percent hosted in the cloud. I’ve been involved for most of that effort including helping decide our direction technically and operationally and determining how our operational framework needed to change over time to support a hybrid environment. We went down some paths that we had to back out of (or are still trying to back out of in some cases). And we also had to go back to our internal customers and really listen to what they wanted, compromise and iterate our services to enable them to get to the cloud more easily.
One of the foremost examples of a compromise we had to make was moving applications into the cloud in a modern way to meet pressing timelines. Ideally, if you’re looking for the most efficient way to move an application, you would consider refactoring it into a microservice or cloud native architecture. However, in our case, we had some strict deadlines to meet on exiting datacenters and not necessarily enough budget to invest in a massive refactor of all the applications that had to get out. So we employed the popular lift-and-shift migration strategy that took our applications from systems in the on-premises to the Azure datacenter as IaaS virtual machines. As a colleague properly illustrated: it’s like taking boxes out of your garage and putting them into an offsite storage, without having to unpack or rearrange them. It got the desired datacenters closed on time, and we can go back and revisit the applications over time and as budget allows.
As we trekked further into our expedition to the cloud, we found we needed to rethink the way we handled our management and monitoring as well as how the Azure subscription service was delivered. We quickly embraced the agile methodologies other parts of our organization were moving to for software development, and started using them for our service engineering and operations.
In the next few blogs, I’m going to dive a little deeper into each of these processes to give you an idea of where we were and where we got to with our Azure service—with only a few bumps and bruises along the way—and hopefully save you some uncomfortable trauma as you embark or move along your cloud computing journey. Meet me back here in a couple of weeks and let’s talk cloud.
Visit our content library for more Azure scenarios and datacenter transformation content.