Why the right Search infrastructure is critical for your Sitecore deployment

Capacity is defined by your infrastructure’s ability to handle the expected traffic based on a given configuratio

Search is critical to a great customer experience

Buyers in both B2C and B2B buying cycles demand a relevant, personalised search experience to help them navigate the vast amounts of information required to make a decision. Whilst Google and other search engines do a great job of getting users as deep into the site as possible, it can be upwards of 30% of visitors who begin their journey at the site's home page, preferring site search over other navigation and menu elements.

Journeys which originate from a public search engine, typically lead users to pages that contain partially relevant information, not an exact answer, product or service they are looking for.

Search plays a pivotal role in the delivery of great customer experiences, however it is often overlooked when designing and implementing enterprise MarTech solutions such as Sitecore. Organisations looking to deploy Sitecore often believe that "if my site doesn't have search, then I don't need a search solution". It is important to remember that search underpins several key production capabilities particularly in a product like Sitecore.

Sitecore features that rely on a search platform such as Azure Cognitive Search, or Apache Solr include;

• Sitecore xDB (Personalisation)
• Sitecore Experience Profile
• Sitecore List Manager (Segmentation)
• Sitecore EXM
• Sitecore Marketing Automation
• Sitecore Content Editor
• Sitecore Experience Optimisation

Failing to invest in the correct search infrastructure can cause significant issues with the Sitecore XP platform including, poor UI performance, slow email dispatches, slow list indexing and segmentation.

For those organisations who need a world-class search experience for their website visitors, failing to invest in the right approach can not only result in a slow front-end searches, but also severely limit your ability to deliver table stakes features like faceting, boosting, relevance and tuning, custom field types, geospatial search and for those in the advanced space, AI powered search.

Sitecore has invested heavily in an incredible search framework that out of the box with minimal development effort will suit a large portion of customers. They also provide an extensible provider framework that allows 3rd parties to deliver even more powerful cloud-based search solutions, including our friends over at Coveo.

So which Sitecore search solution is best?

Well, we are not here to tell you that specifically today, there are plenty of write ups comparing all of the different options, including one of our own, comparing Azure Search to Solr (which we recently updated for 2021). Deciding between the default and Technology partner driven search solutions is incredibly subjective and typically requires a considered discussion with your Sitecore Partner to decide the right approach. 

Ok, so what's the safest choice for Search provider?

The safe option for the aforementioned "large portion of customers" is Solr.

This is in stark contrast to our previous view we have held since 2017 in that Azure Search was your go to. Sitecore had invested largely in Azure Cognitive Search and created the framework for easy deployments in Microsoft Azure PaaS, easily deployable and along with the Dataweavers technology stack, easy to manage.

However two big reasons why we have shifted our focus to Solr in the last 12 months.

1. Sitecore stopped investing in Azure Search
   We have previously written about a critical flaw in the Azure Search implementation that means key features of EXM, List Manager, Personalisation and Marketing Automation do not work. It's a shame, because this would be a solve for us to continue to champion Azure Search again.
2. Containers made Solr cost effective to deploy and manage
   When working around issue #1, we prototyped a number of deployment options for Solr including Azure Web Apps, Azure VM's, 3rd Party providers. We then decided to experiment with Containerisation of Solr and more specifically the Azure Kubernetes Service (AKS). More on this later.

Previously Solr and more specifically SolrCloud's general complexity and our Dataweavers mandate to be geo-scaled (even if only within country) across all implementations meant we had significant complexity to manage in the underlying Virtual Machines in order to achieve cost-effective scale.

We are also under the impression that Sitecore maybe retiring its support for Azure Search in the future, but this is mostly hearsay and we were unable to find any confirmation in Sitecore materials.

Sitecore has published a list of limitations for Azure Search.

You maybe also be thinking, what if I am happy with the limitations and don't expect to use any of those features you mentioned? Well, you are welcome to make your own path, so long as you consider that the cost of changing providers is not trivial and unlikely something you will want to tackle alone. We do offer it as part of our service catalog for Managed Service customers, but trust us when we say its a painful task!

Tell me about infrastructure?

We have established that in the absence of choosing a 3rd party provider like Coveo, we recommend Solr as your default search provider when deploying in Microsoft Azure. Side note: those deploying Sitecore XM, with low-complexity front-end search experiences are still safe to deploy Azure Cognitive Search.

The discussion now centers around how you should provision Solr or SolrCloud in a way that is easy to deploy, configure, manage, upgrade and most of all, cost-effective.

In the cloud, you typically have the following "diy" choices:

1. Solr standalone on a Virtual Machine
2. Solr standalone on a Azure Web App (yes it can be done, sort of!)
3. Solr standalone deployed in AKS or other Container service
4. SolrCloud deployed across multiple Virtual Machines
5. SolrCloud deployed in one and/or across multiple AKS/Container services

There are significant pros and cons to each approach, the approach we have found best is Option 5. So much so that we chose to migrate almost all our customers to our powerful AKS Multi-tenancy Cloud Platform. We are launching this service standalone for Sitecore customers in late January 2021. Stay tuned.

Apache Solr is a complex beast in production, here's our top list to help those on a Do-It-Yourself journey;

1. What works locally, isn't right for production.
   Many scripts exist for deploying Solr onto local development machines, but many of these bypass the checks and balances needed to run Solr in production successfully. Even if you deploy a single, secure VM in production, please don't rely on these scripts as your only deployment mechanism. Consider production-grade images from Bitnami, or invest time in the Solr documentation and build your own repeatable deployment VM templates.
2. Security is paramount, especially as Sitecore will index PII dataSecurity is not limited to Dedicated SSL, Following the Solr security guide, local machine security, disk encryption, secure secrets and passwords in Azure KeyVault. Don't forget logging and security of your logs too, which if unprotected can become an attack vector. Sitecore xDB with xConnect Search will index PII data and becomes extremely powerful when it does. Consider your RBAC approach and who can access these machines inline with your organisations security standards and policy compliance.
3. Virtual machines are OK, but don't ignore the operating system
   Windows or Linux security is critical to the underlying security profile of any application. Keep it up to date, secure and inline with your organisations security standards.
4. Version, version, version incompatibility will hurt you if you get it wrong
   Solr compatibility is define here: https://kb.sitecore.net/articles/227897
   Also, don't forget to plan your Solr upgrade during your Sitecore upgrade.
5. Real CX performance is about 99% about latency, not sheer machine horsepower
   We could (and probably will) write a whole article about this. Critical to Solr performance is the latency between your Azure Web Apps and the Solr instance. When connecting within and across regions you can come across some serious latency issues, none of which are solved by private networks or Azure technologies, apart from maybe Premium Networking on VM's. We love this tool for testing region latency, it is real-time and provides interesting insights into the Azure network; https://www.azurespeed.com/Azure/Latency 
6. Geo-scaling is not easy and needs careful consideration
   Traffic Manager, Load Balance, Application Gateway, Azure Front Door, Nginx, too many other critical factors to cram into this short paragraph. Whilst the Sitecore CMS and XP backend is very fault tolerant, the Content Delivery server is not and you need to plan effectively how to span across Azure regions to avoid total failure. Who needs another 6 hour Azure US East outage...?
7. Search doesn't escape your IaC and DevOps process
   Custom fields, Solr Manifest, Patches, Versions and configuration is critical to your DR approach. Dataweavers runs a 1 hour and 4 hour RTO respectively, for our different editions. The ability to recover Solr configuration is absolutely imperative. If you are doing it yourself, don't fall into the trap of getting servers back online quickly only to find your waiting hours for Solr configuration and then indexing.
8. If search is critical to your CX and UX, then invest proportionately 
   Regardless of your Search platform choise, consider the impact to your ROI from a correctly implemented, well-maintained and efficient search experience for both end customers and your marketers. In our experience search typically is seen as a after thought, quickly pushed into production, with little consideration for the overall ongoing management.
9. Know your core focus
   Deploying Apache SolrCloud in the cloud, let alone, in AKS isn't something every Sitecore Partner and Customer can afford to do, it is a time consuming investment in technology and likely detracts you from your businesses core focus. Having this open conversation with your customer and leadership can help remove the burden from you to work many of these things out yourself and radically improve your time to market.

Summary

We know that planning a Sitecore deployment (or any enterprise Martech platform of similar capability) is an important and often time consuming process for even the most seasoned Sitecore Professionals. We hope this article helps you make informed choices on the underlying search provider, helps you avoid the mistakes we made getting to Solr on Azure AKS and reduces your time to market.

Next read: 5 reasons we chose to build our multi-tenancy Apache SolrCloud in AKS.