This is a response to an old message Brooks posted.
Brooks, Tom, others on the thread.
I said I would respond about my reservations on CKFR's system
development, and I have an hour now and need to get this
obligation behind me, so here it is. My reservations are due to
using technologies which I think are nearing the ends of their
useful lives. I have so stated before, and can only expand
on the reasons.
I've posted essentially everything I based my opinion on
already.
On staffing:
Message 3406684
On technology:
Message 3377805
Historically, IBM's operating systems have not scaled up well,
and incremental improvements in capacity for coherent transaction
processing against a single database image have depended upon
technology upgrades. Clusters alleviate this a little, but
queueing around shared resources makes the incremental available
capacity from adding members of a cluster fall off exponentially
as cluster size grows.
Beyond a certain point (typically about 4 processors), adding more
processors yields negative "improvement" (that is, adding more
actually degrades total performance). When that occurs, the only
avenue for growth (in tightly coupled clusters) is to upgrade the
underlying technology.
For batch operations, this isn't so serious, for several reasons.
Batch operations lend themselves to partitioning across independent
systems. Batch scheduling is low overhead (compared
to batch job times), so queuing around scheduling resources has
less impact, and sophisticated schedulers can arrange batch operations
to schedule other resources efficiently (databases, primarily). Batch
jobs rarely get antsy and call customer service because they're sitting
in the job queue half the night.
On line transaction processing (as opposed to batch transactions) is a
different matter. In this environment,
queuing around shared resources is THE limiting factor in total capacity
for a given service level (total throughput at given response times)
and a given technology base (individual processor speed). To make a
whimsical analogy, in this situation every horse
you add yields proportionally less horsepower, and beyond a certain limit
the only way to go faster is to do a trade up for faster horses. You can't
add more horses effectively.
High-volume transaction processing systems are built with large numbers
(hundreds) of independent, loosely coupled processors. These massively parallel
systems can scale essentially linearly from very small to very large. You can
add horses till the cows come home and get a full horsepower from each one.
(Technically, these systems add logarithmic overhead as they scale up, while
tightly coupled systems add exponential overhead as they expand.)
IBM's mainframes historically have not competed well at the upper end of this
scale. There are fundamental differences in architectures between IBM's mainframe
OSs and the loosely coupled architectures optimized for transaction processing.
This fact is why you don't as a rule find mainframes running truly large, coherent,
on-line transaction processing systems. Instead you find other systems running the
stock exchanges, the ATM networks, the telephony processors; and you find the
IBM mainframe doing the back office work--overnight batch and monthly billing and
summary reports in the morning.
~~~~
Sysplex was (is) an attempt to change that fundamental difference. In Sysplex,
IBM is attempting to graft the loosely coupled approach of the massively parallel
transaction processing systems onto it's traditional mainframe environment, or,
perhaps, it would be better stated the other way around: graft the mainframe
environment onto a loosely coupled, coherent, parallel configuration.
As a fundamental proposition, I certainly can't disagree with the approach
(assuming the ends are desirable), and maybe it will work in the long run,
but I have serious reservations.
First, can IBM pull it off technically? Well, depending on where you want
to start the clock, they're 10-20 years behind some competitors, and at least
five behind all of them.
You could argue the exact timing, but IBM is coming from way behind in
this technology, wherever you start from. Compaq, HP, etc. are not going to
stand around twiddling thumbs, and Tandem (now a Compaq subsidiary) is
implementing their message-based loose coupling fundamentals on NT in
partnership with Microsoft. They recently demonstrated a coherent terrabyte
database on NT.
Similarly, it's hard enough to build an industry-
strength OS from scratch, but that's infant's play compared to integrating an
existing OS into a foreign, philosophically divergent architecture. I note with
amusement that the IBM white papers on Sysplex dwell at length on batch
performance. Well, you have to do that if you want to claim that 18% overhead
translates into 82% of the performance. In a transactional environment, it just
isn't so.
IBM claims it's done now. That I don't buy for a minute. Loosely coupled,
scaled systems are HARD. There are many, many very subtle problems to
overcome.
-----------
I'm sorry, I am going to have to cut this short. My original hour has now
turned into nearly three, and this is more time than I can afford. (Yeah, I
know, it doesn't look like three hour's work. So I'm slow, ok?) I'll
briefly list some of my other reservations.
----------
o If success, what gain is there over competition that can build the same
result in smaller increments?
--Possibly cost. That seems to be one of CKFR's
main reasons, but it posits something I'm not willing to buy. I don't believe
the large systems can compete on cost in the long run. (Incidentally, this
is the flaw in TCO arguments--they're made now and used to justify long-term
commitments).
--Possibly manageability. I don't buy this one either, for a lot of reasons.
That would require a lot of convincing. All of these systems are hard to manage.
o If completely successful, what differentiates from competition? Drawback is
large increments. Got to buy 200 horses if you need 2 (because of the size of
the processors).
o Does Moore's law hold forever? Is this a necessary assumption to keep
"mainframe" processors competitive with "microprocessors"? By that I mean
suppose Intel starts churning out single chips faster than the mainframe
"superservers". Suppose EVERYBODY makes processors of roughly comparable
speeds? How do you differentiate product?
Sorry, must quit now. I apologize for the organization (lack of), and I
haven't covered everything, but I must let it go.
Disclaimer: I offer this for whatever it may be worth. I am stating what
I think because I was asked. I am NOT trying to convince anybody of anything.
And I do wish CKFR all success.
Spots |
