Using virtualization infrastructure for J2EE application distribution- viable alternative?

Question

Our company builds custom J2EE web solutions. At the moment, we use standard J2EE 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 J2EE 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 J2EE solutions.

Anyone has experience with this model? What are the downsides? Will we not just replace one type of complexity with other?

Answer 1

Will we not just replace one type of complexity with other?

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

(...) In our experience, clients often have infrastructure, configuration and administration problems and in the end they default to us. Neither our partners (app. server vendors) have proven helpful in that sense. In the end, our teams have to go to client installation and help with configuration, tuning and installation. I feel that virtualization model would provide cleaner separation of concerns.

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.