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.

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.

• 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)

Netizen (http://netizen.cloudapp.net/ is a Windows Phone 7 application (available in the marketplace for free) that brings the voting record of your congressional representative to your finger tips, directly from your mobile phone. Simply select the Member of Congress you want to follow and "flick through" their voting record. Information about each member’s voting record is stored in Windows Azure Storage and is updated daily.

But don’t just follow how your representative is voting in congress, make your voice heard. By clicking on the "Like It" button on the mobile application, you can influence your friends and neighbors about the bill through the power of social networking. For each bill, Netizen automatically provisions a Facebook page[1] dedicated to your member of congress. This page acts almost as a virtual ballot for a bill as well as a community hub where fellow constituents can gather to express their support. Pasted below are some screenshots from the application:

Not using a mobile device? No problem! Simply point your browser to the addresses listed below: To get a list of representatives for the state of Virginia, use this address:

http://netizen.cloudapp.net/NetizenService.svc/reps/VIRGINIA/atom

To view the recent votes cast by the representative from Virginia 11th district, use this address:

http://netizen.cloudapp.net/NetizenService.svc/vote/VIRGINIA-11th/atom

To view the Facebook page for the Bill H.R.4853 and Virginia 8th District, use this address:

http://netizen.cloudapp.net/H.R.359/VIRGINIA-8TH/

Screenshot #1 – Select state

Screenshot #2 – Select Representative

Screenshot #3 – “Flick through” the most recent roll call votes

Screenshot #4 –  “Virtual ballot” – Dynamically generated Facebook page,

Technical Details

Netizen combines the power of Windows Phone 7 & Windows Azure. Here is how the application works

WP7 App

Windows Phone 7 app is designed to have a small footprint. As a result, the bulk of the functionality is located inside the Azure hosted service. Here are some of key highlights:

1) The main screen (display of votes) is based on Pivot Control. Pivot Control provides a quick way to manage views. Each view (PivotItem) displays the details associated with a vote. Pivot control makes it really convenient for switching between different vote views. The Pivot control employs lazy loading to conserve resources. In addition, in order to limit the resources used, we only display the ten most recent votes.

2) Some addition performance related items include:

· Invoking garbage collection explicitly after the rebinding the pivot control.

· Storing the state in the isolated storage in order to make application resumption quicker.

· Doing all the data transformation on the server, again in order to reduce the processing foot-print on WP7.

· Keeping a close watch on the overall size of the XAP file – the current version is under 150K.

The following link provides great performance related tips:

http://msdn.microsoft.com/en-us/library/ff967560(v=VS.92).aspx

3) Since it is important to support a disconnected mode of operation, we always store the most recent data obtained from the Azure service into isolated storage. Another possibility is use of Sync Framework 4.0.

4) We experimented with embedding the browser control for web-based logins. It is possible for the web page to callback into the Silverlight code.

5) All the Netizen Azure service methods are based on REST. This made it quite easy to use the WebClient class to access them. A better alternative would have been the use reactive extensions as it would have made the code a bit cleaner.

6) One gotcha that we ran into was based on our decision to use SyndicationFeed as the data format. This was based on our desire to allow users to access the voting records
via their favorite feed readers (in addition to the WP7 app). In order to process the returned SyndicationFeed type, we had to explicitly add a reference to System.ServiceModel.Syndication. Here is the relevant code:

   1: XmlReader reader = XmlReader.Create(new StringReader(xmlContent));

   2: SyndicationFeed sFeed = SyndicationFeed.Load(reader);

   3:                    var entries = from en in sFeed.Items.Take(MaxNumberOfItemsPerFeed)

   4:                                  select en;

   5:                    foreach (var en in entries)

   6:                    {

   7:                        var x = en;

   8:                        SyndicationContent sc = x.Content;

   9:                        XmlSyndicationContent xsc;

  10:                       if (x.Content.Type == "text/xml" || x.Content.Type == "xml")

  11:                       {

  12:                           xsc = (XmlSyndicationContent)x.Content;

  13:                           VoteDetails vds = xsc.ReadContent<VoteDetails>();

  14:                           Votes.Add(vds);

  15:                       }

  16:                 }

Where the class VoteDetails is defined as shown below:

   1: [DataContract(Namespace = "http://schemas.datacontract.org/2004/07/Netizen.Service.Entities")]

   2:         public class VoteDetails

   3:         {

   4:             [DataMember]

   5:             public string BillID { get; set; }

   6:             [DataMember]

   7:             public string Date { get; set; }

   8:             [DataMember]

   9:             public string Democratic_AYEs { get; set; }

  10:             [DataMember]

  11:             public string Democratic_NAYs { get; set; }

  12:             [DataMember]

  13:             public string Description { get; set; }

  14:             [DataMember]

  15:             public string Question { get; set; }

  16:             [DataMember]

  17:             public string Republican_AYEs { get; set; }

  18:             [DataMember]

  19:             public string Republican_NAYs { get; set; }

  20:             [DataMember]

  21:             public string Result { get; set; }

  22:             [DataMember]

  23:             public string Roll { get; set; }

  24:             [DataMember]

  25:             public string Vote { get; set; }

  26:         }

Azure Service

As stated earlier, the bulk of processing resides within the Azure based service.

This includes the following:

· A WCF/ REST service hosted on Windows Azure (x-small instance) that exposes the voting record as an RSS/ATOM feed. Here is what the WCF contract looks like.

   1: namespace Netizen.Contract

   2: {

   3:     [ServiceContract]

   4:     [ServiceKnownType(typeof(Atom10FeedFormatter))]

   5:     [ServiceKnownType(typeof(Rss20FeedFormatter))]

   6:     public interface INetizenService

   7:     {

   8:  

   9:         [OperationContract]

  10:         [WebGet(UriTemplate = "rep/{zip}-{zipFour}")]

  11:         string GetRepresentative(string zip, string zipFour);

  12:  

  13:         [OperationContract]

  14:         [WebGet(UriTemplate = "reps/{state}/{feedType}")]

  15:         SyndicationFeedFormatter GetRepresentatives(string state, 

  16: ng feedType);

  17:  

  18:  

  19:         [OperationContract]

  20:         [WebGet(UriTemplate = "vote/{repID}/{feedType}")]

  21:         SyndicationFeedFormatter GetVotes(string repID, string feedType);

  22:  

  23:         [OperationContract]

  24:         [WebInvoke(UriTemplate =

  25: bscribe/{state}/{district}/{notificationUri}")]

  26:         void SetSubscription(string state, string district, 

  27: ng notificationUri);

  28:  

  29:     }

  30: }

  31:  

All the data is stored in Azure tables. A batch program is used to obtain the congressional voting record from Office of the Clerk of the U.S. House of Representatives and stored in Azure Tables. Data is appropriately transformed to make sure that Azure Table queries are efficient.

· Since the batch job runs once a day, it did not make sense to have dedicated worker role just loading data. Instead, we rely on a concept of “dynamic worker” within the web role job. We launch a console based data loader executable using the concept of startup tasks.

2. A MVC2 based web application hosted on Windows Azure (co-located within the same worker) Is used to dynamically generate Open Graph API  pages (that are deemed as Facebook Pages).

http://netizen.cloudapp.net/H.R.359/VIRGINIA-8TH/

[1] A page hosted on our site that includes Open Graph tags, making it equivalent to a Facebook Page

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.

This blog post is about the evolution of Microsoft’s application server – a collection of products including IIS and .NET framework libraries such as WCF and WF. Over the last few releases Microsoft has added 1) runtime container and activation service, via WAS; 2) multi-protocol support that goes beyond Http, via IIS 7.0; and 3) manageability extensions and caching, via AppFabric. Some of these enhancements overlap with the capabilities offered by Microsoft’s flagship integration server, BizTalk. BizTalk is well known for its robust hosting and integration capabilities. This overlap has stirred conversation in blogs and news stories over the last several months.

My goal in this post is to step back and look into some of the reasons causing application and integration servers to grow closer; we will do a side-by-side comparison of a scenario that is right in the middle of the overlap which I alluded to earlier. Additionally, as pure conjecture on my part, we will take a look at an approach to making them live together closely.

Application and Integration Server

Application servers are well known for the capabilities that enable hosting of application logic. As you would expect, they offer capabilities such as robust hosting – auto start, load balancing, fault tolerance etc. Integration servers are well known for enabling communication with external systems and, as you would expect, offer support for various message exchange patterns, guaranteed delivery, and family of adapters to connect to desperate systems and so on.

Note -as stated earlier, BizTalk is more than a typical integration server. The diagram below is intended to be more generic and depicts typical workloads of application and integration servers.

With emphasis on composite applications, application designers are increasingly looking for ways to combine the best of the capabilities offered by application and integration server. For example, they want to deploy a business service (exposed as a SOAP endpoint) and at the same time, expose it as a service endpoint that is consumable as an external system via MSMQ. Conversely, they want to expose integration endpoints that have low latency requirements and don’t necessarily need features such as guaranteed delivery and business activity monitoring.

Another factor that is driving application and integration servers closer is the move towards the cloud. Traditional on-premise based application logic is being refactored to take advantage of cloud based services such as storage, compute and access services. This is also placing a demand for integration capabilities to be added to application servers.

Not surprisingly, Microsoft’s recent announcements suggest that the line between AppFabric and BizTalk is being blurred. For instance, the BizTalk team has stated publicly that they are looking to build the next generation of BizTalk on top of AppFabric – http://www.microsoftpdc.com/2009/SVR15.

Current Dilemma

If you are architecting an enterprise application today, should you just move all your integration logic to AppFabric? There are a number of reasons why you would be tempted to do this, including 1) AppFabric is part of the OS; 2) most integration is now SOA/ WS based anyways, thus reducing the need for custom adapters; 3) operational setup and maintenance cost of running an AppFabric WebFarm is likely lower than a BizTalk farm; and 4) development of components is more approachable to a .NET developer who does not have prior knowledge of BizTalk. However, if you go down in this direction, be aware that there will be some features that will not be available. To better understand what is available and what is not available, let us use a scenario that is well supported by both – hosting a WCF endpoint. The following table compares the hosting a WCF endpoint in BizTalk and AppFabric.

WCF hosted Inside BizTalk	WCF hosted inside App Fabric
Binding flexibility – support for custom WCF configuration	Binding flexibility – support for custom WCF configuration
Load balanced, fault tolerant setup · Central administration covers all aspects. For example, a change to the WCF binding needs to be applied to a single location (port setting dialog).	Load balanced, fault tolerant setup · Central administration for tracking purposes only. A change to a WCF binding needs to be replicated to all nodes using tools such as msdeploy. http://download.microsoft.com/download/3/1/C/31CED722-2E5F-48D6-96B1-E73AAFD9873F/AppFabricWebFarm.docx
Common tracking database	Common tracking database
Tooling to review tracked instances · Tooling is somewhat dated –BAM portal.	Tooling to review tracked instances · More modern tooling.
Cross – cutting concerns – exception handling, BAM, pre and post processing (formatting etc.) · Advanced support in the form of suspended message queue, BAM portal.	Cross – cutting concerns – exception handling, BAM, pre and post processing (Formatting etc.) · Not as advanced as BTS yet.
Guaranteed delivery	No guaranteed delivery (except when provided by the transport such as msmq)
Better suited for async message exchange. Request /Response for low latency scenarios are not easily handled.	Better support for different message exchange patterns – Request/Response, Asynchronous.
Extensibility points for transforming incoming and outgoing messages · Pipeline components (, EDI, AS2, MIME, etc.) · Mapper · Flat File Parser	Extensibility points for transforming incoming and outgoing messages as defined by WCF · Custom Channels
Business logic is baked into a set of code and configuration components spread across the system · Custom pipeline component · Receive and send port definition · Custom mapper · Orchestration This setup allows flexibility in handling changes. For example, a new message decoder can be added for incoming messages, by simply adding a custom decoder step in the receive pipeline.	Business logic is encapsulated into the body of method (of course, factored appropriately into a class libraries etc.). This setup is makes it easy to single step through the code. But this also means that every aspect of the logic manifests itself as code. In essence, you need to roll out a new version of binary to make a change.
Large message handling · Every message in BizTalk by default is routed via the message box. This makes it a challenge to handle large messages. However, there are well known workarounds for this. One of them is described in detail by Paolo http://blogs.msdn.com/b/paolos/archive/2010/05/25/large-message-transfer-with-wcf-adapters-part-1.aspx.	Large message handling
Type safety · WCF adapters use un-typed contracts for receiving messages. This allows it to receive any type of message.	Type safety · Contracts can be typed and un-typed
No built-in caching	Caching
Secure Storage Service(SSS) to secure store credentials	No equivalent capability

What can we expect next?

The latest release of BizTalk 2010 is already bridging the gap between the two products. For instance, AppFabric connect feature of BizTalk 2010 offers ways to leverage BizTalk capabilities inside AppFabric hosted programs. Specifically:

1) Ability to leverage the BizTalk mapping capability inside a WF program using the Mapper activity.

2) Ability to generate WF activities that invoke operations on WCF LOB adapters provided by BizTalk.

For more information see – http://blogs.msdn.com/b/biztalk_server_team_blog/archive/2010/06/09/biztalk-appfabric-an-introduction.aspx

I expect this trend to continue, in fact, I envision that a future version of App Fabric would look something like the diagram below (again, this is pure conjecture on my part). As you can see, the BizTalk provided capabilities will be moved into AppFabric (shown in red). This will allow WCF endpoints to take advantage of guaranteed delivery, as well as, the configuration flexibility offered by BizTalk ports (pipeline components, mapper etc.).

Call to Action

It is clear that AppFabric and BizTalk are moving closer together. In future, we can expect to have access to capabilities offered by both, rather than choosing between them.

Messaging, with its defining characteristics including adapters, reliable communication and mediation, is generally accepted as the preferred way to connect disparate systems (look no further than Gregor Hohpe’s seminal book on Enterprise Integration Patterns for more on messaging). As we have seen in this post, BizTalk has built-in support for messaging. This is why it is recommended that BizTalk be considered for most integration scenarios

AppFabric should be considered for hosting most of the application logic. Microsoft is making strategic investment in AppFabric to not only to bring advanced management and robust hosting capabilities but also as a way to seamlessly enable application migration between on-premise and the cloud based deployments (commonly referred to as Server / Service symmetry).

Over the last two years, SharePoint has increasingly been established as an enterprise platform  in organizations worldwide. Now, with the advent of SharePoint 2010, organizations have the ability to develop, host and manage custom services (as in SOA services) within SharePoint.

This new capability in SharePoint 2010 is  part of Service Application Framework (SAF) .  SAF  allows out of the box services ( such as search and managed metadata), as well as, custom developed services to be hosted on the SharePoint infrastructure. In this post, we will take a deeper look at SAF, explore the benefits it offers and discuss examples of services that can take advantage SAF.

Note – While SAF is new in SharePoint 2010, the Excel Services capability in MOSS is similar in concept. Excel Services introduced the notion of moving the processing out to a different application pool ( possibly to different machine altogether )

Services  Platform

SOA done right can bring a number of benefits to an organization including software reuse, better alignment with business processes and lower cost and  agile development cycles. However, achieving these benefits requires building on top of a platform that provides a number of capabilities including:

1) Governance and Registry – Capability to catalog and publish access to the available services.

2) Load Balancing and High Availability – Capability to make the services fault tolerant and resilient to varying loads.

3) Administration -  Capability to centrally manage services including configuration, security, leverage backup and restore functionality.

4) Security – Capability to secure services and set the security context.

5) Tooling  – Capability to author business logic by orchestrating different services through mashups and workflows.

For more information on  SOA terms and concepts please refer  to OASIS Reference Model for Service Oriented  Architecture at  http://docs.oasisopen.org/soa-rm/v1.0/

Services Application Framework (SAF)

As stated earlier, the latest version of SharePoint introduces the notion of Service Application Framework (SAF). SAF allows creation of custom services that can be hosted within SharePoint. These services can then be consumed by applications within  SharePoint. In fact, SAF forms the basis for all the core SharePoint services including Search, Managed Metadata and Excel Services.

Let us take a detailed look at SAF Object Model.

The diagram below depicts the overall SAF object model. SPFarm and SPServer classes have been available in the previous versions as well – SPFarm represents a SharePoint server farm while SPServer represents a server within the farm. SAF adds a few new classes to the mix. SPService represents a service (such as the Search service ) that is registered within a SharePoint farm. SPServiceInstance represents an instance of the service installed on an application server ( think of a service that is installed on more than one application server within the SharePoint farm). SPServiceApplication and SPServiceApplicationProxy represent logical endpoints (logical because they abstract the notion of multiple services instances from the consumers of the service). The fact that service is broken into distinct Application and ApplicationProxy classes, is a key concept that allows  services to take advantage of a flexible deployment , auto load-balancing and fault-tolerance.

Now that we have seen the key classes in the SAF object model we are ready to look into the various pieces required for creating a custom service.  The diagram below depicts the different pieces involved. 

Let us start from the bottom of the stack and look at the SQL Server tier.  Services rely on SharePoint configuration database for storing any settings. Additionally, it is possible to provision  a custom database ( separate from the content DB) as a persistence store.  Next is the application server tier. This is where the all the components that make up the service are installed. For instance, executables, Windows services and class libraries etc.  A WCF contract is the easiest way to expose the service endpoint. While SAF does not preclude the use of non-WCF stacks, using WCF offers a number of advantages such as the built-in service context, load balancer etc. Finally, let us look at the Web Front End. As stated earlier, a custom service is typically consumed by SharePoint Web Front End (WFE) such as a WebPart. WFE is where you would typically install the ServiceApplication proxy. The proxy abstracts the fact that a service can be installed on multiple application servers. Service consumers invoke the service via the proxy. The proxy, in turn,  figures out which application server to go to, by leveraging the built-in load balancer.

More concretely, implementing a custom service involves following high level steps:

1) Define the WCF endpoint (address, contract and binding) where the custom service will be hosted within the SharePoint farm.

2) Implement  the business logic and package them in the form of class libraries, executables, windows services.

3) Implement the SAF classes

Let us assume that we are building a service called Custom Service. Let us further assume that this service utilizes the WCF as its  communication stack and is hosted in IIS (note again that we are not required to use WCF/IIS)

Building Custom Service will require that we implement the following SAF classes:

CustomService – This class inherits from the SPIisWebService and is used to register the service with the farm. As part of inheriting from SPIisWebService we are required to provide installation steps, links to ASPX pages that are surfaced within the SharePoint central administration.

CustomServiceInstance- This class inherits from the SPIisWebServiceInstance and is used to register the service with an application server.

CustomServiceApplication- This class inherits from the SPIisWebServiceApplication and is used to register a logical endpoint. This class also encapsulated all the configuration settings associated with a service. For instance,   as part of inheriting from SPIisWebServiceApplication , we are required to implement a properties such as VirtualPath that tells SharePoint the URI of the service endpoint.

CustomServiceApplicationProxy- This class inherits from the SPIisWebServiceApplicationProxy and represents a connection to CustomServiceApplication.

4) Determine if a custom persistence store is required or not. If a custom persistence store is needed, we can have it  created as part of  the service application provisioning step and include it in backup and restore operation.

For more information on steps involved in building a custom service, including sample code, please refer DTaylor’s excellent SAF blog at http://blogs.msdn.com/b/dtaylor/

SharePoint as a Services  Platform

Now, armed with an understanding of  SAF, we are ready to look at how SAF enables SharePoint to be leveraged as a services platform.

1) Administration – Once the service has been registered with the farm, it can be managed via the SharePoint Central Administration. The following diagram depicts the central administration screen to add a new service  and manage an existing service.

2) Governance and Registry – SharePoint provides a topology service that allows SharePoint administrators to discover published services available within a farm. Typically, it is used by administrators to connect to services from remote farms. The following diagram depicts the UI for publishing an existing service via the topology service.

3) Load Balancing and High Availability – SAF allows multiple service deployment topologies to meet high load and availability requirements. The following diagrams depicts two different topologies.

This setup relies on a dedicated services farm (Farm 2)topology. Farm1 and Farm 3 subscribe to service offered by Farm 2. 

This setup depicts a single farm configuration. For load balancing purposes, the custom service is installed on three out of the four application servers in the farm. The service proxy is installed on both the WFEs.

4) Security – SharePoint supports claims-based authentication using Windows Identity Foundation (WIF). Custom services can take advantage of this capability to delegate user permissions to services. In other words, custom services can make authorization decisions based on delegated identity of the user involved( even if the communication is over multiple hops – across farms, for instance) 

5) Tooling – Tools such as SharePoint Designer,  Visio and third party tools such as Nyntex make it easy to create mashups by utilizing  OOB and custom services.

Custom Service Scenarios

Let us look at a couple of scenarios where developing custom services would be beneficial.

Integrate external applications into SharePoint

In this scenario, a customer has an existing proprietary .NET based task tracking application that they would like to  integrate into their SharePoint farm. In doing so, they are seeking to leverage the collaboration, maintenance and provisioning capabilities offered by SharePoint.

Using SAF they could package the backend code as a ServiceApplication that can be installed on one or more application servers. In addition, they would need to develop an application proxy that will be installed on WFEs.

The benefit of packaging the task tracking system as a custom SharePoint service is that the users can seamlessly use it in conjunction with other SharePoint capabilities such as authentication. In addition, the task tracking system is now managed within the unified governance model for the SharePoint farm and can thereby leverage its fault tolerance, backup and restore capabilities.

Externalize compute intensive processing

In this scenario, a customer requires elastic computing capability to handle high volumes of calculation requests. Rather than perform these calculations within the SharePoint infrastructure ( by adding application servers), it may make sense to take advantage of a cloud platform such as Windows Azure.

Using SAF, they could develop just the ServiceApplicationProxy that  simply forwards the incoming requests to Windows Azure. Note that ServiceApplication is not needed since the backend computation is happening within Windows Azure.

The benefit of abstracting the invocation of Windows Azure hosted calculations, as custom service is that customers can now seamlessly access it, not unlike how they would access the out of the box services such as search. So, for instance, consumers  can continue to use claims based scheme to invoke the service. Another benefit of this approach is that the configuration information, such as Windows Azure project details, can be maintained in the SharePoint configuration database.  

Summary

In this post, we have seen how SharePoint Service Framework (SAF) enables custom services to be developed, hosted and managed within SharePoint 2010. By taking advantage of this capability, organizations can develop new functionality and expose  existing software assets, as services that are managed within the SharePoint infrastructure. It is also expected that  ISVs will take advantage of this capability to expose their offerings as services within SharePoint.

you are about to embark on a distributed application development project and are wondering how you can leverage the Windows Azure Platform. Should  you invest in private cloud, move your application to the public cloud, choose a hydrid approach or keep the application on-premise?   In this blog post, I will try to briefly describe each model and provide some commentary on the impact each of the aforementioned model can have on development and operations.

Before we begin, let us sketch a fairly common  multi-tier application architecture. We will use it through the course of this post.  Along the name of each layer, I have appended, in parenthesis, a few implementation choices. For instance the data layer may be implemented using SQL, Analysis Service, and Master Data Services (MDS).

Private Cloud

The term private cloud has been used to describe two very different models. The first is the ability to run a variant of Windows Azure in a customer’s datacenter. While at least one Microsoft executive has hinted at this possibility, it is highly unlikely that we will see this anytime soon.

The second model refers to the techniques like virtualization, automated management, and utility-billing models, within their own data centers. Microsoft has been increasingly talking about toolkits such Dynamic Datacenter Toolkit  that will allow IT managers to implement the aforementioned cloud computing concepts, in their data centers. This is different from running a cloud OS on-premise. 

In addition to the two private cloud models described above, there is also the notion of Virtual Private Cloud wherein a cloud provider will segregate a bunch of machines in its data center and dedicate them for a given customer. While vendors such as Amazon have talked about this option quite a bit, Microsoft has not announced anything significant in this area.

Impact on Development and Operations

1) Development and operational impact will depend on the degree to which an organization commits to building a private cloud. If the private cloud is primarily designed to offer Infrastructure as a Service (IaaS), the impact on development is minimal. In other words, the development effort is not very different from a traditional on-premise development.

2) Setting up a private cloud requires significant investment and careful planning and is therefore only recommended for very large enterprises with special security needs.

Public Cloud

Public cloud refers to the approach wherein the entire application is hosted on the Windows Azure platform. For our candidate architecture it would mean that all layers of architecture are in the cloud. While this is the most cost effective model, there are a number of limitations associated with it. The ability to install custom software is limited unless one can use xcopy to deploy third-party applications. All of the Azure compute instances  run the same base image (64 bit Windows Server, .NET 3.5 SP1). Microsoft has announced that future versions of the Azure platform will allow customers to create their own base images. Another limitation is the SQL Server functionality that is available as part of SQL Azure. For instance, MDS is not available with SQL Azure today. Additionally, SQL Azure databases are limited to a  maximum size of 50 GB.

Impact on Development and Operations

1) The design should adhere to a patterns including multi-tenancy, statelessness, and ability to dynamically handle the changes to the configuration (adding web front end nodes with increase in load).

2) Limits imposed by the Windows Azure Platform must be taken into account. For example, the data layer will need to utilize some sort of sharding  scheme to get around SQL Azure max size limits.

3) Public cloud option offers other significant advantages such as  automated service management, fault detection and notification that can potentially reduce the operational cost.

4) Upfront capital expenditure is replaced with ongoing operational expenditure based on the resource used.

Hybrid Cloud

Hybrid cloud refers to a style of cloud computing that combines functionality available in the cloud with the resources based on on-premise. Such an arrangement could be motivated by special security requirement (such as the Payment Card Industry security standards)for data.   For our proposed architecture, one scenario would be to have the UI and business services layer hosted in the cloud, while the data layer resides on-premise. Technologies such as Azure AppFabric ServiceBus and Project Sydney can be used to bridge the connection between cloud and on-premise datacenter.

Impact on Development and Operations

1)The design should adhere to a patterns including multi-tenancy, statelessness, and the ability to  handle changes to the configuration dynamically(i.e., ability to add additional web front ends to handle higher load).

2) Application design will need to compensate for the latency as a result of the data layer being remote. For instance, a caching layer may need to be introduced.

3) The operations team will need to plan, review, and setup adequate trust between the Azure and the on-premise data center.

4) A scalable / robust connected infrastructure between Windows Azure and the on-premise data center needs to be available.

5) IT will need to evaluate the impact on security, compliance, and availability.

Cloud Ready Design

Perhaps you are not ready for any of the aforementioned cloud options. In this instance, you can consider designing your application in a manner that will allow you to leverage the cloud in the future.  The “server-services" symmetry depicted in the diagram below exemplifies this approach. It illustrates how Microsoft plans to align the building blocks across its server OS (Windows Server 2008 and beyond) with the “Azure OS”. A good example of the overlap between server and services is AppFabric Caching -  According to Gopal Kavivaya[1], the underlying architecture of velocity is based on data fabric technology that powers SQL Azure.

Impact on Development and Operations

1) Utilize existing management tools such as System Center that are being refactored to work with the on-premise, as well as, Azure based applications.

2) Understand and leverage the App Fabric as new services become available.

3) Be cognizant of the differences between the SQL Azure and SQL Server running on-premise and avoid large monolithic database instances, as well as, features such as CLR and Service Broker that may not be immediately available in SQL Azure.

4) Avoid relying on special security privileges, file system or registry access etc. that will not be available when executing on Windows Azure.

[1] http://channel9.msdn.com/pdc2008/BB03/

Live Demo  http://ais.cloudapp.net  **

** To limit  the cost of hosting this demo application, the availability is limited to  regular business hours -  9:00 am to 5:00 pm EST. An on-premise  utility, based on Windows Azure Service Management cmdlets, is used automate the creation and removal  of this application.

 [ Readers who are not already familiar with Windows Azure concepts may find it useful to review this first ]

This project was motivated by an article by Christian Stitch:   In his article, Christian Stitch describes an approach for financial option valuation implemented with Monte Carlo simulation using Excel Services. Of course, with Windows Azure, we have now  easy access to  highly elastic computational capability. This prompted me to take  Christian’s idea and refactor the code to run on the Windows Azure Platform.

Monte Carlo Simulations

You can read more about Monte Carlo Simulation on the Wikipedia page here.  But here is an explanation from Christian’s article that I found succinct and useful: 

“Monte Carlo simulations are extremely useful in those cases where no closed form solutions to a problem exist. In some of those cases approximations to the solution exist; however, often the approximations do not have sufficient accuracy over the entire range. The power of Monte Carlo simulations becomes obvious when the underlying distributions do not have an analytical solution. Monte Carlo simulations are extensively used in the physical and life sciences, engineering, financial modeling and many other areas.”

It is also important to note that there is no single Monte Carlo method of algorithm.  For this project I follow these steps:

I cannot claim it to be an act of volition, but, over the last three years I have found myself involved with building software designed to allow the business users to create the programs they need. I now have a somewhat presumptuous name for this approach – Higher Order Software Development. This approach is similar to the composite application site wherein applications are assembled using existing software assets. The difference, however, is that composite applications such as mashups are about assembling assets that have been built independently. Higher order software development is about software building blocks, designed from the ground-up, to allow business users to “develop”. In the last few years, many approaches including BPM (business process management) have espoused empowering the end-users. Even though BPM systems have been successful in improving the process agility, they have fallen short of making software development end-user ready. This is mainly because the BPM tools are designed to address a broad set of application scenarios, and in most instances, BPM offerings represent a collection of tools (workflow designer, rules engines, modeling, and so on). This has inadvertently raised the level of complexity, thus making it harder for end-users to participate. On the other hand, higher order software development has a much narrower focus — it is about solving a specific business problem within a given business domain. This approach has been made possible because of the rise in the level of abstractions available within the development platform itself. As we will discuss shortly, platforms such as SharePoint have served as a catalyst for higher order software development. 

Why is this important?  First, business users know the requirements the best. Unfortunately, most business users are not very good at communicating them – hence the famous phrase “I will not know what I want until I see it working”. Furthermore, a portion of the requirements are invariably lost in translation, as they are conveyed to development teams. Second, rather than learn new interfaces, business users want to continue to work with the tools they are already familiar with. What could be better than enabling the business users to create programs using familiar tools like Microsoft Office? Third, IT departments, already backed up in supporting existing operational systems, seldom have the resources to take on new application development projects.  Thus, empowering the business users to build their own software may be the only real way to scale and enable the business to adapt/react quickly to external market forces.  Since business users are directly involved in building, the cost and scope of development can be more efficiently managed. Business users are in a much better position to respond to questions such as – “Do we really need this feature? Is the customization really needed, or will the out-of-the box functionality do?”  Last, but not least, unlocking the true potential of IT and effectively competing in the next generation of business cycles will require a greater ability to adjust and change software systems cost effectively. By evolving how programs are put together, businesses can implement a process of continuous improvement over time.

For the remaining portion of this post, I will describe four concrete examples of applications to which we have applied this paradigm.

Example #1: Custom Calculation Engine in the Professional Services Industry

A common requirement in this domain is to implement calculations/reports that adhere to the Financial Accounting Standards Board (FASB) standards. These types of reports are often large and complex. The calculations in the reports are specific to a geographical region, so a multi-national company needs to implement different versions of these calculations.  Furthermore, over time these calculations have to be adjusted to comply with changing laws. Traditionally these calculations have been implemented using custom code, and, as a result, suffer from the challenges outlined above, including: the high cost of development and maintenance, requirements being lost in translation, the lack of traceability, and the lack of a robust mechanism for making a quick change to a calculation in response to  a change in a standard. In a nutshell, the analysts needed a flexible calculation engine tool that makes it easy to develop and maintain the calculations, and at the same time, provides the necessary robustness and scalability.

Here is a quick overview of the Excel Services based solution we developed. For an introduction to Excel Services please refer to the MSDN Magazine article – http://msdn.microsoft.com/en-us/magazine/cc163374.aspx. We used XSDs to capture all the input and output data elements needed for implementing a given calculation.  Using a custom Excel pre-compiler, we translated the XSD into named ranges. For example, the generated template workbook has three sheets – one each for input, output, and calculation. Analysts could then use the generated template workbooks to develop the algorithms.  As long as they worked within the contract – as defined in input, output and calculation sheets – they could use any Excel functions. Once the workbook was developed and tested, they placed the workbook into an Excel Services trusted folder for execution. To support high scalability, we used a cluster of Excel Services nodes. The following figure shows the basic architecture:

Who built what

Development Team Built a framework based Excel Services Business Users Developed the calculation logic using Excel

As you can see from above example, we built the software building blocks using Excel Services, which in turn enabled the analysts to implement the calculations as needed. 

Example #2: Incident Management System for Law Enforcement Agencies

Law enforcement agencies are looking for ways to improve the processes surrounding incident reporting and management. Managing an incident entails gathering a variety of information to aid in the investigation, including documentation about the case (date, location, type of incident, summaries from eye witnesses, photographs, and evidence), as well as information about contacts and sources who can provide more information. In addition to providing an intuitive repository for this information, the system should enable an agency-wide collaborative work amongst the law enforcement personnel assigned to work on the cases. This requires the ability to assign and track tasks, initiate process steps such as review and approval, provide access to a group calendar and messaging, record the status of the case (open, active, closed, and archived), and generate centralized reports (such as the status of all cases or assignments). Information about cases also needs to be searchable and shareable with extra-agency organizations as necessary.

In addition to the high-level functional requirements, incident management systems need to be highly secure and be able to protect confidential information. This typically implies a number of requirements to control access to information based on the role, organization, and level of data sensitivity. There are also typically requirements for these types of systems to support auditing and policy compliance monitoring, tracking of email correspondence, support of e-discovery requests, and enforcement of agency governance rules.

The above requirements highlight the need to store large and variable amount of information about the case in one “container.”  The different document types that make up the case can have unique metadata and lifecycles associated with them. Law enforcement personnel working on the case need the flexibility to add notes to cases, include ad hoc documents, and store different versions of a document. They also need to be able to initiate a number of workflows such as approval and disposition for individual documents or a group of documents.  These workflows can be pre-defined or dynamic in nature. 

We decided to build this system on the SharePoint platform. We provisioned the appropriate container (site collection, site, document library) for a case. The provisioned container is based on a pre-defined blueprint we built. The blueprint includes document types, folder structure, web parts and workflows. Users are then able to customize the provisioned container as needed, including changing the folder structure, adding new ad hoc workflows, and installing additional web parts for reports and data visualization. A nice side-benefit of using a SharePoint based container is the built-in support for archival and restoration of cases.

Snapshot of SharePoint based Incident Reporting System

Who built what

Development Team Built SharePoint artifacts including site definitions, web parts, VS.NET based workflows Business Users Provisioned the site, customized the site, content types, adhoc workflows, custom lists and views

As you can see from above example, we built the software building blocks using the SharePoint platform that in turn enabled the law enforcement officials to effectively manage the incidents.

Example #3: Data Analysis Tool for the Telecommunication Industry

Network optimization engineers often need to convert vast amount of raw network performance data into useful data visualizations and data products that can assist them in identifying network performance bottlenecks. The goal is to allow non-programmers (in this instance, network engineers) to visually define complex multi-step algorithms  that specify the steps and control dependencies for analysis of raw data.  

The key requirement is that of flexibility and ease of use needed by network engineer to define custom data processing workflow steps. A solution that is completely built by IT would be too expensive and at the same time not be able to accord the flexibility needed in this instance.

We decided to build the solution using Windows Workflow Foundation (WF). The WF Designer tools provides the network engineers with useful and flexible way to author the data processing algorithms.  To make it easier for network engineers to author the workflows, we developed a set of custom domain specific activities. A lot of attention was devoted to making the workflow authoring experience as simple as possible.

Once the workflows are defined, they are executed asynchronously and results are made available for further analysis. The following diagram depicts the user interface for authoring the workflows.

Snapshot of Workflow Foundation based designer used by network engineers

Who built what

Development Team Built a framework to host WF programs, developed domain specific WF activities, customized the WF designer to make it business-user ready Business Users Developed custom workflows

As you can see from above example, by building a set of building blocks in the form of custom workflow activities,  we were able allow network engineers to develop the programs that allowed them to analyze vast amounts of raw data.

Example #4: Management of Policy Data in the Insurance Domain

A common requirement in the property and casualty (P&C) Insurance industry is to store and retrieve “snapshots” of a customer policy or contract, such as an automobile policy or a homeowners policy, as it existed at any given point in time in the past.  Clearly, there are a number of ways to implement this functionality. However, a key requirement is to be able to retrieve the policy snapshot very quickly – typically a sub-second response time is expected. Given the millions of rows worth of historical data that is common for such systems, it would be hard to retrieve a specific version of the policy data dynamically. An alternative approach is to pre-generate templates for the snapshots and tradeoff disk space in favor of response time. In other words, accept the additional cost of storing the entire policy snapshot for every change to the policy.   In addition to the response time requirement, there are two other  distinct requirements related to the historical data.  The first requirement is to generate reports for verification of compliance with various state laws. As you can imagine, compliance based reports tend to vary quite a bit, based on the laws of each state (within the US). The second requirement is to allow end-users to mine the historical data for interesting patterns, for instance: Why is there a higher rate of customer attrition in a given county over others?  What types of changes are more common in a given state?

The key aspect of this scenario is that while there is a need to support high performing historical queries, there is also a competing need for flexibility in reporting and data mining. In short, the system needs to allow self-service business intelligence (BI) for the end-users.

Let us now take a look at the solution we decided to build:  We used SQL Server Analysis Services (SSAS) based OLAP (online analytic processing) cube as an application building block.   To store the policy data snapshots we populated a OLAP cube in real time. The OLAP model we developed is depicted in the diagram below.  The dimensions (dimensions are reference information about the data) are obvious ones including customer, geography, and time. The interesting aspect of this model are the fact tables (facts are generally the numeric aspects of the transaction data). Since we are dealing with events (change in policy address, for example) as opposed to a classic business transaction that involves numbers, we ended up creating a “factless” that captures a log of all events on a policy. Additionally, to be able to retrieve the policy as of a certain date quickly, we maintain another “factless” table that captures the snapshot a given policy following any change to it.

:

Once the OLAP cube is in place, analysts are able to perform queries using a tool such as Excel, as shown in the diagram below.

Who built what

Development Team Organized the data in OLAP structure, developed a scheme to populate the OLAP structure in real time Business Users Developed the queries to respond to historization related requests, built adhoc reports to meet compliance and regulatory needs

Readers who are familiar with BI (business intelligence) systems are probably wondering how the solution described above is different from a traditional BI solution. Furthermore, why do I see this as an example of higher order solution development? While this is indeed a BI-based solution, it is a different from a traditional BI Data Warehouse / Data Mart in several important ways. First, the dimensional model, with the factless and snapshot tables, is different from a traditional BI data warehouse. In this instance, the data model has been designed in a manner to promote “assembly” by business users. Secondly, the OLAP cube is very much part of the application architecture in the sense that  queries from the UI (user interface) layer are serviced by the OLAP cube in near real-time. This also unlike a traditional BI system which is usually a distinct system designed to serve as  a decision support system. Finally, by combining a traditional relational database with the OLAP cube, we are able to offer the notion of a composeable data services layer.

As you can see from above example, the OLAP based building blocks built by the development team enabled business users to perform dynamic queries to respond to historization requests from the client and build adhoc reports to meet compliance and regulatory needs.

In summary, with all of the above examples, we built the software tools that allowed the business-users to create the program they need.  This approach has a number of benefits including reduced cost of development and increased agility to adjust and change software systems.