Re: Microsoft .NET frontending IBM i -- WEB400

Hi Nathan

Thanks for the response. I really should have listened to my first
impulse which was to say nothing, so I apologise for putting you to
the trouble of writing a reply.

I don't disagree with much of what you say, but you still have no
database sizings, no user numbers, no transaction volume - in fact
nothing that would allow an alternate solution or proposal to be
developed or costed (Not that I want to develop such an alternate
proposal, either). You have specified that we are talking about an ERP
system as opposed to "Facebook for i" so that helps in terms of what
kind of workload you could expect.

What I was really trying to get at was that it is not as simple to
scale as you make out. What happens if you start out with a 515 ? You
can't upgrade it in place IIRC - that's a pretty disruptive upgrade.
What happens when you need to add disk and need an 0595 ? That's a
pretty expensive and disruptive storage upgrade.

The i tends to scale in rather larger increments than other platforms
and is also more expensive when comparing like-for-like hardware costs
- e.g. disk units, ethernet cards etc. the cost and availability of
iseries people is also something of a negative - and even a risk in
some places - compared to a commodity/mainstream solution. I realise
the value of the integration factor, but perhaps it's not quite the
premium IBM have been charging for it unless you are already locked
in.

I've spent nearly 30 years on iSeries boxes so it's not a case of
misunderstanding the value the platform can add, but a solution that
has a very small pool of deep technical knowledge has a great deal of
risk attached to it in the market.

Can the iSeries scale ? Sure. Can I easily get cheap iSeries talent to
take advantage of that scalabality - that's not quite so easy to
answer.

On Wed, Oct 13, 2010 at 11:30 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

From: Evan Harris
No, it's your job to define the scope of what is being done and what
audience is being served.

Okay, I'll try. Let's say the scope includes broadly-scoped, highly complex
business applications; like ERP suites. And the audience includes all HTTP
clients (browsers, mobile devices), which may include employees, vendors, or
patrons of the enterprise. Plus web service clients.

The only thing really clear so far is that you believe the i scales
better because you can "add cores".

Perhaps I've failed to write clearly, or you haven't read my posts. One can
"add cores" to any system. But if that's your first answer, that may be a sign
that your system does NOT scale well. I would suggest that IBM i CGI scales
better than JEE, PHP, and MS .Net because:

You can configure the IBM i HTTP Server for *NOMAX threads, the threads are
light weight, and client connections can remain alive. CGI programs may be
loaded into HTTP server worker jobs once, then remain active, or not, depending
on the selected activation group option for each. You can configure IBM i CGI
worker jobs to a defined maximum limit. You can configure and run multiple
separate HTTP server instances for separate clients. RPG programs perform better
than the others; they will inherently handle more users & increasing
workloads. There are more and better work management options under IBM i, than
other virtual machine environments. CGI programs run in the same address space
as the database, as opposed to establishing a connection with a remote DB
server; there's a lot less latency. CGI programs use streamlined interfaces, as
opposed to multi-tier architectures that transfer data from one virtual
container to another to another to another...CGI programs scale to the capacity
of the server automatically; you never have to deploy them across multiple
application server instances, or across virtual partitions, or across server
farms to maximize throughput. But you still have the option of dividing
workloads across multiple physical & logical tiers if you want. Under CGI there
is absolutely no need to separate complex business logic into separate business
logic servers, which add more latency, potential failure points, &
bottlenecks. There is a persistent CGI option, which may apply to specific
applications. I use an architecture where users can release files and free all
resources they may be using by clicking an "Exit" link, and ending a *JOB. That
can be a hidden gem for improving scalability. The system is not dispatching a
garbage collector. I use an architecture where developers can deploy a single
instance of a program to serve multiple concurrent users, or chose to launch a
separate instance for individual users, depending on the type of application.

-Nathan