使用虚拟化基础设施进行 Java EE 应用程序分发 - 可行的替代方案吗？
我们公司构建定制 Java EE Web 解决方案。目前，我们使用标准的 Java EE 分发机制（ear/war 档案）。 应用程序服务器通常由客户的 IT 部门管理，由于我们无法完全控制环境，因此解决方案中可能会引入大量熵。例如：
- 最新的应用程序。未应用服务器补丁，应用
- 程序内有冲突的第三方库。服务器根
- 服务器运行时和调整参数未配置（例如，数据库池中的连接数）
我们正在研究使用虚拟化基础设施进行 Java EE 应用程序分发。我们不发送ear/war 存档，而是发送带有应用程序服务器节点和预安装的应用程序的图像。 一些好处与一般使用虚拟化基础设施相同，即更好地利用硬件资源。对于我们来说，它减少了托管基础设施的熵——分布式虚拟机应该较少受到托管环境的影响。
到目前为止，我看到的缺点可能是应用程序服务器许可证，在这里他们必须为我们的解决方案使用专用服务器，但这通常已经这样做了。此外，维护虚拟化基础设施也很复杂，但这通常是 IT 部门比管理和微调 Java EE 解决方案更有经验的事情。
有人有这个模型的经验吗？有什么缺点？ 我们不会用一种复杂性来取代另一种复杂性吗？
Our company builds custom Java EE web solutions. At the moment, we use standard Java EE distribution mechanisms (ear/war archives).
Application servers are generally administered by our clients' IT departments and since we do not have complete control over the environment, a lot of entropy can be introduced into the solution. For example:
- latest app. server patch not applied
- conflicting third party libraries inside the app. server root
- server runtime and tuning parameters not configured (for example, number of connections in database pool)
We are looking into using virtualization infrastructure for Java EE application distribution. Instead of sending the ear/war archive, we’d send image with application server node and our application preinstalled.
Some of the benefits are same as using with using virtualization infrastructure in general, namely better use of hardware resources. For us, it reduces the entropy of hosting infrastructure - distributing VM should be less affected by hosting environment.
So far, the downside I see can be in application server licenses, here they will have to use dedicated servers for our solution, but this is generally already done that way. Also, there is a complexity with maintaining virtualization infrastructure, but this is often something IT departments have more experience with than with administering and fine-tuning Java EE solutions.
Anyone has experience with this model? What are the downsides?
Will we not just replace one type of complexity with other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想确实如此。首先，虚拟化基础设施仍然需要维护。其次（恕我直言，这是最重要的变化），您将负责应用程序和运行时（容器）。换句话说，这意味着将开发外包。作为客户和服务提供商，我不希望这样，特别是没有强有力的合同来定义规则、边界、条件等以避免任何责任之争。这听起来很复杂，而且这似乎不是您的客户选择的路径。
更新：回答OP的评论
您所描述的情况在我的经历中也经常发生，我明白您在说什么，但即使默认情况下解决基础设施问题，您也不负责对于他们来说，这是一个巨大差异。我不是在这里提倡 CYA 策略，我只是在强调一个差异：如果你开始提供基础设施服务，如果服务器出现故障并且你的客户损失金钱，会发生什么？这将是你的错。因此，虽然虚拟化模型确实可以提供更清晰的关注点分离，但这会产生严重的非技术影响（法律、财务），您的公司需要考虑到这一点。
I think so indeed. First the virtualization infrastructure would still have to be maintained. Second (and this is the most important change IMHO), you will become responsible of the application and the runtime (the container). In other words, this means outsourcing the exploitation. As both a customer and as a service provider, I would not like that, especially without a strong contract defining the rules, the boundaries, the conditions etc to avoid any responsibility wars. This sounds complicated and this doesn't seem to be the path chosen by your clients.
Update: Answering a comment from the OP
What you are describing happens frequently to my experience too and I understand what you are saying but still, even if the resolution of infra problems defaults to you, you're not responsible for them, that's a huge difference. I'm not promoting a CYA strategy here, I'm underlying a difference: if you start providing infrastructure services, what will happen if a server goes down and if your customer loose money? It will be your fault. So while a virtualization model may indeed provide a cleaner separation of concerns, this has serious non technical implications (legal, financial) that your company need to take into account.