Docker for Elasticsearch多租户SaaS或单实例和代理？

我正在尝试构建Elasticsearch作为服务的原型.我想到了两种不同的方法,我想对一个或另一个实现提出意见

>一次安装Elasticsearch,并在顶部添加代理层以添加用户验证(http基本身份验证用户帐户以验证使用情况).

这种方法相对简单,主要的挑战是正确配置集群以处理负载以及权限,因此没有数据泄漏的用户无法访问集群管理API.

>使用Docker作为容器,并为每个用户提供一个elasticsearch实例.在这种情况下,我将使用Linux容器(Docker)提供隔离.我仍然需要管理身份验证.

实现这两者,玩游戏并了解事物的行为可能会很好.关于每种方法的利弊的任何意见？

谢谢！

免责声明：我是Elasticsearch服务提供商 Facetflow的创始人,该服务提供商目前提供共享集群.

我认为这两种方法都有价值,但可能适合不同类型的客户.

看看其他SaaS提供商,比如MongoDB提供商MongoLab,他们最终提供了两种设置(尽管不使用Docker).

所以,我看到它们的利弊：

共享群集

大多数Elasticsearch即服务提供商都以这种方式运营.

优点：

>对于寻求良好搜索和分析的大多数用户来说,价格更便宜.

>更简单的维护,更少的集群供您监控

>与Elasticsearch集成的潜在版本较少.如果您需要与其他系统(您这样做)进行通信,请编写自己的插件(我们这样做,用于身份验证,孤岛,权利,统计等).更少的版本将更容易维护.

缺点：

>必须监视嘈杂的邻居,你必须扩展和重新定位索引来处理这个问题.

>用户必须从Elasticsearch的有限版本中进行选择,通常是单个版本.

>用户无法获得完整的群集管理控制权.

使用Docker的私有群集

以这种方式工作的一个提供者是Found.

优点：

>用户可能能够部署各种版本的Elasticsearch

>用户可以拥有完整的群集管理员权限

>嘈杂的邻居不会影响他们的群集,减少您的人工干预

缺点：

>复杂的监控和支持.如果人们可以做任何他们想做的事情(通过api关闭群集),你必须清楚你作为提供者的责任在哪里结束,以及什么唤醒你在晚上.>与多个版本的复杂集成,请参阅共享集群专业人员.>更昂贵,因为您必须分配可能并不总是使用的资源.