Deciding Which Applications to Migrate to Azure

There are now so many supported platforms on Azure IaaS, not to mention the applications and services you can connect to them available on Azure PaaS, we can start with the notion that every application could be moved to Azure. We should then debunk some of the commonly held misconceptions as to why you shouldn’t migrate an application, and move on to why you should move applications to Azure. Finally, we’ll isolate the few actual reasons as to why you wouldn’t migrate a particular application.

Migration Misconceptions

Some of the commonly held misconceptions we hear about hosting migrations in Azure are below:

• The cloud is insecure – This is a common objection to moving to the cloud that presupposes that the cloud is somehow less secure than the on premise infrastructure. This may be based on some early failures of consumer-grade cloud services, such as Apple’s iCloud, Dropbox, Gmail etc. Microsoft have taken a security first approach to engineering Azure, with trust being at the core. They know that subscription services, all of which they deliver on the Azure, are the future of the company, and if people don’t trust the platform, that future is gone. To this end, the Azure cloud includes cutting edge security features that just can’t be replicated on premise – such as the artificial intelligence platform used to predict future threats from analysing previous attempts.
• Microsoft Azure is only for Microsoft platforms – Microsoft support a plethora of 3rd party platforms on their cloud, and it’s possible to choose ready-made images of Unix, Linux, Oracle, Hadoop, MySQL, CentOS, Mongo DB, not to mention specialist networking platforms such as Cisco, Fortinet, Barracuda – the new Microsoft mantra is very much any platform is welcome, and open source is good. And if it’s not available in the store, there’s nothing stopping you uploading your own images – if it runs on a virtual machine, it will run on Azure. Now we’re in the age of containers and nested virtual machines, the isolation from the host platform makes it virtually irrelevant. That’s before you even consider the ease of which cross-cloud and hybrid solutions are with the connectivity methods available.
• This application is too complex – technically any application that runs on premise could be recreated in the cloud, particularly in a hybrid network scenario. Complexity generally translates to cost of migration, and its costs that will stop a migration, not technical complexity. These can then be balanced against the potential cost savings the cloud can bring, particularly in Big Data/Big Compute.
• We’ll be breach of EU data protection/subject to US anti-terror legislation (Patriot Act etc.) – Here’s the official statement on Microsoft’s compliance with EU data protection law from Brad Smith, President and Chief Legal Officer, Microsoft, following the announcement that US Safe Harbor framework isn’t valid. https://blogs.microsoft.com/on-the-issues/2015/10/06/a-message-to-our-customers-about-eu-us-safe-harbor/

Why Applications Should Be Moved to Azure

• The application is given the focus – For on premise applications, attention has to be given to the platform(s) the application runs on, together with the infrastructure those platforms run on. This inevitably means some resources, however small, must be dedicated to that, even when the application is using a shared platform. With the amount of services Azure has to offer, applications can take advantage of pre-existing services to both reduce the amount of resources an application consumes, and enable developers/application architects to focus solely on the application’s business purpose. For example, a web application on premise would require web servers, database servers, backup, load balancing, authentication – it may share some or all of these services with other applications, but it’s still consuming elements of all those resources, and all of them must be supported and maintained, together with their underlying platforms and infrastructure. All those same services are required in Azure, the difference being they are all delivered to the application without any need for the developer/architect to consider how they are supported/maintained/provided.
• Applications benefit from scale – Many business applications have non-uniform usage patterns. This may be as simple as the staff intranet being busier during the day, to financial batch processes that run overnight once a month. On-premise infrastructures that support these application platforms have to be able to access the computing resources needed to run applications at their maximum usage, which usually means they are underused most of the time. Storage is also over-provisioned, as it has to be allocated “up front” for the lifetime of the application. In Azure, all resources are flexible, meaning applications can scale up and down as needed. Everything is paid for on a consumption basis, so you also only pay for what you use – so the application that only requires scale once a month, only incurs charges once a month. Storage too can be provisioned for many terabytes, but is only paid for as those terabytes get used. Scale is also automated – applications scale on demand, according to which resources are needed.
• Availability is built-in – as well as the resources an application needs to run, developers/architects also need to consider what happens to an application if those resources are interrupted, from a database failure to a power outage. This will often involve the platform engineers building in levels of redundancy into the infrastructure and application layers. Again these may be shared, but add to the costs and complexity of every application that the organisation has. In Azure, the PaaS and IaaS services have multiple layers of redundancy designed to ensure 99.95% uptime, and these sit outside of the application layer, “invisible” to it and the people who run it. Because the cost of this redundancy is born by all the users of Azure, it adds nothing to the cost of an individual application.
• Business need is given focus – In large, complex IT environments, the costs of maintaining an individual application, and any comparisons to the benefits it brings, are difficult to quantify. Just tracking the resources they use is hard when applications are shared across platforms and a common infrastructure. In Azure, every application resource is quantifiable, billable and can reported on. Monthly usage reports can be generated that show how each resource is used. The EA billing platform can split subscriptions to individual departments (IT should not be the only one), and each can be given a cap. This focus on how much an application costs the people that use it means IT can become a cost-generator, rather than a just a cost centre, as it recharges the cost of providing application services to the departments that run a particular application.
• IT becomes a can-do service – The inherent flexibility of Azure, combined with the rapid speed of provisioning (and tear down) of services, gives IT new capabilities when it comes to prototyping, testing and deploying applications. It’s no longer necessary to assess the impact an application would have in the production environment, as each is effectively isolated from the other. It becomes economically viable to run dedicated server instances for individual databases, that still benefit from high availability features. Storage costs aren’t even a consideration anymore. Ready to go services, such as mobile notification hubs, cognitive services, and analytics, reduce the time needed to develop applications. Existing applications can also take advantage of these connected services, improving their business value by adding features with relative ease.

Factors Affecting Why You Wouldn't Migrate a Particular Application

Given all of the above, there isn’t many reasons why you wouldn’t consider moving an application to Azure. Here’s some of the potential show stoppers:

• Complexity/Cost – As previously mentioned, some applications are so complex (or so old), that cost of migration becomes a factor. Finding people who understand the application well enough to do the migration, and have time to do it, will contribute to these costs. This has to be weighed against the potential savings Azure can bring, which can be difficult to quantify before it’s migrated, and without knowing what the application costs to run where it is. One way of doing this may be to estimate what it would cost to redevelop the application for Azure, which may reduce its complexity and/or bring it up to date, making it both cheaper to run and more capable.
• Licensing/Legal Restrictions – particularly with 3rd party applications, or applications that rely on 3rd party components, there may licensing restrictions imposed on where and how the application can be run. This is a particular issue with applications that use server node licensing, or rely on some aspect of the hardware (such as SMBIOS ID), but absence of these technical restrictions doesn’t mean legal restrictions don’t exist. In such cases, an updated agreement may need to be sought with the vendor, together with updated software to overcome the technical licensing method – which could mean a version upgrade. Microsoft themselves place restrictions on where their licences can be run – for example, its only recently been made possible to “bring your own licence” to Azure for SQL server.
• Support – similar to the above, some 3rd party applications may place restrictions on supported environments. Some may insist that the application is installed on premise, or on customer hardware, otherwise it won’t be in a supported state. A decision would need to made as whether vendor support is needed (which may preclude updates/patches being available), or the advantages of moving to Azure outweigh the benefits of vendor support. Again, many vendors are moving to support agreements that include cloud infrastructures, and will work to certify applications on specified cloud platform configurations. Again a version upgrade may be required.