If you have read my previous posts on the topic of building your own Exadata then you have seen my arguments for the substantial costs of building your own both when developing the system and after it's gone operational. In this section, I discuss miscellaneous other costs - most of them reoccurring - that are associated with build your own...
Notice that one thing I've done, for the most part, is avoid the discussion about specific features in Exadata. I think I mention them in a few places respect to flash and compression but in general I've tried to focus on costs specific to just standing up such a system and maintaining it...
Here is the last part of my thoughts:
1. Other Cost Considerations
a. Lack of scale – This method of procuring systems does not scale
well at all. The cost of additional resources will increase as the scale of the
infrastructure increases. As the system scales further, the ability to support
the infrastructure juxtaposed to Exadata will quickly probably be several
orders of magnitude different, with Exadata clearly being the better choice.
b. Refresh – Each refresh requires a re-run of Steps listed in 4.
c. Additional Cluster – Each cluster created will have to go
through step 4 again. This is because the same hardware/software components you
put into cluster #1 have become obsolete. So, now we have a growing
infrastructure that is wildly component divergent – increasing costs yet again.
d. Local Body of Knowledge encapsulated in one or few people
on-site – The working body of knowledge with BYOH (Bring your own hardware) is
local and usually limited to a few people on-site. This is a significant risk
and increases costs, sometimes significantly. If the maverick who put this
monster together ever left, who will support it and will they be able to
support with a comparable body of knowledge?
e. Disciplined approach – The Engineered Systems design,
development and production have a specific discipline to them that includes
things like peer review, deep experience in hardware as well as past customer
issues and problems. This leads to a disciplined approach to engineered systems
that is very hard to replicate in most IT departments. One maverick designing a
“Exadata Killer” is likely to not benefit from input of others with deep
technical experience. Thus, while the maverick may have specific expertise in
particular areas, he lacks the overall vision of what is required and has few
if any peers capable of matching him on the same technical level he lives at.
Thus, what you get is a solution that is designed from the point of view of the
expertise of the designer, rather than one that is holistic in its approach –
as is Exadata.
So, in selling Exadata it’s not just about the special sauce or
whatever – it’s bigger and broader than that. It’s about TCO – which includes
all of the items I’ve listed above and more.
When I was first getting into IT I was a C programmer. They
brought in Oracle on AIX and I fought a huge fight to get the internal DBA job
they were offering – which I got. I saw it as cool and an incredible
opportunity. I was going to get to build warehouses and OLTP databases and be
the DBA… power!!! Moooohahahahahaha oh the power! In the end I was really no
different than the maverick that wants to build the Exadata killer – he’s
probably drooling at the idea – conjuring every excuse and reason to do it that
he can dream of (honestly - I can see me doing this!).
The Achilles heel of these types is that they always talk in
vague terms. They speak using generic arguments and never provide a single fact
to back up what they say. The response is to expose the true costs of the
effort they propose. Shed light on the fatal flaws of their arguments (which
isn’t that hard). Present these intangible costs to management and ask THEM to
assign a cost to these items. Accumulate these costs and all of a sudden this
great Exadata killer won’t look so grand.
Yeah…. All in all it looks like it’s much cheaper to BYOE (Build
Your Own Exadata) – NOT.