{"id":6765,"date":"2023-11-08T08:16:11","date_gmt":"2023-11-08T16:16:11","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=6765"},"modified":"2023-11-08T09:35:33","modified_gmt":"2023-11-08T17:35:33","slug":"managing-microsoft-azure-solutions-on-microsofts-expedition-to-the-cloud","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/managing-microsoft-azure-solutions-on-microsofts-expedition-to-the-cloud\/","title":{"rendered":"Managing Microsoft Azure solutions on Microsoft\u2019s expedition to the cloud"},"content":{"rendered":"
A very popular clich\u00e9 used in Silicon Valley, the notion of having to \u201cship it and fix it and ship it again,\u201d was all too familiar to my team as we focused our efforts on moving, managing, and monitoring solutions in Microsoft\u2019s expedition to the cloud.<\/p>\n
Hello again and welcome back to our blog series on how our team helped Microsoft move most of Microsoft\u2019s internal workloads to the cloud and Microsoft Azure. My team in Microsoft Digital, the organization that powers, protects, and transforms Microsoft, is the primary horizontal infrastructure group and we\u2019re 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 the company operate internally.<\/p>\n
It became clear we were going to have to hybridize our management solution if we were going to get Microsoft\u2019s expedition to the cloud right.<\/p>\n
– Pete Apple, cloud services engineer, Microsoft Digital<\/p>\n<\/blockquote>\n
Check out Pete Apple’s expedition to the cloud series<\/strong>
\n<\/p>\n\n
- The learnings, pitfalls, and compromises of Microsoft\u2019s expedition to the cloud<\/a><\/li>\n
- Managing Microsoft Azure solutions on Microsoft\u2019s expedition to the cloud<\/a> (this story)<\/li>\n
- Automating Microsoft Azure incident and change management on Microsoft\u2019s move to the cloud<\/a><\/li>\n
- The awesome ugly truth about decentralizing operations at Microsoft with a DevOps model<\/a><\/li>\n
- Mapping Microsoft\u2019s expedition to the cloud with good cartography<\/a><\/li>\n
- Microsoft uses a scream test to silence its unused servers<\/a><\/li>\n<\/ol>\n<\/div>\n
In this blog post I want to share what it took for us to effectively migrate solutions from on-premises to the cloud while managing and monitoring them for day-to-day operations. Go here to read the first blog in our series: The learnings, pitfalls, and compromises of Microsoft\u2019s expedition to the cloud<\/a>.<\/p>\n
When I was running the hosting environment on-premises, our physical and virtual machine (VM) footprint was spread across multiple geographic datacenters, in two primary security zones\u2014\u201ccorporate\u201d and \u201cDMZ.\u201d Corporate refers to our internally facing services that our own employees use day to day for their jobs, while the DMZ holds our partner facing services that interact with the outside world. You might have a similar environment.<\/p>\n
We used Microsoft System Center Operations Manager (SCOM) for monitoring and Microsoft System Center Configuration Manager (SCCM) for patching (this set of tools has been combined into Microsoft Endpoint Configuration Manager). As we started to look at moving solutions over to Microsoft Azure, it became clear we were going to have to hybridize our management solution if we were going to get Microsoft\u2019s expedition to the cloud right.<\/p>\n
Microsoft Azure ExpressRoute allowed us to \u201clift and shift\u201d many of our on-premises VMs to the cloud as-is, which allowed us to operate them unchanged without disrupting our users. As more and more hosts moved from on-premises into Microsoft Azure, we eventually did a lift and shift on the Microsoft System Center servers themselves, so they were also operating out of a Microsoft Azure datacenter. Fair warning\u2014there\u2019s a tipping point when you get over 50 percent into the cloud based on the size of your environment and how quickly you\u2019re moving VMs into the cloud, so think about it ahead of time.<\/p>\n
Along the way, we learned that, in many cases, a cloud transition coincides nicely with shifting your application team to a DevOps model of deployment and management. We realized this early, which allowed us to change our technology and site reliability engineering practices in unison. For the DMZ and other internet-facing solutions, there were other options. We made sure our VMs in our internet-facing environment were within Microsoft Azure Update Management<\/a>, so they stayed up to date and monitored.<\/p>\n