By now, we have all heard of the “Cloud”. What exactly IS the Cloud, though? In its simplest form, the Cloud is really just a set of traditional data centers around the globe that are inter-connected. Over the last few years, as Cloud platforms like Azure, AWS and Google Cloud Platform have evolved, the term “Cloud” has come to encompass not just those physical data centers, but the software services that run within those data centers that aid software developers to create applications. In this post, we’ll focus on Microsoft’s Azure platform as we dive into a typical scenario for moving a business application from on-premise servers to the Cloud.
Challenge
You’ve invested years into creating intranet web applications that serve your business units well. They assist your users in their day to day jobs and are relied on by the company for any number of critical business processes. However, these applications were built with the assumption that your employees were all on-site and behind your corporate firewall. As the mobile era dawned, however, more of your workers started working from home, remote offices, or even the corner coffee shop. Then, your workers needed a VPN server on premise to allow them to securely get to apps hosted behind the corporate firewall, creating more overhead and more infrastructure. If the VPN goes down, your IT staff has a fire alarm to get it back up. If the database server goes down, your IT staff has a fire alarm to get it back up. If the web server goes down, your IT staff has a fire alarm to get it back up. IT staff costs money, downtime costs even more money, and no one wants to deal with fire alarm after fire alarm. So why is the Cloud the solution to these problems? The Cloud offloads all of this infrastructure to managed resources, backed up by SLAs, which means less maintenance by your IT staff and less fire alarms!
Solution
Consider a typical, legacy intranet web application. It was probably designed to use integrated, Active Directory based authentication to allow access and perhaps to look up an application role. The application is likely hosted on one of your internal web servers, or perhaps a server farm if you have high volume workloads. Then, there is probably an Oracle, MySQL or SQL Server database being hosted on an internal database server or database server cluster. How do you go about trying to migrate an application like this to off-premise servers hosted in Microsoft Azure, or any Cloud provider for that matter? As with any development problem, you must first break down the problem into small, easy to manage chunks. Let’s start with what the users start with: Authentication.
Authentication
There are a few options for authentication implementation in a Cloud based application. But let’s assume the typical scenario described above. You have an application that authenticating to an internal Active Directory domain controller, with application roles based on those identities. The lowest friction way to move authentication up to the Cloud is to have your network staff deploy Active Directory Federation Services (ADFS) to a publicly facing web server on premise. A few steps have to be taken to make the application “federation aware” so that authentication points at the new ADFS server rather than the old internal domain controller. This will likely be the the most challenging piece of the puzzle when moving a typical application. There will be a lot of testing to ensure you’re still correctly authenticating against your company’s Active Directory, and that the user identities are still mapped to the proper application roles. For example, your users may have been stored before as <companydomain\firstname.lastname> where the ADFS server now recognizes them as <firstname.lastname@companydomain.com>.
Database
The next step in migrating our application is to migrate our database to the Cloud. Yes, there may be some other external resources such as file shares or internal APIs we are accessing, but again, let’s assume a “typical” application, and assume the database is our only other external resource to migrate. Depending on your original database platform and your target database platform, this step could have varying degrees of difficultly. You may get lucky, however, as I have with several implementations that had SQL Server as the original platform, and SQL Azure as the target platform, and been able to do a simple export/import from SQL Server Management Studio. A quick note on other external resources. External applications or APIs could have a very significant impact on your ability to migrate an application to the Cloud. If you rely on internally facing web services or internally facing storage systems like EMC Centera, you will have to have a company-wide solution in place for migrating those resources before even considering moving your application to the Cloud. If you have a file share resource or something that is contained to just your application, consider Azure File Storage, or some other Azure-based service as a replacement when migrating.
Web Code
The final step in migrating our simple web application would be to move the updated web code to Azure. If you’re lucky, once you’ve updated your Authentication and Database resources, you may be able to just “lift and shift” your code to a new Azure App Service. In my experience, simple apps are almost always “lift and shift” once you take care of the external resources we discussed above. There are a few deployment options to choose from including FTP, Web Deploy and even Continuous Delivery options integrating with Visual Studio Online!
Competitive Edge
Now that your entire application is deployed to the cloud, not only have you spared yourself the headaches of managing all that network and hardware infrastructure, you’ve put out those fire alarms FOR GOOD! In addition, your users are able to hit a highly available, automatically scalable web application wherever and whenever they want.
