Maybe they want to standardize on HP servers, vSphere for virtualization, RedHat for Linux, Cisco for the data center network, EMC for the storage, and so on.
The specific choices aren't relevant in this argument; the underlying philosophy is what matters.
The newer thinking in this arena is pre-integrated stacks: converged (e.g. VCE Vblocks, HP CI, etc.) or perhaps some of the newer hyperconverged offerings (e.g. VMware's EVO, Nutanix, etc.). Less effort all around thanks to a modicum of integration, but still a generic stack by any other name.
So, let me ask a clarifying question: what are the most important and demanding workloads in your landscape?
I'm guessing it's databases, and the applications that use them. Might it make sense to think in terms of *optimized* stacks for these crown jewels vs. generic ones?
If your business is heavily invested in databases, maybe mainstream generic infrastructure thinking isn't doing you any favors.
If you're like most enterprises, databases are at the very heart of your business. We almost take for granted that timely, accurate information is immediately available at our fingertips, in a format of our choosing. We can't imagine doing business without it.
Statistically speaking, more often than not these are Oracle databases. The larger the workload, the more likely this is the case.
OK, think for a moment on just how much money you've invested in the database technology underpinnings: software, hardware, facilities, etc. Probably a tidy sum.
Now think about everyone in IT who helps to make all that database magic happen: operations, architects, database administrators, business analysts, etc. Quite a crowd, eh?
Now think about all the applications that interact specifically with the database. And all the LOB folks who have built queries and reports. Think about how the database is woven into boardroom topics like information security, data governance, risk management, audits and compliance.
Anyone care to put a dollar figure on that total enterprise investment? Even in a modest enterprise, you end up with a Very Big Number that's been sunk into databases and everything that touches them.
In our data-driven world, databases are the engines that power our businesses.
Now Let's Talk Infrastructure, Shall We?
I've hung with IT infrastructure folks for decades. I know how many of them think.
Here's who we use for server, hypervisor, operating system, data center network, storage, etc. etc. Pick a preferred vendor, have another as a backup second choice.
And then run as much as possible on the result.
While that build-it-yourself approach is under pressure from the growing cadre of converged and hyperconverged players, there's a fundamental flaw in the underlying thinking.
Databases are different. In particular, Oracle databases are different.
There is no way that a generic, homegrown technology stack can deliver the same results as an optimized stack, engineered to work together in the presence of an Oracle database. Pick any IT metric you choose: performance, availability, data protection, security, capex, opex, time-to-value, support, maintenance, migrations, cloud consumption, etc.
No shortage of examples, as I've found.
None of the generic choices can compete.
Server vendors, storage vendors, hypervisor vendors, data protection vendors, etc. -- you just can't ignore the 800 pound gorilla in the room. Trust me, I know this.
But, by the same token, none of these vendors has access to Oracle Database internals. To them, it's just a black box that they have to play nice with. Nor is the Oracle Database particularly aware of any of them.
Architectural agnosticism at its finest.
Oracle's Red Stack (and the Oracle Engineered Systems and Oracle Cloud that uses these same technologies) thus has a completely unfair architectural advantage. Oracle can -- and has -- co-engineered the stack to be optimized in the presence of the database, and vice versa.
The deeper you dig into the details, the more stark the comparison becomes. It's not a fair fight.
Force And Counterforce
So, if you're willing to accept my premise for the moment, why is it that so many IT infrastructure teams insist on building their own stacks to support Oracle databases vs. use Oracle's engineered stack?
It's certainly not about cost. Plenty of evidence that Oracle's infrastructure stack is less expensive from both a capex and opex perspective. How much are you paying for virtualization these days? Storage? Compute? Data protection? Archiving? Etc. etc.
It's certainly not about support, either. Oracle's end-to-end support model is arguably better than any alternative, simply because it includes the database as well as infrastructure.
And it's certainly not about cool functionality, as there's a raft of compelling features only available with Oracle infrastructure.
No, I think it's about mindset.
The IT infrastructure folks have usually picked their favorites without fully appreciating the unique role that databases and their applications play in the enterprise portfolio. The idea of using a separate stack for databases rubs them the wrong way, despite any evidence that might be presented to the contrary. Maybe the thinking is "a workload is a workload -- what's the difference?"
I can't fully explain it.
Should Database Infrastructure Be Considered Separately?
But that doesn't keep the IT infrastructure teams from tirelessly working in that direction: standardize, standardize, standardize!
Here's a radical thought: given the outsided importance of databases, and the massive enterprise-wide investment in them, might it not make sense build "standardized" stacks behind those pillars of enterprise IT? Especially if doing so could check every IT metric that the business cares about?
Maybe we're thinking about it the wrong way. Maybe we should selectively standardize different parts of the landscape -- with different stacks -- driven by business outcomes vs. brand preferences?
Yes, I'm Wearing An Oracle Hat
On one hand, here's a clear and compelling infrastructure value proposition for perhaps the most critical asset in the enterprise IT landscape -- the database. There's no shortage of evidence that Oracle databases and their applications run better, faster, cheaper, more securely and better protected with less operational effort when running on Oracle infrastructure.
Just as you'd expect.
On the other hand, there's this IT infrastructure desire to "standardize" horizontally using technology from different vendors, which paradoxically ends up costing more money, taking more time and delivering substandard results as compared to viable alternatives.
Maybe you should consider standardizing on the Oracle stack behind your Oracle databases.
It's not about religion, it just makes business sense.
Like this post? Why not subscribe via email?