Published
Sep 08 2018 06:48 AM
821
Views
First published on CloudBlogs on Jun 02, 2015
A couple of years ago we had to make a very difficult choice about how we were going to deliver Enterprise Mobility management to our customers. At the time, we knew that the solution had to be delivered as a cloud service since that was the only way we could help the 100,000’s of customers and 100,000,000’s of mobile devices using the solution stay up-to-date amidst the constant change in the world of mobility. To do this, we had two options:
There is an
incredible
amount of innovation happening inside these Azure datacenters. Everything inside of them is automated and driven through policy, and, with our “Cloud-first” engineering principle, we prove out new capabilities in areas such as software-defined networking, software-defined compute, and software-defined storage at-scale in these cloud datacenters and
then
deliver them for you to use in Windows Server and System Center. This is one of the reasons why our pace of innovation has accelerated so much for our on-premises products.
We are also innovating how we house the compute, storage, and networking in our datacenters. One example of this is our Chicago datacenter (pictured below).
I think the last thing anyone would guess when looking at the containers above is that this is a cloud data center.
Each of those containers house about 2,500 servers and we can pull the container in, hook it up to the power and the network, and have 2,500 additional servers up and running in minutes. When it is time to upgrade to new hardware, we simply remove the old container and replace it with the latest and greatest. The speed and agility this provides us is phenomenal.
With this as a background, here’s how some of the Azure platform components that we use in Intune (and in all our services) provide the scale, performance, availability, and reliability required by our customers around the globe:
Within Intune, each micro-service owns its own data. This architectural setup is very different from a traditional on-premises client-server product where everything is usually written and read from a single database. The compute requirements of the Intune service is affinitized with its data allowing for performance and each micro-service can scale independently via independent service partitioning. This means that each micro service is able to make changes and updates without requiring communication and coordination with other teams. Everyone working on Intune is thus able to move faster and the changes in one micro service do not introduce risks in other micro services.
Bottom line
: You get more value and capabilities faster – and they are more resilient.
Resiliency
is a native part of this architecture, and many of our micros-services rely on
Azure Service Fabric
for availability and scalability. To give you an idea of just how much we value the resilient nature of our infrastructure (and, by extension,
your
organization) consider this: We maintain 5 (yes, five) replicas of our data in many of our micro-services. As nodes in Azure go up and down, the Windows Fabric automatically brings up a new instance of a service partition replica. Thus, there is no single point of failure in the infrastructure nor the data. In addition to automatically spinning up new nodes and seamless service functioning when this happens, we can also add new nodes into our subscription. When nodes are added, we can start moving hot service partition replicas to the new nodes. This gives us tremendous flexibility.
Also important is the “geo-affordances” provided by Azure. As noted above, we keep a lot of data in memory affinitized to compute, but, additionally, we write out to Azure Storage for those micro-services that need data durability. Today, we use Azure table and blob. This data gets replicated using
Geo Redundant Storage
. With this type of storage, a transaction is replicated synchronously to 3 nodes within the primary region and queued for asynchronous replication to a secondary region (hundreds of miles away from the primary), where the data is again made durable with triple replication. As a result, if there is a disaster, we can pick up with the persisted data from a completely different region.
Bottom line
: You get more value and capabilities faster – and they are more resilient.
We have done a massive amount of work to successfully architect the Intune and the EMS services in Azure as true cloud services. The end result of this unique architecture is a huge benefit for your organization.
A couple of years ago we had to make a very difficult choice about how we were going to deliver Enterprise Mobility management to our customers. At the time, we knew that the solution had to be delivered as a cloud service since that was the only way we could help the 100,000’s of customers and 100,000,000’s of mobile devices using the solution stay up-to-date amidst the constant change in the world of mobility. To do this, we had two options:
- Take SCCM and host it in the cloud and call it a cloud service or
- Build a true cloud service from scratch
Choosing option #2 came with costs, however .
Building our solution from scratch put us a little behind in the Enterprise Mobility Management market, but the agility it has enabled has made that worthwhile. For example, consider the volume of new value we have released through the monthly updates to Intune since November 2014. This agility will remain a key part of our differentiation, as well as a key part of your ongoing value, for years to come. As I mentioned in a previous blog post , when we decided to move our EMM to the cloud, we did not simply port SCCM to Azure. Instead, we decided to invest in a cloud service architecture for our solution to Empower Enterprise Mobility. Aside from the obvious difference of single-versus multi-tenancy, and the need to embrace and interact with other Microsoft Services (AAD, O365, etc.), we knew a modern architecture was necessary to allow us to really benefit from the advantages the cloud offers. These benefits includes our continuous (micro-service) deployment , elastic scale, technology heterogeneity, etc. This setup also provides a huge amount flexibility and autonomy to our engineering teams – which means they can innovate, update, and improve services constantly . Intune’s mobility micro-services are fully hosted in Azure and, even if we were in a single datacenter, this would provide tremendous benefits. However, with the global reach of Azure, the benefits of availability, performance and jurisdictional governance and sovereignty are massive. (This is a topic I’ll cover at length in a future post.) This use of Azure is a huge advantage. There is a mantra we use here that “we will follow Azure wherever it goes.” With 19 "regions,” Azure truly has a global footprint. Each of those regions has one or more datacenters with built-in redundancy within the datacenter, as well as redundancy to other regions. Microsoft is continuing to build Azure capacity around the world to keep up with accelerating demand, deepen the global footprint, and accommodate specific needs, like regulatory requirements that require data to be kept within a country (China) or region (EU). As Azure continues to stand up data centers around the world, Intune and all of EMS will take advantage of the capacity to deliver services in that region. Currently, our services run in North America, Europe, and APAC – with geo-redundancy within each of those regions.
There is an
incredible
amount of innovation happening inside these Azure datacenters. Everything inside of them is automated and driven through policy, and, with our “Cloud-first” engineering principle, we prove out new capabilities in areas such as software-defined networking, software-defined compute, and software-defined storage at-scale in these cloud datacenters and
then
deliver them for you to use in Windows Server and System Center. This is one of the reasons why our pace of innovation has accelerated so much for our on-premises products.
We are also innovating how we house the compute, storage, and networking in our datacenters. One example of this is our Chicago datacenter (pictured below).
I think the last thing anyone would guess when looking at the containers above is that this is a cloud data center.
Each of those containers house about 2,500 servers and we can pull the container in, hook it up to the power and the network, and have 2,500 additional servers up and running in minutes. When it is time to upgrade to new hardware, we simply remove the old container and replace it with the latest and greatest. The speed and agility this provides us is phenomenal.
With this as a background, here’s how some of the Azure platform components that we use in Intune (and in all our services) provide the scale, performance, availability, and reliability required by our customers around the globe:
Within Intune, each micro-service owns its own data. This architectural setup is very different from a traditional on-premises client-server product where everything is usually written and read from a single database. The compute requirements of the Intune service is affinitized with its data allowing for performance and each micro-service can scale independently via independent service partitioning. This means that each micro service is able to make changes and updates without requiring communication and coordination with other teams. Everyone working on Intune is thus able to move faster and the changes in one micro service do not introduce risks in other micro services.
Bottom line
: You get more value and capabilities faster – and they are more resilient.
Resiliency
is a native part of this architecture, and many of our micros-services rely on
Azure Service Fabric
for availability and scalability. To give you an idea of just how much we value the resilient nature of our infrastructure (and, by extension,
your
organization) consider this: We maintain 5 (yes, five) replicas of our data in many of our micro-services. As nodes in Azure go up and down, the Windows Fabric automatically brings up a new instance of a service partition replica. Thus, there is no single point of failure in the infrastructure nor the data. In addition to automatically spinning up new nodes and seamless service functioning when this happens, we can also add new nodes into our subscription. When nodes are added, we can start moving hot service partition replicas to the new nodes. This gives us tremendous flexibility.
Also important is the “geo-affordances” provided by Azure. As noted above, we keep a lot of data in memory affinitized to compute, but, additionally, we write out to Azure Storage for those micro-services that need data durability. Today, we use Azure table and blob. This data gets replicated using
Geo Redundant Storage
. With this type of storage, a transaction is replicated synchronously to 3 nodes within the primary region and queued for asynchronous replication to a secondary region (hundreds of miles away from the primary), where the data is again made durable with triple replication. As a result, if there is a disaster, we can pick up with the persisted data from a completely different region.
Bottom line
: You get more value and capabilities faster – and they are more resilient.
We have done a massive amount of work to successfully architect the Intune and the EMS services in Azure as true cloud services. The end result of this unique architecture is a huge benefit for your organization.
