RE: Scalability -- MIDRANGE-L

On Sat, 5 Feb 2005, Joe Pluta wrote:

From: James Rich
Interesting. Strictly hardware, then I would guess something like the
SGI
Altix would take the crown. Trouble is, how do you define hardware?
What
about 100s of blades?
Actually, we're talking how to scale up an application. Here's my

Ok, if we're talking about application scalability, then certainly the winner has to be Google, SETI@home, or any of several weather/nuclear simulators. Far more use use the Google application than use any application on any single machine. And while Google is distributed, nevertheless the application functions as one and thus qualifies. The SETI@home application is massively scalable. Potentially almost every machine on earth could run a SETI@home instance. In this case, the application is finding signals in a data set and everyone can work on that at once. So SETI@home qualifies as a massively scalable application. But if you want to restrict things to applications that run on a single machine image then surely weather or nuclear reaction simulators have to take the crown. These applications can use more than 1000 CPUs and contantly consume and produce many terabytes of data. And while these applications are typically run only on very high end machines, they could run on smaller versions of these same machines (i.e. a 2 processor Origin vs. a 1024 processor Origin) but no one wants to wait :)

It means that you can write an application on a small iSeries that
serves five users.  As your needs grow, you can upgrade the server to
larger and larger boxes and, without having to change the application,
support hundreds or thousands of users.

Do you mean a single instance of an application? Or do you mean many instances of the same application? The distinction is important. For example, if your application is EDITF then you can probably very easily have 10,000 of those all running at once as long as they all access different files. The same is true of vi. But if your application is something that only has a single instance (i.e. it only shows up once in WRKACTJOB or ps -ax) then it is very unlikely that you can design it for only 5 users and get great results when 1,000 people use it. For these types of applications they depend less on OS scalability (though that is important!) and more on their own scalability.

It seems to me that you are referring to many instances of the same application running on a single system image. In which case the scalability of the application itself doesn't really matter and we aren't talking about application scalability at all. So we're back to hardware or OS scalability. It feels like we're running around in circles!

If you write a Unix application on a small box for five users and then
want to support more users it will go something like this: add ten or
twenty users, you can simply add RAM to the Unix machine and a faster
processor and some more disk, but you will probably have to add someone
to tune your database.  As you approach 100 users, you may need another
server, at which time you will have to worry about inter-machine
communications.  Your programming staff will need to make sure all
servers are running the same version of the code.  You'll also need
someone to administer the database and someone to make sure passwords
are synchronized between machines.  And since your database is now on a
different machine than your application, your performance will suffer
due to latency issues (as you well know).  As you grow towards 1000
users, you'll need to add more and more servers, and more and more
support staff to keep them running.  At this point backups and operating
system patches and application fixes become a nightmare.  Security is an
issue, and so is network throughput.

Have you used unix much? What you describe doesn't sound like a typical unix installation, it sounds like an MS Windows installation. You may have and I don't want to assume anything.

There is no reason to assume that as you approach 100 users you will need another machine; I don't know why you do. Just like an iSeries if a small machine doesn't provide the power you need you get a bigger one. You don't need multiple unix machines any more than you need multiple iSeries.

But even if you did, the problems you describe are not typical of most unix installations - at least not the ones I have expoerience with. Password syncronization is not an issue, there is a simple solution for that. Worrying about code versions is no more an issue than it is for the iSeries. Patches are no more often nor difficult than PTFs. Security is as good as iSeries and not hard. Backups are not difficult. If anything, unix is better at multi-machine maintenance than any other platform. unix is where networking started after all.

With the iSeries, it will still be just one machine, with simple backups
and easy management, no network issues and no database latency.  In the
most complex scenario, you will need an additional machine to support
high availability, along with a database mirroring package.  But you'll
still be able to survive with a very small support staff and not a lot
of time spent on system management.

This isn't unique to the iSeries. You don't need multiple unix machines to get big performance. The various lists of TPC benchmarks and top500 should proof enough of that.

But if you want to talk scalability then talk just scalability. If you are only concerned about scalability then it doesn't matter how big the support staff is, this is a scalability issue. The number of support staff or the difficulty of administration or the cost or color of the cases are not scalability issues. Scalability is, "how big can we make it?" and "how small can we make it?" A machine than can be bigger and smaller than another is more scalable, regardless of cost.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw