Yes, only a handful of us at Microsoft have been around long enough to 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 what’s more invigorating is 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 in Microsoft Digital, the organization that powers, protects, and transforms Microsoft, is the primary horizontal infrastructure group and we’re responsible for ensuring our internal customers have servers, storage, and databases, all the hard-crunchy bits of hosting, to run the critical applications that make Microsoft operate internally.

Check out Pete Apple’s expedition to the cloud series

1. The learnings, pitfalls, and compromises of Microsoft’s expedition to the cloud (this story)
2. Managing Microsoft Azure solutions on Microsoft’s expedition to the cloud
3. Automating Microsoft Azure incident and change management on Microsoft’s move to the cloud
4. The awesome ugly truth about decentralizing operations at Microsoft with a DevOps model
5. Mapping Microsoft’s expedition to the cloud with good cartography
6. Microsoft uses a scream test to silence its unused servers

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, technical subject matter expert, or both. You have either been thinking about moving your company to the cloud or have been given the direction by management to start doing so.

You’ve also been told to make sure 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 seven-plus years we’ve been working on this inside Microsoft—we’ve gone from zero resources in Microsoft 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 existing datacenters and not necessarily enough budget to invest in a massive refactor of all the applications that had to go out.

Because of that, we employed the popular lift-and-shift migration strategy that took our applications from systems in the on-premises to the Microsoft 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 Microsoft 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 Microsoft Azure service, with only a few bumps and bruises along the way. Hopefully we can save you some time, and headache, as you embark or move along your cloud computing journey. Meet me back here in a few weeks and let’s keep talking cloud.

Visit our content library for more Microsoft Azure scenarios and datacenter transformation content.

Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post The learnings, pitfalls, and compromises of Microsoft’s expedition to the cloud appeared first on Inside Track Blog.