我们公司构建自定义Java EE Web解决方案。目前，我们使用标准的Java EE分发机制（ear / war archives）。 应用程序服务器通常由我们客户的IT部门管理，由于我们无法完全控制环境，因此可以在解决方案中引入大量熵。例如：
我们正在研究使用虚拟化基础架构进行Java EE应用程序分发。我们不会发送ear / war存档，而是发送带有应用服务器节点的图像，并预先安装我们的应用程序。 一些优点与使用虚拟化基础设施一般使用相同，即更好地使用硬件资源。对我们来说，它减少了托管基础设施的熵 - 分发VM应该受托管环境的影响较小。
到目前为止，我看到的缺点可能是应用程序服务器许可证，这里他们将不得不使用专用服务器来解决我们的问题，但这通常已经这样做了。此外，维护虚拟化基础架构也很复杂，但这通常是IT部门比管理和微调Java EE解决方案更多的经验。
任何人都有使用此型号的经验吗？有什么缺点？ 我们不只是将其中一种复杂性替换为其他类型吗？
答案 0 :(得分：1)
我确实这么认为。首先，仍然需要维护虚拟化基础架构。第二个（这是IMHO最重要的变化），你将负责应用程序和运行时（容器）。换句话说，这意味着外包剥削。作为客户和服务提供商，我不喜欢这样，特别是没有强有力的合同来定义规则，边界，条件等以避免任何责任战。这听起来很复杂，这似乎不是您的客户选择的路径。我们不会仅仅将其中一种复杂性替换为其他类型吗？
更新：回复OP的评论
（...）根据我们的经验，客户经常遇到基础设施，配置和管理问题，最后他们默认我们。在这个意义上，我们的合作伙伴（应用程序服务器供应商）都没有证明有用。最后，我们的团队必须进行客户端安装并帮助进行配置，调整和安装。我觉得虚拟化模型可以更清晰地分离问题。
你所描述的内容也经常发生在我的经历中，我理解你在说什么但是，即使基础问题的分辨率默认给你，你也不是负责任的< / strong>对于他们来说，这是一个巨大的差异。我不是在这里推广CYA策略，我有一个不同之处：如果你开始提供基础设施服务，如果服务器出现问题，你的客户会没钱，会发生什么？这将是你的错误。因此，虽然虚拟化模型确实可以提供更清晰的关注点分离，但这具有严重的非技术含义（法律，财务），贵公司需要将其考虑在内。