Do Operating Systems Matter? Part 1

A month or two back, I had a conversation with a vendor who I won’t name here (given that I’m at VMWorld, I should probably say that it wasn’t VMWare) on the subject of application and service provisioning via a grid type application. A mouthful, I know. Essentially, the demonstration we were given centered around how the application permitted the drag and drop connection of a variety of resources: MySQL database to JBoss application server to Apache web server, and so on. Interesting, to be sure, despite the fact that I’ve seen similar demos and similar promises from vendors over the years.

The surprising thing was that the conversation got quite heated as I pushed for more information on what operating systems the individual applications were running on. Those of you that have interacted with me in person will probably realize that I don’t really get contentious easily. I cannot recall, in fact, a similarly antagonistic briefing in my career to date. Ultimately, the dispute – in my view – boiled down to a central and fundamental disconnect: I believed that the operating system mattered, while the vendor in question did not. Vehemently, did not.

My principle argument was simple: ISVs, in my opinion, still write to operating system layers. As much as Java and J2EE have simplified platform compatibility questions, a majority of vendors, I argued, supported certain operating systems and not others. Red Hat and SuSE, for example, and not Debian (much to my chagrin) or Fedora. The Oracle Unbreakable Linux decision, in that sense, can be seen as a fundamental validation of this assumption.

In case the link between the above argument and the original cause of the dispute is non-obvious, think about it this way. Being able to create applications ad-hoc with drag and drop tools is useful, no doubt, but my problem was what happens when you have a problem. If you have, as an example, an issue with MySQL and contact them for support, it seemed likely that they might ask what operating system that you’re running on. And that an answer of “it doesn’t matter” was not going to get you terribly far. To some degree, it’s similar to my reservations concerning running dynamic languages on top of the JVM: it’s not a bad idea, but when something goes wrong the uniqueness of your environment can be a significant problem.

But clearly more research was needed here. To help address the question, I set out to contact a handful of vendors to get a feel for their support policies with respect to virtualized or otherwise unique environments. The survey – using the term loosely – was designed not to be comprehensive, but to provide some feedback on how a handful of vendors handle support requests of this type. The questions asked of each vendor were the following relatively simplistic questions:

1. Does [vendor] support running in supported operating systems running on top of the following types of virtualization platforms?
a. Native virtualization (e.g. VMWare)
b. Paravirtualization (e.g. Xen)
c. Operating system-level virtualization (e.g. Solaris Containers, FreeBSD Jails)

2. Does [vendor] support running in supported operating systems running on top of grid type environments (e.g. Amazon’s EC2, Sun’s network.com)?

3. Does [vendor] support running within the context of a meta-operating system (e.g. 3Tera, which hosts a variety of “guest” operating systems within one “meta” operating system)?

Generally, all of the vendors were cooperative. A couple of requests fell through the cracks, but most of the vendors contacted provided responses. The quickest response took about 48 hours to process, the longest was just short of three weeks; the mean was probably a few days. While that’s obviously attributable mainly to communication inefficiencies, I did find it both interesting and noteworthy that few of the vendors are prepared to answer the support questions regarding increasingly complex virtualized environments off the top of their head. Nor should they be expected to, of course, because the production deployments of virtualized environments are just in the process of becoming mainstream, as even the VMWare folks have allowed.

Anyhow, here are the responses received thus far. Incidentally, if you’re a vendor and would like to be included, just ship over your answers.

• Covalent:
  1. a. Yes; We have a number of customers running Apache and Tomcat in this environment
     b. Possibly, but not officially at this point; working with one customer to evaluate this now
     c. Yes on Solars Containers; we have supported this for some time; we do not support the BSD operating systems

  2. Not currently; We have not had a request for this environment so far
  3. Not currently; Same as above … Has not been requested to date
• DB2:
  General support statement: we support environments that support the same versions of the operating system that DB2 runs on, whether that’s AIX, RHEL, Solaris, SuSE, Windows.

• SourceLabs:
  1. Yes – with focus on paravirtualization (xen)
  2. Yes
  3. Yes
• Sun:
  1. a. Yes, for example, we support the customers running VMware on our systems and Solaris 10 running on VMware. So does VMware.
     b. We will, on SPARC we will have Logical Domains, on x86 we will have a Xen version of Solaris. In addition we plan to support 3rd party Xen solutions like XenSource’s XenEnterprise and Novell’s SLES 10 Xen.
     c. Absolutely, Solaris Containers as part of Solaris 10 is definitely a big push for us and we have many happy customers running Solaris Containers in production.

  2. Yes
  3. More information required
• WebSphere:
  Has a virtualization support statement posted here. General response:
  In general, as long as binary compatibility is maintained (it looks and acts as a normal OS would), then we’ll support it. The note about performance is a good one, app server performance can be dramatically affected by resource allocation (memory, processor caching, etc.) — this is why we put this note in our support statement…On #2 and #3, we don’t see enough action/traction here to have an official support statement, but, again, as long as binary compatibility is provided for, it wouldn’t necessarily be an issue.

• Zend:
  1. a. Yes
     b. Should work, but we’ve never tried it.
     c. Yes, provided all of the necessary software/libraries is available in the container/jail

  2. That was never tested, my gut feeling is that we can expect some incompatibilities that would require some tailored solutions.
  3. Again, wasn’t tested and my gut feeling is that it would require some tweaks to get working.

  Generally all of Zend’s software is running in user mode, with no special drivers or kernel patches that are necessary. As such, it should work fairly well with virtualized environments. Some tweaks may be required to get it to work on some more ‘exotic’ virtualized environments, because of certain assumption made as to whether the software is running on a single server or not.

My conclusion, based on the above? If support matters, operating systems matter. If the subject is production systems, then, operating systems matter.

What’s equally clear, however, is that VMWare’s contention, made here at VMWorld, that the role of the operating system is changing is accurate. This is reflected not only in the technical innovation seen around virtualization from both a hardware and software perspective, but by the complexity of the support questions facing ISVs. The WebSphere folks are more than justified in their response that they haven’t seen substantial demand for virtualization solutions such as that provided by either Amazon or 3Tera, but I think it’s inevitable that we’ll see more of that.

Disclaimer: IBM, Sourcelabs, Sun, and Zend are RedMonk clients, while Covalent is not.