The challenge of certified versus supported as highlighted by RHEL

certifiedThere doesn’t seem to be a week that goes by without some form of controversy in the world of technology. It often gets escalated to the classic use of FUD (Fear Uncertainty and Doubt), and more often than not it is just a matter of the lack of an explicit answer which leaves an unfortunate amount of interpretation on a statement.

Explicit versus Implied by Absence

This is the classic tool of the pundit where the lack of an explicit statement is assumed to imply that the statement is not true. What we mean by this is that by not specifically stating “X” that others choose to say that “Y” is obviously the case, although “Y” was never mentioned at all.

Consider a conversational example:

Person 1: “I see on your webpage that there is no mention that you like oranges?”

Person 2: “I didn’t feel the need to say that”

Person 1: “So you are clearly saying that oranges are bad then?”

And then the argument ensues. This is seen on a daily basis in politics where political party A says that because political party B hasn’t specifically authored a bill stating that they will enact some law, that they are clearly lawless and wish for the total tear down of society.

As you can see, this is completely inflammatory, and untrue. So why does this relate to our RHEL situation? Well, let’s take a look at another specific example from the world of virtualization.

“Move it to physical and call me back”

I’ve been in technology implementation for long enough to have experienced all of the challenges of support. I run Microsoft Exchange on VMware vSphere, and I’ve virtualized Oracle long before it was supported. At many points along the way, applications like Microsoft CRM, Microsoft SharePoint and many others have had the caveat that they can run in virtualized environments, but only on their parent company’s platform.

This brings up the worst case scenario that you have a performance issue, or some kind of deep seated problem that requires advanced troubleshooting. During the course of the troubleshooting the application vendor asks what platform you are running on. Of course, you have to disclose that you are running a hypervisor that isn’t certified by them and you are in a quandary because technically they can ask you to re-platform your application environment onto a certified hypervisor, or even onto a bare-metal platform.

The reality of this scenario is that it is rare, and although I have had a support rep say that they couldn’t support me for an application because I was using VMware, I phoned the same vendor back and got a different representative who went a little further with the troubleshooting anyways and we discovered the real underlying application issue which was not related to the hypervisor platform.

This is a risk of course, and I can’t endorse that you just fly in the face of your software vendor because you and your organization have a responsibility to maintain your supportability. In the cases where I had a vendor tell me that re-platforming was the required next step, I either found the issue myself, or we pushed past the red herring issue of my underlying host.

So, where can I run RHEL?

The fine line that was questioned was the difference between supported and certified. Certified platforms are those which have a business agreement between the hosting vendor and Red Hat that allows them to offer enhanced levels of support directly from the Red Hat support teams.

This isn’t just a hand shake, but a full testing regimen that was done to ensure that RHEL can run with predictability and performance that meets the expectations of the Red Hat team and therefore provide the best customer experience.

Here is an article from Red Hat that explains the support levels:  https://access.redhat.com/site/articles/1067

Rather than going into the full explanation myself on the Red Hat stance on supported hardware and hypervisor platforms, it’s best to point you to the newly updated FAQ that gives the information that you will need to know how to run RHEL with full support.

Red Hat Supported Hypervisors FAQ: https://access.redhat.com/site/articles/886983

My take on this is that Red Hat has done what is necessary to ensure that their products run to the best of their capability, and with the best ability to support with their certification program. Many of us will run our RHEL instances in a way that may not match the “certified” method, and you will be fine. This is just a matter of Red Hat protecting their interest in how deep they need to chase a support issue.

Hopefully the FAQ covers the bases for people and we can get back to doing what we do best and to build our platforms to keep our customers moving ahead with great technology!

3 thoughts on “The challenge of certified versus supported as highlighted by RHEL”

  1. I think everyone’s who ever deployed Oracle has had to contend with this argument, I know I have. Despite running Oracle virtualised (on a VMware platform) for many years in our dev/test environments, without ever encountering an issue caused by the hypervisor, there was and still is reluctance to virtualising production.

    Sometimes the lack of certificatoin is due to the support issues you’ve described above, but there’s also the political angle. Oracle obviously want you to use their hypervisor, despite it’s niche market adoption, and I’ve seen the ‘it’s not certified’ argument win a transition to that hypervisor. Luckily hypervisors are all a commodity now so it really doesn’t matter does it? I’m curious to see how this plays out! 🙂

    Reply

Leave a Reply to Eric Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.