RE: Casino switches to AIX

but I'll beg to differ about it NOT being good for simple applications like Facebook.

The "i" is also good for running facebook, in a pure technical sense.
It's more robust, more easily scalable, etc.
But, referring to "facebook" as a business, IMO it's better to just use common hard/software.
The advantages are:
1. Facebook the business has the skills to operate a server park. They have these skills anyway because operating a massive server park is their core business, as with google, Flickr, etc.
2. It's massively scalable, using the right open source tools and combined with skills the application can be scaled massively. A single "i" would not scale enough. You would also have to cluster but you can not grow endlessly. Google has hundreds of thousands servers with their own adapted linux kernel. In their business, this makes sense. It's more costly, but they can differentiate themselves, it's their core business. The core business for a company for which the "i" would be a good fit is never IT.
3. Not being dependent on proprietary software and/or a single company, like IBM and "i". The needed skill set is always available. Investing long-term in a proprietary OS would be risky for a business like facebook. It costs more in terms of support but the skills are in-house anyway.
4. Using standard development tools. Like 3, the skills are readily available. It costs more to build an app with pure open source or standard tools, but this gives more flexibility, and not being dependent on a specific skill set.
5. Not specific for facebook, but the advantage of "i" as a simple and straightforward server operating system is less if 80% of application development / deployment is hacking HTML/javascript these days. Or in general, in a (thick) client / server architecture, the fact that we have a "better" server OS is less relevant. It is an advantage, but this quickly outweighs the disadvantage of having a different, unknown OS, as opposed to e.g. Linux for which skills are readily available.

Second, the application would benefit from using RPG and record-level access.

IMO, RPG and record-level access is way overrated. It will not be the deciding factor, i'm quite sure. The rest of the development world (and they may be wrong of course) is really not impressed with this dynamic duo. And if the RPG community keep saying things like "we don't need no stinkin' objects" that will not help either. Fact is, RPG is tightly integrated with the OS and the database. To be able to do record-level access is a plus, certainly. But it is the platform which has added value, not the default language RPG, with it's 50's heritage, arcane syntax and being "modern" but still rather primitive compared to contemporary languages.

Yes, I'm suggesting that you could do that with RPG under IBM i, and eliminate the server farm.
Not with CGI. Not with PHP. Not with Servlets. But it could be

done by efficiently routing requests to RPG servers which would be
performing DB I/O and generating browser content.
Yes you could. But then you would miss out on the vast amount of available (open source) software for building, deploying and managing websites. These may run on the "i" but are not written in RPG. So you need to keep investing in RPG knowledge. It would be less risky, and maybe even less costly, to use standard open source software. Because it's a "simple" website. And like i said, if you build a web site / app, then 80% of the time is spent hacking HTML/Javascript that runs on the client. The rest of the code, which runs on the server, can also be easily managed and deployed using a standard application server. It's not a production ERP environment, with a team of programmers, which build and adapt the business software on which the company runs.

Date: Thu, 4 Dec 2008 21:18:37 -0800
From: nandelin@xxxxxxxxx
Subject: Re: Casino switches to AIX
To: midrange-l@xxxxxxxxxxxx

From: john e
But if you want to build "facebook", then it would
not be a good idea to deploy on a "i'.

You made a lot of good points about the "i" being best for broadly scoped business applications and complex workloads, but I'll beg to differ about it NOT being good for simple applications like Facebook. Even Facebook needs a database. And regardless of your Web application architecture, when you're serving millions of requests, you'll need multiple database servers of the 64-way class.

So you could put your database on a Power server running IBM i, AIX, or Linux. Or you could go with a comparable server, running something like Oracle. Either way, you're talking about a big investment.

What makes IBM i better? First, the native environment is easier to manage. Second, the application would benefit from using RPG and record-level access.

Most architects today would go with a server farm to host the Web application, and go with a series of big Power servers to host the database. But what if one database server could handle database I/O and dynamically generate Web content about as efficiently as another could generate SQL result sets? Yes, I'm suggesting that you could do that with RPG under IBM i, and eliminate the server farm.

Not with CGI. Not with PHP. Not with Servlets. But it could be done by efficiently routing requests to RPG servers which would be performing DB I/O and generating browser content.

Nathan.




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

_________________________________________________________________
De leukste online filmpjes vind je op MSN Video!
http://video.msn.com/video.aspx?mkt=nl-nl