Migrating Financial Services Applications to the Azure Public Cloud
Our Microsoft finserv team is seeing a major uptick in financial services firms and partners looking to leverage Microsoft Azure public cloud offering. Windows Azure and the cloud offer a paradigm shift in computing where a company can outsource all aspects of running their software except for their application logic and data. Windows Azure is truly “Platform as a Service” (PaaS) as it manages the full platform stack, operating the data center, server hardware, server operating system, and the application server. Finserv companies are beginning to see ways they can leverage the benefits of the public cloud. For example, a recent survey by Novarica published in the Jan/Feb 2011 Insurance Networking News periodical shows an increasing number of insurance IT executives spending a growing percentage of their budgets on SaaS offerings. This survey corresponds to the results of a Microsoft survey of finserv IT decision makers asking the same questions. In both sets of independent surveys, the main problem outlined was a lack of available SaaS offerings for finserv solution domains today. Our Microsoft finserv team is doing something about this problem, and is proactively engaging with a core set of our independent software vendors (ISV’s) to help migrate all or parts of their solutions to Windows Azure and the public cloud. The idea is to use the Azure Marketplace App Market to advertise and sell finserv SaaS offerings available for customers. More on App Market here: https://www.microsoft.com/windowsazure/marketplace/default.aspx. Windows Azure is a large subject area with lots of features and technical details; however, below we share some insight into migrating ISV applications to the Azure public cloud. Future blog postings will fill in more details on Azure and financial services, such as security, integration, and storage.
Common misconception. Existing applications needs to be rewritten to successfully work in Azure, or Azure is really only for new application efforts that are specifically targeted for the Azure cloud computing platform.
Reality. While there’s some traditional application techniques that will need tweaking/resolution before successfully moving to the cloud (i.e. statefull architectures holding session data in server memory), the reality is Azure is quite flexible and can be configured to handle many existing scenarios. Finserv ISV applications come in all shapes and sizes and most applications typically have 3rd party dependencies. These kinds of applications can be migrated to the Azure public cloud. This blog will explain how in some level of detail.
Windows Azure is broken up into core functional services such as Compute, Storage, and the Fabric Controller. The compute service is the virtual machines that run your business logic. Ultimately Azure compute is a set of specialized Windows Server2008 R2 hyper-v instances that a customer rents for their application processing needs. Azure also provides relational (SQL Azure) and non-relational storage (Azure Storage) services, which are separate from the core compute service. Windows Azure compute is broken into 3 different types of roles, where an application can execute multiple instances of each role. The available roles are: (https://www.microsoft.com/windowsazure/compute/default.aspx)
· Web Role. Virtual machine designed to handle web requests where IIS (Internet Information Services) is used as the web server. Typically a web role is used for HTTP or HTTPS type functionality.
· Worker Role. Virtual machine designed to handle arbitrary tasks or anything where IIS is not used as the web server. Sometimes these are background tasks, and sometimes this role is used for running non-IIS web servers.
· VM Role. This is a customer built Windows Server 2008 R2 virtual image, where the customer preconfigures and loads a ready-to-run virtual image. Note. This is not “infrastructure as a Service” (IaaS) where you rent a virtual machine instance and have full control over it. More on this below.
Microsoft is very clear that Azure is “platform as a service”, not “infrastructure as a service”, which means that although you are renting virtual machine processing power, the Azure platform manages those virtual machines for you and manages the virtual machine lifetime. This is handled by the Azure Fabric Controller. This service is essentially the brains of Windows Azure. A useful metaphor is that if Windows is an operating system for a server, Windows Azure is an operating system for a data center. The fabric controller is the core of Windows Azure. It handles starting up your Azure role instances (each instance is a separate virtual machine), moving your application over to the virtual machine (in the web and worker role cases), upgrading the virtual machine (web and worker role cases), and managing physical hardware failures. Windows Azure load balances requests across two or more instances of your running application (2 or more role instances), and the fabric controller can at any time pull a virtual machine out of the load balanced cluster, and put a new one in (with your software). Because of this, you can never assume that something sitting in memory on a particular virtual machine instance is still in memory, but what you can assume is that Azure will keep multiple instances of each role running, load balancing requests, and safe from hardware failures. It’s an amazing platform designed for scale, automation, and self-service.
So what does this all mean from the application migration perspective? One of the confusing aspects of Azure when it first appeared was how to migrate existing applications that involved lots of configuration and 3rd party components. Azure was best served for traditional pure .NET applications. This is no longer the case. An Azure web role and worker role are essentially wiped clean each time a role instance is started by the Azure fabric controller. Your software is migrated to the instance during an initialization step that happens went the role instance starts up. So the question is how can 3rd party components get installed, and what if the application has configuration requirements like registry settings, Windows services, or other types of required scripting? Windows Azure allows for “Startup Tasks” to execute on a particular role before the role actually runs and receives requests. https://msdn.microsoft.com/en-us/library/gg456327.aspx. Startup tasks provide the ability to run executable code as part of starting up and configuring a role and these tasks can run as the administrator on the machine and have the necessary access to the machine. With startup tasks, your configuration can do things like install other 3rd party software, access the registry and other requirements to get the software properly configured. In addition to startup tasks, Azure also provides the ability to fully configure IIS on a web role for things like multiple websites, virtual directories, and other IIS required configurations. More on full IIS capabilities here: https://blogs.msdn.com/b/windowsazure/archive/2010/12/02/new-full-iis-capabilities-differences-from-hosted-web-core.aspx.
Recently working with a finserv ISV to migrate existing functionality to Azure, the particular company used a 3rd party web server, Apache, as part of their software. Clearly Apache is not a standard component used in a .NET application, so what options did this ISV have for migrating this solution? Turns out Azure is quite flexible and agile in how it handles non Microsoft application components, and something like Apache works just fine on Azure. The requirement is that the software must run on Windows Server 2008 R2, which is a 64-bit operating system. Assuming it works under those requirements, chances are good that it will work on Azure (assuming it follows cloud conventions like not holding session state in memory, etc.). As noted above, Azure has a Web role, and Worker role virtual machine instance type. The main difference is that a web role comes configured with IIS and a worker role does not. So to use Apache as a webserver you leverage an Azure Worker role (because you’re not using IIS), create a startup task to install and configure Apache, open up an input TCP endpoint for Apache’s incoming requests, and run your application. More information on this concept here: https://blog.smarx.com/posts/using-other-web-servers-on-windows-azure. Bottom line is that Azure does not require Microsoft application server stack technologies. It can run unmanaged C++, Java, PHP, and most software that will run on Windows Server 2008 R2.
Another great new feature of Azure is the ability to remote desktop connect to the virtual machine instances themselves. Through remote desktop, you can logon to each instance after it is setup and running in Azure. The benefit to verify and make sure everything you installed and configured was setup correctly. It has some testing benefits as well, however, a manual change made to the virtual image through remote desktop will be lost once the fabric controller removes and starts a fresh VM instance. So remote desktop should not be used for manually installing or configuring software, but it is very useful for testing and verifying the migration of a software solution. Any configuration change needs to be properly scripted as part of a startup task to ensure it happens every time the VM instance is started by Azure.
Given Azure is very flexible for moving existing logic to Web and Worker roles, what is the point of the VM Role? The VM allows a customer to setup and configure their software locally by building their own virtual machine VHD image and uploading that image to Azure. The benefit is you can build and setup everything beforehand and have Azure run your own custom instance. That said, a VM Role behaves similar to a Web and Worker role where the Azure fabric controller controls the lifetime of the instance, and anything left in memory could be removed at any moment by the fabric controller (if it restarts a VM instance), so a stateless architecture is still required. This is why a VM Role instance is considered part of the Azure PaaS architecture, and is not true IaaS. The downside of a VM role is that Azure can no longer patch the operating system and update the image. You are now required to do this yourself, and upload the patched images manually (VM Role does support Differencing VHDs).
What is the best practice on when to use a VM Role, and when to use a Web/Worker role? Do to the great new set of application migration features provided by Azure startup tasks and full IIS configurability, the best practice is as follows:
· Attempt to use a Web/Worker role first and leverage startup tasks. Startup tasks can be used for most installation and configuration requirements. Web and Worker roles are advantageous to truly get the most benefit of running in the powerful Azure PaaS environment. Web an Worker roles are properly patched and upgraded as part of the platform.
· Use a VM Role when the installation is very complicated and simply cannot be scripted with startup tasks. Perhaps the 3rd party software installation does not have an unattended option, or it just takes too long to install the 3rd party components. This was the scenario the VM Role was designed to solve.
Hopefully you now have a better idea of the powerful and flexible environment provided by Windows Azure. It is not just for new application development as it supports a wide variety of migration options that should help financial services institutions and partners quickly obtain the economic benefits of the public cloud. In the future I’ll blog about security, integration, and storage options as they pertain to financial services.