iSeries or Linux

jcenteno

Member
Hi All (1st post btw),

We are currently at the formative stages of cutting across from a BPCS MRP system to JDE E1. Aside from how powerful E1 will be to this organization, l'm at a quandary as to the best server package/operating system (JDE will be on Oracle).
I'm more of a MS server person and have very limited Linux & iSeries skills so both packages will require me to contract then eventually hire a bloke to admin the server.
Question is:
For a user size of 50 users with up to 25 concurrent, which poses the better argument?
Is it possible to run Production and Test/Development in the same iSeries box yet allow me to test Oracle security patches without compromising the Production side?
Or is more economical to run 3 x Linux Intel boxes (well 1 x MS server for deployment).
Our company has been held back by our 20yo BPCS system and l can see us wanting to quickly deploy JDE onto the Web as well as integrated with our Lotus Notes server (on an Intel).

So guys, which is the better option in terms of overall economics and efficiency?

Cheers in advance.
 
Is there a particular reason for not putting everything on intel? whilst it is arguably not th eplatform for big installations for 25-50 users it should be more than adequate and would save you diluting your experience pool.

We're running all intel and whilst it is beginning to creak a bit when we hit above 160 concurrent below that load it's sound. Of course we're only on Xe so that may affect things.
 
I second Richard. Wintel/SQL (or Oracle, if it's set) is certainly the easiest platform. And it's sufficiently fast, scaleable, stable, etc. No reason not to go with it. And it's usually much less expensive too.

To get the same performance off an IBM box, you'd be spending millions. And it's undoubtedly a "pSeries", as Oracle does not run on iSeries.

Linux will likely cost you more than Windows too - the Enterprise edition you'll require is not free, plus the skills are likely not as easy or cheap to source.

And aswering your direct question: yes, you can have multiple Oracle and JDE installs running concurrently, but this would be detrimental to your Production performance (the extent would depend on the DV/CRP sizes, placement and utilization, but the will be some impact at any rate, possibly severe), so ideally you should have different servers for these different setups...
 
Hi,

I agree with both opinions, for 25-50 users the easiest and
cheapest options are to go with Win/SQL or Linux/Oracle
depending on your organization skills.
However, if they're "in love" with AS/400 let them know
that it can run (just on DB2/400) but investing a lot
more money than they would with Windows or Linux.
You should never put Production and Development on the
same box (though they can be on separate LPARs on the
same physical machine). You may have heavy DV/PY queries
seriously impacting PD performance.
 
So everyone loves to trash the iSeries eh?

I have 7 live 812 customers running on the iSeries and another 5 running on Intel/SQL.

The people that are comparing costs are simply looking at hardware and not the total cost of ownership (TCO) with iSeries.

If you want to run 812 on an iSeries you can put everything on an all-in-one box and have simple DR, management, etc. at a very low cost.

As for the Linux stuff, yes you can run this but for only 50 users I would look at Intel/SQL Server.

Oh and BTW 85% of all 812 customers run Production and Prototype and Development on the same box. Actually 99% of my 100+ JDE customers that I support run in this manner so running together is not a problem. Even some of my billion dollar+ accounts run in this manner.


Colin
 
Hi Colin,

It's not about thrashing the i-Series, which is a great
platform, but about choosing one which may fit the
requirements of a small company with 25 simultaneous users.

Small shops usually live with restricted IT budgets, so
it's hard for them to acquire i-Series, p-Series, Sun or
HP-UX hardware and licenses (even if their long-term
TCO is definitely lower than Windows).

All these platforms also require SysAdmins which are more
rare and expensive than Windows IT guys, that also adds
to the cost.

On the other hand, that customer wants to run JDE on
Oracle database, which is not supported on i-Series.

Finally, some countries regulations enforce IT shops
to physically separate PD environments from DV/PY ones.
 
Alex and Sebastian,

OK, I'm going to challenge the "Keep Development and Production on separate servers" opinion.

First, if its a small install (and 50 is definitely small), then its unlikely that there will be a lot of development work going on. In many such sites the most activity the Dev and Prototype environments see is from ESU updates.

Even if they go to multi-foundation that still works quite well on a single Windows server.

As far as database (Oracle) goes, its unlikely in his situation that there will be so much I-O from development/prototype that it will impact production. Particularly since it will be a new install without a lot of transaction history built up.

What I'm really arguing for here is simplicity and ease of maintenance. In a larger shop, going multi-foundation, separating databases, etc is much a much better way to go in terms of overall administration. But in a small shop . . . use the K.I.S.S. principle.

I'm saying this coming from a shop that typically has run all environments on a single server with the database (Oracle) on the same server. We've been both single foundation and multi-foundation, single database instance and now separate production/dev instances - but still just one server, whether it was Unix or windows. (FYI on our next upgrade we'll finally separate the database onto a separate, 64 bit server.)

JCento, the best configuration for you depends on factors you know best. Anticipated customizations, number of users, number of support staff, growth plans, skill base, etc. The great thing about JDE is the ability to easily change your configuration as your needs change and knowledge/experience increases. Don't be afraid to start with a simple configuration (but simple does not equal under-powered).

My 2 cents,
 
I'm one to push the DV/PY + VP/PD positioning... "Yar's ago - my background was public safety - and you would never allow any development on your Production 911 system
cool.gif
"

I can list the dozens of reasons to completely seperate the development from the Production box(s) - I'll just highlight a few:
* The first time your Developer tweaks the OCMs and runs updates Production
* The first time you install a tools package and you get handed a pink slip for two days of manufacturing/sales/whatever going down
* The first time someone changes a Data Dictionary item (thinking it was Only updated in DV)

Ideally, for a Public Company - the ultimate setup would be a minimum of three boxes.
1 - DV and PY for developement and initial testing
2 - VP (Verification for Production) - this is a duplicate box (Hardware, OS, DB, Tools - Everything) of your Production Box. It is used to validate the promotions, setup changes, tools updates - EVERTHING - that is going to hit Production has been tested in the 'Virtual Production' before hitting Production. Yes - I know this is expensive
3 - PD (Production Only)

I've witnessed several orgs where the Auditors have come "pennies short" of mandating the above config - claiming SOX Compliancy (and we all know that SOX is complete interpretation of the organization implementing or governing it
blush.gif
)

The real issue - if you want to protect Production, you only (ONLY) allow Production use on that box.

(db)
 
Larry, yes, it's certainly acceptable in many cases. And the impact will be dependant on the use, etc.

Yet, even if unused at all, it would still take up the memory. And each instance will still be sending all those polling SQL's (like SELECT * FROM SVMxxx.F986110 WHERE ...). And there will be more processes to switch between. So there will be some small unavoidable impact in any case, maybe about 1-5% min (and likely noticeable, if it's actually used).

And a single ad-hoc query in DV that does FTS on a large table (and can run for hours) can stall everything as an unintentional (and unexpected by 99.99% of users) side-effect.
 
Danny,

Since you feel like debating today, I'll spar wit cha.
grin.gif


"The first time your Developer tweaks the OCMs and runs updates Production"

Why are developers tweaking OCMs? That's the CNCs job. Why have all those extra servers when you can, and should, take that authority away from developers?

"The first time you install a tools package and you get handed a pink slip for two days of manufacturing/sales/whatever going down"

That happens often to you?
tongue.gif
This is easy to remedy as well. A company can either have a seperate "sand box" set of servers that is in a lab some where to try that out on, or you can follow good back up procedures. Have a server back up, as well as a second "hot" backup of your foundation code so that you can easily revert to your previous foundation in case something weird happens.

"The first time someone changes a Data Dictionary item (thinking it was Only updated in DV)"

That's the easiest one of all. That falls squarely on the developers. They need to add in a change control record for making a data dictionary change. They need to take responsibility for the change if it causes a problem.

Gregg
 
Jcento

I agree with some of the other posters - for a shop as small as yours, go with wintel. I manage a JDE instance that is more than sixty times your size on Windows servers.

Gregg
 
ok - weighing in my 2c...

No iSeries or Linux/unix bashing (they're awesome platforms and are very good at all size corporations) - but you need to pick the platform you have the most comfort level internally with. If you are comfortable with WinTel/SQL Server - then go with that combination ! I have customers on SQL Server with more than 600 to 1000 concurrent users during the day - the scalability is an architecture question, not a platform question.

Go with Windows/SQL. You'll find a LOT of customers are on that platform, and it gives you a lot more flexibility when it comes to implementing your architecture.
 
Cuzn Gregor,

* Do I change OCMs - NO; but, do other employees/consultants and CNC play with them to test results - YES! They should be locked down so only the CNC has access - but... we all live in the real world??. If PD is poperly isolated from DV - it's not an issue (right?)
* I don't install Tools Packages - I get to enjoy the havoc when things don't go as planned. I'm also the guy that gets to help troubleshoot what the tools did to Production and, more times than not - get to work with Oracle to determine that the issue is tools related in Production. I've always been told that the Tools are shared across all environments 'on a box'. Thusly, I work within the belief that the only way to isolate tools issues between environments is to put them on Seperate Boxen?
* If Development is a completely seperate box from PD - then Developers/CNC and Super-Users could shoot themselves in the head All Day Long - and not impact Production.

Yes - Change Management is Extremely important in all facets.

Thanks for the SPAR!

(db)
 
Dan, this isn't a good place to discuss - but I have to disagree with you.

You're not an architecture person, so you might not fully see how architecture is designed - but I have to disagree with some of your broad-sweeping statements.

First of all, the IDEAL architecure, in ALL environments, is to separate the Database from the logic. That way, you can secure/tune each server within its specific role. There really isn't a reason to try and stick everything on a single machine - even on the AS/400 (LPAR).

When you partition the machine differently, then you can place all your databases onto a single large database machine. Now, a DV database isn't going to affect a PD database - unless your disk architecture is set up incorrectly.

BUT, you can set up a Production application (enterprise) server and a Dev/Test application server with the JDE Enterprise logic. That way, you can prevent users from launching bad jobs/business function code and it crashing the production server ! I also strongly recommend separate JAS servers as well - although some companies use VMWare for their DV/TEST JAS server (and the physical box for the production JAS server).

LASTLY, to answer your points. There is only one OCM - in System - and only one Data Dictionary. Developers should absolutely be secured so the only thing they can do is ADD to the data dictionary. Too many issues come from changing DD or updating OCM tables - and they usually get a pink slip for making their own mappings in OCM without informing anyone.
 
Apparently - it's "beatdown danny day"
shocked.gif


Time to continue the defense....
I've had two Auditing firms and worked with two private companies that have been required to setup just as I stated (three seprate machines, or LPARs) for; DV/PY, VP and PD. one of the two public companies 'proved' to the auditors that the expense wasn't worth having a VP. The other three went with arching three seperate boxes (and/or LPARs) for the four 'base' environments. This work EXCELLENT within Change Management (ESUs, DD mistakes, Tools Releases and Development). There were significantly few PD Down Issues.

At one site - there were multiple OCMs and DD. I am not a CNC - so, I can't quote how the configuration look. I do know that the Development/retrofit team could not see the destination VP/PD boxes via OCM - however, if we logged into the VP or PD boxes - we could see DV/PY (and I was told this was not done with Security). I was told that OCM and DD was different on each box - specifically to isolate Development from Production.

Jon is right - this isn't the thread to discuss the architecture and I'm no CNC/Architeture person. I do know that in ALL Development Life Cycles - the Goal is to:
1 - Development environment - completely isolated from any form of impact to Production
2 - Prototype/Testing environment - completely isolated from any form of impact to Production
2.b - Verification Environment - if the Production environment is significantly different from the Prototype/Testing environment, change managment needs to occur on a similar box/database/environment to Production
3 - Production Environment - where the action takes place.

Sorry for ruffing feathers. My goal was to explain from the Developer / Change Management aspect - Seperation is imparative

(db)
 
Cuzin Dano,

I like your concept of seperate boxes for Production and Development. In an ideal world that's a great concept. Here in Fortune 500 world, we use a similar concept if not exactly what you spelled out. The only flaw in your well spoken arguement (no, there is absolutely no sarcasim in that remark) is that it is a fully loaded Cadillac solution.

The original posters moderate size implimentation sounds like it needs a Chevy solution. If they are transitioning from a 20 year old legacy system, I think it would be a tough sell to put in a fleet of Cadillacs. In fact, pitching the Caddies would only give the naysayers in his company more excuses to go another 20 years on the legacy. Likewise, that's a good reason to go Microsoft since that is what they are geared up for. There's nothing wrong with iSeries or Linux other than having to go out and hire a new skill set. If they can avoid that, then that's a win.

Let's give the guy a good Chevy and welcome him to the club. Oracle will come along soon enough with the requirement to move up from an Aveo to a Suburban. Let's just help them get rid of the Edsel first. (Did I use enough car analogies?
grin.gif
)

Gregg
 
Sebastian....

not sure if he wants Oracle beacuse he indicated that "Is it possible to run Production and Test/Development in the same iSeries box yet allow me to test Oracle security patches without compromising the Production side?"

Didn't see any indication of an Oracle DB?

Perhaps a point we should consider especially since this may be new is that the iSeries (AS400) has an imbedded database call "DB2 UDB for iSeries). This means an Oracle isn't required.

Now given that there are only 50 users and 25 concurrent I don't think one can justify seperate Production and Development boxes.

IT'S ONLY FINANCE!

And with only 25 users just how much development is being done?

Now we sell hardware - lots of it. Lots of iSeries, lots of Blade and lots of SAN so I'm the first guy to want to seperate Production and Development but in so many cases it's just totally not justified. Many clients just don't do enough development to rationalize it.

So what good is it to have yet another hardware asset sitting around doing nothing? We already have the Deployment Server performing this role :)>).

This looks like a perfect opportunity of Virtualization if you want to have a seperate Production and Development "instance".

Just my $0.02 (CDN) - $0.019878 US.

Colin
 
[ QUOTE ]

Let's give the guy a good Chevy and welcome him to the club. (Did I use enough car analogies?
grin.gif
)

Gregg

[/ QUOTE ]

I agree, as long as the Chevy is a nice C6 Vette or possibly a C5 Z06.
 
Alex,

all your points are well taken - for a larger shop.

Based on experience with a shop that's about 5 times his size . . . Dev is unlikely to have any noticeable impact on production. The assumption of course is that the hardware is appropriately sized. If the hardware is borderline then, yeah, I'd be more willing to buy your argument.

Anyway, given that it sounds like its a one man operation at present, the overriding principle still needs to be K.I.S.S.
 
Back
Top