Windows Azure Spring 2012 Release: Four Scenarios in the Hybrid Cloud

In the past, I have written about the benefits of Platform as a Service (PaaS) style of applications. While I continue to believe that PaaS offers the best ROI for hosting custom applications in the cloud, there are a number of scenarios where inserting elements of Infrastructure as a Service (IaaS) to a PaaS solution can help alleviate some of the limitations that have prevented the adoption of PaaS. In a recently published post on the appliedis blog, I  look at a few compelling scenarios that are enabled by combining PaaS with the recently announced IaaS features within a Windows Azure Cloud Service.

http://blog.appliedis.com/2012/07/16/windows-azure-spring-2012-release-four-scenarios-in-the-hybrid-cloud/

Windows Azure Planning – A Post-decision Guide to Integrate Windows Azure in Your Environment

 

Once an organization has made the decision to adopt Windows Azure, it is faced with a set of planning challenges, beginning with the basic, “Who should be responsible for signing up and managing the Windows Azure account?” to more involved, “How will Windows Azure impact the ALM process, availability, operational costs?” In this guide, we will seek to answer some of these questions.

 

1. Plan for Administration

Billing

A Windows Azure subscription can be setup by creating a Microsoft Online Services account via the Microsoft Online Services Portal. Before you create a subscription, you must decide on a billing method. Unless you buy resources in bulk ahead of time, providing a credit card to pay for monthly services has been the only available option until recently. While the credit card approach works for individuals and smaller organizations, finance departments at larger organizations are simply not structured to support this billing model. Recognizing this as a potential problem, Microsoft has recently initiated an invoice billing model.

Administrators

At least two individuals in your organization should be given Co-Administrator rights to your service. That said, the number of Co-Administrators should be carefully controlled as people in those roles have full access to add, modify, and delete services. Note that adding a user to the Co-Administrator role will accord them administrative privileges across Windows Azure Compute, Storage and SQL Azure services (Windows Azure AppFabric service is not integrated at the time of writing).

Subscriptions

You should determine the number of subscriptions that will be needed. Each subscription is associated with an Azure datacenter and comes with a quota of resources – storage (100 TB) and compute (20 cores). A subscription can contain up to six hosted services (applications) and 5 storage accounts by default which can be increased if needed by contacting Windows Azure support. For example, an organization may choose from among two distinct services to host in Windows Azure and two environments – production and test – for a given application. Many organizations will start with one subscription but may want to add other subscriptions later. Thus, it is important to plan meaningful names for subscriptions. One other consideration when planning subscription(s) is that storage within a subscription can only be shared by services contained within a subscription. For example when deploying a service, the package file can be deployed from an Azure storage account that is part of the same subscription as the service.

Certificate Management

Windows Azure relies on X.509.v3 certificates for authentication. There are two types of certificates used by Windows Azure:

Management Certificates are associated with a subscription and, as the name suggests, are utilized when performing management operations against it. Typical clients include Windows Azure Tools for Visual Studio, command line tools, such as CSUpload.exe, and custom programs leveraging the Windows Azure Service Management REST API. Management certificates only contain the public key (.cer file). Clients connecting to the subscription need to be trusted and should have the private key.

Service Certificates are associated with a service and are used by Windows Azure services to enable secure interaction with its users. For example, a Windows Azure service that hosts a HTTPS based web endpoint will need a service certificate. Another example is a WCF based Windows Azure Service that requires mutual authentication. Unlike the management certificate, service certificates are private key (.pfx ) files. Service certificates associated with a service are analogous to certificates in a certificate store in on Windows. In fact, Windows Azure copies the service certificates to each role (Virtual Machine) instance associated with a service.

Here are some of the considerations for managing Windows Azure certificates:

· There can be a maximum of 10 management certificates associated with a subscription per administrator. So if there is a need to associate more than 10 certificates, additional administrators would need to be added to a subscription. Note that administrators can share certificates.

· There is no role-based access to the portal. All administrators have the same level of access. This is why it is important to keep the setup simpler by limiting the number of administrators and distinct management certificates.

· Follow industry best practices to secure certificates. If, for whatever reason, there is a need for large number of certificates, consider the use of a third-party tool to manage the certificates.

· Management and service certificates can be self-issued or trusted certificates. Self-issued certificates will cause a security warning that will need to be explicitly bypassed. This is more likely an issue for service certificates that are used to secure HTTPS endpoints.

· Service certificates can be managed by multiple individuals. For example, developers typically work with self-signed certificates. At a later time, IT pros can replace self-signed certificates with trusted ones without having to redeploy the service. This is possible because Windows Azure references the certificate (store name and location) as a logical name stored in the service definition file. This way a certificate can be changed by simply uploading a new service certificate and changing the certificate thumbprint in the service configuration file.

Operations

The Windows Azure portal provides unified access to various operational tasks such as creating subscriptions, creating storage accounts, deploying services, etc. At the same time, most administrators prefer a repeatable, automated way of performing these tasks. Fortunately, the Windows Azure Platform PowerShell Cmdlets can make this task easier. These Cmdlets fall into four categories:

· Hosted services, affinity groups and role instance management, including functions like adding a new hosted service, getting an instance status, adding an affinity group, etc.

· Automation of SQL Azure deployments, including creating and removing a SQL Azure server, adding a firewall rule, and setting/ resetting a SQL Azure password

· Windows Azure Diagnostics Management, including downloading specified performance counters, and clearing Windows logs from storage.

· Windows Azure Storage including adding a new storage account, clearing a container, and getting and setting storage analytics.

For more information please refer to http://michaelwasham.com/2011/09/16/announcing-the-release-of-windows-azure-platform-powershell-cmdlets-2-0/ & http://msdn.microsoft.com/en-us/library/gg433135.aspx

Affinity Groups

When creating a Windows Azure service, you can either specify the datacenter location or specify that the services you create should be part of an affinity group. Affinity groups are logical containers for associating services and storage accounts to a data center. The advantage of having all your services in same affinity group is low latency between these services. Once an affinity group has been defined at a subscription level, it becomes available to any subsequent services or storage accounts. It is recommended that administrators first create an affinity group before provisioning services and storage accounts.

Note that currently the affinity groups do not apply to SQL Azure and Windows Azure AppFabric. You will need to ensure that you create an instance of these services in the datacenter to which the affinity group is associated.

2. Plan for ALM

David Chappell, in his ALM whitepaper, divides Application Lifecycle Management (ALM) into three distinct areas: governance, development and operations (as shown in the screenshot below).

 

Pasted from http://go.microsoft.com/?linkid=9743693

For ALM to be effective, an organization needs a common foundation (depicted in screenshot below) for version control, build management, test case management, reporting, and other functions. Having a common foundation makes it easier to share artifacts between teams. Additionally, having a consistent foundation makes it possible to share processes for build and deployment, thereby reducing overall costs.

 

Pasted from http://go.microsoft.com/?linkid=9743693

The governance aspects of ALM remain largely the same for Windows Azure based projects. Teams can continue to use tools in place for use case development, project management, and application portfolio management.

Since Microsoft Team Foundation Server (TFS) is a common choice for Windows Azure based projects, we will use it for our discussion here – although this discussion is applicable to other ALM tools such as IBM Rational Concert. Development aspect of ALM will be impacted by Window Azure in the following ways:

· Unlike traditional projects, most of the initial development will take place inside the cloud emulator built into Visual Studio. From time to time, developers will need to develop directly against Windows Azure. This is mainly due to the differences in behavior between the emulator and Windows Azure. For example, the code running in the emulator runs under the administrative privileges and has access to GAC. This is not available to code running in Windows Azure. Another example would be Azure AppFabric services. There are no emulator versions of these services. For a complete list of differences between the emulator and Windows Azure please refer to http://msdn.microsoft.com/en-us/library/gg432960.aspx

· Starting with version 1.4 of Windows Azure Tools for Visual Studio, it is possible to create separate target files for different environments. By default, it creates a local and a cloud target environment. It is possible to create a custom target configuration such as “Production” or “Test”. This feature makes it easy for developers to test against the emulator and Windows Azure hosted service.

· The test team will primarily be testing against Windows Azure hosted services. This means that build definitions (including compilation, code analysis, smoke tests and deployment steps) need to be modified to target a Windows Azure based test environment. Fortunately, codeplex tools such DeploytoAzure, provide custom workflow actions for extending the build process. Another approach would be to use Azure Powershell Cmdlets to modify the build definition.

· Windows Azure service deployments are conducted by copying the service package and configuration files to Azure Blob storage first (unless the deployments are being done manually via the Azure portal). So you would want to copy the build output to a Azure Blob container (described in the previous step). As an aside, the elastic nature of Azure storage makes it a great place to archive build outputs. Please refer to Joel Forman’s post on Building and Deploying Windows Azure Projects using MSBuild.

· Windows Azure provides production and staging environments to create a service deployment. Typically, a service is deployed to the staging environment to test it before deploying it to the production environment. A service in staging can be promoted to the production environment by a simple swapping process, without the need for redeployment. For details on swapping, please refer to MSDN article. The swapping feature can be used to deploy changes or to rollback to a previous version of the service without interrupting the service.

· Tom Hollander is his blog post provides an example of a typical Windows Azure setup:

Pasted from http://blogs.msdn.com/b/tomholl/archive/2011/09/28/environments-for-windows-azure-development.aspx

· The elastic nature of Windows Azure makes it suitable for generating load for a stress test. One such test setup is proposed in a series of blog posts by ricardo. As shown below, Agents run on Windows Azure, thereby making it possible to quickly load on the system. The test controller resides on-premise and uses Windows Azure Connect to communicate with the controllers.

 

Pasted from <http://blogs.msdn.com/b/ricardo/archive/2011/04/08/load-testing-with-agents-running-on-windows-azure-part-1.aspx>

 

3. Plan for Availability

Architectural Considerations

While detailed discussion on architectural best practices is out of scope for this guide, it is important to note that availability begins with a good design. Every aspect of your Windows Azure Service should take advantage of scale-out features available on the platform. Let us refer to the following architectural diagram in order to review of some key scalability aspects:

· Load Balancer. Each service is assigned a single Virtual IP (VIP) for all role instances. VIP is managed by the load balancer. Load balancer uses a simply round-robin approach for routing incoming requests. This means that each role instance has to be stateless. Any role instances that become non-responsive for any reason are taken out of the load balancer automatically, and Windows Azure will start the process of healing the service by adding another role instance in due course. This is why it is important to have at least two role instances to maintain availability (in fact having two role instances is a requirement to qualify for the SLA). The same principle of availability and self-healing applies to the worker roles shown in the diagram below. In addition to having multiple role instances, it is also important to logically split the role instances into fault and upgrade domains. Please refer to Improving Application Availability in Windows Azure for more information.

· Partitioning of the Azure Storage Queues. The Azure Storage Queues are used to communicate between Web and Worker roles. For availability and scalability reasons, it is important to consider partitioning the Azure queue.

· Storage. Azure storage and SQL Azure are designed to be fault tolerant. Each manages multiple replicas of data behind the covers and can failover to a different replica, as needed. That said, it is important to partition your storage appropriately to not only improve the availability but also throughput. Please refer to Windows Azure Storage Scalability Targets for more information.

· Intelligent Retry Logic. It is important to design your code to handle failure conditions and temporary unavailability by baking in retry logic when interacting with SQL Azure, Azure storage, etc. Transient Fault Handling Framework developed by Customer Advisory team has built a reusable set of components for adding intelligent retry logic into applications.

· Application Developer Responsibilities. Finally, it is important to know of instances where the platform does not provide high availability out of the box. For example, it is the responsibility of the application developer to make inter-role communication fault tolerant.

 

Global Availability

In the previous section, we reviewed some design considerations for making Windows Azure services more available. However, all of those considerations were limited to services deployed within one datacenter. No matter how available a service is within a data center, it does no good if the there is a data center outage. If the business requirements dictate accounting for such a contingency, there are additional considerations that apply. In the next section we will discuss design considerations for making your application available globally – across different Windows Azure datacenters.

· Azure Traffic Manager. We already know that in order for an Azure service to be globally available, it must be deployed to more than one data center. However, we also know that each instance of the service gets its own VIP. So how are the customers to know which VIP address to use, especially when, there is a contingency and service has to be failed over to another datacenter? This is where Azure Traffic Manager comes in. It allows customers to balance traffic to service hosted across multiple datacenters. Note that load balancing may be triggered due to load on the system or a failure condition. The following diagram explains at a high level how Traffic Manager works. Based on the defined policy, foo.cloudapp.net can be directed to either foo-us.cloudapp.net or foo-europe.cloudapp.net.

· Deployment Strategies. The ability to route to a different datacenter is great, but what about the data. How will data be synchronized across datacenters? How will Access Control Service or Service Bus endpoints be accounted for? The following table (pasted from David Aiken’s presentation ) provides a summary of deployment strategies that make Windows Azure service globally available. Strategies included in this table are combination of Windows Azure features and custom code. For example, SQL Azure Data Sync Service can be used to synchronize the SQL Azure database instances. Windows Azure Storage has geo-replication (within a region) enabled by default. However, note that geo-replicated data is not directly accessible to services. It is designed for handle data center outages. Service Bus and Access Control Service are not currently covered by Traffic Manager. This means that in order to achieve global availability, separate namespaces will need to be created.

 

Windows Azure Service	Multi-datacenter deployment strategy
Windows Azure Compute	Create multiple deployments – user traffic manager to route traffic
Windows Azure Storage	Geo-replication is turned on by default
SQL Azure	Use SQL Azure Data Sync Service
Reporting Services	Deploy reports to different locations
Service Bus	Create multiple namespaces
Access Control Service	Create multiple namespaces

Service Updates

There are three options for updating a deployed Windows Azure Service.

o Delete and redeploy. Given that the previous service instance is deleted, this option offers maximum flexibility with the updates that can be applied. On the flip side this option is most disruptive because it incurs service downtime.

o Deploy to staging followed by a VIP Swap. This option involves deploying an updated version of the service to staging and then performing a VIP swap. There is no downtime incurred in this option, however, existing connections are not moved over to the newly promoted instance. The types of updates that can be applied via this option are limited as well. Additionally there is an additional cost associated with standing up the staging environment.

o In-place or rolling upgrade. This option involves deploying the updates to a service one upgrade domain at time. (It is recommended that each service have at least two upgrade domains defined.) Only instances associated with the upgrade domain are stopped, while other instances keep running.

The following table depicts the kinds of updates that can be applied via each of the three upgrade options discussed above.

 

Changes permitted	In-place	VIP Swap	Delete and re-deploy
Operating system version	Yes	Yes	Yes
.NET trust level	No	Yes	Yes
Virtual machine size	No	Yes	Yes
Local storage settings	No	Yes	Yes
Number of roles for a service	No	Yes	Yes
Number of instances of a particular role	Yes	Yes	Yes
Number or type of endpoints for a service	No	No	Yes
Names and values of configuration settings	Yes	Yes	Yes
Values (but not names) of configuration settings	Yes	Yes	Yes
Add new certificates	Yes	Yes	Yes
Change existing certificates	Yes	Yes	Yes
Deploy new code	Yes	Yes	Yes

The above table is pasted from http://msdn.microsoft.com/en-us/library/ff966479.aspx

For recommendations on improving availability during the upgrade process refer to this MSDN page.

Diagnostics

Designing for availability does not preclude the need to collect diagnostics. In fact, as shown in the diagram below, the need for collecting diagnostics is even greater in the cloud.

Fortunately, Windows Azure Diagnostics enables you to collect diagnostic data from an application running in Windows Azure and store it in Windows Azure storage. The following diagram depicts the overall architecture of how diagnostic data is collected. Each role has a diagnostic monitor process that collects the collects the data requested by the user. This includes Windows Event Logs, Performance Counters, crash dumps, and even custom file-based logs. The diagnostic data is written to the local disk within the role instance. At a pre-determined frequency, the diagnostic data is transferred to Windows Azure Storage. Please refer to this MSDN link for more on information on collecting diagnostic data.

 

There are a number on open source and third-party tools that can simplify the collection and analysis of diagnostic data. These include Azure MMC and Cerebrata’s Azure Diagnostic Manager.

Organizations that rely on Operations Manager for service management of their Windows environment can add the Monitoring pack for Windows Azure Applications. This pack allows for collecting performance information, Windows events. .NET framework trace data from the Windows Azure storage account. For more information please refer to this download page.

Monitoring

Diagnostics can help monitor the internal health of a Windows Azure service, but they do not tell you if the application is visible to the users. This is where monitoring comes in. These applications can monitor the health of your Windows Azure applications and initiate alerts and notifications in the event of an emergency. Again, organizations using Operations Manager today can use the Azure pack to monitor Windows Azure services as well. In addition, there are a number of third-party providers such as Cumulux’s ManageAxis that can provide similar capability.

4. Plan for Storage

Windows Azure offers a number of different storage options that are elastic and highly available.

Consistent with the theme of this paper, we will focus on how each storage option impacts the existing IT setup. (A discussion on the applicability of each option (SQL vs NoSQL) is outside the scope for this section.) Additionally, we discuss the differences in cost in a later section.

There are two storage solutions available on the Windows Azure platform – SQL Azure and Azure Storage.

SQL Azure

SQL Azure offers a familiar relational capability. However, there are some key differences as compared to an on-premise SQL Server. Let us look at how these differences will impact planning and administration of SQL Azure databases.

· When a SQL Azure subscription is created it results in creation of a master database and server-level principal (similar to the sa role on -premise). The master database keeps track of all the databases and logins that are provisioned. Even though the databases are physically located on different machines, the SQL Azure server provides an abstraction that groups all the SQL Azure databases. For additional information on SQL Azure administration refer to this MSDN page.

· Database administrators will continue to manage schema creation, index tuning, and security administration. However, being a multi-tenant service, SQL Azure abstracts the physical aspects of database setup and administration. For instance, it is not possible to specify a file group where the database or index will reside.

· SQL Azure databases are designed to be fault tolerant within a datacenter, so there is no need for a custom clustering or mirroring setup. However, as discussed earlier, in order to make the SQL Azure database globally available, multiple copies of databases will need to be provisioned across different datacenters. These database copies can then be synchronized using the SQL Azure DataSync service. As you would imagine, the synchronization across different datacenters is not atomic. The inherent latency involved in synchronization can result in loss of data and needs to be accounted for in the design of the application.

· On-premise tools such as SQL Server 2008 R2 SSMS can be used to manage the SQL Azure instances. In addition, third-party tools such as Redgate support SQL Azure as well. For light weight operations against SQL Azure databases, Microsoft provides a Silverlight based tool via the SQL Azure portal.

· SQL Azure is accessible via TCP port 1443. This means that to access SQL Azure databases you will need to ensure that firewall rules allow outgoing traffic on port 1443.

· As discussed, given that physical aspects of a SQL Azure database is not accessible, SQL backup and restore commands will not work. Fortunately, SQL Azure offers a capability to backup and restore databases to Azure Blob storage. There are third-party solutions available as well.

· SQL Azure Administrators and developers need to take into account the transient nature of connections. As stated, SQL Azure databases reside in a multi-tenant setup. In order to prevent one tenant from starving other tenants of resources, database connections can be throttled, resulting in termination or temporary unavailability. This is why it is important incorporate retry logic when accessing the database. Frameworks such as Transient Fault Handling Framework can make this task easier.

· Currently, there is a 50 GB limit on a single instance of the SQL Azure database. In order to deal with this limitation, applications are expected to “shard” (or partition) the data across multiple databases. Today the partitioning logic is owned by the application. A forthcoming feature of SQL Azure, referred to as federation, will allow the partitioning logic to be managed outside the application – by database administrators. For example, if the distribution of data changes across the partitions changes over time, the federation feature will for allow splitting and merging of data without effecting the availability or consistency of data.

Windows Azure Storage

Azure storage offers three different kinds of storage options – Tables, Blobs and Queues. Azure Storage is designed for durability and scalability. For more information on Windows Azure Storage, please refer to this MSDN page.

Here are some planning considerations for Windows Azure Storage:

· Windows Azure Tables. Windows Azure Tables is good choice for storing data that will benefit from a “No-SQL” pattern – a massively large volume with low duty (in terms of query processing). Windows Azure Storage manages multiple replicas of the dataset to protect against hardware failures. However, for business continuity reasons it may be important to protect against errors in the application by maintaining snapshots of data. Blob storage has a built-in snapshot capability (while Windows Azure Table Storage does not). Tools such as AzureStorageBackup or lokad-snapshot rely on snapshot capability of blob storage to offer backup functionality.  Cerebrata Azure Management Cmdlets can also be used to back up a storage account to local computer and restoring the contents of a storage account.

· Geo-replication. As stated previously, Geo-replication is enabled by default at no cost. However, note that geo-replication is a platform level feature that comes into play when there is a data center outage. Replicated data is not directly available to the applications. Furthermore Geo-replication feature is only available between data centers in the same region.

· Tools. There are a number of open source and commercial options available for managing Windows Azure Storage including tools from http://www.cerebrata.com/ and http://cloudberrylab.com/. In addition, Microsoft has made a sample available (including source code) to manage Windows Azure Storage. This sample can be found at http://wapmmc.codeplex.com/ .

· CDN. Consider enabling the CDN feature if the data stored in Windows Azure Blob is public data. For data that is not public, consider the use of shared access signatures.

· Windows Azure Blobs. As the name suggests, Windows Azure Blobs is designed for storing large binary objects. Blob storage is a great place to host streaming content. It supports efficient resume for browsers and streaming media players via Http headers such as Accept-Ranges. It is expected that smooth streaming for video content will be available in future.

· SMB. Page blobs can be mounted as a NTFS volume on a cloud or on-premise machine (a feature referred to as the X-Drive). Only a single instance can be allowed read-write access via X-drive. However, using SMB, it is possible to mount a drive on one role instance and then share that out to other instances. For more information refer to this blog post. The following diagram depicts how Windows Azure Drive works.

· Consider enabling Windows Azure Storage Metrics to better understand usage patterns. For example, it is possible to obtain hourly summary of number of requests, average latency and more for Blobs, Tables and Queues. For more information refer to this MSDN page

· Consider enabling Windows Azure Storage Logs to trace requests executed against storage accounts. For example, it is possible to capture the Client IP that issued a “Delete Container”. For more information refer to this MSDN page.

· Review the throughput guideline for Windows Azure Storage to make sure that the scalability needs can be met. Additionally, consider using tools such as Azure Throughput Analyzer that can help measure the upload and download throughput achievable from your on-premise.

Hybrid Solution – On Premise Data Store

There are scenarios where a cloud based data store is not viable. Here are some scenarios:

· Compliance (HIPPA or PCI DSS) concerns may prevent the data from being stored in the public cloud.

· Non-availability of features such as encryption in SQL Azure.

· Inability to undertake certain performance improvement steps such as changing the fill_factor or pad index or affect the disk I/o by moving to a RAID or another type of controller.

In such situations it may be advisable to host within SQL Server running on-premise. The connectivity to the on-premise instance of SQL Server will be via Windows Azure Connect. Windows Azure Connect provides IP-based network connectivity between on-premises and Windows Azure resources.

 

5. Plan for Compute

Windows Azure compute instances are where applications are hosted. The Windows Azure platform takes care of the operation constraints (administration, availability and scalability) so developers can focus on the applications. However, as you would imagine, some amount of planning / governance is needed to make the most of the compute service. Here are some key considerations:

· Compute instances come in different sizes. You will need to decide which instance meets your needs by reviewing the characteristics of each instance size.

· You will need to decide in which data center to provision the compute instances. As discussed, you need to consider location affinity, fault tolerance and global availability needs.

· There is a system based on heartbeats for monitoring the health of compute instance. If a hardware or software failure causes the compute instance to be down, it will be detected by the Windows Azure platform. (Refer to the diagram below.) The worst case reaction time is heartbeat interval + heartbeat timeout = ~ 10 minutes.

 

The above diagram was pasted from http://channel9.msdn.com/Events/TechEd/Europe/2010/COS326

· Profile your applications to determine if compute instances that you have spawned are causing a bottleneck.

· In order to dynamically scale your applications up and down, you will need to determine thresholds for dynamic scaling based on load and demand. The dynamic scaling threshold can be max queue length, % CPU utilization, etc.

· Once you have determined the dynamic scalability threshold, you can use tools such as AzureWatch, AzureScale or Cumulux to scale the instances appropriately.

· In addition to dynamic scaling, consider periods of day where application will witness low volumes of access. It may be possible to scale down and then up, based on the schedule.

· Note that each compute instance is a virtual server hosted on a shared piece of hardware. Given that compute instances are running inside multi-tenant environment, it is important to consider side-channel attack. For more information, refer to Microsoft Best Practices for Developing Secure Azure Applications.

 

6. Plan for Cost

With the “utility-like pay-per-use” pricing, Cloud computing promises to change the economics of running applications in fundamental ways. This is commonly referred to as Cloudonomics, a term Joe Weinman coined in his seminal article.

In this section, we will review some of the key considerations related to cost of hosting services in Windows Azure:

· You should understand the differences in costs between maintaining a traditional server, virtualized sever, private and public cloud. Please refer to Microsoft white paper for more information.

· It is important to understand the pricing for various Windows Azure Platform components. The easiest way is to start with the Windows Azure pricing calculator to model the costs of various components.

· In the application architecture section above, we reviewed a number of considerations to make the application more scalable and fault tolerant. Added scalability and fault tolerance comes at a cost. You need to make sure that business requirements warrant extra costs. One of the benefits of cloud computing is that many of these options (i.e. deploying service to additional datacenters, and adding a number of instances) need not be enabled upfront.

· Once you have built a Windows Azure Service, it is important to periodically review the monthly bill in conjunction with profile data for your application. This will allow you to eliminate services that are not being used. For example, if the compute instances are not taxed, you may want to scale down to a smaller number of instances. Similarly, if the pattern of usage warrants a lower number of instance during a certain part of day, automate the scaling to have lower number of instances during this time.

· Watch for runaway costs. Even though cost per transaction may be very small (i.e. 100,000 transactions against Windows Azure storage costs $.10) unchecked usage can run up costs quickly. For example, consider the following diagram – monitoring 5 performance counters every 5 second for 100 instances can cost you more than $260 a month.

 

Another example is Windows Azure Storage Analytics. Again, the cost of storage may be small per GB, but if left unchecked, the storage costs can mount over time. This is why it is important to declare a retention policy. When a retention policy is applied, Storage Analytics will automatically delete logging and metrics data older than the specified number of days. Note that disposition as a result of the retention policy is not billable.

· Use the billing period to your advantage. The compute instances are billed per hour. It makes no sense to shutdown and restart an instance for a 30 minute period of inactivity. You would end up paying for two compute hours. SQL Azure charges are pro-rated over a month of usage. If you are not using a database for a period of time, backup it to Blob storage and restore it when you need it.

· Be aware of common pitfalls such as the ones described below:

o You are paying for the service as soon as the role has been provisioned. This means that if your service recycles between ‘initializing’ / ’busy’ / ‘stopping states’ (perhaps due to an error in the deployment package), you are continuing to accrue charges.

o A service that is in a suspended state continues to incur charges.

o To avoid incurring any charges for a service that is not in use, delete that service.

7. Conclusion

In this blog post, we reviewed some of the planning considerations for getting started with Windows Azure. We discussed the following major areas: Administration, ALM, Availability, Storage, Compute and Cost. While not an exhaustive set, hopefully this post can help you plan your Windows Azure deployment.

Thanks to Harin Sandhoo, Kevin Griffie and Gaurav Mantri for their contributions to this blog post.

SharePoint and Azure Integration Opportunities

 

There is a lot of talk about the use of SharePoint, and other Office products, in the upcoming cloud offering Office365. Office 365 is SaaS (Software as a Service) style of cloud computing wherein one can subscribe and use the SharePoint functionality without worrying about the underlying hardware and software infrastructure. The entire underlying infrastructure is owned, built and administered by Microsoft. In addition, the continued management of the infrastructure – including application of patches, upgrades, backups and recovery operations, etc. – is also Microsoft’s responsibility. Subscribers pay one fixed monthly amount for Office 365’s services. Microsoft is able to offer a reasonable price point for a monthly subscription because Office365 is based on a shared, multi-tenant infrastructure. Of course, while the software and hardware is shared, data belonging to each subscriber is appropriately sequestered

While a multitenant offering built on a shared infrastructure can be a cost effective option, there are scenarios where it may not completely meet the needs. Here are some examples:

• Regulatory Compliance: A specific regulatory or compliance requirement may prohibit hosting documents in a shared or public cloud environment. (For example, Canadian privacy laws may restrict data that can be stored in a cloud data center located outside Canada). SharePoint Customization: Since the underlying infrastructure is shared across all subscribers, there is limited flexibility in installing custom modules. Customizations are generated limited to the constraints imposed by SharePoint sandbox solutions (Sandbox solutions run in a separate process and can only access a limited subset of the SharePoint OM).

One possible alternative to the above limitations is to obtain  a dedicated SharePoint instance in the cloud. This is possible in two ways today: i) For customers with a user base of 5000 of more users can take advantage of the dedicated level of service wherein the hardware is dedicated for the customer ii) For U.S. government organizations, Microsoft offers BPOS Federal, in which all data is stored in a secure facility dedicated to the customer. It is interesting to note that BPOS-Federal just achieved the FISMA (Federal Information Security Management Act) certification and accreditation.

• Other Platform Releases: There may be a need to run a previous version of SharePoint, such as Sharepoint 2007, and Office365 is based on SharePoint 2010. Conversely, there may be a need to tap into the functionality offered by a newer release of the .Net framework beyond the version that SharePoint is based on today (for instance, Windows Workflow 4.0).

The key points above represent dilemmas that customers face today. As shown in the diagram below, while SharePoint as a Service via Office365.com provides benefits such as lower costs and elasticity of resources, the flexibility to customize is limited, and there are potential compliance concerns. On the other hand, while setting up SharePoint on-premise addresses these issues , it also comes with the added responsibility of configuring and managing the underlying infrastructure.

Enter the Windows Azure Platform. Windows Azure platform is a PaaS (Platform as a Service) offering from Microsoft. It allows for building and running custom applications in the cloud. The key benefit of Windows Azure is that it offers elasticity of resources such as storage and computation. Customers can leverage these capabilities to “enhance” their on-premise, as well as SaaS-based, SharePoint installations. The diagram below depicts how both the on-premise and online SharePoint environments can leverage the Windrows Azure Platform: 

i) On-premise installations can scale out easily by relying on the virtually infinite storage and computing resources available on the Windows Azure platform. The key benefit, of course, is that massive scalability is available without undertaking a huge capital investment upfront. Instead, customers are able to dynamically scale up and down while only paying for what they use.

ii) Online installations can take advantage of the Windows Azure platform to run customizations. For instance, a custom-built workflow may be hosted within a Windows Azure role. Since the workflow is hosted on Windows Azure, there is minimal administrative overhead for ensuring that the workflow is up and running, OS patches are applied etc.

To better understand this concept let us briefly look at a few scenarios:

Scenario #1: Connecting to Cloud-based databases

This scenario is about leveraging SQL Azure-based databases within an on-premise SharePoint instance. SQL Azure is a database-as-a-service offering that is part of Windows Azure. It makes it easy to provision any number of databases that are easy to administer and come bundled with a highly availability setup.

As depicted in the diagram below, Business Connectivity Services (BCS) can be used to connect data contained within a SQL Azure database to an external list in SharePoint. You can choose to connect to the SQL Azure instance directly or via a Web or Worker role.

For detailed steps on connecting to SQL Azure using BCS please refer to this toolkit.

Scenario #2: Taking advantage of the data marketplace

This scenario is about leveraging the Windows Azure DataMarket to author SharePoint-based dashboards and mashups. The Windows Azure DataMarket provides a marketplace for data where content publishers can make their datasets available to consumers. This includes datasets such as Health and Wellness data, location-based services, demographics, etc. All of the data available on DataMarket is curated and highly available. It is also consumable via a consistent set of REST-based ODATA APIs. This makes it possible to consume the DataMarket data via PowerPivot add-in in Excel. Once an Excel workbook containing PowerPivot data has been authored, it can then be published to SharePoint. This allows SharePoint users to view and collaborate around the Power Pivot application.   For a brief demo of PowerPivot with a Windows Azure DataMarket datasource, please refer to this brief video I recorded a while back.

Scenario #3: Scalable routing of notifications

This scenario is about leveraging the Windows Azure-based infrastructure to route SharePoint notifications. The Windows Azure AppFabric Service Bus provides an infrastructure for large-scale event distribution. As shown in the diagram below, SharePoint notification such as the item added events (for instance adding a new announcement to a list) can be routed over the Windows Azure App Fabric Service Bus to a large number of listeners.

For detailed discussion on building custom SharePoint Service Application that can act as conduit to the Windows Azure AppFabric Service Bus, please refer to my earlier blog post.

Scenario #4: Dynamic Scaling

This scenario is about leveraging the elastic computational resources available on the Windows Azure platform. Windows Azure VM role allows customers to bring their own pre-created OS image to the cloud. Recently, as a proof of concept, we hosted an Excel Services instance via the VM Role. As shown in the diagram below, the benefit of such an approach is that number of VM role instances can be dynamically changed based on the load.  This means that the customer doesn’t need to have a large setup on-premise to handle expected and un-expected peaks. Instead, they can “burst out” to the cloud

For more information on setting up Excel Services in VM role please refer to a blog post by Harin Sandhoo from AIS.

Before I close, I would like to refer the readers to Steve Fox’s blog. Steve Fox has been a thought leader on this topic of integrating Windows Azure with SharePoint.

Windows Azure Boot Camp at MIX

Later today I will be presenting the “Cloud computing with the Windows Azure Platform” boot camp at MIX. My session is comprised of three sections:

• Overview of Cloud Computing
  Introduction to Windows Azure Platform
• Review an on-premise MVC3 app
  Move the on-premise app to Windows Azure
• Fault Tolerance and Diagnostics
  Tips & Tricks – Building Scalable Apps in the cloud

As part of the second session, I will go over the steps to “Azure-enable” an existing on-premise MVC 3 based web application. This blog is an attempt to capture these steps for the benefit of the attendees and other readers of this blog.

Before we begin, let me state the key objectives of this exercise:

• Demonstrate that apps built using currently shipping, on-premise technologies (.NET 4.0 / VS 2010) can easily be moved to the Windows Azure Platform. (Of course, the previous version of .NET (3.5 Sp1) is supported as well.)
• Understand subtle differences in code between  running on-premise and on the Windows Azure platform.
• Reduce the number of moving parts within the application by “outsourcing” a number of functions to Azure based services.
• Refactor the application to take advantage of the elasticity and scalability characteristics, inherent in a cloud platform such as Windows Azure.

 

Community Portal – An MVC3 based on-premise application

The application is simple by design. It is a Community Portal (hereafter interchangeably referred to as CP) that allows users to create tasks. To logon to the CP, users need to register themselves. Once a task has been created, users can kick-off a workflow to guide the task to completion. The workflow represents a two-step process that routes the request to the assignee, first, and then to the approver. In addition to this primary use case of task creation and workflow, Community Portal also allows users to access reports such as “Tasks complete/ Month”.

 

 

 

The following diagram depicts the Community Portal architecture. It is comprised of two subsystems: 1) an MVC3 based Community Portal site, and 2) a WF 4.0 based Task Workflow Service. This is very quick overview assuming that you are familiar with the core concepts such as MVC 3, EF, Code-First and so on.

 

Community Portal is a MVC 3 based site. The bulk of the logic is resides within the actions  as part of the TasksController class.  Razor is used as the ViewEngine. Model is based on EF generated entities. Data annotations are used to specify validation for individual fields.  Community Portal uses the built-in membership provider to store and validate user credentials. CP also uses the built-in ASP.NET session state provider to store and retrieve data from the cache. In order to avoid hitting the database on each page refresh, we cache the TaskSummary (list of tasks assigned to a user) in the session state. 

 

Tasks created by the users are stored in SQL Server. EF 4.0, in conjunction with the Code-First library, is used to access the data stored in SQL Server. As part of the task creation, users can upload an image. Uploaded images are stored in SQL Server using the FILESTREAM feature.  Since the FILESTREAM allows for storing the BLOB data on a NTFS volume, it provides excellent support for streaming large BLOBs [as opposed to the 2GB limit imposed by varbinary(max)]. When the user initiates a workflow, a message is sent over to WCF using the BasicHttpBinding. This causes the WF instance to be created. This brings us to the second subsystem – workflow host.

As stated, Task Workflow Service consists of a WF 4.0-based workflow program hosted inside a console application (we could have just as easily hosted this in IIS). WF program is based on built-in Receive, SendReply, and InvokeMethod activities. As stated, this workflow is a two-stage workflow. The first call into the workflow kicks off a new instance. Each new instance updates the task status to “Assigned” via the InvokeMethod activity and sends a reply to the caller. Then the workflow waits for “task completed” message to arrive. Once the “task completed” message arrives, the workflow status is marked “complete”, followed by a response to the caller. The last step is repeated for the “task reviewed” message.

In order to ensure that all messages are appropriately correlated (i.e. routed to the appropriate instance), a content-based correlation identifier is used. Content-based correlation is new in WF 4.0. It allows an element in the message (in this case taskId) to server as the correlation token. Refer to the screenshot below: Xpath query is used to extract the TaskId from the message payload. The WF 4 runtime compares the result of the Xpath expression to the variable pointed to by the CorrelatesWith attribute to determine the appropriate instance where the message needs to be delivered.

 

A quick word on the reporting piece, again for the sake of simplicity, the Community Portal relies on client report definition files (.rdlc). This is based on the local processing mode supported by the report viewer control. Since the ReportViewer control (a server-side control) cannot be used inside MVC, an alternate route was created.

Finally, the following diagram depicts the on-premise solution – it consists of two projects: 1) an MVC 3 based CommunityPortal project, and 2) a console application that hosts the WF 4.0 based TaskWorkflow.

 

This concludes our whirlwind tour of the on-premise app.

Changing Community Portal to run on Windows Azure

Let us switch gears and discuss how the on-premise version of Community Portal can be moved to the Windows Azure Platform.

Even though our on-premise application is trivial, it includes a number of moving parts. So if we were to move this application to IaaS (Infrastructure as a Service) provider, we would have to setup and manage the various building blocks ourselves. For instance, we would need to install Windows Server AppFabric caching and setup a pool of cache servers; we would also have to install SQL Server and setup high availability; we would have to install an identity provider (IP) and setup user database and so on. We have not even discussed the work involved in keeping the servers patched.

Fortunately, Windows Azure platform is a PaaS offering. In other words, it provides a platform of building block services that can make it easier to develop cloud-based applications. Application developers can subscribe to a set of pre-built services as opposed to creating and managing their own. There is one other important benefit of PaaS – the ability to treat the entire application (including the virtual machines, executable and binaries) as one logical service. For instance, rather than logging on to each server (that makes up the application) and deploying the binaries to them individually, Windows Azure allows developers to simply upload the binaries and a deployment model to the Windows Azure Management portal – as you would expect there is a way to automate this step using the management API. Window Azure in turn allocates the appropriate virtual machines, storage and network, based on the deployment model. It also takes care of installing the binaries to all the virtual machines that have been provisioned. For more a detailed discussion on PaaS capabilities of Windows Azure PaaS, please refer to my previous blog post.

The following diagram illustrates the different pieces that make up a Windows Azure virtual machine (also referred to a compute unit). The binaries supplied by the application developer are represented as the dark grey box. The rest of the components are supplied by the Windows Azure platform. Role runtime is some bootstrapping code that we will discuss later in the blog post. Together, this virtual machine represents an instance of software component (such as an MVC 3 site, a batch executable program, etc.) and is commonly referred to as a role. Currently, there are three types of roles – Web role, Worker Role and VM role. Each role type is designed for a type of software component. For instance, a web role is designed for web application or anything related to it; a worker role is designed for long running, non-interactive tasks. An application hosted within Azure (commonly referred to as an Azure-hosted service) is made up of one more types of roles. Another thing to note is that an Azure-hosted application can scale by adding instances of a certain type.

 

Now that you understand the core concepts (such as deployment model, role and role instances) let us resume our discussion on converting the on-premise application to run on Windows Azure. Let us begin with a discussion of the deployment model. It turns out that the deployment model is an XML file that describes things such as the various roles that make our application, number of instances of each role, configuration settings, port settings, etc. Fortunately, Visual Studio provides tooling so that we don’t have to hand create the XML file. Simply add a Windows Azure project to the existing solution as shown below.

Select a worker role. Remember that a worker role is designed for a long-running task. In this instance, we will use it to host instances of TaskWorkflow. There is no need to select a web role as we will take the existing CommunityPortal project and map it to a web role.

We do this by clicking on Add Web Role in the solution (as shown below) and selecting the CommunityPortal project.

Here is the screen shot of our modified  solution structure. Our solution has two roles.  To mark the transition to an Azure service, I dropped the OnPremise suffix from our solution name – so our solution is now named CommunityPortal.

Through these steps, we have generated our deployment model!

The following snippet depicts the generated ServiceDefinition file. This file contains definitions of role, endpoints, etc. As you can see, we have one web role and one worker role as part of our service. The Sites element describes the collection of web sites that are hosted in a web role. In this instance, we have a single web site that is bound to an external endpoint that is listening to HTTP traffic over port 80 ( line # 12 & 17 ).

   1:  <?xml version="1.0" encoding="utf-8"?>

   2:  <ServiceDefinition name="WindowsAzureProject5" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">

   3:    <WorkerRole name="WorkerRole1">

   4:      <Imports>

   5:        <Import moduleName="Diagnostics" />

   6:      </Imports>

   7:    </WorkerRole>

   8:    <WebRole name="CommunityPortal">

   9:      <Sites>

  10:        <Site name="Web">

  11:          <Bindings>

  12:            <Binding name="Endpoint1" endpointName="Endpoint1" />

  13:          </Bindings>

  14:        </Site>

  15:      </Sites>

  16:      <Endpoints>

  17:        <InputEndpoint name="Endpoint1" protocol="http" port="80" />

  18:      </Endpoints>

  19:      <Imports>

  20:        <Import moduleName="Diagnostics" />

  21:      </Imports>

  22:    </WebRole>

  23:  </ServiceDefinition>

.csharpcode {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
}
.csharpcode pre {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
}
.csharpcode pre {
margin: 0em
}
.csharpcode .rem {
color: #008000
}
.csharpcode .kwrd {
color: #0000ff
}
.csharpcode .str {
color: #006080
}
.csharpcode .op {
color: #0000c0
}
.csharpcode .preproc {
color: #cc6633
}
.csharpcode .asp {
background-color: #ffff00
}
.csharpcode .html {
color: #800000
}
.csharpcode .attr {
color: #ff0000
}
.csharpcode .alt {
background-color: #f4f4f4; margin: 0em; width: 100%
}
.csharpcode .lnum {
color: #606060
}

While the service definition file defines the settings, the values associated with these settings reside in the service configuration file. The following snippet shows the equivalent service configuration file. Note the Instances element (line #4 & line #10) that defines the number of instances for a given role. This tells us that changing the number of instances of a role is just a matter of changing a setting within the service configuration file. Also note that we have one or more configuration settings defined for each role. This seems a bit odd doesn’t it? Isn’t Web.config the primary configuration file for an ASP.Net application? The answer is that we are defining configuration settings that apply to one or more instances of a web role. There is one other important reason for preferring the service definition file over web.config. But to discuss that, we need wait until we have talked about packaging and uploading to application binaries to Windows Azure.

 

   1:  <?xml version="1.0" encoding="utf-8"?>

   2:  <ServiceConfiguration serviceName="WindowsAzureProject5" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">

   3:    <Role name="WorkerRole1">

   4:      <Instances count="1" />

   5:      <ConfigurationSettings>

   6:        <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />

   7:      </ConfigurationSettings>

   8:    </Role>

   9:    <Role name="CommunityPortal">

  10:      <Instances count="1" />

  11:      <ConfigurationSettings>

  12:        <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />

  13:      </ConfigurationSettings>

  14:    </Role>

  15:  </ServiceConfiguration>

.csharpcode {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
}
.csharpcode pre {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
}
.csharpcode pre {
margin: 0em
}
.csharpcode .rem {
color: #008000
}
.csharpcode .kwrd {
color: #0000ff
}
.csharpcode .str {
color: #006080
}
.csharpcode .op {
color: #0000c0
}
.csharpcode .preproc {
color: #cc6633
}
.csharpcode .asp {
background-color: #ffff00
}
.csharpcode .html {
color: #800000
}
.csharpcode .attr {
color: #ff0000
}
.csharpcode .alt {
background-color: #f4f4f4; margin: 0em; width: 100%
}
.csharpcode .lnum {
color: #606060
}

 

Visual Studio makes it easy to work with the service configuration settings so developers don’t have to work with the XML directly. Following screenshot shows the UI for adjusting the configuration settings.

Now that we have the deployment model, it’s time to discuss how we package up the binaries (recall that to host an application on Windows Azure, we need to provide a deployment model and the binaries ). Before we create the package, we need to make sure that all the files we will need to run our application in Window Azure are indeed included. By default, all the application assemblies will be included. However, recall that Windows Azure is providing the environment for our application to run. So we can expect .NET 4.0 framework (or 3.5 Sp1) assemblies, C Runtime components, etc. to be available to the applications running in Windows Azure. There are however, some add-on packages that are not available provided in the environment today such as MVC3. This means we need to explicitly include the MVC3 assemblies as part of our package by setting the CopyLocal=true.

Now that we have covered the concept of a service package and configuration file, let us revisit the discussion on where to store configuration settings that need to change often. The only way to change a setting that is part of the package (such as the settings included within the web.config) is to redeploy it. In contrast, settings defined in the service configuration can easily be changed via the portal or the management API, without the need to redploy the entire package. So, now that I have convinced you to store the configuration settings in the service configuration files, we must make a change to the code to read settings from the new location. We need to use the RoleEnvironment.GetConfigurationSettingValue to read the value of a setting from the service configuration file. RoleEnvironment class gives us access to the Windows Azure runtime. In addition to accessing the configuration settings, we can use this class to find out about all the roles instances that are running as part of the service. We can also use it to make checks to see if the code is running in Windows Azure. Finally, we also need to set the global configuration setting publisher inside the Global.asax.cs as shown below:

 

 

   1:             CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

   2:              {

   3:                  configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

   4:              });

   5:   

That’s all the changes we will make to the web role for now.

But we also need to modify the worker role we just added. The on-premise version relied on a console application to the host the task workflow. The equivalent piece of code (shown) can be moved to the Run method within the RoleEntryPoint. This begs the question – what is RoleEntryPoint and why do I need it? Recall that when discussing the Azure VM, we briefly alluded to the Role Runtime. This is the other piece of logic (other than the application code files themselves) that an application developer can include as part of the package. It allows an application to receive callbacks (OnStart, OnStop. etc.) from the runtime environment and is, therefore, a great place to inject bootstrapping code such as diagnostics, another important example of the type of callback is the notification when there is a change in service configuration setting. We talked about the role instance count as being a service configuration setting. So if the user decides to add or remove role instances, the application can receive a configuration change event and act accordingly.

Strictly speaking, including a class derived from RoleEntryPoint is not required if there is no initialization to be done. That is not the case with worker role we added to the solution. Here we need to use the OnStart method to setup WorkflowService endpoint and open the workflowhost as shown in the snippet below. Once the OnStart method returns (with a return value of true) we will start receiving incoming traffic. This is why it is important to have the WorkflowServiceHost all ready before we return from OnStart.

The first line of the snippet below requires some explanation. While running on-premise, the base address was simply the local host and dynamically assigned port. However, when the code is being run inside Windows Azure, we need to determine at runtime which port has been assigned to the role. The worker role needs to setup an internal endpoint to listen to incoming requests to the workflow service. Choosing an internal endpoint is a decision we made. We could have just as easily decided to allow the workflow host to listen on an external point (available on the public internet) However, in deference to the defense in depth idea, we decided to limit the exposure to the workflow host and only allow other role instances running as part of the service to communicate with it.

 

   1:  RoleInstanceEndpoint internalEndPoint =

   2:       RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["TaskEndpoint"];

   3:   

   4:    string protocol = "http://";

   5:    string baseAddress = string.Format("{0}{1}/", protocol, internalEndPoint.IPEndpoint);

   6:   

   7:    host = new WorkflowServiceHost(new TaskService(), new Uri(baseAddress));

   8:    

   9:    host.AddServiceEndpoint("ITaskService", new BasicHttpBinding(BasicHttpSecurityMode.None) { HostNameComparisonMode = HostNameComparisonMode.Exact }, "TaskService");

  10:   

  11:    host.Open();

The Run method then simply runs a never ending  loop as shown below.  This is equivalent to the static void Main method from our console application.

   1:             Trace.WriteLine("TaskServiceWorkerRole entry point called", "Information");

   2:   

   3:              while (true)

   4:              {

   5:                  Thread.Sleep(10000);

   6:                  Trace.WriteLine("Working", "Information");

   7:              }

Once we have gone through and included the  appropriate files, packaging the application binaries is just matter of right clicking and selecting the publish option. This brings up the publish dialog as shown below. For now we will simply select “Create Service Package option” and click OK.

 

That’s it. At this point, we have both the required artifacts we need to publish to Windows Azure. We can browse to the windows.Azure.com (shown below) and create a new service called CommunityPortal. Notice the two highlighted text boxes – here we provide the package location and the deployment model. Let us  go ahead and publish our application to Windows Azure.

 

Not so fast …

We’re all done and the application is running on Windows Azure! Well almost, except we don’t have a database available to the code running in Windows Azure (this includes the Task database and the membership database). Unless of course, we make our on-premise database instances accessible to the Windows Azure hosted service. While doing so is technically possible, it may not be such a good idea because of latency and security concerns. The alternative is to move the databases close to the Windows Azure hosted service. Herein lies an important concept. Not only do we want to move these databases to Windows Azure, we also want to get out of the business of setting up high availability, applying patches, etc. for our database instances. This is where the PaaS platform capabilities offered by Windows Azure shine.

In the next few subsections, we will look at approaches that allow us to “get out of the way” and let the Windows Azure platform take care of as many moving parts as possible. One other thing – changing the on-premise code to take advantage of Azure-provided services sounds good, but, it is only practical to do if there is semantic parity between the two environments. It is not reasonable to expect developers to maintain two completely different code bases. Fortunately, achieving semantic parity is indeed the key design goal that designers of Windows Azure had in mind. The following diagram represents the symmetry between the between on-premise and on Windows Azure offerings. It is important to note that a complete symmetry between on-premise and Windows Azure is not there today and is unlikely to be there anytime soon. Frankly, achieving complete symmetry is a journey on which the entire ecosystem including Microsoft, ISVs, SIs and developers like us, have to embark on together. Only then can we hope to realize the benefits that PaaS has to offer.

Let us start with moving the database to the cloud.

Windows Azure includes a highly available database as a service offering called SQL Azure. The following diagram depicts the architecture of SQL Azure. SQL Azure is powered by a fabric of SQL Servers nodes that allows for setting up highly elastic (i.e. ability to create as many databases as needed) and redundant (i.e. resilience against failures such as corrupted disk) databases. While the majority of the on-premise SQL Server functions are available within SQL Azure, there is not 100% parity between the two offerings. This is mainly due to the following reasons :

1) SQL Azure team has simply not gotten around building this capability into SQL Azure yet, however, a future release is planned to address this. An example of such a feature is CLR-based stored procedures. This is something that is not available on SQL Azure today, but the team has gone on record to add this capability in the future.

2) It simply does not make sense to enable certain features in a hosted environment such as SQL Azure. For example, ability to specify file groups will limit how the SQL Azure service can move the databases around. So this feature is unlikely to be supported by SQL Azure.

 

As application developers, all we need to do is provision the database on the Windows Azure portal by specifying the size as shown below. For this sample, we have a very modest size requirement. So we don’t have to worry about sharding our data across multiple databases. The next step is to replace the on-premise connection string with the SQL Azure connection string.

 

 

Remember from our earlier discussion that there is not 100 % parity between on-premise SQL Server and SQL Azure. Reviewing our on-premise database reveals one aspect of our schema that cannot be migrated to SQL Azure – this is the FILESTREAM column type that we used to efficiently store an uploaded image associated with a task. The FILESTREAM column type allows us to store the image on a mounted NTFS volume outside of the data file. This is something that SQL Azure is unlikely to support. Fortunately, Windows Azure provides Azure Blob storage that allows us to store large BLOBs efficiently. Furthermore, we don’t have to worry about managing the NTFS volume (as is the case with FILESTREAM) – Azure Blob storage takes care of that for us. It provides a highly elastic store that is also fault tolerant (as it keeps multiple copies of the data). Finally, should we need to, we can serve the images from a location closer to our users by enabling the Content Delivery Network (CDN) option on our Azure Blob containers. Hopefully, I have convinced you that Azure Blob storage is a much more optimal place for storing our BLOB data.

Now, let’s look at the code change that is needed to store the images in Blob store. The change is rather simple. First, we will upload the image to the Azure Blob storage. Next, we will take the address of the Blob container and store it in the Tasks table. Of course, we will need to change the Tasks table to replace the FILESTREAM column with the varchar (255) that allows us to store the address of the Blob container.

 

   1:         public void SaveFile(HttpPostedFileBase fileBase, int taskId)

   2:          {

   3:              var ext = System.IO.Path.GetExtension(fileBase.FileName);

   4:   

   5:              var name = string.Format("{0:10}_{1}{2}", DateTime.Now.Ticks, Guid.NewGuid(), ext);

   6:   

   7:              CreateOnceContainerAndQueue();

   8:   

   9:              var blob = blobStorage.GetContainerReference("imagelib").GetBlockBlobReference(name);

  10:              blob.Properties.ContentType = fileBase.ContentType;

  11:              blob.UploadFromStream(fileBase.InputStream);

  12:   

  13:              // Save the blob name into the table

  14:   

  15:              using (SqlConnection conn = new SqlConnection(RoleEnvironment.GetConfigurationSettingValue("CommunityPortalEntities")))

  16:              {

  17:                  SqlCommand comm = new SqlCommand("UPDATE Tasks SET BlobName = @blobName WHERE TaskId = @TaskId", conn);

  18:                  comm.Parameters.Add(new SqlParameter("@blobName", name));

  19:                  comm.Parameters.Add(new SqlParameter("@TaskId", taskId));

  20:   

  21:                  conn.Open();

  22:                  comm.ExecuteNonQuery();

  23:              }

  24:          }

With this change, we are ready to hook up the SQL Azure based CommunityPortal database to the rest of our application, but what about the existing SSRS reports? What happens to these reports, now that the database has been moved to SQL Azure? We have two options: 1) continue to run the report on an on-premise version of SQL Server Reporting Services (SSRS) by adding the SQL Azure database as a datasource, and 2) move the reporting function to an Windows Azure hosted SSRS service instance (currently in a CTP). The benefit of the latter is obvious by now. We get to subscribe to “reporting as a service” capability without being bogged down with installing and maintaining SSRS instances ourselves. The following screenshot depicts how, using Business Intelligence Development Studio BIDS , we can deploy the existing report definition to SQL Azure Reporting Services instance. Since our database is already migrated to SQL Azure, we can easily add it as the report datasource.

Outsourcing the authentication setup

What about the ASP.NET membership database? I suppose we can also migrate it to SQL Azure. In fact, it turns out that there is a version of ASP.NET membership database install scripts that are designed to work with SQL Azure. So once we migrate the data to SQL Azure based membership database, it is straight forward to rewire our Azure hosted application to work with the new provider. While this approach works just fine, there is one potential issue. Our users do not like the idea of registering a new set of credentials to access the Community Portal. Instead, they would like to use their existing credentials such as Windows LiveID, Facebook, Yahoo! and Google to authenticate to the Community Portal. Since these credentials such as Windows Live ID allow a user to establish their identity, we commonly refer to them as identity providers, or IP. Turns out that IPs rely on a number of different underlying protocols such as OpenID, OAuth etc. Furthermore, these protocols tend to evolve constantly. The task of interacting with a number of distinct IPs seems daunting. Fortunately, Windows Azure provides a service called Access Control Service (ACS) can simplify this task. ACS can act as an intermediary between our application and various IPs. Vittorio and Wade authored an excellent article that goes through the detailed steps required to integrate our application with ACS. So I will only provide a quick summary.

• Logon to the portal.appfabriclabs.com
• Create a namespace for the Community Portal application as shown below.

• Add the Identity Providers we want to support. As shown in the screenshot below, we have selected Google and Windows Live ID as the two IPs.

• Notice that the role of our application has changed from being an IP (via the ASP.NET membership provider that was in place earlier) to being entity that relies on well-known IPs. In security parlance, our Community Portal application has become a replying party or RP. Our next step is to register Community Portal as a RP with ACS. This will allow ACS to pass us information about the authenticated users. The screenshot below illustrates how we setup Community Portal as an RP

 

• The previous step concludes the ACS setup. All we need to do is copy and paste some configuration settings that ACS has generated for us (based on the IPs and RP setup). This configuration setting needs to be plugged into the Community Portal source code. The configuration information that needs to be copied is highlighted in the screenshot below.

• Finally, inside Visual Studio we need to add ACS as our authentication mechanism. We do this by selecting “Add STS reference” menu and plugging in the configuration metadata we copied from the ACS portal, as shown in the screenshot below.

 

• Windows Identity Foundation (WIF) classes needed to interact with ACS are not already installed within the current versions of OS available on Windows Azure. To get around this limitation, we need to install the WIF update as part of the web role initialization.
• That’s it! Users will now be prompted to select an IP of their choice, as shown below:

Outsourcing the caching setup

 Up until now we have successfully migrated the task database to SQL Azure. We have also “outsourced” our  security scheme to ACS. Let us look at one last example of a building block service provided by Windows Azure Platform- caching. The on-premise version of Community Portal relies on default in-memory ASP.NET session state. The challenge with moving this default implementation to the cloud is that all web role instances are networked load balanced, so storing the state in-proc on one of the worker role instance does not help. We can get around this limitation by install caching components such as memcached on each of our web role instances.  However, it is our stated goal to  minimize the number of moving parts. Fortunately, what is now becoming a recurring theme of this blog post, we can leverage a Windows Azure Platform provided service called the AppFabric Caching Service.  The next set of steps illustrate how this can be accomplished:

• Since AppFabric Caching Service is in CTP, we first browse to Appfabric labs portal  – portal.appfabriclabs.com
• We create a new cache service namespace as shown below.

 

 

• We are done creating the cache. All we need to do is grab the configuration settings from the portal (as shown below) and plug it into the web.config of the Community Portal web project. 

• With the last step, our ASP.NET state session provider is now based on AppFabric Caching Service. We can continue to use the familiar session syntax to interact with the session state.

Summary

We have taken an on-premise version of Community Portal built using currently shipping technologies and moved it to the Windows Azure Platform. In the process  we have eliminated many moving parts of the on-premise application. The Windows Azure based version of Community Portal can now take advantage of the elasticity and scalability characteristics inherent in the platform.

Hope you found this description useful. The source code for the on-premise version can be found here. The source code for the “Azure-enabled” version can be found here. Also, if you would like to test drive Community Portal on Windows Azure – please visit http://ais.cloudapp.net  (I will leave it up and running for a few days)

Platform as a Service – When it comes to the cloud, PaaS is the point

 

Today there is a lot of talk about the different cloud-based services including Infrastructure as a Service (IaaS), Software as a Service(SaaS), Platform as a Service (PaaS)and so on. While each of the aforementioned services has its unique place, in my opinion Platform as a Service (PaaS) stands out in this mix. This is not to suggest that PaaS is somehow better than, say IaaS. This would be an improper comparison. In fact, as shown in the diagram below, PaaS builds on the capabilities offered by IaaS.

So here is my point: If you are a developer, IT shop or an ISV responsible for building, deploying and maintaining solutions, leveraging PaaS is where you reap the maximum benefits cloud computing has to offer. PaaS providers offer a comprehensive application development, runtime and hosting environment for cloud enabled applications.  PaaS simplifies the IT aspects of creating software-as-a-service applications by offering a low cost of entry, easier maintenance,  scalability and fault tolerance, enabling companies to focus on their business expertise. This is why, PaaS is seen as a game-changer in the IT world fueling innovation from the larger players including Microsoft (Windows Azure Platform), Google (Google App Engine), SalesForce (Force.com), as well as the smaller players such as Bungee Labs and Heroku .  

APPIRIO recently conducted a State of the Public Cloud survey. What was interesting about this survey is that it focused on companies (150+ mid-to-large companies in North America) who have already adopted at least one cloud application. . The survey found that 68% of these respondents planned to have a majority of their applications in the public cloud in three years. There are two concepts to note here in the key survey finding – applications and public cloud . Let us look at each one of these concepts and how they related to PaaS:

· Public Cloud – As we will see shortly, in order to provide economies of scale and elasticity of resources at a price that is attractive to small and medium businesses, PaaS providers need to maintain a massive infrastructure. The cost of setting up and maintaining such an infrastructure can only be justified if there are a large number of tenants. So it is no coincidence that almost all the major PaaS providers (including Windows Azure Platform) are based on the public cloud.

· Applications – The survey respondents also indicated that they are looking to move their applications to the cloud. This is different from taking their existing on-premise servers and moving them to a public (IaaS) or a private cloud. Doing so would not allow parts of the application to take advantage of elastic resources available in the cloud. Moving the server to IaaS platform has benefits in the form of availability of elastic virtualization. However, the benefits are limited because the various parts of the application (UI tier, business tier, etc.) cannot be individually scaled. This is why it is better to migrate the application to the cloud. In order to facilitate this migration, PaaS platforms offer application building blocks that are symmetrical to the ones available on-premise. In other words, when building cloud applications, developers can still use the same development tools and programming constructs as the ones they use when building on-premise applications.

The diagram below illustrates this concept in the context of a traditional four tier ASP.NET based web application. This application is deployed as a single virtual machine image within the on-premise data center. Moving this image to IaaS is certainly useful. It opens up the possibility to take advantage of shared pool of infrastructure resources. However, it is the PaaS platform (Windows Azure Platform in this instance) that allows each tier to scale independently. And it is not just about the elasticity in scaling (perhaps your application does not have an immediate need for it). But by mapping parts of your application to a set of pre-built application services (such as AppFabric Caching, AppFabric storage etc.) can improve fault tolerance and lower maintenance costs.

As you can see PaaS providers are well-suited to support the two aforementioned concepts (public cloud and applications). This is why PaaS is increasingly seen as such an important development going forward.

Let us take a deeper look at the benefits of PaaS with the aid of some concrete examples. Since I have hands-on experience with the Windows Azure Platform, I will reference its features to make the case for PaaS.

Server VM, Network, Storage

Even though organizations are benefiting from the advances in virtualization technology (live migration, virtualization assist processors, etc ), the overall management experience is not as seamless as they would like. These organizations have to continue to worry about creating and maintaining virtual machine images, and configuring the necessary storage and network before they can get to building and deploying their applications.

By utilizing PaaS, virtual machines, storage and the network are pre-configured by the provider. Furthermore, the PaaS providers monitor the virtual machines for failures and initiate auto-recovery when needed.

As far as the resources such as storage, compute and the network are concerned, PaaS-based applications can simply acquire them as needed and pay only for what they use,

It is helpful to see the series of steps that Windows Azure platform undertakes in order to meet the needs of an application:

· First, the application developer uploads the code (binaries) and resource requirements (# of web and middle-tier nodes, HW, memory, fire wall settings etc.);

· Based on the resource requirements, compute and network resources are then allocated appropriately. Please refer to diagram below. Windows Azure will attempt to allocate the requested number of web-tier nodes based on the resources that are available. Furthermore, it will try to place the nodes across the different racks to improve the fault tolerance.

· Then, Windows Azure creates appropriate virtual machine images by placing application specific code on top of base images and starts the virtual machines;

· It then assigns dynamic IP (DIP) addresses to the machines;

· Virtual IP addresses are allocated and mapped to DIPs; finally,

· It sets up the load balancer to route incoming client traffic appropriately.

The above diagram depicts a snapshot in time of available resources within a Windows Azure datacenter. Little blue boxes denote slots that are available. Windows Azure uses this information to dynamically allocate resources.

As you can see from the above steps, Windows Azure intelligently pulls together resources to create a custom setup that meets application-specific needs (applications can operate under the impression that there is a limitless supply of resources). Note also that all through the steps above, application developers were not expected to setup the OS, log into the machines directly or worry about IP addresses, routers and storage. Instead, the application developers are free to focus on implementing the business logic.

Patch, Service Release, New Version

Whether they are utilizing virtualization or not, organizations have to deal with changes in the form of patches, OS upgrades, etc. This is commonly the case even if the servers are placed with a “hoster”. As we saw earlier, PaaS providers are responsible for providing the OS image. Since they are the ones providing the OS image in the first place, they are also responsible for keeping them up-to date.

It is helpful to see how the Windows Azure platform performs OS upgrades:

· Windows Azure team applies patches once each month.

· In order to ensure that upgrades are performed without violating the SLA, Windows organizes the nodes that make up an application into virtual groupings called upgrade domains. Windows Azure upgrades one domain at a time – stopping all the nodes, applying the necessary patches and starting them back up.

· By stopping only the nodes running within the current upgrade domain, Windows Azure ensures that an upgrade takes place with the least possible impact to the running service.

· The underlying virtual machine image is not changed in this process thereby preserving any cached data.

As a case in point, consider the recent publicly disclosed vulnerability in ASP.NET. ASP.NET-based applications hosted on Windows Azure had the vulnerability patched for them when the Guest OS was automatically upgraded from version 1.6 to version 1.7.

Windows Azure platform recently introduced the notion of Virtual Machine (VM) role. As part of using the VM Role, users are allowed to bring their own custom virtual machine image to the cloud, instead of using an image provided by Windows Azure. This is a powerful capability that allows users to control how the virtual machine image is setup. In many ways this is akin to capability offered by IaaS platforms. But with great power comes great responsibility. Customers using the VM mode are expected to setup and maintain the OS themselves. Windows Azure does not automatically understand the health of applications running in a custom VM image.

No Assembly Required

Distributed applications by their very nature have a lot of moving parts and consequently a lot of steps are required to assemble the various components. For instance, assembly steps include installing and configuring caching components, access control components, database-tier components and so on.

PaaS greatly simplifies the assembly by providing many of these application components as ready-made services.

It is helpful to consider a few examples of application building block services offered by the Windows Azure platform:

Azure App Fabric Caching – This is a distributed in-memory cache for applications running in Windows Azure. Application developers do not need to bother with configuration, deployment or management of their cache. Applications simply provision the cache based on their needs (with the ability to dynamically adjust capacity), and only pay for what they use.

AppFabric Access Control Service – This service simplifies access control for applications hosted in Windows Azure. Instead of having to handle different access control schemes (OAuth, OpenID etc.), Windows Azure-based application can integrate with AppFabric Access Control. AppFabric Access Control service in turn brokers the integration with various access control schemes thereby greatly simplifying the task of application developers.

SQL Azure Service – This is a cloud-based relational database service available to applications hosted on Windows Azure. Application developers do not have to install, setup, patch or manage any software. High availability and fault tolerance is built-in and no physical administration is required.

There are two noteworthy things about the examples above. First, each of the aforementioned services has a corresponding on-premise equivalent. This is what makes it possible for developers to migrate their applications to the cloud. Second, even though these services are functionally and semantically equivalent, they exhibit the core characteristics of the cloud, namely elasticity and fault tolerance. To be specific, let us consider the SQL Azure service. SQL Azure supports most the T-SQL functionality available on SQL Server that is running on premise. However, SQL Azure has built-in fault tolerance (it keeps multiple copies of the database in the background) and elasticity (databases can be scaled out seamlessly). Additionally, there is no need to go though the typical setup steps such as installing the product, applying patches andsetting up back-up and recovery. Setting up a SQL Azure database is literally a matter of issuing a “create database” command.

Summary

In this post, we saw how PaaS providers offer a comprehensive application development, runtime and hosting environment for cloud enabled applications.  This greatly simplifies the IT aspects of creating software-as-a-service applications enabling companies to focus on their business expertise.