On 9/2/2012 11:04 AM, John Yeung wrote:
To those pointing out that you can get a very capable i to run lots of
stuff that would otherwise run on multiple commodity servers:
That's all well and good, but in my experience, it is common to have
multiple platforms anyway. Where I work, we have a relatively small i
as well as a host of other machines. Would it be easier to administer
a large i rather than the complex ecosystem we have? Almost
undoubtedly. But the upfront cost would be astronomical for a company
our size. Not just in dollars but in time and headache.
Like many other companies, you have an organically grown
infrastructure. Bits and pieces have accreted over time and so now you
are every bit as locked in to your current environment as you say IBM
midrange customers are locked into theirs. It happens.
Now, I can't say that we are in a position to abandon the i either.
But would it be easier/cheaper to migrate non-i stuff to i, or to
migrate i stuff to non-i? Both of these are painful (and perhaps
impossible for many companies), but it *feels* like moving toward the
i is moving toward lock-in, and moving away from the i is moving
toward greater freedom (interchangeability, scalability, software
choices, etc., etc., etc.).
Migration to an IBM i-centric environment is different for everyone, but
migration AWAY from the IBM i is nearly always more painful in the long
run. Typically an IBM i system is tightly integrated and highly
customized to the business requirements of the company. If you replace
this with commodity hardware and software, you lose the business
advantages of your applications. If you try to rewrite the code to
replace the functionality, you end up spending a ton (both in time and
money) on custom development and there goes the price advantage.
I stress that it *feels* like that. Maybe it wouldn't feel like that
if IBM made their case better. There is a strong association not only
of i with green-screen,
That's should be easily countered, since not even IBM pushes the green
screen. Twinax is barely supported and they aren't updating their own
green screen development tools. Simple education point.
but also of i with OS/400 and its descendants
(sorry I don't know the proper name).
The whole point of getting the IBM midrange is to take advantage of
i5/OS (or IBM i OS, whatever the official name is). RPG and DB2 are
your core tools. The database is rock solid with powerful SQL
capabilities, and RPG acts as assembly language for the database
allowing peak performance where required. The operating system itself
provides job management, security and auditing features that are
unsurpassed, all in a package that is virtually unhackable and virus immune.
If none of that matters to your business, then by all means move to
Oracle on Red Hat.
I know at some point there was
a split between Power hardware and the i OS, but this is not well
known and the implications of this are not well understood.
(Especially outside the i community, but even to a large extent within
it.)
I'm not sure I understand the question here.
For example, it's not completely clear to me whether you're "supposed"
to run both native i and *nix stuff on the same box. If the answer is
yes, then is the *nix stuff "supposed" to be run on PASE or
"natively"? If PASE, then is there an answer for the porting hassles
and apparently sluggish performance? If "natively" then are there
options other than AIX, and do these perform as well as commodity
boxes?
You have so many options. First, you can run AIX, Linux and i5/OS
partitions all together on the same physical hardware, all linked via
shared hardware (including ultrafast virtual ethernet links). So
whatever your specific requirements are, you can do it. Additionally,
i5/OS allows you to run various levels of compatibility and integration
solutions, whether it's QShell, PASE or various flavors of Java VMs.
If the i is somehow "managing" disparate platforms on the same
box, surely there is some kind of performance overhead for this? Is
the benefit just the reduced number of boxes to manage, or is there
some kind of interoperability improvement (like shared storage, or
smehow better communication between a native i program and a native
*nix program on the same box)?
Not really. This isn't running VMWare. These are separate partitions
that are managed by a hypervisor. CPU cores are assigned to the
partitions and run the OS.
For all I know, there are great answers to these and other questions
that come up whenever people talk about the i. If there are, they
should be pushed out there much, much more vigorously.
This I agree with. To be honest, I've got no business talking about
some of this stuff because I'm no expert. I'd prefer to hear this story
from IBMers or from people who really know the stuff like DrFranken.
But I can tell you from decades of real world experience that the best
configuration for any IT infrastructure revolves around centralized
business rules processor, with ancillary machines as necessary. Here's
my take on it, with roughly three zones:
The IBM i is the premiere business rules repository and occupies the
central zone. No duplication of rules, no stale rules, everything in
the rest of the infrastructure gets its data from the IBM i. Make rules
available via stored procedures and web services.
The second layer consists of systems that still need the highest level
of security and uptime. These run either in virtual environment
(PASE/QShell) or as partitions on the IBM i hardware. Note that this
can even include file servers for business critical data, where you
trade off some performance for the ability to have integrated backup and
recovery plans.
Other systems, whether they're third party shrink-wrap applications,
office automation functions, industry-specific hardware/software
solutions (think CAD/CNC), can all run in the outer shell. This can
also include web applications outside the DMZ that interface with inner
shell functions, although for security you may still want to run
WebSphere or Tomcat on an IBM i partition that's in the DMZ.
Anyway, that's my take on it. Every organic system I've seen has
numerous issues: duplication of data, redundant (and stale) business
rules, and security holes big enough to drive a truck through (through
things like hard-coded uid/pwd combinations or the like). Usually they
get to a critical mass and then require a complete overhaul to address
those issues. And that is nearly always every bit as expensive as doing
the IBM i-centric solution from the beginning.
Joe
midrange.com
