Grids, clouds, parallelism and paralysis

We were debating Parallel Processing, Grids and Virutalisation in
depth last week at the Tradetech Architecture conference.  Halfway
through the conference, discussions of Amazon started en masse.  I have
to say that until recently I thought Amazon was an online book store.
Apparently not.  Amazon is a Cloud.

Cloud computing is the hot discussion in IT architectures and the Amazon service is called Amazon Elastic Compute Cloud (Amazon EC2).  This
is a web service that "provides resizable compute capacity in the
cloud. It is designed to make web-scale computing easier for
developers."  The sales pitch continues by saying that, "just as Amazon
Simple Storage Service (Amazon S3) enables storage in the cloud, Amazon
EC2 enables 'compute' in the cloud. Amazon EC2's simple web service
interface allows you to obtain and configure capacity with minimal
friction. It provides you with complete control of your computing
resources and lets you run on Amazon's proven computing environment.
Amazon EC2 reduces the time required to obtain and boot new server
instances to minutes, allowing you to quickly scale capacity, both up
and down, as your computing requirements change. Amazon EC2 changes the
economics of computing by allowing you to pay only for capacity that
you actually use."

Funnily enough, Amazon are incredibly bright when it comes to web services such as this, as demonstrated by the launch of the payments applications last August.

Anyway,
Amazon's cloud service is in keeping with the core mantra of the late
2000's.   In other words, it enables Software as a Service (SaaS) and
virtual computing through using cloud capacities on demand.  This is
one version of the future of systems technololgies and is seen as an
incredibly important for the trading and dealing rooms of the future.
This is because cloud computing allows the trading and dealing room
technology folks to configure and build systems to scale on demand,
rather than having a large inhouse data centre.

Then the
grid guys stormed in, saying that all this cloud stuff was just
baloney.  You need to look for massively parallel processing using
grids and blades, like the eBay's of this world.  That is the architecture of today and tomorrow.

Someone
then threw the little nuke into the frey by saying, "what if it cannot
be parallelised?"  Now, there's a new word if I ever heard one.

"What do you mean?" asked the chairman.

"Well,
not everything can be processed in a grid in parallel.  Some things are
static and some data is dynamic.  Some data has to be processed in
sequence and some can be processed in parallel.  Some applets and
processes need to cycle, and some do not.  All of this determines if
you can be massively parallel doesn't it?"

The chair and panel conceded the point, and so the conclusion was that the future is a cloud.

Not necessarily.

Another
version of the future reckoned that you can put everything into higher
processing unit power and use the server as a proxy.

At this point, it was doing my head in - as we say in Essex - and so I departed.  But I did wonder what architecture is right. 

Maybe it's massively parallel, cloud computing using proxy servers.

In my own case, I have a different answer. 

As
one trading CIO said to me, "my issue is not processors, green
computing or any of that clap-trap.  It's capacity.  I've run out of
room.  Therefore, I'll sign a cheque just to change my data centre to
support higher capacity, lower latency and faster turn around of
applications and processing at any price.  That's all I care about.
Forget the architecture.  Just tell me what is right for the
application and then make sure I've got the capacity to support the
business."

Seems like a good idea if you ask me.  After all, if
you get too caught up with which architecture is right, you might just
suffer systems paralysis.  Now, that would be a shame, as then you'd be
an ex-CIO. 

So, work it out and implement.