Behind the Curtain of Sitecore on Azure

Sitecore provides several different options for hosting Sitecore in Azure including an infrastructure as a service offering (IaaS) and two platform as a service (PaaS) offerings. This blog will focus on my experience with one of the PaaS offerings, specifically the Sitecore Azure module. I'm assuming you have setup Sitecore on Azure in your environment and have at least a light understanding of what the module does. You can find install instructions here. Note: This Sitecore Azure module referenced in this blog is Sitecore Azure 8.0 rev. 150522.

The Sitecore Azure module does one thing very well and that is making deploying Sitecore to Azure very simple. Sitecore's Azure module provides a point and click interface for deploying an on premise Sitecore environment to the cloud. It offers several features such as separated Staging and Production environments, the ability to scale and deploy to different regions around the world, and the ability to stop, start and pause existing deployments.

Sitecore Azure Module Features

The module only allows you to have one editing environment, which is called the Editing Farm. You can have as many content delivery deployments as your license allows; these are called Delivery Farms. The deployed architecture consist of a traffic manager which provides load balancing between the cloud services, cloud services which represent the set of VMs in each deployment, Azure SQL Servers which house the Sitecore databases, and storage blobs which hold metadata for the deployment process. The cloud services utilize the deployment slot and the production slot to create the separate environments. Within the cloud services Sitecore is deployed on the specified number of VM instances with two additional instances utilized as dedicated cache roles by default.

Azure Portal

Common sense dictates that unless you have a large number of content authors you should keep your Editing Farm to the recommend two VMs and keep them minimally sized. Sitecore notes that each deployment should consist of at least two VMs in order to get Azure's SLA uptime of 99.95%. You should follow normal cloud architecture best practices for sizing your CD environments.

The module has some limitations and probably should not be used alone unless your enterprise lacks the technical resources to adequately maintain and deploy Sitecore to Azure. Using the module limits the ability to control the deploy process, especially with regards to continuous integration. While it's possible to use the module with CI it will more than likely add on additional complexity. The module also limits the type of Azure resources and cloud architecture used for the implementation. The module does have xml elements that can be modified in order to provide customizations per deployment. If your company already plans on going through the process of automating portions of code deployment, building, testing or the Sitecore deployment then you should go ahead and not use the module. The module simplifies the deploy process at the cost of flexibility around deployment, CI automation, architecture and type of Azure resources used.

Common issues with the Azure Module

Analytics configuration

While testing the module I ran across a few issues with it in its current state. First, whenever you deploy you must ensure that the xml related to Sitecore xDB Cloud is properly configured. By default the xml assumes you are using the service and not an on premise implementation of MongoDB for analytics. If you leave the default and are not using the service you'll see an error for an invalid connection string. To correct the issue by turning off analytics go to more options from the deploy menu. Once there, scroll to the Custom Web Config Patch field and place this code there.

false

You should make sure you try to do this before deployment to avoid complications. Another solution is to fix the invalid connection strings to use your own implementation for analytics.

Delivery Farm Size

Another issue concerns the deployment of the Delivery Farms. If you attempt to deploy a delivery farm using the smallest size VM, A0, you'll likely encounter this error:

The XML specification is not valid: The 'sizeInMB' attribute is invalid - The value '0' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:PositiveInt'

The best way to fix this error is to:

1) in the "\App_Config\AzureVendors\Microsoft.xml" file, change size of A0 VM instance from zero to 5GB:
A0: 1 core / 0.75 GB RAM

2) Before starting the actual deployment process in the Azure application, click "More options" and change "DiagnosticStore" and "Temp" storage sizes to 5GB (see the attached "a0_details.png" image for details):

Publishing Targets

One other major issue I found with the module is that the target publish environments are not added to the Editing Farm as they are created. This issue requires either manual creation of the publish targets or acquiring a patch from Sitecore.

IIS Application Pool Identity Database Permissions

An issue relating to using custom accounts for the IIS Application Pool that the on premise Sitecore instance runs in was uncovered as well. I found that unless the custom identity had sys admin rights to the databases in the local dev environment, the resulting deployed site would give this error:

[SqlException (0x80131904): Invalid object name 'Items'.]
System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) +388
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) +810
System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) +4403

The solution is to give the custom identity user sysadmin rights to the database. Once you have done that then the databases should deploy correctly and the resulting site will not contain this error.

Azure Module Emulator

There's also an issue with the Azure emulator included in the module. The purpose of the emulator is to provide a way to simulate a deployed running instance in azure in your on premise dev environment. If you try to run it and receive a message that says:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248

Try moving your Azure solution under a shortened directory structure. The one suggested by Sitecore to me was C:\SC.

Deleting Deployments

An initial major annoyance I found was that deletion of a deployment is a completely manual process for the Azure module. In order to delete all Azure resources and Sitecore items associated with a Editing or Delivery Farm you delete, you must manually go in to the config files, content editor and Azure portal and delete them yourself. This article details the process.

The Azure module is still in its earliest stages and definitely needs more time before it's fully baked. With a few bug fixes and some minor feature improvements this module will be useful for enterprises looking for a simple, hassle free solution for deploying Sitecore to Azure.