We are currently in the process of evaluating Sitecore PaaS (Platform-as-a-Service) on Azure for one of our customers. It is in fact a migration of large multi-site Sitecore implementation – scaled out CM tier, scaled out CD tier, dedicated publishing and indexing server, SolrCloud and having ~50 websites per environment. It is still early days in our evaluation, but I thought of sharing my experience so far and the limitations that I see with Sitecore PaaS.
Note: the limitations mentioned here are in the context of our Sitecore application and its architecture. I do not necessarily consider them as Sitecore limitations, but something to support in upcoming versions.
No Support for Multiple Publishing Targets
By default, you only have one publishing target supported, i.e., the Web database. If your application uses multiple publishing targets (ex: Staging and Live), then there is no provision to spin up an environment with such a deployment configuration. This is similar to the default Sitecore installation on premise.
Scalability Challenges in CM Tier
All Sitecore PaaS deployment configurations (xM1 through xM5) creates only a single CM server in the Basic (B2) service plan. As you may know, Basic plan does not provide Auto Scale and Load Balancer. So there is no way for you to scale up or scale our the CM tier automatically. You will need to manually change the service plan.
Also, B2 instance provides only 2 cores, 3.5 GB RAM and 10 GB of storage. This will definitely not be enough for large Sitecore installations such as ours.
No Support for Dedicated Publishing Instance
Due to the large volume of content authoring and publishing in our Sitecore application, we have a dedicated Publishing Instance so as to have a better content authoring performance. However Sitecore PaaS does not support this today, i.e., having a separate set of config files on one of the CM servers to designate it for publishing. As mentioned above, it anyway doesn’t support multiple CM servers.
No Support for Dedicated Indexing Instance
We use Solr Cloud today as our indexing solution, and in such instances, you would want one of your servers acting as the dedicated Indexing Instance that is responsible for sending indexing requests to Solr Cloud. This is typically done again through a separate set of config files on one of the CM servers to designate it for indexing. This is also not supported by Sitecore PaaS today. Again it anyway doesn’t support multiple CM servers.
And yes, we intend to use Solr Cloud on IaaS mode rather than Azure Search.
There may be others that we may uncover as we progress along. But I do believe that all of these limitations can however be overcome if you customize the ARM templates used by Sitecore PaaS for your deployment topology. We intend to do this and I will share our approach and experience in an upcoming post.