« The Yin and Yang of IT Consolidation | Main | Dell and EMC -- The Aftermath »

October 08, 2015


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!

The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!