When Generic IT Infrastructure Doesn't Cut It

Many IT infrastructure groups are intent on building their own landscapes, using horizontal technologies.

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.

A Moment Of Somber Reflection?

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.

Their vision is usually the same: we're building a horizontal, layered stack, with clear "standardized" choices at each layer.

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.

In fairness, almost all technology vendors have invested heavily in making sure their products work well with the Oracle Database.  So many IT shops run so many important workloads using it.  

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?

There's a holy grail in IT infrastructure to create the One Environment That Runs Them All. The reality is that almost no IT shop of any size has been able to achieve this in the modern era.

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?

Nahhh ...

Yes, I'm Wearing An Oracle Hat

I never cease to be fascinated by how different parts of the enterprise IT landscape look at things. Coming to Oracle was certainly another useful chapter in my continuing education.

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?

 

 

 

Comments

[Aernoud van de Graaff]

Hi Chuck,

This is one of your first blogs I fundamentally disagree with your view. And yes, I am an infrastructure guy, so I am probably a bit biased.

I understand that having a stack fully aimed at running a specific workload (like Oracle's Databases) will help deliver the databases in the most optimal way you possibly can and it is easy to install as you get more or less a DB solution in a box. Because you can just focus of what is important for the Database environment and more or less ignore the world beyond it.

And if you would only run Oracle databases I would go for the specialised stack (assuming you get a good value for your money).

Unfortunately in most enterprises you will find different Database SW because vendors of COTS will limit or even prescribe what DB you can use. And that is only the databases. In larger enterprises you will find multiple different Operating Systems (and probably multiple versions), middleware solutions and applications that make up the enterprise datacenter environment.

If it was just Oracle and the rest, it could be interesting to look if running Oracle databases on a dedicated stack will bring more benefits than it adds complexity to the environment, but IBM will argue the same for the PureApp solutions (e.g. WAS) and others like MSFT will too.

It is not so only about the different technology and the complexity this brings. From my perspective it is mostly about the different management.

We are at a stage where 'what hardware' you run is getting less and less important from a management perspective. And we are moving to a situation where we will be able to say the same about Operating Systems, Hypervisors, Containers, Cloud environment, etc.

Management software is getting better at managing a hybrid environment. But from what I have seen the dedicated stacks like Exadata (and correct me if I am wrong) have their own management solutions that do not integrate well (yet) from an operational point of view, automation, disaster recovery, etc. etc.

So from an Oracle point of view I can understand the solution in a optimised stack (from an architectural point of view as well as commercial). And if Oracle was the only exception or one of the few defined exceptions, that may be interesting to look at. But from a holistic view it just creates more complexity and another silo to manage. And this complexity is killing IT departments. It makes change extremely difficult, quality declines, cost go up, agility goes down.

I am convinced that the only way we will deliver real value to the business, is if we simplify, standardise and automate IT where we can. And yes a dedicated solution may do that for that solution, but not for the whole.

[Iwan 'e1' Rahabok]

Thanks Chuck. Entertaining and informative, as always.
To me, it's not about generic. It's about the business services. Services spans many apps, and many apps spans many "system". A "system" typically has a database.
So there is a need to ensure business services can continue, hence Business Continuity. A common stack enables us to fail-over the entire DC, not just 1 apps. Then fail-back. All done automatically. With the firewall and LB rules follow.
Would be grateful if you can cover how we failover a critical business services that spans many apps. Automatically, not manually. With fail-back, and complete with FW/LB config also.

If you drop by Singapore, drinks await you.

[Chuck Hollis]

Hi Iwan -- your thinking is similar to other folks I've known who build and run data centers. Basically, a workload is a workload, and architectural consistency matters more than meeting unique business requirements.

So you're not alone.

We both know that completely automated failover/failback for complex and demanding application landscapes are like black swans -- you hear about them, but you rarely see one.

It doesn't matter which technologies you use, there's going to be some scripted orchestration of multiple components.

Even Google and AWS have their bad days :)

If someone tried to use that as an argument for cramming everything onto a single platform in ignorance of other business requirements, I'd call "weaksauce".

My view is that many IT infrastructure people have lost the plot. They have become to enamored with their own requirements, and have lost sight of what the business might need.

My two cents.

-- Chuck

[Dan Fisher]

Interesting post, Chuck. I've been following your blog for some time even as it (you) moved from employer to employer. I find this post interesting because it reiterates some things you've said in the past while still at EMC. Good to know that although your employer may have changed, fundamentally your ideas have not. While following your blog I've crafted a strategy that mimics your idea of "selectively standardizing different parts of the landscape -- with different stacks". I too feel that databases are 'different' but in a good way, and treating them as 'just another workload' is inappropriate. I also think that until recently we didn't have many options. Until the converged/engineered stack became available we were forced to build the stack ourselves.

I will argue that one does have to be selective with the converged stack as not all are the same. Oracle, as you point out, is optimized for the database (well - specifically for Oracle databases). Other stacks are centered on other workloads. So, the question becomes does it add or remove management and administration if you run different converged stacks, each centered on their preferred workload? What about DR? Refresh? If you value choice, does this create 'lock in'? (I guess it raises more than one question . . .)

I would like to think that convergence lowers complexity and that enhances management and administration. So, even if it is 'cost neutral' to purchase, you're better off with a converged landscape than not. It may be that using purpose-built converged stacks would be the new 'siloed' organization. Instead of vertically organized around technologies (server, storage, network, etc.) we become cross-functional teams managing different workload stacks?

[Iwan 'e1' Rahabok]

Thank you Chuck for taking time to reply. Allow me to think through what you said. I'm running very high CPU utilisation in the next few weeks as I'm rushing a few projects. In the meantime, I think your blog is one of those who have mastered the fine balance between educating and entertainment. Keep it up!