|
Lukas:
Imagine you want to run facebook:
We don't. The "i" is specifically meant for OLTP applications, ERP.
Facebook et al need to be massively scalable and provide a relatively simple function.
Further, they are based on a client/server architecture. The server needs to process lots of relatively simple requests.
This is completely different than running a system which needs to support the basic processes of a company.
These systems do not need to scale massively, but they do need to scale, from 10s, to 100s and 1000s of concurrent users.
There main function is to process simple data. The functionality can be quite complex and is ever changing.
They do not have to be able to download lots of data, like images etc. They also have much more complex interactions than Facebook.
The main function of sites like facebook is that they need to scale massively, and handle hundreds of thousands simultanious requests.
Also, these sites are outward faced, public.
For the kinds of applications needed to support the main business processes an "i" is the most cost effective solution.
That is, a powerful, but simple, straightforward and predictable OS environment.
Also, the host based application deployment is also best for OLTP apps, instead of client/server, which is a concept from the technical/scientific world.
For scientific/technical apps with lots of processing and less data I/O and manipulation client/server is a good architecture.
Also, for massively scalable apps like facebook and google client/server is - as of yet - the only solution.
But client/server is not a good approach for the kind of business apps the "i" is built for.
Client/server also adds a lot of complexity - even without Windows - but this added complexity has no real return.
It looks like due to the domination of MS the "good old" concept of a host machine with terminals has been completely thrown away resulting in the mess we have today.
Distribution of application code (i.e. separating part of the code to run on another computer, e.g. a connected PC) is a good idea.
But only when done with thought and in a managed way, there where it really makes sense.
But now there seems to be either the "old" way, that is completely centralized like green-screen apps, or completely decentralized.
The popularity of "web apps" for businesses is solely based on easy of deployment.
In the 90's we had the classic C/S approach with thick applications on the PC with only the database on a central computer.
This was difficult to manage and with web apps we suddenly have a completely new technology stack with the only advantage being that more code runs on the server.
I.e. we now have an extra application server adding more complexity on the server side, but is easier to deploy.
But we don't have anything more we already had with classic thick client apps, only easier to deploy.
We also have a complex application technology stack with HTML/CSS/Javascript which deliver less functionality than what we already had with classic VB apps.
Just recently we can use something like jQuery so that a web apps looks and behaves a bit like a classic VB app.
The browser is simply a new application platform other than Windows that is ubiquous but is not controlled by MS.
New application technology platforms like Flash use the browser simply as nothing more than a delivery mechanism for a new proprietary application platform.
The next step would be that all code runs on the server (like "green screen" apps).
In the realm of "modern" systems there hasn't been much progress the last 10 years.
I don't advocate "green screen" apps, but i do advocate a more centralized approach for typical business apps, for which the "i" is the best platform.
If only IBM did not stumble and almost fell in the 80's due to the proliferation and huge success of PC's (on which MS capitalized).
And instead did to X Windows what they did for VT100 terminals in the 70's.
But there still is a future for "i", because the platform is stable and high quality.
Fundamentally it is a good platform. Only the application development technology stack is completely outdated.
But there is hope. On Windows, it is technically not possible to switch to a better platform, but on the "i" the platform is not the problem.
It is the applications that is the problem on the "i". And this can be fixed, technically, and practically.
Date: Sun, 30 Nov 2008 10:44:29 +0100
From: lukas.beeler@xxxxxxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Casino switches to AIX
On Sun, Nov 30, 2008 at 10:20, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
It sounds like you're referring to having a mirrored backup server for high availability; in the event that your primary server goes down. And that's fine.
Yep. At least that's what Microsoft and IBM use the term "cluster" for
(with exceptions like HPC, of course).
There may be many motivations for using server farms. Complex workloads tend to destabilize Windows over time, so farms become a means of managing that problem.
This is exactly the kind of FUD that doesn't help anyone.
Server farms are a way to scale CPU or static IO intensive workload
horizontally, while still providing redundancy. This is a very good
approach for web applications, as it keeps the cost low and provides
very high performance. It is unsuitable for OLTP workloads, and never
used there.
I'd rather deploy applications to IBM i libraries, and maybe to an additional mirrored server, and be done with it.
The architecture used to deploy an application should depend on what
exactly you want to deploy.
Imagine you want to run facebook: You'll needs lots of static
bandwidth for images and such, and lots of processing power for
rendering customized pages for each of the thousands of concurrent
users, located all across the globe.
Even if you have a 64 socket 595, you'll run out of CPU juice soon
enough. And if you need to apply PTFs, facebook will be down. So
you'll need two fully loaded 595, and they still won't be enough.
A better approach would be to use a central DB server (e.G. a
redundant pair of 570) frontended by lots of 520s running the
application.
Things change when you want to run an ERP application, which is very
OLTP heavy. Then, a redundant pair of 595 might make more sense.
The key is to use the right approach for the unique problem your
business is facing - running Facebook is massively different from
running an ERP application.
These key concepts don't even shift much even if you switch platforms
- if you want to run an OLTP heavy ERP on Windows, you're much better
of purchasing an IBM x3950 which can help you scale Windows to up to
96 cores (4 chassis at 4 sockets with 6 cores each).
http://www-03.ibm.com/systems/x/hardware/enterprise/x3950m2/index.html
This that remind you of anything? The general concept behind the x3950
is almost the same as the one used for the Power 570.
--
Read my blog at http://projectdream.org
--
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.
_________________________________________________________________
Nieuw: nu ook chatten op je mobiel!
http://www.overaljevriendenbijje.nl/#superdeal
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.