In our previous two Solr articles we looked at Solr vs SolrCloud and How to configure Sitecore with SolrCloud. This third part looks at a viable alternative to SolrCloud.
Solr has been the preferred (and Sitecore recommended) index provider for setting up Sitecore solutions, and is enabled by default in the Sitecore installation scripts.
Standalone Solr instances are the best option to consider for development and test environments, whereas SolrCloud is a more reliable and scalable option for UAT and production environments. Sitecore has started to provide full support on SolrCloud starting with XP 9.0 Update-2 and later.
With the increased popularity of setting up Sitecore PaaS, Microsoft Azure Search has also become popular. It's one of the few options to configure search indexes for Sitecore as a service. However, it does come at an extra cost, and it has some limitations.
For solutions where the limitations introduced by Azure Search with Sitecore are not acceptable, or Sitecore instances hosted on other platforms than Azure, then Azure Search might not be an option.
SearchStax
One viable alternative for Sitecore index providers is available through SearchStax. SearchStax offers a robust solution by providing 'Solr as a Service' for Sitecore.
This service has the advantage of having all the features and power of Solr, as well as the up-time, maintainability and scalability of SolrCloud - all with minimal configuration and support required from the development and infrastructure teams.
Cost & complexity of SolrCloud
SolrCloud is a better alternative than a combination of multiple Solr standalone instances which was the approach taken with Sitecore environments for versions older than 9. Multiple instances of Solr were needed to ensure a better up-time and zero downtime deployments.
A typical instance of SolrCloud for production consists of 3 servers and a load balancer. For example, a live infrastructure diagram would refer to the Solr instances:
This needs to be replicated for UAT and DR environments (if active). This gives a total of 6-9 servers that serve the search role and 2-3 load balancers for non-prod / prod / DR setup.
It’s also important to ensure Zookeeper is installed and is configured in a Clustered Environment that is required for SolrCloud.
For light workloads, you could run Zookeeper on the same Solr instance, however, it’s not advised to run Zookeeper on the same Virtual Machines (VM) where SolrCloud is running as this requires a much higher footprint for true high availability.
At Codehouse, we've made the setup of this more efficient by scripting the servers' creation and configuration, as well as automating the deployment for new cores.
However this has come at a time-cost in various internal projects, as well as the time needed to experiment, test and perfect the configuration. Then there’s still the time and complexity to set aside for maintenance and upgrades to ensure the compatibility with newer Sitecore versions.
Solr as a Service
Solr as a service is an interesting and appealing concept for developers, especially Sitecore and .NET developers.
Since Solr was introduced for Sitecore, there has always been the need to learn and configure extra tools and software such as Apache and NSSM, culminating with the complex setup needed for SolrCloud.
Sitecore developers needed to learn the basic concepts of hosting and configuring Java applications to be able to support an end-to-end Sitecore setup. This is great from a learning perspective, but these areas aren't always the strongest point of expertise for a .NET developer. This could lead to spending more time doing low-value basic tasks and most likely wouldn’t then offer the same level of support as an experienced Java specialist.
With Solr as a service, rather than investing time and money in configuring a complex cluster setup for search, the developer’s effort is focused back into resolving complex functionality and enabling Sitecore’s marketing and experience features into the web solution.
This allows the infrastructure team to focus on designing and enabling a high-performance system without having to carry the setup and maintenance burden of the extra servers needed to enable the cluster.
Using Solr as a service instead of SolrCloud saves time and effort in deploying and configuring the SolrCloud minimal configuration. It's very suitable for projects with strict or short timelines. It also saves costs in hosting, maintaining and deploying the extra servers and resources needed for SolrCloud.
Solr as a service also offers a viable (and only) alternative to Azure Search when hosting Sitecore as PaaS. When deciding on hosting an application as PaaS, the last thing to consider is hosting an extra set of VMs to enable search. This makes SearchStax a viable alternative to Azure Search.
Benefits of SearchStax
The SearchStax solution has many benefits that are worth taking into consideration when choosing the hosting option for your search engine:
- Less complexity in configuring and installing Solr, and less development effort to consider
- Reduced overall costs in hosting and infrastructure support
- Easy path for deployment automation
- Enhanced monitoring and alerts dedicated for Solr search engine
- Scalable and easily accessed log management
- Back up / Disaster Recover / Scalability
- Easy path for upgrades
- Dedicated support
- Private cloud instances (VNet Peering or VPC Peering) if extra security is needed (Azure, AWS, Google providers are available)
SearchStax provides an exciting alternative to replace all the complexity in setting up and maintaining SolrCloud instances by offering Solr search as a managed service.
Configuring 'Solr as a service' on Sitecore is very easy. Besides providing extensive documentation on their website, SearchStax has a Sitecore Solr Plugin to quickly configure Sitecore and Solr. In addition, SearchStax was recently recognized as a Sitecore Technology Alliance Partner for its ability to accelerate time-to-value for customers.
