Sitecore Cloud Architectures

Here at Oshyn, we typically build our Sitecore solutions on either Azure cloud or Amazon Web Services (AWS) cloud. These platforms offer the best combination of performance, cost, security, and control. We have customers who still build on-premises, but that has become less than 50% of new builds. Mostly, the costs vs. benefits of these platforms weigh in their favor so much as to make them a no-brainer (barring other factors). The consolidation onto these platforms has allowed us to specialize in the setup and configuration of production environments in these platforms. We are able to leverage the templating features of Azure (ARM templates) and AWS (cloud formation templates), their respective PowerShell APIs, and Octopus deployments to make installation of these environments repeatable and as efficient as possible.

Azure

The typical basic highly available Sitecore production environment that we configure on Azure looks like the following:

There are some differences in our architecture from what you get with the Sitecore ARM template for scaled environments:

1. Securing all non-public services into a private VNET only accessible via VPN to the corporate network while still leveraging PaaS for CD environments. Using the Sitecore ARM template for scaled environments, all services are on Azure Web App Services and are only able to be secured by IP Whitelisting within IIS. In addition, they are on hardware shared with other Azure customers unless you purchase the ultra expensive App Service Environment. Oshyn's solution solves this problem in a cost effective way

2. Use of Sitecore scalability where it has the most benefit—and not scaling where it does not. Separation of PRC and DDS from CM and REP servers maximizes performance of the editing environment. Scaling of the XConnect services make a key bottleneck highly available and able to scale, if necessary.

3. Use of Solr for search instead of Azure Search. Azure Search has a functional limitation on the number of fields able to be indexed in a single index. In addition, we have experienced intermittency in the performance of Azure Search that we have not seen in many years of using Solr. In addition, the cost for the same performance is less with Linux Solr servers.

Common additions to this architecture include:

1. Connecting the Identity Server to Azure AD for Sitecore console access

2. DNS Service for managing intra-component references and communication

3. Extensive alerts and monitoring with Oshyn’s DevOps services

AWS

The typical basic, highly available Sitecore production environment that we configure on AWS looks like the following:

The characteristics that define Oshyn’s basic highly available Sitecore AWS architecture are:

1. Use of Sitecore scalability where it has the most benefit—and not scaling where it does not. Separation of PRC and DDS from CM and REP servers maximizes performance of the editing environment. Scaling of the XConnect services make a key bottleneck highly available and able to scale if necessary.

2. Network layer separation of public services from private services to maximize security and minimize penetration risks

Common additions to this architecture are:

1. Additional CDs to handle increased load

2. Client VPN to allow remote workers into the content editing environment

3. Route 53 DNS service to manage intra-component references and communication

4. AWS certificate manager

5. Extensive alerts and monitoring with Oshyn’s DevOps services

On-Premises

On-premises architectures are mostly variations of the above but with Sitecore licensing constraints, operating system support limitations (some Sitecore shops don’t want to support Linux for Solr), and availability of services such as Redis and MS SQL or Mongo).