7

Utilizing Azure Search as the Sitecore search provider has various pro's and con's. One question that immediately comes up is how to develop against Azure Search.

SOLR and Lucene can be run locally and tested appropriately prior to deploying. As Azure Search is cloud-based, developers cannot have a disconnected sandbox to test updates to the index.

What options are available for local development when dependent/higher environments (dev/test/stage/prod) utilize Azure Search? What are the pro's and con's to each technique?

9

This is a super tough question to answer and could lend itself to a number of viewpoints, making it difficult to choose the "right" answer. That said, I believe that this is an incredibly important question because it sheds light on the fact that local development becomes not so local in cloud deployments.

Additionally, when trying to do local development requiring services from a cloud service, generally latency can cause slowness in development. On the other hand that can also be helpful, because it reminds you to consider latency when doing your development.

Using Azure Search for Development

Spin up an Azure Search service

Generally speaking, having an instance of Azure Search running in Azure on a Subscription and just using that to connect to on your local environment is the most straightforward method. There are several cons to this, even if the only pro is that you're actually using the service.

Team Considerations

An entire dev team can use the same Azure Search service, but consider having your dev team members change their index names to be specific to their instance. This will prevent issues with item development and database differences if an item exists in an index but not in your database.

Cons

  • Costly - Azure Search service is not cheap and will burn through MSDN Dev Dollars fast.
  • Latency - Azure Search across the public internet from a local environment is slow. This might be ok depending on your needs.

Pros

  • Production Like - Identical service to what you could expect in a production state.
  • Always There - because it's a cloud service, it's always on and there. It also offloads the pressure of needing to use local resources for indexing.

Not Use Azure Search for Development

Depend on the Abstraction Layer

Sitecore's entire point around Content Search was trying to be agnostic around your index provider. The Content Search abstraction layer should work regardless of whether you're using SOLR, Lucene, or Azure Search. That said, a lot of promises are put onto the abstraction layer that needs to be fully tested before going into production. So if you're not using Azure Search for local development, but intend on using it for production environments, you'll want to make sure that you have some environment up the tree that is testing against Azure Search. Unless of course, you want to test in production.

Cons

  • Limitations - Azure Search has a number of limitations that make it hard to have faith in the abstraction layer. This means that even though the Content Search provider allows certain combinations of methods, that doesn't mean it will work on Azure Search in production.

Pros

  • Cheaper/Free - Being able to use SOLR (or dare I even say Lucene) in a development environment is much cheaper (FREE!) than using Azure Search.
  • Off The Grid - Using SOLR locally, or Lucene, allows you to develop off the grid without having to have cloud dependencies.

As an organization, my team has yet to have a need to have Azure Search in production. Most of our clients have been advanced enough to want a SOLR Cloud implementation for a number of reasons including the cost factor. But I see those days coming to an end as more and more adoption of Azure Search as the pathway to full PaaS deployment is desired. That said, we will probably utilize Azure Search as a development service as described in the first part of this answer, at least until something better comes around.

1

When we started using Azure Search we wanted to develop with the search provider used in production to make sure everything worked the same locally as on production.

To solve this we've set up a Dev Resource Group containing the Search Service. The entire team shares the set of indexes available there. We did consider adding developer specific pre- or suffixes to the indexes to really have those separated per developer. However up until now we didn't spend any time on that and the shared indexes do not cause a lot of issues.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.