2 – Getting to the Cloud

On this page:	Download:
The Premise | Goals and Requirements | Overview of the Solution | Options for Hosting the Application - Affinity Groups, Availability Sets | Options for Hosting the Data | Connectivity for Authentication | Session Support and Load Balancing | Integrating with On-Premises Services | Inside the Implementation | Profile Data | Connecting to the Hosted SQL Server - Database Connection Timeouts and Dropped Connections | Deploying the aExpense Application to Azure Virtual Machines - Deploying the Web Application, Deploying the Database | Testing, Deployment, Management, and Monitoring | Testing Applications for Virtual Machine Deployment | Test and Production Environments | Management and Monitoring - Storing and Backing Up Virtual Machines, Managing Virtual Machine Instances, Elasticity and Scaling | Isolating Active Directory | More Information

This chapter describes the first step the developers at Adatum took on their migration path to the cloud. It discusses the contributing factors for the decision they made to use an IaaS approach for hosting the aExpense application in Microsoft Azure, and explores the process they followed to achieve this. The chapter also discusses issues related to application lifecycle management (ALM), specifically for scenarios that use an IaaS hosting approach.

This first migration step is concerned only with getting the application to work in the cloud without losing any functionality. However, it does address some "big" issues such as security and data storage that are relevant to almost every cloud-based application.

This chapter doesn't explore how to improve the application by exploiting the extended set of features available in Azure. In addition, the on-premises version of the application that you'll see is not complete; for example, it does not support uploading receipt images or interaction with Adatum’s other on-premises systems. The following chapters discuss how to improve the application by using other features available in Azure, and you'll see more functionality added to the application. For now, you'll discover how Adatum takes its first steps into the cloud.

The Premise

The existing aExpense application is a business expense submission and reimbursement system used by Adatum employees. The application is built with ASP.NET 4.0, deployed in Adatum's data center, and is accessible from the Adatum intranet. The application relies on Active Directory to authenticate employees. It also uses Active Directory to access some of the user profile data that the application requires; for example, an employee's cost center and manager. Other user profile data is accessed using the ASP.NET profile provider and membership provider. Because aExpense uses Windows authentication, it recognizes the credentials used when employees log on to the corporate network and doesn't need to prompt them again for their user names and passwords.

Poe Says:
	Integration with Active Directory really simplifies the task of managing this application. The aExpense application leverages Active Directory's access management facilities, and the cost center and manager information that Adatum stores in Active Directory.</td>

The aExpense access control rules use application-specific roles such as "Employee" and "Manager" that are accessed through the ASP.NET role management provider. Access control is intermixed with the application's business logic. It uses a simple SQL Server database for storing application data, and LINQ to SQL as its data access mechanism. The application is configured to connect to SQL Server by using integrated security, and the website uses a service account to log on to the database. The aExpense application also uses the Enterprise Library Logging Application Block and the Exception Handling Application Block for logging diagnostic information from the application.

Figure 1 shows a whiteboard diagram of the structure of the on-premises aExpense application.

Figure 1

aExpense as an on-premises application

Goals and Requirements

Adatum wants to explore the opportunities for cloud hosting the aExpense application in an attempt to maximize performance and availability, even during periods of peak usage, while minimizing the associated costs. The goals at this stage are to avoid, as far as possible, changes to the application code and the associated administrative functions while taking advantage of the flexibility and scalability offered by cloud hosting.

Therefore, as the first step in the migration path, Adatum has decided to deploy the aExpense application to the cloud using an IaaS approach. This will avoid any requirement to refactor the application or to make significant changes to the code because it can continue to run on a hosted server running Windows Server. However, the developers and administrators must still consider what, if any, changes are required to the application; and the impact of moving it from their on-premises datacenter to the cloud.

Bharath Says:
	Your decision to move an application to the cloud should be based on clear goals and requirements.</td>

Adatum chose to use Azure because of its wide range of capabilities for hosting both the application code and the data, and the availability of additional Azure services that are appropriate to meet the application’s requirements. For example, Adatum wants to continue to use Active Directory for authenticating users, and be able to integrate the application with its existing on-premises System Center Operations Manager.

Adatum also wants to be able to deploy the application in a secure and repeatable way to a staging environment first, and then to a production environment when testing is complete. After deployment, Adatum’s administrators want to be able to scale the application to cope with varying usage patterns, monitor its execution, and be able to adjust configuration settings to fine tune it.

Overview of the Solution

This section of the chapter explores the high-level options Adatum had for migrating the aExpense application during this step. It shows how Adatum chose an appropriate hosting mechanism for the application and for the data it uses, and how Adatum can establish connectivity between the cloud-hosted servers and its on-premises corporate network.

Options for Hosting the Application

Having decided on an IaaS approach for this initial step, Adatum must consider the hosting options available. Azure provides the following features for IaaS deployment:

• Virtual Machine. This feature allows you to provision a virtual machine in the cloud with a choice of operating systems, and with a range of options for preinstalling a database server on the virtual machine. Alternatively, you can upload a prebuilt VM to the cloud. You can use it to run any software compatible with your chosen operating system, and configure the operating system and services as required. Virtual Machine instances maintain state between restarts, and so are suitable for use when software or services you install require state to be maintained.
• VM Role. This feature allows you to host your own customized instance of the Windows Server 2008 R2 Enterprise or Windows Server 2008 R2 Standard within an Azure data center. However, the role does not save state when Azure restarts or redeploys it as part of the operations executed automatically within the data center (such as when the role fails), and so it is not suitable for scenarios where the software or services you install require state to be maintained.
• A set of associated services that provide connectivity and additional functionality for IaaS applications. These services include Azure Connect and Virtual Networks for providing connectivity to hosted servers, and functional services such as claims-based access control, Service Bus relay and messaging, database synchronization, and caching.

The major difference between Azure Virtual Machines and the VM role is the behavior when the machine or role is reinitialized. This can occur following a hardware failure, or automatically as the Azure internal systems manage allocation of resources by moving instances to a different physical server.

Any changes to a virtual machine, such as installing applications or configuring the operating system, are persisted when the instance is reinitialized – this is what is meant by the machine being able to maintain its state. VM role instances do not persist these changes. Any changes such as installing applications or configuring the operating system are lost and the role will return to the originally deployed configuration when reinitialized (although changes are persisted across restarts as long as the VM role is not reinitialized).

This means that you must redeploy the complete VM role image each time you need to make changes to it. When you use a virtual machine you do not need to do this. You can install and update applications on the virtual machine without needing to redeploy it every time, which makes it an attractive option for both testing and production deployment.

Note

For more information about how Azure manages maintaining state in virtual machines, see the section “Storing and Backing Up Virtual Machines” later in this chapter.

After considering the available application hosting options, Adatum chose to host the application in an Azure Virtual Machine at this stage of their migration process. Developers and testers will be able to deploy to virtual machine instances in exactly the same way as when using an on-premises server. Administrators and operators will be able to manage the live production server and deploy applications to it just as they do with on-premises servers.

Affinity Groups

When you first create namespaces and instances of Azure services, you must specify the location or datacenter where they will be deployed. However, for some services you can specify only a region rather than a specific datacenter. Therefore, to ensure that elements of your application (such as the compute and storage services) are co-located in the same datacenter as close together as possible you specify an affinity group.

When you specify an affinity group, which must be done when creating the services (you cannot move services into a different affinity group after they are created), Azure will attempt to locate all of the services in the group in the same cluster in the same datacenter. This will maximize performance, reduce latency, and eliminate unnecessary data transfer costs.

Note

For information about using affinity groups, see Importance of Azure Affinity Groups.

Adatum will define an affinity group when it creates the virtual network that aExpense uses to access the on-premises Active Directory service. Adatum will also add all the virtual machines to the same affinity group when it creates them.

Bharath Says:
	You don't need a virtual network to use an affinity group. You can create affinity groups independently of virtual networks.</td>

Availability Sets

In Azure, fault domains are a physical unit of failure. Each virtual machine in an availability set is deployed to a different fault domain in Azure. This helps to ensure that your application stays available during network failures, local disk hardware failures, and other outages.

However, improving the reliability and responsiveness of the aExpense application by deploying multiple copies of the virtual machines in an availability set will add to the running costs incurred by Adatum.

Bharath Says:
	You must decide what level of reliability you need for your application and how much you are willing to pay.</td>

Options for Hosting the Data

The existing on-premises aExpense application stores its data in SQL Server. Therefore, Adatum also had to consider how to provide a comparable capability for the application when hosted in the cloud. Adatum has several options:

• Keep the data on-premises. In theory this is a simple to implement option. The cloud-hosted application would communicate with the on-premises database over the Internet. However, it raises several issues, such as the security of the connection and the requirement to expose the database server outside of Adatum’s internal network. One approach to resolve this would be to use Azure Connect or Virtual Networks to provide a private secure connection. Even with this approach, there are issues around the additional connection latency and the possibility of intermittent connectivity failures, which would require extensive caching in the application and a connection retry mechanism.

  Jana Says:
  	There may be specific reasons why you want to keep your data on-premises, such as physical security, regulatory requirements, specific management or analysis processes, and more. Hosting the application in the cloud while using an on-premises database still allows you to take advantage of the intrinsic capabilities of Azure such as reliability, scalability, and elasticity.

  - **Deploy the data in a hosted SQL Server**. This approach would require Adatum to deploy a separate virtual machine to run SQL Server, although this can be easily provisioned using the templates available in the Azure portal. Connection latency and intermittent connectivity would be minimized by deploying it in the same datacenter as the application.

  Bharath Says:
  	You do not have to use Windows Server and SQL Server when you choose the IaaS approach for your database. You can install a range of operating systems and database servers in a hosted virtual machine using the templates available in the Azure portal. For example, you may decide to use MySQL running on Linux as an alternative to SQL Server running on Windows Server.

  - **Deploy the data in Azure SQL Database**. This approach would require Adatum to subscribe to the managed data service offered by Azure, and accept the few limitations that it imposes when compared to the full version of SQL Server. However, it is a viable and useful option that Adatum will consider in a future migration step. Chapter 4, “[Moving to Azure SQL Database](ff803375\(v=pandp.10\).md),” of this guide looks in detail at the differences between SQL Server and Azure SQL Database, and the factors that affect Adatum’s choice at that stage of the migration process. - **Deploy the data in Azure table and blob storage**. This approach would require Adatum to rewrite the data access code in the application to accommodate the differences between the relational, SQL-based data access approach and the less structured storage mechanisms used in Azure storage. However, there are some specific advantages offered by Azure storage such as lower cost and vast storage capability, and Adatum will consider this in a future migration step. At this stage Adatum’s goal is to minimize the changes required to the code. Chapter 7, “[Moving to Azure Table Storage](ff803362\(v=pandp.10\).md),” of this guide looks in detail at the differences between relational databases and Azure storage. - **Deploy the data in a custom store or repository**. You can deploy a range of operating systems and software on a hosted Virtual Server, and so you can continue to use you existing data stores and repositories. For example, if Adatum used a custom or third party data storage mechanism based on a non-standard file format, or even just use a simple file server, it could be deployed on Windows Server or Linux on a virtual machine. However, as Adatum uses SQL Server running on Windows Server in its on-premises datacenter, this option is not applicable to its migration strategy.

  Note

  Chapter 4, Moving to Microsoft Azure SQL Database, describes the differences between using a hosted SQL Server and Azure SQL Database, and how the developers at Adatum chose a data storage mechanism for the aExpense application in the subsequent steps of their migration path.

  After considering the available data storage options, Adatum chose to host the data in SQL Server running on a separate virtual machine in the same datacenter as the application.

  Connectivity for Authentication

  Adatum’s aExpense application relies on connectivity to the Adatum corporate domain to authenticate users against Active Directory, and Adatum wants to maintain the existing mechanism when migrating the application to the cloud. This will avoid the need to make changes to the code while Adatum evaluates the results of the first step in its migration path. In future migration steps Adatum will consider changing the authentication approach to use another mechanism, such as claims and federated identity.

  However, to continue to use Active Directory for authentication when the application resides in the cloud, Adatum must establish connectivity between the application and its on-premises corporate domain network. One of the advantages of Azure as a hosting environment is that it includes services to enable connectivity that is safe, secure, and easy to set up.

  Adatum must establish connectivity between its virtual machines in the cloud and its on-premises Active Directory server to continue to use Windows Authentication when it deploys to a virtual machine in the cloud. The current version of aExpense also relies on Windows Authentication to connect to SQL Server.

  Adatum has two options for establishing this connectivity between the cloud-hosted application and its corporate domain network:

  • Azure Connect. This technology allows administrators to set up a direct connection between a cloud-hosted virtual machine (or a cloud services role) and an on-premises computer. It relies on endpoint software installed in the remote and on-premises computers, which establishes a secure connection across the Internet. Connect does not require ports to be opened in the corporate firewall, and will usually work when network address translation (NAT) routing is in use. It is easy to set up and manage, and provides a secure connection.
  • Azure Virtual Networks. This technology uses the virtual private network (VPN) approach to establish connectivity across computers and hosted services in Azure and on-premises. Computers, cloud-hosted virtual machines, and cloud service roles are configured on the network in the same way as when running on premises, and a VPN router on the corporate network establishes connectivity between the network segments. Effectively, this extends the corporate network into the cloud, allowing existing services and applications to be used with no special software installation required on the on-premises computers. Virtual networks are ideally suited to more complex scenarios where scalability and additional control are required.

  Note

  Virtual networks are typically used where you need to connect virtual machines and cloud service roles together, for connecting between the cloud and on-premises, or when you need a virtual machine or a role to maintain the same IP address when redeployed. The video presentation Migrating Applications to Azure Virtual Machines contains a wealth of information about setting up virtual machines and connecting then using Azure Virtual Networks.

  Both of these options will allow Adatum to continue to use Active Directory for authentication. However, there are some limitations when using Azure Connect. The Active Directory server must also host DNS for the domain (the Connect service cannot be used where a separate DNS server is used), and administrators will need to install the Connect service endpoint software on the Active Directory computer. If this is not an acceptable scenario, Adatum can configure the cloud-hosted virtual machine as part of an Azure Virtual Network. Although this is more complex to configure, it removes the requirement for installing endpoint software.

  An alternative approach Adatum could take would be to install Active Directory on a virtual machine running in Azure, and connect it to their on-premises Active Directory. However, this means that Adatum must pay for the additional Azure resources it uses. In future releases of Azure, the Access Control service it provides will be extended to allow integration with an on-premises Active Directory.

  Markus Says:

  We could also use Azure Connect to link the cloud-hosted application to an on-premises database by installing the Connect service endpoint software on the database server computer if we needed to keep that database on-premises. Unlike opening a public endpoint in SQL Server, the Connect service provides a secure channel between the application and the database. However, in many organizations installing this type of software on the database server may be frowned upon, and this may preclude you from using an on-premises database with your cloud-hosted applications.</td>

  Session Support and Load Balancing

  Applications that run in an on-premises datacenter often rely on intrinsic features of the network that are not supported in the cloud, and this can affect the way that the application works when deployed to the cloud. A typical example related to the aExpense application is the way that Adatum implements an on-premises web farm by using Windows Network Load Balancing (NLB), and the impact this has on the way that it stores users’ session data.

  The on-premises aExpense web application uses the built-in ASP.NET in-memory session mechanism to support sessions for each user. This means that session data is only available on the server that initiates the session, and so users must be routed to the same server on each request during a session. Adatum configured affinity for NLB in their datacenter so that this occurs automatically.

  Note

  For more information about NLB see Overview of Network Load Balancing.

  However, affinity is not directly supported in Azure (although it can be implemented with a plug-in or with custom code). If Adatum wants to run multiple instances of the virtual machine that hosts the eExpense application in Azure, the developers must change the way session data is stored so that it is available to all instances. For example, they could switch to using the ASP.NET SQL Server session store provider, Azure storage, or use Azure Caching. Chapter 3 of this guide, “Moving to Microsoft Azure Cloud Services,” explores these options and shows how Adatum’s developers implemented session storage during the next stage of their migration strategy.

  Markus Says:
  	When you move an application to the cloud you must consider the impact of running multiple instances in an environment that does not support some of the intrinsic features of your own network. Session management is a typical example. </td>

  At the moment Adatum is most concerned with getting the application running in the cloud to explore the possibilities, validate usability and performance, and gauge user acceptance. Adatum wants to avoid making changes to the code. Therefore, in this step of its migration plan, Adatum will run only one instance of the virtual machine that hosts the aExpense application in the cloud.

  Note

  For information about how to enable load balancing between multiple instances of Virtual Machines in Azure see the section “Load balancing virtual machines” in the topic Virtual Machines. The blog post Setting up a webfarm using Azure Virtual Machines provides a walkthrough of the procedure.

  Integrating with On-Premises Services

  The existing on-premises aExpense application integrates with other applications within Adatum’s corporate network. For example, it reads and writes text files that are used to import and export expenses data for processing by Adatum’s other on-premises systems. Therefore Adatum must consider how it can establish the equivalent functionality when the application is hosted in the cloud.

  Note

  The Visual Studio solution BeforeAzure discussed in this chapter does not include this data import and export functionality. The Visual Studio solution Azure-TableStorage discussed in Chapter 7, Moving to Microsoft Azure Table Storage, shows how Adatum added the data export feature to the aExpense application.

  When using IaaS and virtual servers in the cloud, the application can write to the virtual disk in the same way as when running on a physical server. Administrators can enable direct connectivity with the machine by using Azure Connect or an Azure Virtual Network to allow access to disk files stored on the drives of the remote server.

  Alternatively, Adatum’s developers could change the code so that it serializes the files and stores them in either Azure storage or in the database. As the files will be read and generated remotely, and streamed to and from the in-house application over the Internet, this is not an issue because they will need to be serialized anyway and can be reconstructed on the on-premises server.

  Poe Says:
  	A virtual machine or a VM role or can be used simply as a file server in the cloud. When connected through Azure Connect or Azure Virtual Networks it will be accessible from on-premises computers and by other applications running in the cloud.</td>

  Both of the connectivity options, Azure Connect and Azure Virtual Network, allow Adatum to connect the cloud-hosted virtual machines running the application and SQL Server to their corporate domain. This means that existing tools and practices will continue to work without changes being required. For example, administrators can browse the remote machines, use database management tools, run existing scripts, and use the same monitoring and management applications. For more details of how Adatum’s administrators will manage the remote servers and application, see the section “Management and Monitoring” later in this chapter.

  Inside the Implementation

  Now is a good time to walk through the process of migrating aExpense into a cloud-based application in more detail. As you go through this section, you may want to download the Microsoft Visual Studio development system solution from the Microsoft Download Center. This solution contains an implementation of the aExpense application (in the BeforeAzure folder) as it is when running on-premises. If you are not interested in the mechanics, you should skip to the next section.

  Profile Data

  Before the migration, aExpense used the ASP.NET profile feature to store application-specific user settings. Adatum tries to avoid customizing the schema in Active Directory, so aExpense stores a user's preferred reimbursement method by using the profile feature. The default profile provider stores the profile properties in a database.

  Poe Says:
  	We don't like to customize the Active Directory schema if we can possibly avoid it. Schema changes have far-reaching implications and are difficult to undo.</td>

  Using the profile feature makes it very easy for the application to store small amounts of user data. Adatum enabled the profile feature and specified the properties to store in the Web.config file.

  <profile defaultProvider="SqlProvider">
    <providers>
      <clear />
      <add name="SqlProvider"
           type="System.Web.Profile.SqlProfileProvider"
           connectionStringName="aExpense"
           applicationName="aExpense" />
    </providers>
    <properties>
      <add name="PreferredReimbursementMethod" />
    </properties>
  </profile>
  

  Then developers can access a profile property value in code like this.

  var profile = ProfileBase.Create(userName);
  string prm = 
      profile.GetProperty<string>("PreferredReimbursementMethod");
  

  After migration, aExpense continues to use the profile system to store the preferred reimbursement method for each user.

  The application also uses ASP.NET membership to store the users preferred name, and ASP.NET role management for the custom roles used in the aExpense application. You can see how these are configured in the Web.config file, and how they are accessed in the UserRepository class.

  Connecting to the Hosted SQL Server

  Before the migration aExpense stored application data in a SQL Server database running on-premises. In this first phase, the team moved the database to a hosted SQL Server running on a virtual machine. The data access code in the application remains unchanged. The only thing that needs to change is the connection string in the Web.config file.

  Connecting to a hosted SQL Server running on a virtual machine instead of a SQL Server on-premises requires only a configuration change.

  <add name="aExpense" connectionString=
    "Data Source={Server Name};
     Initial Catalog=aExpense;
     Integrated Security=True;
     Encrypt=yes;" 
    providerName="System.Data.SqlClient" />
  

  This connection string uses the same SQL Server security mode as the on-premises solution. To continue using Windows Authentication mode, both the virtual machines must be able to access the Adatum on-premises Active Directory service. The server name must be set to the server name of the virtual machine where SQL Server is hosted. Adatum also chose to encrypt the connection to SQL Server; for more information see Encrypting Connections to SQL Server on MSDN.

  Note

  If you choose to use SQL Server authentication instead of Windows authentication to connect to SQL Server, your connection string will include a user name and password in plain text. In this scenario, you should consider encrypting your SQL connection string in the Web.config file; to do this, you can use the Pkcs12 Protected Configuration Provider. For more information, see Chapter 4, "Moving to Microsoft Azure SQL Database."

  The connection string also specifies that all communications with Azure SQL Database are encrypted. Even though your application may reside on a computer in the same data center as the server hosting SQL Server, you should treat that connection as if it was using the internet.

  Bharath Says:

  You can also add protection to your hosted SQL Server by configuring the Windows Firewall on the virtual machine so that it allows only a specific range of permitted IP addresses to connect to your database server. However, this is complicated by the fact that you may not always be able to determine ahead of time the IP address of your virtual machine instance(s). For example, when you redeploy a virtual machine, the IP address may change.

  Database Connection Timeouts and Dropped Connections

  If a connection to SQL Server times out or drops while your application is using the connection, you should immediately try to re-establish the connection. If possible, you should then retry the operation that was in progress before the connection dropped, or in the case of a transaction, retry the transaction. It is possible for a connection to fail between sending a message to commit a transaction and receiving a message that reports the outcome of the transaction. In this circumstance, you must have some way of checking whether the transaction completed successfully in order to determine whether you must retry it.

  When using a hosted SQL Server, you can continue to use the same techniques as you do in on-premises applications. As long as the virtual machines hosting the application and the SQL Server are co-located in the same datacenter, connection failures should arise no more often than when running in your own datacenter. However, it is useful to consider implementing a mechanism that can alleviate issues with failed connections. In Chapter 4, “Moving to Microsoft Azure SQL Database,” of this guide you will see how Adatum chose to use the Enterprise Library Transient Fault Handling Block to manage connection retries when connecting to the database.

  Deploying the aExpense Application to Azure Virtual Machines

  This section outlines the steps that Adatum took to deploy the aExpense application to two Azure virtual machines: one for the web application and one for the SQL Server database. For a more detailed description of the steps, see the Hands-on Labs that are available for this guide.

  Deploying the Web Application

  1. Create a virtual network to enable connectivity to the Adatum on-premises Active Directory server.
  2. Create a virtual machine based on the Windows Server image available in the portal and ensure that the virtual machine is part of the virtual network.
  3. Set up remote desktop connectivity to enable access to the virtual machine from on-premises.
  4. Join the machine to the Adatum Active Directory.
  5. Install .NET 4 on the virtual machine.
  6. Install and configure the dependencies of the aExpense application: install Internet Information Server (IIS), enable Windows Communication Foundation in IIS, enable Application Pool User Profile in IIS, install certificates required for HTTPS, and configure HTTPS in IIS.
  7. Copy the application code to the server, and add a web application in IIS.

  Bharath Says:
  	By configuring appropriate endpoints for your virtual machine in the Azure portal, you can improve security by limiting its publicly available TCP ports.

  Deploying the Database

  1. Create a virtual machine that includes SQL Server. Adatum did this by using an image available in the portal that includes SQL Server 2012, but it could have installed a different version. This virtual machine should be part of the same virtual network and affinity group as the virtual machine that hosts the web application.
  2. Set up remote desktop connectivity to enable access to the virtual machine from on-premises.
  3. Join the machine to the Adatum Active Directory.
  4. Open port 1433 in Windows Firewall to allow access to the database (you may want to use a different port to help hide SQL Server), and enable network connectivity in SQL Server for the TCP/IP protocols.
  5. Migrate the on-premises database used by the aExpense application to the SQL Server installation in the virtual machine. Ensure that the domain account used by the application pool on the web server has access to the database.

  Poe Says:
  	Adatum is using a virtual network to enable connectivity to the on-premises services that the aExpense application uses. The virtual network is not needed to enable connectivity between the two Azure virtual machines.

  During testing the development team at Adatum is working with sample data. However, the developers must consider how they will deploy both test and live data to the SQL Server instances running in the hosted virtual machines. To migrate an existing database schema and data to a hosted SQL Server, Adatum can use SQL Server Management Studio. The SQL Server Integration Service and other export tools it contains allow administrators to connect to both the local and the Azure hosted servers to create a copy of the database and its data in the hosted server.

  An alternative is to export the schema—and, if required, the data—as a Transact-SQL script, and then connect to the remote server using Remote Desktop Protocol (RDP) and run the script using SQL Server Management Studio or the command line on that server. Using a script allows Adatum to include this as part of the build process for the test server running in Azure staging, so that the application can be tested without using the live data.

  Testing, Deployment, Management, and Monitoring

  This section discusses application life cycle management topics for applications hosted in Azure. Although specific requirements will vary between applications and across organizations, everyone develops applications, then tests them, and finally deploys them. Typical factors that must be considered are where applications should be tested, and how the deployment process should be managed to make sure that only authorized personnel have access to the live production environment.

  In this chapter the focus is on the specific scenarios related to IaaS deployment using hosted virtual machines. In subsequent chapters you will find additional information related to the subsequent stages of the migration process Adatum followed. If you choose to use the Azure VM role instead of virtual machines, you will need to establish a testing and deployment procedure that encompasses redeploying the server images each time you change the application or reconfigure the server.

  Adatum has a well-defined set of existing processes for deploying applications to its on-premises servers. The development and testing teams use separate servers for testing, staging, and production. When the development team releases a new version of the application, its progression through the testing, staging, and production environments is tightly controlled. Very rarely, though, small fixes, such as updating the text on an ASPX page, are applied directly to the production servers.

  Poe Says:
  	We want to have a clearly defined process for deploying applications to Azure that allows us to control and trace operations carried out on our subscriptions.

  Adatum has a number of goals for application life cycle management for Azure. Adatum wants to maintain its clearly defined process for deploying applications to Azure, with clearly defined roles and responsibilities. More specifically, it wants to make sure that access to the live environment is only available to a few key people, and that any changes to the live environment are traceable.

  Note

  You can use the Azure API to get a list of create, update, and delete operations that were performed on a subscription during the specified timeframe. For more information, see List Subscription Operations.

  In addition, Adatum wants to be able to roll back the live environment to a previous version if things go wrong. In a worst-case scenario, they would like to be able to pull the application back to be an on-premises application.

  Testing Applications for Virtual Machine Deployment

  One of the major advantages of using virtual machines to test and deploy applications is that the application lifecycle is identical to that when using your own on-premises datacenter. Nothing needs to change; all of your existing procedures and practices continue to work in the same way. The only difference is that the servers are no longer in your own datacenter, but located in an Azure datacenter. Other than the increase in network latency and throughput compared to a local network, developers, testers, and operators should be unaware of any differences.

  Developers can run unit tests and ad-hoc tests on their local computers. The on-premises build server also runs a suite of tests as a part of the standard build process. The application can take its data from a local server running a test copy of the SQL Server database for the aExpense application. This is no different from the normal development practices for on-premises applications.

  For final testing to confirm correct operation, the application is deployed to a test environment consisting of one or more Azure virtual machines. While the runtime environment in a virtual machine is identical to a local Windows Server installation, testing in Azure ensures that the application works correctly in an environment that uses the same network and infrastructure as the live Azure runtime environment. Testers can change the connection string in the application so that it uses data stored in a SQL Server running on a virtual machine in Azure.

  Poe Says:
  	You should try to ensure that your local Windows Server testing environment is configured identically to your Windows Server virtual machines in Azure, and has the same patches installed.

  Test and Production Environments

  Adatum wants to continue to be able to deploy an application to either a staging or a production area. This is a typical scenario where new versions of applications are deployed first to the staging area and then, at the appropriate time, deployed to the production area.

  When using virtual machines and a virtual network, Adatum can provide test and production (live) environments simply by configuring network subnets, segments, and permissions so that only specific people can access each environment; just as it does in the existing on-premises test and production environments.

  Poe Says:
  	Because development and testing staff don't have access to the production environment, there's no risk of accidentally deploying to the live environment.

  The test and production applications use Windows authentication to connect to SQL Server. The test application connects to a test database server, while the production version uses a different server name in the connection string to connect to the live database in the production environment. The application pool in IIS runs under a different identity for test and production areas.

  Markus Says:
  	By configuring the endpoints in the testing subscription to use non-standard ports you can reduce the chances that casual users will access the test version of the application.

  Figure 2 summarizes the application life cycle management approach at Adatum. It uses a single virtual machine for the test environment, which connects to a virtual machine hosted SQL Server containing the test database. The production environment also uses a single virtual machine, which connects to a virtual machine hosted SQL Server containing the live database.

  

  Figure 2

  Adatum's application life cycle management environment

  Even though there is a separation between on-premises and cloud-hosted environments, indicated by the dashed line in Figure 2, keep in mind that this is just a logical division. The Azure virtual network that connects all the computers hides the division so that the virtual machines appear to users and to automated software processes running on-premises as though they are part of the on-premises network.

  You can deploy an application to your Azure test environment just while you run the tests, but don't forget that any time you do something in Azure–even if it's only testing–you will be charged for the virtual machines and for data transferred out of the datacenter. You can minimize data transfer costs by locating all your test virtual server instances in the same datacenter. However, when you use Azure Virtual Machine, you are billed even if the virtual machine is shut down because Azure reserves the resource for you. You should use PowerShell scripts to import and export your virtual machine settings, and delete the test virtual machines when you are not using them.

  Management and Monitoring

  Administrators at Adatum can connect to the virtual machines running the application and the SQL Server using RDP, and manage them in exactly the same way as when the application and database were installed in their local server room. All of the built-in Windows Server monitoring and management facilities are available, and operate in the same way as when on-premises. The only likely difference will be additional latency through the use of the public Internet as the connectivity transport.

  The on-premises version of aExpense uses the Logging Application Block and the Exception Handling Application Block to capture information from the application and write it to the Windows event log. Administrators can view these logs to obtain information about the application and the operating system. They can also use tools such as Windows Performance Counters and Task Manager.

  In Adatum’s case, automated monitoring of on-premises applications takes place using System Center Operations Manager. By establishing connectivity between the hosted virtual machines and the on-premises Operations Manager server, Adatum’s administrators can continue to monitor the hosted servers in exactly the same way as when they were running on-premises.

  Storing and Backing Up Virtual Machines

  When you create a virtual machine, the virtual hard disk (VHD) image is held in blob storage and is used to initialize the virtual machine. You can create a virtual machine from one of the standard templates available in the Azure Management Portal, in which case a copy of that template image is placed in a blob in your Azure storage account. Alternatively, you can create the virtual machine by uploading your own VHD into blob storage.

  Poe Says:
  	You can think of your virtual machines as rehydrated instances of the VHDs stored in Azure blob storage. It’s easy to initialize a virtual machine from the stored VHD or capture a virtual machine to a VHD in much the same way as you would when using an on-premises hypervisor such as Windows Hyper-V.

  Once the VHD is in blob storage, you can initialize one or more virtual machines from it. When the virtual machine is running, any changes are replicated in the blob so that they are persisted when the machine restarts. Blobs are automatically replicated three times for durability, and you can copy the blob to another location in your storage account (or to another storage account) to create a backup. You can also capture an image of a virtual machine and place it in blob storage.

  Note

  For more information about how Azure stores and manages VHDs and virtual machines, see “Data Series: Exploring Azure Drives, Disks, and Images.”

  Managing Virtual Machine Instances

  Adatum will need to manage the virtual machine instances it uses to perform tasks such as stopping, starting, adding, and deleting instances, and for managing blob storage that holds the VHD images. For example, the instances used for testing the application are charged even when not running, and so Adatum will need to remove these when not in use. They can easily be reinitialized from the VHD image held in Azure blob storage when required.

  There are three ways to access an Azure environment to perform management tasks such as this. The first is through the Azure Management Portal, where a single Microsoft account has access to everything in the portal. The second is by using the Azure Service Management API, where API certificates are used to access to all the functionality exposed by the API. The third is to use the Azure Management or Node.js PowerShell cmdlets. Within Adatum, almost all operations that affect the test or production environment are performed using scripts based on the PowerShell cmdlets instead of the Management Portal.

  Poe Says:
  	We use scripts because it means that we can reliably repeat operations. We're also planning to enhance some of our scripts to record when they were run, by whom, and what parameters were used. You will see more details of how we use scripts in Chapter 3, “Moving to Microsoft Azure Cloud Services,” of this guide.

  Elasticity and Scaling

  In addition to managing and monitoring the application, Adatum wants to be able to scale the application to meet the additional load it typically encounters during the last few days of each month. At present, Adatum has deployed only a single instance of the application and the database server. However, during the busy period administrators can use the Azure Management Portal or scripts to change the number of instances deployed.

  Note

  As described earlier in this chapter, the on-premises version of the aExpense application uses in-memory session state management. Adatum recognizes that this limits the ability of the application to scale out across multiple virtual machines until it replaces the session state management with a web farm friendly solution, such as storing session state in the SQL Server database, in Azure table storage, or in the Azure caching service. We discuss these options in more detail in Chapter 3, Moving to Microsoft Azure Cloud Services.

  The options available to Adatum for scaling the aExpense application are to use a larger virtual machine at times when demand is high; however, this would require Adatum to briefly shut down the application as it moved the application from one virtual machine to another. Alternatively, if Adatum modifies the session state management to be web farm friendly, it can scale the application out by adding additional virtual machines when demand is high. For example, they may decide from the results of monitoring the performance and response times that an additional two instances of the virtual machine hosting the application should be available for the last three days of the month, and then scale back to a single instance on the first day of the following month.

  At the time this guide was written, the additional costs for running two extra small virtual machine instances for three days is less than $ 20.00, and so for a total cost of under $ 250.00 per year Adatum can make the aExpense application much more responsive during the busy month-end period.

  Poe Says:
  	When you scale out using virtual machines in Azure, you must be careful to delete the virtual machines when you scale in again. You will be charged for virtual machines even if they are shut down in Azure.

  Isolating Active Directory

  The aExpense application uses Windows Authentication. Because developers do not control the identities in their company's enterprise directory, it is sometimes useful to swap out Active Directory with a stub during the development of your application.

  The on-premises aExpense application (before the migration) shows an example of this. To use this technique, you need to make a small change to the Web.config file to swap Windows Authentication for Forms Authentication and then add a simulated LDAP profile store to the application. Swap Windows Authentication for Forms Authentication with the following change to the Web.config file.

  <authentication mode="Forms">
    <forms name=".ASPXAUTH" 
        loginUrl="~/SimulatedWindowsAuthentication.aspx"
        defaultUrl="~/default.aspx" requireSSL="true">
    </forms>
  </authentication>
  

  You need to add a logon page to the application that enables you to select the user that you want to use for testing. In aExpense, this page is known as SimulatedWindowsAuthentication.aspx.

  You also need to add a class that simulates an LDAP lookup for the Active Directory attributes that your application needs. In this example, the GetAttributes method simulates the LDAP query "&(objectCategory=person)(objectClass=user);costCenter;manager;displayName".

  public static class SimulatedLdapProfileStore
  {
      public static Dictionary<string, string> GetAttributesFor(
          string userName, string[] attributes)
      {
          Dictionary<string, string> results;
  
          switch (userName)
          {
              case "ADATUM\\johndoe":
                  results = new Dictionary<string, string>
                  {
                      { "costCenter", "31023" },
                      { "manager", "ADATUM\\mary" },
                      { "displayName", "John Doe" }
                  };
                  break;
  
              …
          }
  
          return results;
      }
  }
  

  Note

  These code samples come from the BeforeAzure solution in the downloadable solutions.

  More Information

  MSDN is a good starting point to learn more about deploying applications to Azure.

  The Azure Manage Center contains links to plenty of resources to help you learn about managing applications in Azure and about Azure Virtual Machines.

  You can find out more about networks and connecting cloud hosted resources to on-premises resources in the Networks topic on MSDN.

  For a detailed guide to creating an Azure Virtual Machine, see “Create a Virtual Machine Running Windows Server 2008 R2.”

  For a detailed guide to installing SQL Server on a Virtual Machine, see “Provisioning a SQL Server Virtual Machine on Azure.”

  The Hands-on Labs that are available for this guide include a step-by-step guide to setting up Virtual Machines, SQL Server, and Windows Active Directory. For more details, see the Moving Applications to the Cloud - Hands on Labs on the Microsoft Download Center.

  Next Topic | Previous Topic | Home | Community