@Toby: Agree on ZFS but I wish it’s available on all platforms!

@Neil: “annualized cost forcasting” — does it remind me ROI criteria? The problem is that people can make such forecasting including what they think is appropriate to make numbers look right. Until, this forecasting is separated into independent business unit and/or audited, there is no way to apply it flawlessly.

If the customers DR design prevents then from using the DR equipment in an active fashion, then “cheaper” alternatives are selected due to the economics of the design. A 2x cost on infrastructure to support DR where 1/2 is sitting idle does not get approved. So, alternatives and cost cutting options prevail from less compute power (less cpu) to less io performance capability. This is further defined by “If we are in a DR situation we will be able to run at partial capacity for 2-3, 5 months.”

Other economics prevent “false-designs” no different then “false positives”. A lot of customers, frankly overpurchase technology. And this is due to the negotiation power of vendor sales reps and large OEMs. Simple example, larger companies never look at Oracle Standard edition as a database option, they run Oracle Enterprise at some 55% higher the cost annualized yearly in increased support cost. That cost goes into someone elses pocket. And is $$$ that could have been spent to have proper infrastructure, equipment, projects and technology implmeneted to run their business. But, they will all complain that “oracle” is too expensive. Same paradigm happens with hardware where customers by compute capacity because their skills and architecture can not align with annualized planning to incrementally deploy scalable solutions. And to this I say, “It is a lot harder to incrementally add a $750k server.”

There is value in using different solutions in tiered approaches where impacted is isolated. Like virus definitions. Clearly you can not do this same thing in the “Application” design like swap out Weblogic for IIS.

I think like the last year of the US economy has made families really look a their spending and return on their $$$, so will happen in IT investments. And cost value additions like Cloud Computing and IT purchases looking at the annualized cost forcasting will make the customer aligned to making smarter decisions.

NetApp? Schmeh. Use ZFS!

More skills, different procedures, different bugs, issues, huge integration headache. I just don’t see how you can keep simplicity with increasing diversity. I guess we are going a bit sideways from the original topic… not that it’s matter. :)

We *never* fail. At least not in those meetings when we discuss it ;-)

If takes to the extreme, we will end up with two different applications (.NET vs Java), different DB vendors (MySQL or SQL Server vs Oracle), and local storage with cloud – for a good measure. With this, “we cannot fail”. Eh?

No, not at all. Security often means more diversity.

If you make everything the same, all a hacker has to do is find a technique to break in once and it’s repeatable everywhere in that site.

If the hacker has to break into everything every step of the way and for each step it’s a different lock, then things are a lot harder for their kind – and a lot easier for us to find them by increasing the chances they step on a trip wire. The Cucko’s Egg book explains this at length.

Is that necessary everywhere? I don’t think so. Not every site needs mil-level security – when we talk genetic diversity that’s what it’s about.

For the vast majority of places, I would not bother to that level: many other security options available with less impact, before one jumps to the ultimate.

Well, security often means more complexity (no?) and “complexity is the enemy of availability”. I think my experience with how people make things secure might be bad according to this.

Joel,

Or through the same application. There will always be same’s otherwise, it’s insane. :)

I can even understand some of the technical reasons why you might want to do this, but my personal opinion is that HA without as much simplicity as you can manage is unlikely to be HA in practise.

Of course I don’t mean *technical* simplicity but administrative simplicity because this stuff will ultimately be managed by humans.