Back in early 2010, when the first version of Elasticsearch was released, the future (we were reliably informed) was orange. Or was it black? Or green? Nobody really knew. Nobody knew how the NoSQL space would envolve, nor how Elasticsearch would end up being used.

Back then, we tried to have a horse in every race. You could talk to Elasticsearch with JSON, YAML, SMILE, CBOR, Thrift, and Memcached protocol. You could specify settings using JSON, YAML, Java properties, and environment variables. We logged to Log4J and SLF4J. There were three ways to configure mappings. And templates. And analyzers. Elasticsearch could run standalone or embedded. Your HTTP web servers could join the Elasticsearch cluster as real nodes. Plugins could override pretty much any part of Elasticsearch, replacing integral parts of the core.

One of the things that made Elasticsearch so popular was its flexibility and its familiarity. It was easy to get started, and easy to integrate Elasticsearch into your application, no matter how unusual the design.

Six years later, Elasticsearch has evolved into a powerful search and analytics engine. It has been downloaded by millions of people and is a core technology depended upon by hundreds of thousands of users and companies. Flexibility and leniency are no longer as important as:

A reliable stable cluster

Predictable performance

Clear error messages

Warning early about problems that may occur in production

Safety from attacks

Flexibility comes at a price: complexity. With so many alternatives it is impossible to test them all and to be sure that they actually work. Complexity interferes with the goals listed above. We can’t have it all, so we have to narrow our focus to be able to deliver a solution that can be relied on.