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.
