The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.
– Douglas Adams (Genius of this Parish)
You have standardized on CentOS and have free access to all the goodness of a low cost of ownership solution, backed by Industry Heavyweight Red Hat’s source code, contribution, and engineering muscle. Not to mention (but I will) CentOS Extra and the innovation and agility that the open source community brings to advancing CentOS features and performance.
What you don’t have is Red Hat’s branding, logos…. and support.
CentOS support is primarily provided by the community via mailing lists, web forums, and chat rooms. This isn’t so much of an issue when you are developing and testing, but it should certainly be a concern for any mission critical system in production. There’s no convenient 0800 number, no service level agreements, no hot fixes, no contractually committed roadmap, or guarantee of backward compatibility for the long tail of versions and releases.
There is “no throat to choke” if it all goes horribly wrong. To misquote Douglas Adams “Just you and the sound a deadline makes as it goes whooshing by.”
When you read that CentOS bug and security fixes are provided “from time to time” it hardly inspires confidence that an issue requiring an immediate find and fix is going to get turned around fast enough to stop your system flat lining your business.
If you try and take a cat apart to see how it works, the first thing
you have on your hands is a nonworking cat.
– Douglas Adams
Your systems are the sum of the parts, carefully selected, integrated, configured, and deployed, often at great cost to meet your specific needs.
So who are you going to call?
Even if they can find the fault, can they fix it?
What if the fault lays in some technology combination rather than squarely and solely within CentOS?
Where else is this fault (or worse, a security vulnerability) lurking in your other systems?
They are quick but not THAT quick, and what does the community know about the specifics of YOUR deployment and architecture?
Ad hoc via your local CentOS “experts”?
How will they replicate the issue?
Once they do, do they have the skills and resources to fix it?
And at the risk of repeating myself (but I will), what do they know about the specifics of YOUR deployment and architecture?
Even if some combination of all the above does yield an answer, of sorts, what’s the perennial technology vendor’s get-out-of-jail-free card?
“It’s not my product that’s the issue here, it’s something else in the stack”.
Do you have time for this?
Or are you going to call an industrial strength support team who will put you straight through to a team of architects? People who don’t just understand CentOS but the key dependencies on other open source projects (and a variety of commonly used proprietary open source technologies) within your stack of deployed technologies?
In-house CentOS contributing engineers who can provide YOU a fix within an agreed time and CONTRIBUTE the fix back to CentOS so that you are always as close to “vanilla” as supportably possible? (Yes I coined a word. You can use it. For free).
Industrial grade support for CentOS doesn’t need to destroy the cost of ownership, and business case for CentOS and cost effective “full-stack” support isn’t an impossible dream.
Our dedicated CentOS team adds value to our customers and creates value for all CentOS users by contributing back to the project. Get in touch to find out how we can provide you with cost effective enterprise-strength support for CentOS (and her fellow travelers Apache, MySQL, and PHP).
To give real service you must add something which cannot be bought or measured
with money, and that is sincerity and integrity.
– Douglas Adams