Using a virtualization framework to distribute Java EE applications - a viable alternative?
Our company builds custom Java EE web solutions. For now, we are using standard Java EE distribution mechanisms (ear / war archives). Application servers are usually managed by our customers' 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 application. server root
- server runtime and settings not configured (e.g. number of connections in the database pool)
We are exploring using a virtualization infrastructure to distribute Java EE applications. Instead of sending an ear / war archive, please send an image with the node app server and our app is pre-installed. Some of the benefits are the same as leveraging the virtualization infrastructure in general, namely more efficient use of hardware resources. For us, this reduces the entropy of the hosting infrastructure - VM distribution should be less affected by the hosting environment.
So far the flaw I see may be in the application server licenses, here they will have to use dedicated servers for our solution, but this is usually already done that way. There is also difficulty in maintaining a virtualization infrastructure, but this often happens with IT departments that have more experience than administering and tweaking Java EE solutions.
Anyone have any experience with this model? What are the disadvantages? Are we not just replacing one type of difficulty with another?
source to share
Are we going to replace one type of difficulty with another?
I think so. The virtualization infrastructure must still be supported first. Second (and this is the most important change IMHO), you become responsible for the application and the runtime (container). In other words, it means outsourcing operations. For both the client and the service provider, I will not like this, especially without a strong contract defining rules, boundaries, conditions, etc. to avoid any wars of responsibility. It sounds complicated, and it doesn't sound like the path your clients have taken.
Update: Responding to a comment from OP
(...) In our experience, clients often have infrastructure, configuration and administration issues and in the end we don't need them by default. In this sense, our partners (application providers) have been helpful. As a result, our teams should go to the client installation and help with setup, configuration and installation. I believe the virtualization model will provide a clearer separation of concerns.
What you are describing often happens to my experience and I understand what you are saying, but still, even if you are not allowed to resolve infra problems by default , you are not responsible for them, which is a huge difference . I am not promoting the CYA strategy here, I mean the difference: if you start providing infrastructure services, what happens if the server goes down and if your client loses money? This will be a mistake . Therefore, while the virtualization model can indeed provide a clearer separation of concerns, it has serious non-technical implications (legal, financial) that your company needs to consider.
source to share