When moving your Sitecore infrastructure/solution to the cloud, there are two main deployment strategies to choose from: Infrastructure-as-service (IaaS) and Platform-as-service (PaaS). IaaS is a virtual server hosting approach where we are responsible for operation system (OS), middleware, runtime, Sitecore software and the application on top of it. PaaS enables us to focus explicitly on what matters most: Sitecore software, application and configurations. There’s no doubt that Sitecore deployed on the modern Microsoft Azure PaaS infrastructure remains strong on the agenda, but when we dig a bit deeper we will see that there are more aspects to be considered. Here, we’ll explain the different options for Azure App Services SKUs and how they relate to the choices we need to make when designing Sitecore solutions on PaaS.

Understanding Sitecore PaaS

Native support for Sitecore with Azure App Service (PaaS) has been introduced from version 8.2 update-1. It comes with an appealing value proposition: minimizing operational and administrative burden, increasing availability, optimizing for scale, simplify maintenance and enable greater speed to market. But when an organization reaches its decision point for this model, they must consider detailed requirements. That’s because the Azure App Service Web Apps (or just “Web Apps”) platform, which is the hosting layer/ecosystem for Sitecore XP, has two flavors with distinctive characteristics:

• Azure App Service Web Apps is a service for hosting web applications by leveraging a fully-managed platform to take care of infrastructure maintenance. It is also referred to as a multi-tenant application hosting service.
• Azure App Service Environment (ASE, also called “isolated”) is a single-tenant instance of the Azure App Service that provides a fully isolated and private dedicated environment. It is isolated to run only a single customer's applications and it is always deployed into a virtual network.

The table below outlines the distinct characteristics which must be mapped against the requirements for the solution being built.

The main difference is the way workloads for each Azure customer are internally deployed and isolated. This directly impacts how security, scalability and connectivity scenarios can be achieved. In the multi-tenant approach, Sitecore roles (content delivery, content management, processing, xConnect, etc.) by default are always accessible via public internet. There is a workaround to restrict access by using IP and domain restriction but, fundamentally this is not scalable. Imagine how challenging it would be to manage these restrictions in a situation of multiple environments as production, UAT, test, dev etc. and multiple Web Apps.

Sitecore PaaS for enterprises

Sitecore’s official tools and assets utilize multi-tenant Web Apps approach. This includes Sitecore Azure Toolkit, Azure Resource Manager (ARM) templates, web deploy packages, Azure Marketplace and Sitecore Managed Cloud Standard. These assets are a great starting point, and the model will work as-is for many Sitecore customers and their scenarios.

However, for the enterprise customers where the requirements around security, scalability, and connectivity are more demanding, things are get a bit more complex. Typical enterprise customers support multiple applications/systems both in the cloud and on-premise. Their IT groups usually have defined governance processes for Azure subscriptions management for each business unit, strict security policies, identity management, team enablement for projects in isolation and cost tracking. Each project usually has multiple environments such as dev, integration, test, UAT and production. Content editors, marketers, testers and support personnel need to access resources in a consistent and secured way. The solutions are rarely isolated islands; they need to connect and integrate with a variety of other systems/services - securely and reliably.

In the end, just choosing Sitecore PaaS as a strategy is not enough; we must make extra considerations when designing these enterprise Sitecore solutions. This is why a complete understanding of Azure PaaS technology is needed to meet advanced security and connectivity requirements.

When to choose ASE?

The choice between the two forms of Azure App Service deployments drills down to security, scalability and connectivity. It is important for organizations to take a holistic approach when putting web properties in the public cloud that require enterprise grade management.

Go with Sitecore PaaS deployment in multi-tenant App Service when:

• “Go-to-market” or environment build speed is important - start quickly with existing pre-build assets from Sitecore
• Network security control and isolation is not a factor
• Cost is a major factor
• Scalability limitations are acceptable

Go with Sitecore PaaS deployment in single-tenant / isolated App Service Environment (ASE) when:

• Security and isolation of network access/control are must-haves (private access & connectivity)
• Full-fledged Web Application Firewalls (WAF) security feature is needed
• Extended high scalability and memory utilization is expected
• Cost is not the primary driving factor
• Flexibility is required to dynamically address performance needs

A general decision flow for evaluation of Sitecore PaaS feasibility can look like this:

Adopting Sitecore with modern PaaS is a tempting proposition, but it requires deeper understanding to evaluate if it is the right choice for any given scenario. We at Avanade have worked with many different clients – by size, industry and scale perspectives. Contact us to learn more about the Digital Marketing services we provide and even more we can help you with.