Microsoft’s Corey Sanders provides more insight into Azure migration

Microsoft has divided the process of moving on-premises workloads and applications to the cloud into three key steps: Assess, migrate and optimize. Once the assessment of existing infrastructure, applications and dependencies is complete, there are four general options for undergoing an application migration to Azure. Those are: re-hosting or lift and shift, refactoring with containers, re-architecting for PaaS, and starting from scratch by rebuilding apps (or creating new ones) with a fully serverless PaaS environment.

In addition to a number of new tools offered by Microsoft, the company has quite a few partnerships for those that have specific requirements. In an interview with ITOps Times, Corey Sanders, Microsoft’s corporate VP for Azure compute, discussed these migration options.

ITOps Times: Do you find the majority of organizations that are making the move going with the lift and shift approach?
Sanders: A majority of organizations have at least some portion of their infrastructure doing lift and shift or rehosting. But increasing amounts are including refactoring and containerization as part of that stage. I see a significant number of customers coming in with some portions being lift and shift, some portion being refactored and containerized to put those pieces together in the cloud to get the benefit in Azure. Both are fantastic managed PaaS services that make sure that the minimal amount of changes are required to take advantage of the Agile and cost benefit capabilities of Azure.

Is there a leaning towards IaaS or PaaS these days in terms of the migration?
It certainly leans toward infrastructure-as-a-service. A majority of the migrations on the compute side lean towards infrastructure-as-a-service. More and more of the data migration is moving towards more managed services like SQL Managed Instances or SQL Database with the combination of the PaaS services with those compute-based infrastructure services.

When organizations do a lift-and-shift approach, do they quickly find that perhaps they should have done a greater percentage of the move via refactoring, or is it more common to just want to get it out there and get the ball rolling?
I find most customers are getting into the cloud and taking advantage of agile infrastructure, which is a strong benefit unto itself. You can save up to 60 percent, which is a pretty exciting opportunity for a lot of customers. Having said that, as soon as lift- and-shift is underway, it’s a very quick conversation. ‘How am I modernizing now by bringing containers into my service that is taking advantage of serverless solutions?’ This is where that combination of really strong infrastructure as a service with great PaaS services, both on the data and compute side, make Azure such a such an appealing choice for a lot of these large enterprises.

Do you find that organizations that are doing this are shifting their applications or .NET applications to .NET Core, Cloud Foundry or Kubernetes?
We see more customers target modernization and target some of the compute-based PaaS platforms. We definitely feel a lot of excitement around all of the many open-source platforms, including certainly Kubernetes and the Azure Kubernetes Service offered on Azure. Additionally, we recently announced the first managed OpenShift in the public cloud but we’re also absolutely very excited to see customers moving their Java applications onto Cloud Foundry and even onto Docker Enterprise as well. We see the full range of platforms being used by customers as they look to modernizing their solutions with containers, which is typically a step after that first lift-and-shift.

You have also worked closely with Ansible, Puppet and Chef. While those are DevOps orchestration platforms, should they be considered in the migration process?
Typically, customers deploying Puppet and Chef are moving toward more of a DevOps approach. They’re looking for the ability to manage their infrastructure in a simpler and more automated way. I see many customers doing that on premises, prior to migration, but most are doing that post-migration. From my experience it’s not necessarily a part or a key aspect of the migration process. I have found the migration to public cloud to be a distinct decision-point from moving workloads to more of a DevOps and an automated process, which can happen both on premises or in the cloud.

Is it recommended that organizations think about how they want to approach DevOps before they make the move, or is that something they really can do after moving some applications to the cloud?
One of the biggest benefits that customers can get from deploying in Azure, whether it be deploying on infrastructure or deploying on a data PaaS service, is the ease of management and ease of automation with both the built-in tool sets but then also with many of the capabilities, either from partners like Chef, Puppet or container-based solutions, or even serverless platforms sitting on top. It’s incredibly easy to automate and manage infrastructure in a much simpler, faster way and much more cost-effective way. I strongly recommend that customers who make their lift- and- shift into Azure consider the next step in their journey, which frequently is a step around automation and a step around DevOps.

For organizations that are a little more conservative or doing this reluctantly —they know they have to do it —what is the best type of workload to start off with for the migration process?

I think the best applications for customers to start with as the first deployment option, whether they’re on Windows or Linux, whether it’s SQL or Postgre, really comes down to the expectations around management and operations of that workload. For workloads that are a little bit more flexible in the way that customers manage and deploy, they will be able to embrace the process of migration but also to be able to better take advantage of some of the agility offered by the cloud, whether it be shutting things down or scaling things down on the weekend or after hours. I always recommend this first and certainly the rest as they come along have varying degrees of value that could be added from that ability, from that agility, from those managed services, from that containerization. But certainly, the easiest first ones are the ones that cleanly lift and shift and get some benefit from flexible infrastructure.

Are you finding that some are bypassing infrastructure-as-a-service, lift-and-shift migrations altogether and just going right to PaaS?
Absolutely. There are customers who will do it as part of the migration step— containerize and deploy as a Kubernetes service or even go entirely to platform-as-a-service and go straight to managed SQL or straight to managed PostgreSQL or CosmosDB with the Azure App Service sitting on top as more of a rebuild or refactor of their application. It’s really tied to the business requirements of the customers and we have the right tools and the right support models and the right people to go help customers no matter which step they want to skip and what their end date is for those applications.

Can an organization make the leap from on-premises to a Data Lake- type environment or is that a relatively ambitious step to take?
It depends very much on the application with services like Azure Data Box being able to take entire Data Lakes sitting on premises and effectively ship them into Azure and then build analytics and AI services on top using our best- in- class services for that analytics layer. With the data coming in through Data Box it creates quite a great opportunity for specific workloads and specific customers.

How much uptake so far have you seen for Azure Stack in the six months it’s been out? Should that be considered part of a migration strategy or option?
Azure Stack is a part of the overall continuum and it is a part of the overall story for customers as they make this migration. Certainly, Azure Stack has the cloud experiences, the cloud optimizations but running in edge locations and so enabling customers to be able to still benefit from the Azure programming model and the Azure data experiences. Still being within close proximity to their end customer or close proximity to their end devices is a big part of the overall story where migration to the cloud can be migration to an edge-based Azure Stack, and we see many customers looking at that as a part of their overall hybrid and edge strategy.

In addition to migrating from on- premises, obviously you have customers that are migrating from other clouds or even from the classic Azure service [pre-Azure Resource Manager]. Are there enough tools out there for that as well?
Certainly, on the partner side, quite a bit of the tooling is enabled to support migration from other clouds into Azure and even our services do have the ability to enable some aspect of migration from other clouds as well, including things like Azure Site Recovery. And some of the capabilities as part of that overall migration service are enabled as part of other cloud-based migrations. But most of that support engagement is offered as partner-based services and solutions.

What new migration tools do you anticipate releasing in the coming year?
We have a lot of planned investment coming from the Azure team, both across compute and across data in the migration space. It’s an area where we’re seeing a lot of customer interest and a lot of customer passion. And that investment is going to come in two forms. It’s going to come in improving, enhancing and expanding our capabilities on the Azure side to offer these services directly to customers. But it’s also going to come with better and improved integration opportunities for partners to be able to deliver upon their services and their specialized capabilities as well. I expect the combination of those two will dramatically expand over the next year, the capabilities for customers to be able to do [migration] very easy and fast.