# Motivations

* Customer demand (example customer feedback chosen at random:
"We’re setting up our production instance of chef-server today, and we’re struggling w/ the ability to use external postgres, and redis databases. Any help with this would be great."

* Easier to sell OHC as a service that platform partners could run (e.g. why restrict OHC to running it ourselves; why not have Azure or AWS run it for us as a service and just give us money & the telemetry)

## Overall objective

Make Chef server as "stateless" as possible or at least in such a way that you can externalize all the state from the actual server machines

## Features:

* Support external PostgreSQL databases
* Support external search cluster (or consider migrating away from Solr?)
* Remove serialized gzipped JSON blobs in database, use native JSON-B support in PostgreSQL 9.4 when it comes out
* Eliminate redis from the stack / or at least allow redis/lua routing rules to be hardcoded & turned off by default (unnecessary complexity when running on-premise)
* Improve HA/tiered setup procedure.
  - Should be able to stand up multiple backends (even more than two if you want)
  - Able to cross the region/AZ boundary on an HA setup.
  - Should be able to stand up N number of frontends
  - Stand these up in any order. Autodetection of whether a cluster has been "bootstrapped" or not
* Improve upgrade scenarios
  - Should be able to upgrade any piece in any order, other pieces should be able to figure out what to do
  - In practice it might not be "anything", but for example, you could upgrade the BE's first without taking down FE's and the FE's would be able to figure out if they're compatible with the BE version in question and serve/not serve requests appropriately