Early in my career, I gave up photojournalism for computing. I worked in a small town, and across the square from my newspaper office was a computer center. They had a mainframe computer and five customers – banks, all of them. The guy who ran it was ancient: a grizzled, chain-smoking veteran who’d worked in computing since its dawn 30 years earlier. He offered me a 50 percent raise and all the free sodas I could drink if I learned how to run the bank processing every night.
This was 1985, and it was for me the beginning of an itinerant journey from one bleeding edge of the business to another. Fast forward approximately 30 years, and I am at Microsoft, stepping once again onto new terrain. As a Principal Software Engineering manager in Microsoft IT, I’ve spent the past three years immersed in the most interesting and unexpected ride of my career: helping Microsoft move our entire IT footprint to the cloud.
We’re making solid progress. Along the way, we’ve unearthed a lot of hard-earned wisdom. Our lessons are frequently the results of unforeseen problems, gnarly issues, and flat-out mistakes. Not surprisingly, our customers are quite curious to hear about this stuff in order to avoid experiencing the same pains themselves.
For today, let me share one of the first great lessons we learned.
As we built the strategy to move as fast as we could, one of the first and seemingly obvious things to do was to “lift and shift” our virtual machines (VMs) into the cloud. At that point, we had about 60,000 VMs running in on-premises servers across the company. It seemed rather logical that we could just “lift” them off our resident hardware and “shift” them onto the Azure IaaS (Infrastructure as a Service) cloud platform. Pick ‘em up, move ‘em on, shut down the hardware, and it’s all good, right?
It wasn’t long before we discovered that “lift and shift” in and of itself doesn’t work out too well. First off, it can increase your costs if you don’t know what you’re doing. VMs aren’t simple and nor do they operate independent of other factors. All that complexity can lead to a lot of unforeseen expenses. Your apps use data – a lot of which might remain on premises for some time in-house – and that can require expensive ExpressRoute connections to ensure security and compliance. Subscription costs, management challenges, and the many moving parts associated with a move to the cloud all represent potential problems that not only threaten to add costs but also to send you in unwanted directions.
After a couple years of wrestling with these problems, we finally came up with the right strategy.
Todd Himple, one of the senior engineering leaders on the team, and I managed to get it all onto one single slide, with the simple headline of “Microsoft IT’s Cloud Strategy.” We literally drew it on a whiteboard one day. And it’s probably one of the most viral slides in the company over the past couple years. It’s basically an inverted funnel:
You proceed from the top down, starting with “Retire it, right-size, eliminate environments.” In other words, just kill off as much as you can. Typically, this is more than 25 percent of everything in your datacenter – just garbage. Toss it out.
Going down the funnel, you move through the processes of using Software as a Service (SaaS), converting to Platform as a Service (PaaS), optimizing IaaS, and at the bottom, remaining on-premises. Literally, the last step in the roadmap is “lift and shift” – ironically, one of the first things we did when we started our cloud journey. There’s a place for it, but it should be done in the context of a comprehensive approach.
If this piques your interest or you’d like to know more, please don’t hesitate to reach out to your local Microsoft representative to arrange a visit to our Executive Briefing Center. And of course, we’re happy to share a whole universe of knowledge with you on IT Showcase.
That’s it for now. Thanks for reading!
To Learn More about Professional Services, contact us at 800-208-3617
May 31, 2017
Azure vs. AWS
Azure vs. AWS Why is Azure growing so quickly? Because […]