Sitecore on Azure Migration - White Paper

Sitecore® on Azure migration guide This white paper presents a guide to the process and considerations for migrating Sitecore to the Microsoft Azure cloud

White paper // Sitecore on Azure migration guide

2

Copyright © 2001-2015 Sitecore Corporation A/S. All rights reserved. Sitecore ® and Own the Experience ® are registered trademarks of Sitecore Corporation A/S. All other brand and product names are the property of their respective owners.

Table of contents

Overview ��3

Why put Sitecore on Microsoft Azure? ��3

What is Microsoft Azure? ��3

Platform security and availability 4

Azure services 5

Choosing a region 5

Azure Websites vs� Web Role Cloud Services vs� virtual

machines 6

Sitecore xDB Cloud 7

Critical decisions when selecting components 8

Reference architectures 8

Estimating and managing costs 12

Data Security, Cleansing, Leakage and Sovereignty 13

Sitecore ��14

Version considerations 14

Sitecore licensing 14

Sitecore module compatibility 14

Back-office integration considerations 14

Third-party integration considerations 15

Email considerations 15

Site security 15

Single sign-on 16

Database considerations 16

Sitecore implementation considerations 17

Provisioning an Azure environment ��18

The migration process ��19

Lift-and-shift 19

Update-and-upgrade 20

Upgrading Sitecore 21

Telemetry and APM �� 22

Continuous Integration and Continuous Delivery

�� 22

Continuous Integration vs� Continuous Delivery 23

Continuous Integration approaches 23

Continuous Delivery approaches 23

Continuous content 24

Glossary of Azure services ��25

About the Authors ��28

References ��30


3

OverviewThis white paper provides information about migrating Sitecore® Experience PlatformTM (Sitecore XP) from an on-premise deployment to the Microsoft Azure® cloud� It provides assistance and direction with regard to technical considerations, architecture and tooling� This document will be of most benefit to IT managers and executives who are in the planning stages of a migration or are considering Microsoft Azure as a hosting platform for Sitecore and require an overview of the process involved�

Throughout this document you will find recommendations and best-practice guidance signified with an icon in the margin as can be seen here.

Why put Sitecore on Microsoft Azure?Microsoft Azure is the Platform-as-a-Service (PaaS) oriented cloud computing offering from Microsoft� It is differentiated from most other cloud providers, whose offerings are generally geared towards Infrastructure-as-a-Service (IaaS), though many have a foot in each camp�

Being a Microsoft service, it is strongly aligned to the Microsoft technology stack, including SQL Server and ASP�NET – the core supporting technologies required for Sitecore� This makes Microsoft Azure an excellent fit for hosting Sitecore and reduces the friction associated with adoption of the platform, as all the tooling and APIs are designed to work seamlessly with the technology that Sitecore already requires�

Unlike many traditional hosting offerings, Azure is billed entirely by usage, which provides for excellent cost management� Most compute services are billed by the minute, and data services are mostly billed by the gigabyte� Use of administration scripts and automation allow services to be dialled back to minimum specifications during quiet times and automatically and almost instantly scaled up

when traffic increases, with no interruption in service�

As services expand and costs fall, there is almost no argument left in support of self-hosting a new Sitecore deployment, but what about migration of an existing environment? Migration projects are not without costs and risk, even when the platforms are this well aligned� The following sections in this document are designed to assist with the selection of relevant services, architectural patterns and Sitecore components to help determine costs and risk and to help with migration planning�

What is Microsoft Azure?Microsoft Azure is Microsoft’s offering in the cloud computing platform space� Azure has taken a slightly different approach to cloud computing than the other major players in the space� Azure offers IaaS, PaaS and hybrid cloud options, but instead of focusing their efforts on providing infrastructure, they putting their effort into the PaaS offering��

IaaS refers to the provision of physical infrastructure components – in general, this is networking and virtual machines (VMs)� Customers can configure the number of central processing units (CPUs) and the amount of, storage and memory for their machines and can often select from a library of VM images that include an installed and licensed operating system and optionally installed and licensed applications as well, usually a database management system such as SQL Server or Oracle� Customers are responsible for software patching, configuration and maintenance of the applications on the machine, including configuring high availability and monitoring�

PaaS refers to the provision of higher-level services� Instead of provisioning a four-CPU virtual machine with 32GB of RAM to run SQL Server, you just upload a database and select the “100 transactions per second” scaling level� And instead of configuring a Windows Server with the Application Services role and installing IIS, PHP, Helicon, ASP�NET, SQL Express and various IIS modules, you just publish your site and select the “medium” server size� When traffic gets too high for your service, you can always dial it up to “large” in a few seconds (or just turn on autoscaling


4

and let the system adjust the power automatically)� High availability and disaster recovery are built into the environment, as is monitoring� With PaaS there is nothing to patch, nothing to upgrade and nothing to back-up�

To understand the difference, think about electricity�

Not so long ago, major companies had a Chief Electrical Officer, whose main responsibility was to ensure the supply of electricity to the business� This involved sourcing electricity from several providers to ensure continuity of service and reliability of supply� Few organisations think about the reliability of their electricity supply these days� PaaS is much the same – instead of acquiring and managing the hardware, infrastructure and skills necessary to provide a computing platform to the business, organizations outsource these tasks to a specialist provider and purchase them on an “as needed” basis�

Although many organisations have the skills in-house to create and manage infrastructure and platforms, it is becoming increasingly cost-effective to consume these platforms as needed, and the Microsoft Azure platform

is well positioned for anyone managing applications that are largely based on the Microsoft technology stack�

Where custom application implementations such as Sitecore are applicable, PaaS cloud models represent the sweet spot, balancing off the need for control of application behaviour against the efficiencies and cost savings that PaaS cloud providers such as Microsoft Azure offer�

PaaS models allow the IT organisation to focus on productivity and agility, which helps them become more responsive to the business� In turn, this facilitates innovation across the organisation�

Platform security and availabilityPlatform services can be configured to provide 99�99% availability, which equates to about 52 minutes of unplanned outage per year� We can use additional service configurations to further mitigate unplanned outages� The Azure fabric controller manages availability through two key concepts: update domains and fault domains�

On-Premises

Applications

Data

Runtime

Middleware

O/S

Virtualization

Servers

Storage

Networking

Infrastructure as a Service (IaaS)

Applications

Data

Runtime

Middleware

O/S

Virtualization

Servers

Storage

Networking

Platform as a Service (PaaS)

Applications

Data

Runtime

Middleware

O/S

Virtualization

Servers

Storage

Networking

You

man

age

You

man

age

You

man

age

Oth

ers

man

age

Oth

ers

man

age

IT Contol & Cost IT Efficiency & Saving


5

■ Update domains are a means of grouping services to ensure that when deployment updates are applied, they are not applied to all instances of a service at the same time� This creates a short period of reduced capacity but ensures that the service continues to operate during updates�

■ Fault domains refer to the physical environment and ensure that there are no single points of failure in regard to the physical environment, and it is this measure in particular that provides the high-availability of the environment� A fault domain isolates network equipment, power and physical (rack) location�

The Azure cloud has a number of security features, including the following:

■ Virtual networks allow services and machines within a subscription to be isolated from one another�

■ Public-facing endpoints are NAT’d to the destination service to prevent casual discovery of administration features and allow ACLs to be applied�

■ Site-to-site VPNs allow fixed endpoint communications between a corporate LAN and an Azure network to ensure that all communications with internal services is secured�

■ Distributed denial of service (DDoS) defences are built into the fabric with standard detection and mitigation techniques such as SYN cookies, rate limiting and connection limits� This defence system also withstands attacks that originate inside the Azure environment, with offending VMs automatically removed from the network�

■ Virtual appliance web application firewalls (WAFs) are supported if there is a need to provide additional intrusion detection and DoS mitigation�

Additional information about Microsoft Azure network security can be found online� See the “References” section at the end of this document for URL details�

Keep a list of Management IP addresses for your site handy. Whenever you provision a new service, immediately add ACLs to the RDP and PowerShell endpoints.

Azure servicesThe section below lists services that are most broadly applicable to a Sitecore Azure deployment� The “Glossary of Azure Services” section of this document describes each of the services in more detail�

■ Infrastructure services ■ Traffic Manager ■ CDN ■ Virtual networks ■ Virtual machines ■ Backup and recovery services ■ Multifactor authentication ■ Storage ■ SQL Azure ■ Storage (blobs, tables and basic queues) ■ Redis Cache ■ Application ■ Azure Websites ■ Cloud Services ■ Mobile Services ■ Push notifications ■ Media Services ■ Service Bus ■ API management ■ Machine learning ■ Development and administration ■ Visual Studio Online ■ Automation ■ Scheduler

Choosing a regionAt present Azure provides datacenters in 15 locations around the world� In general, it is best to put Azure resources in a datacenter that is


6

geographically nearest to the main audience�

The following considerations should weigh into any decision regarding in which region to host services:

Base priceThe cost for some services can vary from one region to another, sometimes dramatically so� Services cannot easily be moved once they have been provisioned, so this decision should be made early�

DataEgress data charges are grouped into Zones each with a different price�

LatencyNetwork latency affects throughput and has the greatest impact on the perceived speed of a website� A 200Mbps connection with 5ms of latency should achieve throughput of around 74Mbps on the internet, but with 200ms of latency, that throughput drops to 1�85Mbps�

Use the Microsoft Azure Speed Test to show approximate latency from a browser to an Azure datacenter. Create a VM in a remote datacenter to use when simulating remote visitors. See the “References” section for the URL.

Azure Websites vs. Web Role Cloud Services vs. virtual machinesUse the following matrix of features to compare and contrast these technologies when deciding how to deploy Sitecore� Each of these, at some level, is underpinned by a Windows 2012 R2 Server and IIS, so each is capable of hosting Sitecore�

Feature Websites Web Role VM

Speed of scaling / deployment Fast Moderate Moderate

Configuration options Few Lots Unlimited

Vertical scale configurations 8 >20 >20

Management overhead None Low Moderate

Number of instances supported (max) 10 50 50

Configuration (setup) overhead Low Moderate High

Deliver content through Azure CDN Yes Yes Yes

Traffic Manager routing available Yes Yes Yes

Deployment slots 5 (preview) 2 0

Connect VS debugger Easy Moderate Moderate

Automatic backup Yes No No

Web Jobs (triggered or scheduled out of process job engine) Yes No Manual

Cost* (Standard 4 core + 7 GB RAM in Australia East) ~$380 AUD / mo ~$340 AUD / mo ~$340 AUD / mo

Sitecore Azure Module support No Yes Yes

* Correct at time of writing; prices are changed often, so refer to the Azure Pricing pages for up-to-date information�


7

The main points of differentiation are:

■ Scale options – Cloud Services (and VMs) have many more options available, including new D-class options with more memory and temporary solid-state drives (SSDs)� Note that a single Sitecore license may be used on eight cores or less, but “web gardens” are supported� Scaling options are in favour of Web Roles and VMs�

■ Speed of scale / provisioning – Websites are provisioned in seconds, compared to minutes for Web Roles and VMs, and deployments are faster also ,which can help systems respond to sudden changes in load more quickly� Responsiveness is in favour of Azure Websites�

■ Simplicity – Websites require a less complex Visual Studio setup, are better suited to automated deployments (CI and CD) and are less complex to configure than Web Roles and VMs� Simplicity is in favour of Azure Websites�

■ Maintenance – There are no maintenance requirements for an Azure Website as it is a 100% managed service� Web Roles and VMs still require Windows Updates to be applied periodically and will suffer from regular (short) outages unless they are configured into Availability Sets (at double the price or more)� Ease of maintenance is in favour of Azure Websites�

■ Flexibility – Web Roles and VMs can be configured at the VM level, which provides almost limitless flexibility� Flexibility is in favour of Web Roles and VMs�

■ Sitecore Azure Module – This module provides configuration and deployment assistance from within a Sitecore shell and supports Web Role Cloud Services�

Speed of deployment, the ability to support multiple deployment slots (currently in preview), simplicity in configuration and VS deployment options make Azure Websites a compelling option for hosting Sitecore, even despite the reduced overall control, reduced scale options and lack of support for the Sitecore Azure module�

There are, however, a few critical limitations in Websites that need to be considered:

■ Domain names must be individually configured into Azure Websites but there is support for wildcard subdomains� Adding a new domain requires both configuration changes and DNS changes�

■ Websites have additional requirements around the configuration of SSL certificates, particularly where SNI is required�

■ At this time, Sitecore supports only Azure deployments to Cloud Service Web Roles and VMs�

If your Sitecore application does not require this level of domain name flexibility – particularly the ability to dynamically or frequently provision new domain names – and you are comfortable moving forward without the Sitecore Support safety net, then a an Azure Website–based deployment is a good option� In any other circumstance, the use of Web Role Cloud Services should be preferred over manually provisioned and managed VMs�

Ultimately, the selected options need to be considered with the specific goals and requirements of the business in mind�

Sitecore xDB CloudSitecore v8 expands considerably on the Sitecore® Experience Database™ (xDB™), introduced in v7�5 as the replacement for the Sitecore Analytics platform� xDB introduced a highly scalable architecture built around MongoDB and a map/reduce algorithm and supporting services used to populate “fact” tables stored in SQL Server that facilitate reporting and query functions� This near-real time analytics processing with independently scalable components greatly improves both analytics recording and reporting performance and allows the function of the once-specialised Analytics platform to be greatly expanded�

This new architecture is more complex, requiring the provision of MongoDB on top of the SQL Server analytics database and the implementation of several new processing service components� These new elements demand new skills, and some IT teams may not have had exposure to these technologies�


8

To aid adoption and simplify the deployment, Sitecore now offers the xDB platform as a cloud service, called Sitecore® Experience DatabaseTM, Cloud Edition (xDB Cloud)� A true SaaS offering, this service will plug into an existing Sitecore implementation through a few configuration screens in Sitecore’s built-in App Center and will not require a detailed knowledge of the underlying architecture or componentry�

Critical decisions when selecting componentsSome requirements can have a significant influence on the architecture and components that should be used� Considerations regarding performance, and in particular latency, as well as cost, scalability, automation and the level of sophistication and competency of your operations team will all come to bear�

The following list includes some of the critical requirements and how they may influence deployment decisions�

DomainsIf requirements dictate dynamically adding new domains, then Azure Websites are probably not a good choice� Wildcard subdomains are supported, but otherwise each new domain requires configuration through API, PowerShell or the console to add support� Further, those changes are predicated on DNS changes, which can add a considerable delay to the process�

CostAutomation can be used to manage cost by deprovisioning or scaling down services during non-business hours� This has the most effect on an IaaS implementation, as VMs that are not in use can be shut down with no ongoing charge (aside from storage)� Cloud Services and Websites can be scaled back but not deprovisioned entirely – this will reduce the cost somewhat but will leave the environment available at a minimal performance level�

xDB CloudChoosing to use the Sitecore xDB Cloud for your analytics removes a lot of complexity, including the requirement to provision Mongo databases and several processing servers� However, as with any other SaaS product, there is a performance cost in additional latency that may be introduced� If money and skills are not a consideration

then provisioning additional infrastructure to host xDB services will improve performance of the analytics systems�

Continuous Integration and Continuous DeliveryContinuous delivery can be achieved in a number of ways� The tools that a development team may leverage and the level of automation desired may necessitate architectural options backed by an accessible virtual machine� For example, Octopus Deploy provisions resources by using “Tentacles”, which must be installed on a target environment, ruling out Websites as an architectural choice; VS Online, however, has considerable functionality pre-configured for deploying to Azure Websites and Cloud Services but not to VMs� See the “Continuous Integration and Continuous Delivery” section later in this document for more information�

Azure moduleUsing the Sitecore Azure module is the approach recommended by Sitecore for adopting PaaS cloud services� This module is fully supported on most recent versions of Sitecore� If adoption of the Sitecore Azure module is part of the cloud strategy, then Web Role Cloud Services are necessitated and Sitecore v7�2 or above is strongly recommended�

Reference architecturesIn this section, we provide reference architectures to cover some common deployment scenarios� These architectures focus on the Sitecore application and do not attempt to account for third-party services that may be connected� Although these are common in Sitecore deployments, there are too many methods of integration to document properly�

The architectures provided do not add any consideration for Sitecore licensing costs, which will vary depending on the options and requirements relevant to the deployment� See the Sitecore licensing section later in this document for more information� Architectures depicted below assume the use of Sitecore Enterprise Edition with four server licences:

■ 2 x Platform Production Delivery ■ 1 x Platform Production Management ■ 1 x Non-production Staging Server


9

Recommended components to consider include:

■ Traffic Manager – This is strongly recommended, as it facilitates redirection between Azure services without requiring DNS changes� If there is a problem with an Azure region or service, the use of Traffic Manager allows efficient redirection of users to a service established in a new region� Traffic Manager cannot be used with the CDN service�

■ Redis Cache - The use of Redis Cache for shared session state persistence is strongly recommended, as other caching platforms are being de-emphasised or deprecated on Azure� Once provisioned, this cache should also be used for application-level shared data�

■ CDN - Use Azure CDN for small to medium-sized sites to take some of the load off the origin sources, allowing the use of smaller machines to serve the same content load� CDN cannot be used in conjunction with Traffic Manager, as both of these systems are configured with Azure Websites or Cloud Services as endpoints� Note: CDN caches only static content, as indicated by MIME type headers and by the fact that cache lifetimes are set by the HTTP headers sent from the origin servers� This allows precise cache control from the origin but adds a configuration overhead that needs to be considered during system programming�

Azure load balancers are “round-robin” and have no sticky-session capabilities. It is critical that multi-instance applications are deployed with a shared Session State architecture for reliable operation.

Optional components that you may consider include:

■ VPN – A site-to-site VPN costs very little and streamlines access to the environment for users on the corporate LAN�

■ Domain Controller / ADFS – Adding a small VM as an Azure-side domain controller or ADFS replica can provide content authors with Windows Integrated logins to Sitecore�

■ xDB infrastructure – Additional infrastructure for hosting xDB services and databases in place of Sitecore xDB, Cloud Edition�

■ SQL Server VMs – SQL Azure is billed on a per-database basis; a potentially significant cost saving can be achieved by hosting the test environment databases on a medium-sized SQL VM rather than PaaS� This will mean that databases will need to be manually synchronised between environments, but the server(s) can be turned off when not in use�

Sitecore Enterprise Edition with CI – WebsitesThis architecture leverages Azure Websites to serve Sitecore for Live, Auth and Test� Using it is the simplest approach to delivering Sitecore from Azure, making full use of Azure’s PaaS capabilities, with the caveat that this approach is not officially supported by Sitecore at this time�

Features of this architecture include:

■ Low management overhead ■ Very high availability of production environment ■ High safety for code deployments with multiple

deployment slots ■ Good integration with VS Online

Sitecore Enterprise Edition with CI – Cloud ServicesThis architecture leverages Web Role Cloud Services to serve Sitecore for Live, Auth and Test� Using it is the most common approach to delivering Sitecore from Azure, making full use of Azure’s PaaS capabilities and Sitecore’s modules and services and is fully supported by Sitecore�


■ Minimal management overhead ■ Very high availability of production environment ■ Moderate safety for code deployments with two

deployment slots ■ Additional flexibility in scaling options ■ Sitecore Azure module to assist deployments ■ Good integration with VS Online


10

Sitecore Enterprise Edition – hybrid PaaS / IaaSThis architecture leverages IaaS elements in a bid to control costs� Azure Websites and Cloud Services are billed even when they are stopped, as they cannot be deprovisioned� Virtual machines, however, are billed only when they are running� This approach relies on the premise that authoring and test environments need to run only during business hours, which represent less than 25% of the hours in a typical month�


■ Very high availability of production environment ■ Low safety for code deployments – manual, per-

server code deployments required ■ Flexibility in scale ■ Use of autoscale in the Auth and Test

environments to ensure that one and only one machine in the Availability Set is running (There

can be a lag of a few minutes for the autoscale system to rectify a machine outage, so 99.95% availability should not be the goal).

■ Automation used to control costs

Sitecore Enterprise Edition – hybrid cloud / on-premisesThis architecture makes use of existing on-premises infrastructure for all environments except Live� This architecture represents a possible initial approach to adopting the Azure platform where an existing on-premises infrastructure already exists�


■ Small initial investment in cloud technology ■ Easy migration path from an existing environment ■ Very high availability of production environment ■ Easy support for AD integrated authentication for

authors

Traffic Manager LIVE Traffic Manager AUTH

Azure region

Corporate LAN

Traffic Manager TEST

Failover

HTTP/S

www-1 www-2 www-down auth-1 test-1Sitecore xDB Cloud1 [Test]

xDB TFS buildServer

Tracking, processing,Aggregation,

EAS, reporting

xDB

Sitecore xDB Cloud1

HTTP HTTP/S IP-Sec HTTP/S IP-Sec

Failover

CoreRedis session

Web Core OtherRedis session

Web Master Core OtherRedis session

Redis session

Development Core, masterWeb, other

Master

Notes:

• Sitecore xDB Cloud Edition is supported only on Sitecore 7�5+�• WebDeploy is automatically enabled on Azure Websites�• Sitecore PowerShell Remoting can be used to enable

continuous delivery of Sitecore Assets�• Deployment slots should be used for

deployments to Test, Auth and Live�

Enterprise Edition with CI — Websites

Continuous delivery

Reporting


11

Traffic Manager LIVE


Traffic Manager AUTH

Traffic Manager AUTH

Azure region

Azure region

Corporate LAN

Corporate LAN



Failover

Failover

HTTP/S

HTTP/S

www-1 auth-1 test-1

www-1

WebDeploy PS Remote Mgt IP-Sec


www-2 auth-2 test-2

www-2

www-down

www-down

Sitecore Azure Module

auth-1 test-1

Sitecore xDB Cloud1 [Test]

Sitecore xDB Cloud1 [Test]

xDB

xDB

TFS buildserver

TFS buildserver

Tracking, processing,aggregation,

EAS, reporting

Tracking, processing,aggregation,

EAS, reporting

xDB

xDB

Sitecore xDB Cloud1

Sitecore xDB Cloud1

HTTP

HTTP

HTTP/S IP-Sec

HTTP/S IP-Sec

HTTP/S IP-Sec

HTTP/S IP-Sec

Failover

Failover

Core

Core

Redis session

Redis session

Web

Web

Core

Core

Other

Other

Redis session

Redis session

Web

Web

Master

Master

Core

Core

Other

Other

Redis session

Redis session

Redis session

Redis session

Development

Development

Core, masterweb, other


Master

Master

Notes:

• Sitecore xDB Cloud Edition is supported only on Sitecore 7�5+�• Sitecore PowerShell Remoting can be used to enable

continuous delivery of Sitecore Assets�• Autoscale is used to ensure that at least and at most

one Auth and Test server is available in the set�• Automation can be used to scale or provision

resources during business hours�

Notes:

• Sitecore xDB Cloud Edition is supported only on Sitecore 7�5+�• Sitecore PowerShell Remoting and PowerShell Remote Management

can be used to enable continuous delivery of Sitecore Assets�• Backstage deployment slots should be used for

deployments to Test, Auth and Live�• Automation can be used to scale resources during business hours�

Sitecore Enterprise Edition — hybrid PaaS/IaaS

Sitecore Enterprise Edition with CI — Cloud Services

Continuous delivery

Continuous delivery

Reporting

Reporting


12

Estimating and managing costsThe cost of provisioning an Azure environment can be difficult to predict, since services are billed based on usage and frequently detailed usage information is almost impossible to estimate�

The following factors need to be assessed in an estimate for provisioning an Azure environment:

■ Deployment region Charges can differ dramatically from one region to the next� Be sure to check per-region pricing for your services, and don’t rely on the Azure “Full Calculator” page�

■ Hosting strategy VMs and Web Role Cloud Services cost about the same in Australia, but Cloud Services are generally a little cheaper in other parts of the world� Azure Websites tends to be a little more expensive�

■ Additional software Pricing for SQL Server, BizTalk and SharePoint is in addition to the base VM� Almost all additional software that you can provision with your VM comes at a price, often more than you expect�

■ Bandwidth Data charges are different depending on the region with US/Europe being in Zone 1 and most of the rest of the world in Zone 2, which is about 40% more expensive� Even though only outbound data is charged, you should budget more than you expect to use�

■ CDN If you choose to deploy the CDN, be aware that charges apply for the CDN egress data and that you’ll incur regular egress bandwidth charges from your services to the CDN endpoints, which may be in Zone 1, 2 or 3�

■ Traffic Manager Charges are based on DNS queries, which are generally cached by a browser for the duration of a visit� Lowering the TTL (cache timeout) increases flexibility when you need to change the configuration but can greatly increase the number of requests handled by the Traffic Manager� In general, these charges are lower than you might expect and well worth the cost�


Azure region Corporate LAN

Failover HTTPHTTP/S

www-1


www-2

Sitecore Auth

www-down

Sitecore AzureModule

xDB

TFS BuildServer

SitecoreTest

Tracking, processing,aggregation, EAS, reporting

xDB

Sitecore xDB Cloud1

Web Core OtherRedis session

Redis session

Development



Core, masterWeb, other

Notes:

• Sitecore xDB Cloud Edition is supported only on Sitecore 7�5+�• Sitecore PowerShell Remoting and PowerShell Remote Management

can be used to enable continuous delivery of Sitecore Assets�• Backstage deployment slots should be used for deployments to Test, Auth and Live�• Automation can be used to scale resources during business hours�

Sitecore Enterprise Edition — hybrid cloud / on-premises

Reporting

Continuousdelivery


13

■ Redis Cache Charges are based on capacity, but it can be difficult to determine how much data is being stored in session state (assuming that is what the Redis Cache is being used for primarily)� Always use a Standard tier for production, but Basic is fine for Auth and Test� To determine session state usage, start with more than you think you need and then monitor usage, in the Azure Portal while running load tests from a tool such as Blitz�io� Charges are calculated per hour, so a day’s worth of testing shouldn’t cost very much� Scalability is greatly reduced with increasing use of session state, so limit this where possible�

■ SQL Azure Charges for SQL Azure are accrued per database, by performance tier� Determining the required performance tier is a black art, but in general you should scale your web databases higher than the others� Use performance counters to determine whether you are hitting throughput limits on your tier, indicating that a higher tier may be required� Make sure Sitecore’s HTML, item, and component caches are properly configured to reduce overall database load�

■ Backup If you have deployed VMs, consider using Azure Backup to provide point-in-time recovery for data and configuration�

■ Visual Studio Online For most organisations, access to VS Online is available through existing MSDN subscriptions�

■ Media Services If your site includes the delivery of streamed media, then Azure Media Services provides an ideal platform for encoding and streaming media at scale�

Data Security, Cleansing, Leakage and SovereigntyAny enterprise cloud provider needs to address concerns about data security, cleansing and leakage� In this case,

Data Security refers to the ability for an unauthorised individuals to gain access to information they should not have, cleansing refers to the safe destruction of information and leakage refers to cases in which data that is owned by one customer becomes exposed to another�

Storage in Azure is allocated sparsely� This means that although space is reported for a drive or disk it is not provisioned against physical hardware until it is written to� An intermediary table is used to identify which blocks on a virtual disk contain data and where on a physical disk that data is located, by using a pointer� If a block is read by a customer and the table identifies the block as “free”, all zeroes will be returned without causing any reads from the physical disks� When a customer deletes a block, it is marked as free and the pointer to the data is deleted in the table� The deletion activity is also asynchronously applied across all georeplicated copies of the data� Customers, who must read any data through the storage subsystems, no longer have access to the location on a physical disk where the data is stored� Only an Azure administrator could read blocks that are marked as free and it is impossible to determine the owner of any particular block of data once the pointer has been deleted�

When a subscription is cancelled, data is held by Azure for at least 90 days to enable recovery from accidental (or malicious) cancellations� Between 90 and 180 days after a cancellation, all data related to a subscription will be marked as free� Azure uses a log-structured file system, so overwriting a file with zeroes is not helpful, as new data is always written to the end of the log�

When a physical drive is cycled out of a storage subsystem in Azure, it is cleared with a seven-pass wiping system before being disposed of� Any drive that cannot spin is physically destroyed in a shredder�

Azure data centres have been independently verified against at least 20 compliance programs including:

■ ISO 27001/27002 ■ SOC 1 / SSAE 16 / ISAE 3402 and SOC2 ■ FedRAMP ■ PCI DSS Level 1 ■ United Kingdom G-Cloud ■ Australian Government IRAP


14

■ EU Model Classes ■ FBI CJIS

This makes Azure environments certified for use with most government departments around the world� It is the first (and presently only) public cloud in Australia to receive IRAP certification, which validates the Australian Geo for use in storing unclassified government information�

Extensive information about Azure security, privacy and compliance is available in the Azure Trust Center portal�

Sitecore

Version considerationsMicrosoft Azure supports �NET 3�5 and �NET 4�5 on Azure Websites, Web Roles and VMs, so all modern versions of Sitecore from v6 onwards should be able to run in Azure�

Sitecore 7�5 is required to make use of the Sitecore xDB Cloud service�

The Sitecore Azure module assists in configuring and deploying Sitecore Web Role Cloud Services and supports all Sitecore versions from 6�3 up to 7�5� The module provides a user interface inside the Sitecore shell and has the ability to write the Service Definition and Service Configuration files needed to provision a Web Role Cloud Service� It will also package and deploy an entire Content Delivery farm to the Azure region of your choice�

Use of Sitecore v7+ is recommended for Azure-based deployments, but any version can be safely provisioned to Azure�

Sitecore licensingIt is always best to check with your Sitecore Account Manager in regards to licensing requirements� Azure features and capabilities change on a month-to-month basis, and Sitecore is working hard to provide licensing options that allow customers to take advantage of Azure’s range of features�

Sitecore currently offers the following licenses:

■ xPlatform Production Management Servers – a production authoring server

■ xPlatform Production Delivery Servers – a production content delivery server (no Sitecore shell)

■ xPlatform Non-Production Staging Servers – a non-production authoring server such asTest

■ xPlatform Non-Production Delivery Servers – a non-production content delivery server (no Sitecore shell)

■ xPlatform Integration Servers – a CI build target server used for development/QA

■ Azure Enablement Installation – additional Web Role instances for a production server

■ Azure Deployment Installation—Sitecore Azure module license

Sitecore module compatibilityMost modules available through the Sitecore Marketplace or the wider Sitecore community should function without issue on Azure; exceptions include those modules that rely on sticky sessions� More information on session state is provided in the Sitecore implementation considerations section below�

The use of the Sitecore PowerShell Extensions and the Remote Automation web service that is delivered as part of it is recommended� These tools are particularly useful for automation and remote management as well as CI/CD endeavours�

In many cases, Sitecore Marketplace modules are open source and provide links to the project code repositories� If problems are encountered with using a module in Azure, there is ample opportunity to raise an Issue, contact the module author or even correct the problem for the good of the greater community and log a pull request�

Back-office integration considerationsSitecore provides a rich integration API, and it is likely that any sophisticated implementation will include integration with several systems�


15

For Sitecore implementations that are hosted in-house, it is common to find integrations with back-office systems that leverage protected communication channels including domain-based authentication and authorization� The WAN communications between an on-premises system and a cloud-based system are much more fragile than with an entirely LAN-based system and carries significant additional latency and bandwidth limitations� These need to be assessed as part of a migration effort, and in particular, the effort required to decouple these systems needs to be estimated carefully� Tasks will include:

■ Implementing non-domain authentication, or provisioning ADFS�

■ Opening inbound traffic ports on the corporate network (IP-Sec should still be used)�

■ Implementing message-based communications where possible to buffer communications that may be unreliable (Azure, provides two solutions here: Storage Message Queues and Azure Service Bus)�

Third-party integration considerationsAll outbound communications are allowed from Azure services, so adjusting existing integrations with third-party services should not present a problem� Consideration should be given to IP-Sec secured communications, however� In general, IP addresses are not statically provisioned to an Azure service� Instead, services are located through CNAME DNS referrals� Where IP-Sec is required for the communication to third-party services, a Reserved IP should be provisioned for the Azure service�

Reserved IPs are available only for Cloud Services and VMs at this time and must be allocated at the time of provisioning the service – they cannot be added after the fact� The Service Configuration schema supports the provisioning of a Reserved IP, but at present this is not possible through the Sitecore Azure module�

Email considerationsIt is common for Sitecore websites to send triggered emails� For Sitecore implementations that do not

leverage Sitecore’s Email Experience Manager (formerly ECM) or where the MTA being used is local to the Sitecore machine, some modification to the outbound email system will be required�

Although an Azure VM could be provisioned with an SMTP server for the purpose of delivering mail, this is not recommended by Microsoft� DNS Pointer records are used as part of anti-spam heuristics and cannot be assigned on the Azure cloud� DNS SPF records can be crafted to indicate Azure-based origin servers, but in this case, a Reserved IP should be allocated�

Cost and configuration complexities lead us to recommend the use of a third-party email platform, which will include many additional features at a greatly reduced cost, including analytics and template management�

Some providers of email services include:

■ SendGrid Provides SMTP and Web APIs as well as many supporting APIs – probably the world’s largest provider�

■ Mandrill Provides features as per SendGrid and then some, according to their documentation; CSS inlining and A/B testing of transactional emails are the main feature differences for most Sitecore use cases�

Site securityOnce assets are moved to Cloud infrastructure, it is important to consider what the repercussions might be if unauthorised access to the databases or platforms is experienced� Most Sitecore implementations rely on standard ASP�NET forms-based authentication, which uses cryptographically weak hashing protocols to protect user passwords including SHA1 and MD5� Although this system may provide sufficient protection against brute force attacks directed through a login form, it does not provide sufficient protection if the password hashes become public�

Enhanced authentication protocols should be considered where there is a risk that user information might be targeted by cybercriminals or where the repercussions of


16

user account information being made public is very high�

At a minimum, it is important that the guidelines set out in the “Sitecore Security Hardening Guide” be implemented� This guide is available for download from the Sitecore SDN website�

PING Works provides a module for Sitecore versions 6�5 (Update-5) and higher called the High Security Module is available� This is a drop-in replacement for the standard ASP�NET authentication providers that provides greatly increased protection for passwords and user data�

Features include:

■ HTTPS redirection for forms and logged-in sessions ■ Hardened password storage with:

• High-repetition PBKDF2 hashing• Combined system-level and per-user salting• Passwords not stored with user records and not

linked by foreign keys ■ Blackout periods for failed logins ■ IP authorisation and login auditing ■ Integrated web service and FTP authorisation ■ Azure multifactor authentication support ■ User profile data encryption at rest (i.e., data is

stored in the database encrypted) ■ Field-level decryption privileges for authors

Single sign-onAs with other integration considerations, SSO systems should be investigated for compatibility� Increased lag in communications between Azure resources and on-premise resources will negatively affect the user experience, as authentication and authorisation events are very frequent in ASP�NET applications� This may necessitate changes to the engineering in SSO systems including buffered communications or Azure-side caching of roles, tokens or credentials� Using Dynamics CRM or Salesforce authentication connectors without buffering and Azure-side caching, for example, is not recommended�

Providing Windows Integrated Authentication for logging content authors into Sitecore requires some additional components, which could include a small VM to act as a DNS and DC and ADFS configuration�

Database considerationsSQL Azure databases are approaching but do not yet have full feature parity with SQL Server 2014� Although the fact that the missing features are missing does not present an issue for Sitecore databases, it can for custom databases that may form part of a Sitecore implementation�

Some examples of not-supported and partially supported features include:

■ Clustered index requirements – all tables are required to have a clustered index. Avoid applying a clustered index to the UNIQUEIDENTIFIER primary key column, as this can have performance implications and cause index fragmentation. Note that NEWSEQUENTIALID() is not supported on SQL Azure.

■ Connecting to more than one database. ■ Global temporary tables. ■ SELECT INTO clause. ■ Service Broker – this feature is required for use

with SqlCacheDependency objects.

V12 of Azure SQL Database is due for GA in March 2015 and will include several new features including “table as a heap”, which removes the clustered index requirement and facilitates the “Select … Into” clause. Other notable improvements include online index rebuilds, row-level security, support for ANSI window functions with the OVER clause, .NET CLR integration and change tracking at the database or table level.

The SQL Azure Migration Wizard is an open source tool that can migrate databases from an on-premises


17

version of SQL Server to SQL Azure� The Wizard has knowledge of applicable restrictions and, in many cases, will take corrective action automatically as it produces migration scripts� It also features the use of BCP for migrating data, which is many times faster than, standard INSERT operations�

Tools are also provided in SQL Server Management Studio 2012+ for extracting a data-tier application from an existing database or deploying an existing database to Azure� Each of these results in the creation of a BACPAC file, which contains both the structure and data of a database in a portable format that can be imported into SQL Azure� These methods tend to be less reliable than the Migration Wizard approach for real-world databases with complex schemas, however�

It should be remembered that general database maintenance is still required. Index rebuilds and defragmentation are a standard maintenance task that must be carried out on any database, even Azure SQL databases, as the platform cannot determine whether these tasks are relevant for a given implementation automatically� This is a common cause of Sitecore performance problems�

Create stored procedures to perform routine index maintenance, and use the Azure Scheduling and Automation platform to execute these procedures regularly� Aside from improving database performance, reduced fragmentation also reduces the overall space of the database and therefore reduces the cost�

Sitecore implementation considerations

Session state and cachingThe vast majority of Sitecore site implementation code will run on Azure without modification, but special consideration needs to be given to in-process caching and Session State�

Load balancers in Azure are not sticky-session� Visitors to the website are likely to switch connections between servers many times in loading a single page� Storing session data in memory (in-process) in this circumstance will cause significant issues with the operation of the website and is ill advised�

To address this issue, out-of-process session state management is recommended, but not all types of object can be automatically stored in an out-of-process session state manager� Notably, Sitecore Item objects cannot be stored and it is an unfortunately common practice to do so in Sitecore implementations� Time should be provisioned to ensure that all objects that are being persisted to Session State are properly marked in the code (using the Serializable attribute)�

A number of out-of-process session state management systems are available in Azure at present, including Azure Managed Cache Services and Cloud Service In-Role Cache� Microsoft Azure documentation recommends that all new deployments use Azure Redis Cache over other cache services� The Sitecore Azure module does not include a mechanism for provisioning a Redis Cache as part of an Azure deployment to a region�

Other data caching patterns used in the Sitecore implementation should be modified to make use of the shared storage functionality provided by the Redis Cache� Such patterns include the use of the HttpContext�Current�Cache object and classes that implement static fields and properties for caching data� Moving these objects into shared storage allows all Sitecore instances to make use of the cached data� Multithreaded locking techniques that are used with static object caches should be migrated to a distributed locking semantic�

Content Management Server and session stateThe Sitecore CMS UI requires in-process session state so multi-instance Sitecore CM servers are not officially supported, though practical experience reveals few issues with everyday use of the CMS under this scenario�

ASP.NET Temp and IIS Compression Temp foldersAzure Web Role and VM Cloud Services are provisioned with a “D drive” for temporary data� These drives should be used for ASP�NET temporary files and for IIS compression folders to spread some of the I/O workload� When services or machines are reprovisioned, they are not guaranteed to be restored with the same D drive, so it may be blank the next time your service starts up� For VMs a simple batch script can be used to create the required folders and can be configured into Windows Task Scheduler to


18

run on machine startup� For Cloud Services, you will need to use a Startup Task rather than using Windows Task Scheduler to trigger the execution of the batch script�

Azure Web Role and VM Cloud Services recently added D-class machines to the configuration options� The temporary drive in these machines is SSD, making for an even more compelling case for offloading I/O tasks to that drive�

Both the ASP�NET Temp and the IIS Compression Temp folder setting form part of web�config, so these settings can be included in a Config Transform for publication to ensure that the correct settings are used in development and production� The settings are show below:

<configuration xmlns:xdt=”http://schemas.

microsoft.com/XML-Document-Transform”>

<system.web>

<compilation tempDirectory=”D:\aspnet_

temp\” xdt:Transform=”SetAttributes” />

</system.web>

<system.webServer>

<httpCompression directory=”D:\iis_

temp\” xdt:Transform=”SetAttributes” />

</system.webServer>

</configuration>

Location of Sitecore Data folderTo ensure portability between VM, Cloud Services and Azure Website deployment models put Sitecore Data folder into App_Data� Aside from offering intrinsic protection to the contents of the folder – App_Data content is protected from being served by IIS through the default configuration of the Request Filtering module – you will be ensured write privileges on the folder�

Relocate the Sitecore Data folder by using a Config Transform on the web�config (or Sitecore �config file if you have one) as follows:

<sitecore xmlns:xdt=”http://schemas.

microsoft.com/XML-Document-Transform”>

<sc.variable xdt:Transform=”Replace”

xdt:Locator=”Match(name)” name=”dataFolder”

value=”/App_Data/SitecoreData” />

</sitecore>

Lucene indexesIn a multi-instance Sitecore CD environment, additional configuration is required to ensure that Lucene search indexes are updated on all Sitecore instance servers� Follow the instructions in the “Sitecore Scaling Guide” (also v6�6) to ensure correct configuration and operation� Sharing the Lucene search indexes across multiple Sitecore instances is not supported� Alternatively, configure an independent SOLR server as a Worker Role Cloud Service instance or standalone Cloud Service�

Link databaseThe Link database maintains records of the relationships between items in Sitecore� The Core database is responsible for maintaining this information, irrespective of which database the relationship exists in� Information about correctly configuring the Link Database settings for use in a multi-instance Sitecore CD environment is provided in the “Sitecore Scaling Guide” (also v6�6)�

Provisioning an Azure environmentProvisioning your environment successfully takes experience, as many elements in Azure cannot be altered once they have been created and it isn’t always obvious what order things should be created in to complete the setup in one pass� The good news is that there is a lot of tooling and documentation on the internet to help� Additionally, if a mistake is made, it is generally simply a matter of deleting the incorrectly provisioned thing and re-creating it correctly – a process that is normally measured in seconds or minutes� Since Azure bills only by usage, these mistakes are not costly�

There are (at least) four ways of establishing a Sitecore environment on Azure:

1. Provision services through the web portal and manually copy files

2. Publish using tools integrated into Visual Studio

3. Create/execute PowerShell scripts

4. Publish using the Sitecore Azure module

The Sitecore Azure module provides a wizard that takes


19

the user through a series of steps, making decisions about the environment along the way� It automatically creates the necessary XML files for provisioning an environment (CSCFG and CSDEF) and then executes the process by using Azure APIs built into Sitecore�

For the most part, the same results are achieved no matter which method is used; only the degree of complexity varies� As with any automation, it can be helpful to understand what is going on “under the hood” – the following describes the manual steps for provisioning an environment in the order dictated by Azure dependencies�

1. Document your design decisions Which data centre are you using; do you have the gateway IP addresses for your “secure access” users; do you have a naming convention?

2. Create a new subscription [optional] Almost all functions in Azure are isolated by subscription, and each subscription has limits on the number of cores, Cloud Services, storage accounts, etc. You can lift the limits by raising a ticket to Azure Support, but at some point you’ll hit a hard limit.

3. Create any service co-administrator users [optional].

4. Create a storage account.

a. Add a container called vhds that will be used for VM disks.

5. Provision the virtual network if you are going to use one.

6. If you’re using a virtual network, provision a VM to act as a DNS server.

a. Assign a static IP to the DNS server (Set-AzureStaticVNetIP from PowerShell). Do not set a static IP into the VM’s network settings – this is not supported in Azure.

Create a reserved IP address if your deployment requires one. If you require a known IP for your VMs or Cloud Services, now is the best time to create them, as a reserved IP can be assigned only at the time of

provisioning the service (New-AzureReservedIP from PowerShell).

7. Provision the Redis Cache.

8. Create Cloud Services or Websites Assuming you will be deploying to Web Roles, configure Visual Studio projects with the appropriately.

9. Create any other VMs you may need

10. Provision Traffic Manager for Prod, Auth and Test as necessary and assign the appropriate endpoints

11. Provision any other services you require

Once your environment is provisioned, you will have enough information to configure Visual Studio for deploying your project properly�

The migration processFor an existing Sitecore implementation, there are two main approaches to migrating to Microsoft Azure: lift-and-shift and update-and-upgrade� The former requires the minimum alterations to an existing implementation and focuses on simply switching out the current hosting arrangement in favour of a cloud-based solution� This is commonly used as a “first step”, as it allows companies to take immediate advantage of autoscaling, integrated CDN services, high availability and competitive pricing without having to undertake modifications to a system that may be costly and take time to implement� The most gains are made using the latter approach, as this allows for a full adoption of PaaS and can lead to streamlined management and deployment scenarios that are not easily achieved through IaaS�

Lift-and-shiftMost commonly this approach involves leveraging the cloud as an infrastructure provider, as few implementations designed for use outside of an Azure Cloud environment will translate without modification to the PaaS hosting models�

The advantage of this approach is that no modifications are made to the Sitecore implementation outside of


20

configuration� This means there are no development cycles, no testing, and no legal signoff� This greatly reduces the amount of time required to complete the process� Additionally, since the new environment is provisioned side-by-side with an existing live implementation, there is no interruption to service during the switchover process� A simple DNS change is all that is required�

Key Azure services that can be leveraged in a lift-and-shift approach could include the following:

■ Traffic Manager ■ Virtual Networking ■ Virtual Machines ■ CDN ■ SQL Azure

At this time, the CDN works differently for Cloud Services than it does for Azure Websites and blob storage. For the latter, the CDN serves any content from the root of the site, but for Cloud Services, only content in the http://origin.domain.com/cdn path is served from the CDN. See the CDN documentation for more information.

This provides businesses with access to key functionality on Azure such as:

■ Fast scaling and auto-scaling ■ Multiregion availability (georedundancy) ■ High availability ■ Zero-downtime deployments ■ Automatic georouting ■ Low-management infrastructure ■ Secure mechanisms for distributed access to third

parties ■ Easy access to a global CDN ■ PaaS, high-availability, managed SQL

Unless the Sitecore implementation contains very complex

custom SQL Server databases that are not supported, it is recommended that all Sitecore implementations use SQL Azure for their databases� Clustering SQL server properly requires the use of at least three servers, shared storage and an Active Directory domain� Not to mention a fair amount of skill in the configuration, management and administration of patching, updates and backups� SQL AlwaysOn, in any form, is quite complex� SQL Azure removes all the complexity and provides all the features you are likely to need for most scenarios� Full details are available in the SQL Azure documentation�

Those factors are compelling enough, even without considering the cost reductions� This makes the lift-and-shift approach very attractive for businesses looking to make a first step into the cloud� To realise the full potential, however, it is necessary to convert a Sitecore implementation to run on PaaS, which often means making adjustments to the code�

Update-and-upgradeTo make the most of the Azure Cloud, it is necessary to convert a Sitecore implementation to properly support PaaS� Although SQL Azure can be adopted with even a basic lift-and-shift approach, there are a number of advantages available once the website hosting aspect is also moved onto a PaaS model such as Azure Websites or Web Role Cloud Services�

Key advantages include:

■ Access to “deployment slot” features – greatly improves code deployment safety and availability

■ Shared caching infrastructure – reduces the workloads of individual servers in a farm

■ Access to the Sitecore Azure module – simplifies deployments and management

■ Expanded access to CDN ■ Continued product support from Sitecore

To gain access to these features, a number of development tasks are recommended:

■ Upgrade Sitecore to the highest version supportable in your implementation

■ Move any in-process cache such as static variables,


21

and objects stored in ASP.NET Cache to the Azure Redis Cache service

■ Configure Redis Cache as a session state provider ■ Deploy Sitecore to Azure Websites or Cloud

Services in place of VMs ■ Configure deployment slots ■ Adjust deployment scripts or CI/CD approaches as

necessary

For the most part, these alterations should present low risk to a project and in general do not take much development time to adopt� A full regression test and user acceptance test are recommended, however, as these are fundamental changes to information persistence that affect financial transactions, logged-in state and authentication and authorisation�

It is also recommended that this opportunity be used to upgrade Sitecore to the highest supported version at this time� Newer versions of Sitecore, including 7�5 and 8 have been designed and tested against Azure and are better supported by Sitecore, not to mention that they introduce numerous new features, bug fixes and support for the latest browsers�

Upgrading SitecoreRegularly updating Sitecore is recommended to ensure ongoing access to support� From July 2015, Mainstream Support will end for all Sitecore versions earlier than and including v6�5� From the end of calendar year 2015, the only supported Sitecore versions will be v7 and higher� That means that any issues that are discovered in the product may be rectified only at the cost of the customer� If you are paying for Support and Maintenance on your Sitecore licence, there’s really no good excuse to get this far behind on patches and upgrades you are already paying for�

The full set of dates for the Sitecore Product Support Lifecycle is available on the Sitecore knowledge base at https://kb�sitecore�net/articles/641167�

Sitecore periodically releases revisions to each minor version� Revisions are labelled one of three ways:

■ Hotfix A special release designed to address a single issue

■ Update Rolls up generally applicable hotfixes and other bug fixes and minor enhancements since the last Service Pack

■ Service Pack Rolls up updates and hotfixes and often includes product enhancements

Careful consideration should be given to the Release Notes before applying a revision, but in general:

■ Apply a Service Pack to any revision in the same minor version (e.g. v6.5 or v6.6).

■ Updates must be applied in order, one at a time beginning from the last Service Pack.

■ Hotfixes should be applied only under the direction of Sitecore Support.

Note that some Sitecore modules have their own revision cycle, including Sitecore Azure module, Sitecore Commerce and the Email Experience Manager� Updates to these modules can also have dependencies on a particular Sitecore application version�

Occasionally when you are applying updates, and more frequently with Service Packs, data structures within the application are changed� The Installation Wizard (part of the Sitecore shell) executes data manipulation tasks to ensure that structures are aligned correctly with the expectations of the code� This is why it is imperative that close attention is paid to executing the update steps in the correct order and with the correct prerequisites�

The upgrade process can be non-trivial, so ensure that sufficient time is allocated for investigation, experimentation, testing and documentation� In a production scenario, it is unlikely that a development team will be able to secure a content freeze long enough to complete the upgrade process from start to finish, particularly where many revisions need to be applied� A better approach is to take copies of the production environment, execute and document the process and complete testing to establish a definitive set of steps that are required� Prepare as many files, scripts and instructions as possible in advance and then execute the process again when all the issues have been identified and addressed and a minimal content freeze window is required�


22

Ideally, the implementation is never more than one or two revisions behind� Aside from the benefit of early access to security and feature releases, this greatly reduces the time, effort and risk associated with the upgrade process�

The export/import alternativeUnder some circumstances, it may be faster to export the Sitecore tree and reimport it into a new Sitecore instance of the new version, rather than performing several in-place upgrades� This can apply if the revisions to be applied do not include changes to data structures and the Sitecore implementation is “straightforward” from a data hierarchy perspective�

Unfortunately, it is not possible to prequalify whether this approach will be successful without careful reading of the Release Notes for all revisions to be applied� In circumstances where it is applicable, however, a considerable time saving can be achieved by using this technique�

Where a large number of updates are to be applied, it may be worthwhile to attempt an export / import as a first step and to use a regression test to check for problems� Sitecore rarely deprecates APIs or makes breaking changes to the SDK, so problems with the custom code in a Sitecore implementation are rare�

Updating the implementationWith each new update to Sitecore comes new functionality� Updating the Sitecore application provides access to this new functionality, but that is not a guarantee that the implementation is taking advantage of these new features� As part of the upgrade process, it is important to identify any new functionality from the Release Notes and determine whether changes to the implementation need to be made in order to take advantage of them�

Telemetry and APMA number of providers are available to provide various levels and types of performance monitoring, and price can vary considerably� It is important to check that any monitoring suite is compatible with the architecture required for the organisation and not the other way around� Note that some tools, New Relic, require additional code to be deployed alongside your website, or an agent to be installed on a VM whereas others rely on the telemetry and monitoring APIs provided by the platform� In general, the visibility provided by code and agent-based APM tools is superior to that of agent-less ones�

Popular monitoring suites include:

■ Application Insights Application-level telemetry wired into the Azure Portal by Microsoft for Azure

■ Operational Insights Agent-based monitoring by Microsoft for Azure; works with System Center

■ NewRelic Provides O/S monitoring for VMs and APM monitoring for Azure Websites and Web Roles

■ AzureWatch Agentless monitoring with scale control features

■ DataDog Provides an entire DevOps collaboration platform as well as monitoring tools but has no support for Azure Websites or Azure SQL at present.

■ Nagios IaaS monitoring only – an industry staple

■ Pingdom Basic agent-less availability monitoring

Continuous Integration and Continuous DeliverySitecore on the Azure platform is well suited to Continuous Integration and Continuous Delivery, and there are many tools that can be used to facilitate this� The approach available and configuration of these tools are beyond the scope of this document, but it is useful to have a point of reference for tools that are known


23

to work well in this environment for a new Sitecore implementation or if an existing Sitecore implementation has not yet incorporated a CI/CD process�

Continuous Integration vs. Continuous DeliveryThere is commonly some confusion about these terms, so it is helpful to start with some definitions�

Continuous IntegrationThis is the practice of continuously and automatically merging and testing all developer working copies of a project� It relies on a centralised source control system and centralised “build” and “test” servers that will respond to code updates and automatically merge changes into a combined working set, applying unit and automated system testing to the code and alerting the team to any issues encountered or tests failed�

Continuous DeliveryThis is the practice of automating the deployment pipeline� It is commonly paired with Continuous Integration, whereby a successful CI round will be automatically deployed to production (or non-production) environments�

Continuous DeploymentThis term is generally considered interchangeable with Continuous Delivery� Where both terms appear in a context, the distinction is sometimes raised that Continuous Delivery means that code is proven to be deployable all the time (but isn’t actually deployed all the time and is deployed manually as required), where, Continuous Deployment adds the step of actually deploying the code automatically�

In this document, the terms Continuous Delivery and Continuous Deployment are used interchangeably, since the act of “proving code to be deployable” is a subset of the tasks generally understood to form part of Continuous Integration� This is an area of some debate�

Continuous Integration approachesAs Sitecore is an ASP�NET application, the most common (but not only) development platform is Visual Studio� The most popular CI setups for Visual Studio generally

employ Microsoft Team Foundation Server, Microsoft Visual Studio Online and JetBrains TeamCity� TeamCity can also be used in conjunction with VSO/TFS in place of the build functions; it also supports Git, Mercurial and SVN for source control� There are plenty of examples of these working with Sitecore on the internet�

Continuous Delivery approachesContinuous automated deployments carry some element of additional risk to traditional deployment models� The CD practice mitigates this risk through a “fail fast, fix fast” mentality� Sitecore is an enterprise CMS, and few enterprises will tolerate issues and outages on their production websites, even if they are brief� It is, therefore, uncommon to find an organisation looking to employ continuous deployment all the way through to their production environments� Far more common is to have the output from CI servers continuously deployed to a centralised development server or QA server� From there, additional automated test tools can be brought to bear to ensure that the operation of critical functions are not affected by new code deployments�

As an ASP�NET application, all CD approaches that are valid for ASP�NET and for the deployment architecture in your organisation are very likely to be valid for use with Sitecore�

Some tools that can be used to facilitate Continuous Deployment of Sitecore to QA include the following:

■ MSBuild – the default build automation platform for Visual Studio. Powerful stuff.

■ PowerShell – advanced scripting platform for Windows that can be incorporated into MSBuild. Also very powerful and worth learning.

■ Sitecore PowerCore – PowerShell extensions to assist in deployment efforts tailored to Sitecore’s requirements.

■ Octopus Deploy – automated deployment tooling specifically for .NET. Comes with the added advantage that it can package and deploy supporting Windows Services and other application as well.


24

Many of these tools have special adaptations for delivering to the various Microsoft Azure website hosting strategies, but not all tools support all types of websites� Notably there is little “out-of-the-box” support for Continuous Delivery to Cloud Service Virtual Machines, but this can still be achieved by treating each VM instance as a stand-alone deployment target, at the cost of not respecting update domain configuration�

Continuous contentUnfortunately, Sitecore comes with an additional challenge over regular ASP�NET content�

Under most circumstances, it is not sufficient to simply deploy code; we need to handle the additional complexity of automatically delivering content elements� At a minimum, this will include layout items, templates and settings but will very often include regular content that can be hard to separate programmatically from test data�

There are a number of tools and strategies that can be used to achieve continuous content updates, such as:

■ Sitecore Unicorn 2 – an open-source serialisation and synchronisation tool powered by a custom data provider.

■ Team Development for Sitecore – uses item serialisation to make Sitecore content part of the source control system and provides support for deserialising items in remote Sitecore deployments.

■ Sitecore Courier – Creates native Sitecore packages automatically, based on applied filters used to determine eligible items.

■ Sitecore PowerShell Console – framework functionality for creating packages and manipulating items in local and remote Sitecore implementations.

■ Glass Mapper Code First – Glass for Sitecore is an ORM that wraps Sitecore template items in type-safe POCOs. Glass has a “code first” mode that can be used to create or amend template structures on system startup. This solution works only for templates.

Most approaches rely on Sitecore packages and/or item serialisation� Mileage will vary, so research and experimentation will be required to find the model that suits the team and particular implementation� There is no universal “right way”�


25

Glossary of Azure servicesThe following table of terms provides a brief overview of some of the services available on the Azure platform that are most likely to be found in a Sitecore deployment� The scope and number of services available on Microsoft Azure grow each month – find much more information about the platform and its capabilities at http://azure�microsoft�com�

API Management

The Azure API Management solution provides a mechanism for providing access to a public-facing API� It encapsulates access management components with throttling and quotas as well as providing a self-building documentation site� If there is a public-facing API component to a Sitecore application, then this service is well worth a look�

Automation

Azure Automation supports the creation of Run Books, which are PowerShell scripts that can act upon resources in Azure� These are used to automate all manner of administration tasks such as the cleanup of backups stored in a blob container or the scaling or shutdown of Azure services on a schedule�

Backup / Recovery Services

Backup (previously Recovery Services) provides an agent-driven file-level continuous backup solution for Windows servers� This is an ideal solution for providing point-in-time recovery for websites that require deployment on IaaS virtual machines or for supporting VMs in an Azure infrastructure�

CDN

The Azure CDN provides automatically routed, performance-based access to resources held in blob storage or served through Azure Websites or Cloud Services� The CDN supports the use of query strings to differentiate assets, which is a necessity for use with Sitecore’s ASHX media handler system� At this time, the Traffic Manager cannot be used in conjunction with the CDN service, as the CDN promotes content directly from a Cloud Service, storage account or Website�

Cloud Services

Cloud Services are wrappers for VMs and Web and Worker Role applications� In each case, a VM is provisioned to support your application, but the features and configuration mechanisms vary greatly�

It is generally preferable to use PaaS services such as Web Roles and Websites in favour of raw virtual machines, due to the range of features, built-in availability and reduced maintenance required.

Machine Learning

Azure Machine Learning is a set of tools and prefabricated algorithms that can be used to generate predictions and trends by processing historical data� Although this service greatly lowers the barriers to entry for ML, a decent amount of domain knowledge with respect to analytics and predictive analysis is still required to make use of the platform� At Sitecore’s Digital Trendspot 2014 conference, we saw how Sitecore is already experimenting with packaged ML resources that can be used to power the next level of data-driven marketing�

Media Services

Azure Media Services provides encoding/transcoding, storage and streaming services� Media can be delivered to various iOS, Android, Flash and Windows devices and platforms and makes use of the Azure CDN for delivery�

Mobile Services and Push Notifications

Mobile Services provide a support layer for any mobile application that you might be building� They provide convenient cross-platform data services, authentication and push notifications� iOS, Android and Windows Store/Phone are supported, as is the use of either JavaScript or �Net for back-end code�


26

Multifactor Authentication

For high security applications, Azure provides a Multifactor Authentication service that can be connected to Sitecore, though there is no generic module available at present to do so� Supported authentication factors include: Call mobile phone, Text mobile phone, Call office phone, Respond to app notification and receive one-time password through app� Some additional work will be needed to make Sitecore work with this system but integrating this service will be far more cost-effective than creating a similar service from scratch�

Networks

Azure provides networking features that allow for the provision of VLANs� This is particularly useful where it is important to know the IP address of various machines in an Azure environment, as IPs provisioned by the Azure controller fabric are subject to change, and often do� Azure provides the ability to configure a DNS server for each network, which should be a VM with the first usable IP on the subnet�

Redis Cache

The Redis cache key-value store is the recommended technology for shared-session and shared-cache across load-balanced VMs and multi-instance Cloud Services and Websites� A Redis Cache ASP�NET Session State Provider is available from Microsoft as a drop-in replacement to other out-of-process session providers, making adoption of the technology very simple�

Scheduler

The Scheduler is used to execute HTTP/HTTPS requests on a timer and track the responses� This system is perfect for triggering the execution of a web service at a set interval, say to process any messages that have accumulated in a storage queue, and record the response�

Service Bus

Azure Service Bus provides an infrastructure for widespread communications and large-scale event distribution� There are connectivity options for both WCF and REST endpoints� Of particular interest with respect to Sitecore websites is the durable brokered

queue which features FIFO, automatic deduplication, at-most-once and at-least-once delivery and long message lifetimes� This is ideal for decoupling supporting systems from the main Sitecore site, such as the sending of triggered emails or long-running background tasks�

SQL Azure

SQL Azure provides SQL 2014 databases as a service� They incorporate many features of a SQL AlwaysOn Availability Group at a fraction of the cost and configuration and maintenance effort� Databases are provisioned onto a “server”, but this should be considered more of a database container than a server in the traditional sense� Since databases can be provisioned and scaled independently of one another, this is an ideal candidate for hosting Sitecore databases, where the capacity requirements vary dramatically from one database to another� There are some limitations on the functionality available in SQL Azure compared to regular SQL Server, and these must be accounted for during deployment� Important features include Georeplicated readable secondaries, built-in auditing, automatic backup and elastic scaling (currently in preview)�

Storage

Azure Storage encapsulates a number of standalone and supporting services to other Azure features� Notably, page blob storage is used to house the VHD files of VMs and Cloud Services� Blob storage is also used as a backing store for the Azure CDN, and since an individual blob gets a unique URL, it makes for an excellent repository for static website resources�

Azure Storage also provides table and queue storage, which have many useful application-level features in their own right� It should be noted that storage queues have some limitations when compared with Service Bus queues: messages have a lifetime of less than seven days, they are not guaranteed FIFO, there is no long-polling support and deliveries are not guaranteed to be at-most-once� On the positive side, storage queues can handle over 80GB of messages in a queue�


27

Each storage account is limited to 500 IOPs, but multiple accounts can be used to greatly increase throughput for disks attached to VMs, shared storage and static asset delivery.

Traffic Manager

Traffic Manager is a DNS service that provides smart traffic routing using three modes: Round-Robin, Failover and Performance� Endpoints are configured that consist of Azure Cloud Services and Azure Websites� In Round-Robin mode, Traffic Manager will distribute traffic to each configured endpoint in turn; in Failover it will send all traffic to nodes that are determined to be “up” in order; in Performance it will use geographic information to route visitors to the nearest service location�

Virtual Machines

These are traditional IaaS machines that can be licensed with SQL Server, Oracle or other software� A range of add-on software is available, including antivirus, ALM (monitoring) and deployment technologies (such as Chef)� A number of operating systems are supported, including various Windows and Linux varieties as well as preconfigured images for SQL Server, SharePoint, BizTalk and the like� Once provisioned, all VMs are “wrapped” in a Cloud Service automatically and become an Instance of the service�

Visual Studio Online

VSOnline provides source control, team collaboration and project management features that are tightly integrated into Visual Studio� This is an ideal platform for a geographically distributed team and incorporates many features focussed on streamlining Continuous Integration and Continuous Delivery to other Azure services�

(Azure) Websites

Sitecore can be run on an Azure Website� These are the simplest containers for a web application on Azure,

and they can be used to serve ASP�NET, PHP and static content� Essentially these are IIS-as-a-service� In contrast to Cloud Services, there is no access to the underlying VM by Remote Desktop, there is no capability to write files outside of the web root and there are fewer scale options available� Deployment slots for Azure Websites are currently in preview� The Deployment Slot feature of Cloud Services has been the most compelling reason to choose a Web Role Cloud Service over an Azure Website for Sitecore�


28

About the Authors

Richard Hauer – PING SydneyRichard Hauer is the CTO and Chief Architect for PING Works in Sydney, Australia� He has been working with Sitecore technology since 2010 and is a 20-year veteran developer specialising in Microsoft stack technologies�

Richard has been fortunate to receive a Sitecore MVP - Technology award four consecutive times between 2012 and 2015�

Contact Richard through the following channels:

Blog site ping-works�com�au/blog

Twitter @richardhauer

LinkedIn au�linkedin�com/in/richardhauer/

PING Works is a leading digital agency in Sydney and Auckland specialising in Sitecore and Microsoft-stack technologies and well known in the industry for delivery of the most technically demanding implementations� PING provides consulting in digital strategy, user experience, SEO/SEM and technology as well as creative design, implementation services and fully managed hosting services specialising in Microsoft Azure�

PING is a Sitecore Partner for both Hosting and Implementation and one of fewer than 30 partners globally to have multiple staff members with a Sitecore MVP award�

Contact PING through the following channels:

Website ping-works�com�au

Email sales@ping-works�com�au

Jerry Norman-Nott – Sitecore Australia / New ZealandJerry Norman-Nott manages the Sitecore partnerships across Australia and New Zealand with an emphasis on technical enablement and business nurturing�

Jerry has a long history in the technology industry with a deep understanding of the Sitecore platform, Cloud computing and Microsoft technologies� He has held senior leadership positions in agencies, software houses and system integration partners for the last 10 years�

Jerry is a regular speaker at industry events on topics ranging from cloud hosting to print strategies�


29


30

ReferencesNote that in early 2014, Microsoft rebranded “Windows Azure” to “Microsoft Azure” – these terms may be used interchangeably�

General

Azure Icons and Symbols for Visio & PowerPoint http://www�microsoft�com/en-us/download/details�aspx?id=41937

Azure Pricing Information http://azure�microsoft�com/en-us/pricing/

Blitz�io Load Testing http://blitz�io

Wikipedia: Continuous Integration http://en�wikipedia�org/wiki/Continuous_integration

Wikipedia: Continuous Deployment http://en�wikipedia�org/wiki/Continuous_delivery (via redirect)

Wikipedia: Continuous Delivery http://en�wikipedia�org/wiki/Continuous_delivery

Wikipedia – Microsoft Azure http://en�wikipedia�org/wiki/Microsoft_Azure

Azure

Architecture

ASD security certifications to boost Azure’s Australian cloud: MS http://www�cso�com�au/article/556776/asd-security-certification-boost-azure-australian-cloud-ms/

Azure Data Security (Data Cleansing and Leakage) http://blogs�msdn�com/b/walterm/archive/2012/02/01/windows-azure-data-cleansing-and-leakage�aspx

Azure Fault Domains and Upgrade Domains Explained (Reprised) http://blogs�technet�com/b/yungchou/archive/2011/05/16/window-azure-fault-domain-and-update-domain-explained-for-it-pros�aspx

Azure Network Security Whitepaper (Nov 2013)

http://download�microsoft�com/download/4/3/9/43902EC9-410E-4875-8800-0788BE146A3D/Windows%20Azure%20Network%20Security%20Whitepaper%20-%20FINAL�docx

Azure Operational Insights https://preview�opinsights�azure�com/

Azure Service Configuration Schema (�cscfg File) https://msdn�microsoft�com/en-us/library/azure/ee758710�aspx

Azure Service Definition Schema (�csdef File) https://msdn�microsoft�com/en-us/library/azure/ee758711�aspx

Azure Speed Test http://azurespeedtest�azurewebsites�net/ Note: try this in a few browsers as there can be quite a discrepancy; IE seems to produce the most reliable results (honestly)�

Azure Storage Queues and Service Bus Queues - Compared and Contrasted http://msdn�microsoft�com/en-us/library/azure/hh767287�aspx

Azure Trust Center portal http://azure�microsoft�com/en-us/support/trust-center/

Azure Websites, Cloud Services, and Virtual Machines comparison http://azure�microsoft�com/en-us/documentation/articles/choose-web-site-cloud-service-vm/

Azure Websites and wildcard domains http://azure�microsoft�com/blog/2014/04/23/azure-websites-and-wildcard-domains/

Azure Websites vs Web Roles http://robdmoore�id�au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/

Top 10 lesser known facts about Windows Azure Security http://www�lifehacker�com�au/2013/04/top-ten-lesser-known-facts-about-windows-azure-security/

Monitoring


31

Add Application Insights SDK to your web project http://azure�microsoft�com/en-us/documentation/articles/app-insights-start-monitoring-app-health-usage/

PowerShell

Create Backups of Virtual Machines in Windows Azure by using PowerShell http://blogs�technet�com/b/heyscriptingguy/archive/2014/01/24/create-backups-of-virtual-machines-in-windows-azure-by-using-powershell�aspx

Enable PowerShell Remoting on Windows Azure [Web & Worker Roles] http://www�davidaiken�com/2011/01/12/enable-powershell-remoting-on-windows-azure/

SQL Server

Azure SQL Database documentation http://azure�microsoft�com/en-us/documentation/services/sql-database/

Azure SQL Database Transact-SQL Reference http://msdn�microsoft�com/en-us/library/ee336281�aspx (SQL Server features that are partially supported or not supported on SQL Azure)

Don’t Forget About Index Maintenance on Windows Azure SQL Database https://alexandrebrisebois�wordpress�com/2013/02/06/dont-forget-about-index-maintenance-on-windows-azure-sql-database/

Fragmentation in SQL Azure! http://blogs�msdn�com/b/dilkushp/archive/2013/07/28/fragmentation-in-sql-azure�aspx

SQL Azure Migration Wizard – Codeplex Project https://sqlazuremw�codeplex�com/

Development

ASP�NET Session State Provider for Azure Redis Cache http://msdn�microsoft�com/en-us/library/azure/dn690522�aspx

Distributed locks with Redis http://redis�io/topics/distlock

Deploying on Azure Websites from on-premise TFS http://www�codewrecks�com/blog/index�php/2013/07/05/deploying-on-azure-web-sites-from-on-premise-tfs/

How to Use Azure Redis Cache http://azure�microsoft�com/en-us/documentation/articles/cache-dotnet-how-to-use-azure-redis-cache

Integrate a cloud service with Azure CDN http://azure�microsoft�com/en-us/documentation/articles/cdn-cloud-service-with-cdn/

Running Windows PowerShell Scripts from MSBuild Project Files http://www�asp�net/web-forms/overview/deployment/advanced-enterprise-web-deployment/running-windows-powershell-scripts-from-msbuild-project-files

Which Azure Cache offering is right for me?


32

http://msdn�microsoft�com/en-us/library/azure/dn766201�aspx

Sitecore

Continuous Deployment in Sitecore with PowerShell http://blog�najmanowicz�com/2011/12/19/continuous-deployment-in-sitecore-with-powershell/

Glass Code-First Templates http://s399856118�websitehome�co�uk/tutorials/glass-sitecore-mapper-tutorials/tutorial-13-code-first-templates/

Sitecore Azure Module http://sdn�sitecore�net/Products/Sitecore%20Azure�aspx

Sitecore Product Support Lifecycle https://kb�sitecore�net/articles/641167

Sitecore Scaling Guide v6�6 http://sdn�sitecore�net/upload/sitecore6/66/scaling_guide_sc66-a4�pdf

Sitecore Scaling Guide v7 http://sdn�sitecore�net/upload/sitecore7/70/scaling_guide_sc70_a4�pdf

Sitecore Security Hardening Guide v7�5 http://sdn�sitecore�net/upload/sitecore7/75/sitecore_security_hardening_guide-sc75-a4�pdf

Sitecore is the global leader in customer experience management� The company delivers highly relevant content and personalised digital experiences that delight audiences, build loyalty, and drive revenue� With the Sitecore® Experience Platform™, marketers can own the experience of every customer that engages with their brand, across every channel� More than 4,400 of the world’s leading brands–including American Express, Carnival Cruise Lines, easyJet, and L’Oréal–trust Sitecore to help them deliver the meaningful interactions that win customers for life�

Sitecore on Azure Migration - White Paper

Technology

Transcript of Sitecore on Azure Migration - White Paper