When you’re charged with mapping Microsoft’s expedition to the cloud, sometimes it’s best to go back to the basics—like using an old fashioned map to help you find your way.
- The learnings, pitfalls, and compromises of Microsoft’s expedition to the cloud
- Managing Microsoft Azure solutions on Microsoft’s expedition to the cloud
- Automating Microsoft Azure incident and change management on Microsoft’s move to the cloud
- The awesome ugly truth about decentralizing operations at Microsoft with a DevOps model
- Mapping Microsoft’s expedition to the cloud with good cartography (this story)
- Microsoft uses a scream test to silence its unused servers
An explorer in his own space, famous British film director Peter Greenaway once noted the significance of maps and cartography. “A map tells you where you’ve been, where you are, and where you’re going,” he noted in fascination. “In a sense, it’s three tenses in one.”
As a pioneer myself (in digital transformation), I couldn’t agree more. In my last blog post, I shared with you the awesomely ugly truth about how we decentralized operations at Microsoft and the intricacies and nuances we experienced as we adopted the Microsoft Azure DevOps model.
In talking to many of our customers, I know some of you are just starting out on your own cloud computing journey. So, let’s go back in time to the very beginning and share what happened the exact moment when our leadership gave the orders to start on Microsoft’s expedition to the cloud.
Microsoft Digital, our IT organization, is split into horizontal services (compute, storage, network, security) and vertical Line of Business (LOB) teams that provide solutions to our internal end users (Finance, HR, etc.). As the horizontal, our job is to ensure that our application teams have the appropriate computing systems and that those assets are tracked for cost and inventory purposes.
For a transcript, please view the video on YouTube: https://www.youtube.com/watch?v=jMGmL0B-4YQ, select the “More actions” button (three dots icon) below the video, and then select “Show transcript.”
When we got the announcement from management to start moving assets to the cloud, we simply did not know where to begin. Our first thought was to grab some “low hanging fruit” by targeting servers going out of service. We took a hard look at our physical and virtual inventory and soon realized that we weren’t even sure what was there.
One of the very first lessons we learned was that you can’t understand what applications you need to move if you don’t know what applications you have.
—Pete Apple, cloud services engineer, Microsoft Digital
My team took this opportunity to evaluate our inventory processes and assess how inaccurate our Configuration Management Database (CMDB) was—very! We found systems in datacenters that didn’t have any records. We found records in the CMDB for systems that no longer existed. Cleaning this up became someone’s part-time job (when it really could have been a full-time one).
One of the very first lessons we learned was that you can’t understand what applications you need to move if you don’t know what applications you have.
To move forward, we broke down the inventory effort by vertical organization and partnered a representative from each LOB to a designated person from our team. With the help of Microsoft Azure Service Map, we were able to scan each LOB application, identify what systems each LOB used and what other applications they relied upon to build a more robust dependency map.
This is an important step to take because, as you move applications into the cloud, systems that are next to each other in on-premises datacenters might end up in two different Microsoft Azure datacenters, creating an unexpected latency the team might not have accounted for in the design. Understanding this relationship ahead of time will help you factor which Microsoft Azure datacenter applications should go into and diminish the delay.
A good example of this is when we moved a financial database that many other applications depended upon. If we moved that critical application’s servers into the Microsoft Azure US West region, we wanted to ensure the dependent applications would end up there too, or otherwise, consider the possibility of change latency for calls to that data. Similarly, if the critical database had a disaster recovery setup to the US East region, it just made sense to map the dependent applications to that same region for disaster recovery.
With this approach, we were able to begin our “cloud cartography plans” and map our inventory in on-premises datacenters and plan their final destinations for migrating into Microsoft Azure. We now knew where they had been, where they were right now, and where they needed to go!
And then…during the cartography process we discovered an interesting fact. Maybe we didn’t need to move as much as we originally thought? More on that next time…
Read the rest of Microsoft’s move to the cloud series:
- Automating Microsoft Azure incident and change management on Microsoft’s move to the cloud.
- The learnings, pitfalls, and compromises of Microsoft’s expedition to the cloud.
- Managing Microsoft Azure solutions on Microsoft’s expedition to the cloud.
- The awesome ugly truth about decentralizing operations at Microsoft with a DevOps model.
- Microsoft uses a scream test to silence its unused servers
