Executive Considerations for Azure Adoption

By Andrew Snodgrass

Azure has the potential to help organizations reduce cost and deploy services faster than possible in most on-premises data centers. Azure provides scaling, security, data governance, global reach, and advanced features, such as machine learning, that many organizations struggle to deliver independently. However, not all workloads are suitable for Azure, and developing the skills to deploy and manage Azure services can increase cost. Migrating to Azure can be a difficult process that requires additional technology, management, and process changes with IT to keep pace with the rapid update cadence demanded by Microsoft.

Potential Benefits Are Real

Potential benefits include the following:

Scaling and quick deployment offer cost savings and reduce upfront capital expenditures. Azure services can be quickly deployed and scaled (up and down) to meet demand without an upfront cost. As compared to on-premises, where hardware is typically purchased for a high-water mark of demand and underutilized most of the time, hosted services allow customers to purchase only what is needed, when it is needed. For example, server capacity can be scaled up at the end of a fiscal quarter to meet the demands of a finance department and scaled down after the reporting period is over, thus reducing cost without purchasing additional hardware.

Global reach extends applications and data to users and customers. Organizations can leverage Azure’s global distribution of data centers to provide access to users and customers regardless of where they reside. Microsoft’s data centers and connectivity may be more robust than those of organizations, and they provide localized control and compliance with national data privacy, data governance, and data sovereignty requirements. Microsoft also delivers specialized data centers for the U.S. government, China, and the European Union that protect data in those locations from being accessed by foreign entities.

Security is better than most organizations, but it is still a hosted environment. Understanding the security risks and benefits of Azure can be difficult. Azure data centers are physically secured, and Microsoft provides advanced security features that are better than those most organizations employ. However, using Azure does not ensure higher levels of security, because customers can configure servers and interfaces that make them inherently insecure. Additionally, Azure is generally a multitenant environment where thousands of customers share the same data centers and hardware, which is different from on-premises where customers have the ultimate level of isolation.

Lack of Control Highlights Differences

Significant differences, as compared to on-premises, include the following:

Not your traditional data center arrangement. Azure provides hosted services rather than operating as a traditional data center hosting provider, such as EDS and IBM. Azure customers must use Microsoft’s equipment, and there is no option for Microsoft to accept and house a customer’s existing equipment. Consequently, when migrating to Azure customers often write off retired equipment with remaining life. Similarly, there are no provisions for on-site customer access to Azure data centers to work on the servers and storage directly, although there are limited options for shipping disks for direct import or export of data.

Legal access is not always revealed. Hosting providers, such as Azure, must respond to legal service from a government or as part of litigation for data, and sometimes that request must remain private or time may pass before the customer learns of the request. As a consequence, customers might not know their data is being released to authorities. On-premises, in contrast, all legal requests for data are served on the customer.

Update cadence is out of customers’ control. On-premises, many Microsoft products are purchased with perpetual rights that allow customers to stay on a version of the product for as long as desired, or until it is no longer supported. The same products in Azure are updated more frequently than on-premises, typically multiple times per year. Customers benefit from Microsoft management of updates, and customers have access to new features sooner, but the update cadence could require customers to change associated applications and perform testing more frequently than on-premises, which can impact auditing and validation processes.

Major changes and retirements happen with little notice. Microsoft may change or withdraw any Azure service with minimal notification to the customer, typically less than 12 months. Customers who have built applications or designed workloads using a service must react quickly and modify their applications to ensure they work with the proposed changes, prior to Microsoft implementing the change to production. It is also not unusual for Microsoft to retire a service that is either unprofitable or has poor adoption, which can significantly impact customers who have adopted the service. Unless a customer has an insider relationship with Microsoft, they should avoid new services until they have matured and been accepted by a wider audience, ideally securing the longevity of the service.

Hybrid deployments need specialized connectivity. Most organizations start with a hybrid deployment where a limited number of components are migrated to Azure, while the rest remain on-premises. This gradual migration is often done to mitigate risk, meet the schedule of a migration plan, or minimize disruption to the business. A hybrid deployment usually requires special connectivity between Azure and the customer’s on-premises data center to ensure that data is delivered quickly and securely. Such connectivity is an additional cost that is often underestimated.

Management and Migration Require New Skills and Diligence

Management and migration concerns include the following:

Ease of deployment is a benefit that can lead to rising costs. Azure’s ease of deployment allows customers to quickly configure new services. However, many resources allocated in Azure can accrue charges even when idle. This structure differs from traditional data centers, where purchased servers, storage, and applications can remain idle without additional cost. Without new forms of oversight, this method of deployment can lead to higher costs than originally anticipated. Customers will need new reports, analysis, and management diligence to monitor and shut off unused services, or to scale down and retire services that are underutilized.

New management and skills offset some cost savings. Azure requires new skills to properly manage the environment and ensure the customer recognizes the cost benefits that are expected. Azure differs from on-premises or a traditional data center provider, and many concepts will need to be relearned. Deployment, security, monitoring, storage, and access are all different, which means existing staff need to learn new skills. Some customers might require new staff and positions to manage the environment, offsetting some expected cost savings.

Migration is not as easy as advertised. Migrating to Azure (as with any cloud provider) is not simple, but rather it is a significant undertaking with considerable risk and should not be underestimated. Migration to Azure (even with the same configuration as on-premises) is still migrating to new equipment in a new environment, and it requires planning, analysis, code changes, security changes, testing, training, and new support processes. It may also require new forms of connectivity that tie Azure to an on-premises environment, particularly if only some services are initially migrated.

Making the Call by Workload

Azure provides a wide range of services that accommodate most data center requirements. However, potential customers should not assume Azure is a solution for every data center need. There are workloads that customers have been unable to deploy on public cloud platforms because of requirements that can currently be met only in traditional on-premises environments. Consequently, there are strong candidates and weak candidates for migrating to Azure.

Examples of strong candidates for Azure:

  • New compute-intensive or storage-intensive applications that require large upfront investments, for example, Big Data analysis
  • Workloads with significant variability in demand (elastic), such as seasonal activities, where the scaling features of Azure can provide cost savings
  • External-facing components that need isolation from on-premises applications and can benefit from Azure’s geographic coverage
  • Workloads running on aging or outdated infrastructure, where deploying in Azure requires less capital and could be faster than replacing the infrastructure on-premises
  • New projects or projects entering a new development cycle where architecting for Azure services is possible and the services provide benefit
  • Development and test environments that require using servers for a relatively short time period or that are needed infrequently.

Examples of weak candidates for Azure:

  • Workloads with servers that still have remaining life and do not need the other benefits of Azure hosting
  • Workloads that import and export large volumes of data external to the environment, which will suffer from transfer speeds and incur egress charges
  • Workloads with complex dependencies that are incompatible with Azure or would incur unacceptable risks to migrate
  • Location-specific workloads that require servers to be physically connected to other processes, such as servers supporting a manufacturing site or utility
  • Highly sensitive application data or intellectual property, such as pharmaceutical research or data from regulated industries.

Some of the weak candidates for Azure may be better candidates for Azure Stack.

About the Author

Andrew Snodgrass is the Research Vice President for Directions on Microsoft