Wednesday, December 17, 2008

Re: FW: [ Cloud Computing ] Compute surface as a traded commodity?

Back in 2005/6, when the team I ran built Zimki (a utility computing
environment with a JavaScript application framework) - think
GoogleAppEngine but with JavaScript and not python - my intention was
to open source the platform at OSCON in 2007.

The reason for this, is that the entire framework (or what is more
commonly called PaaS these days) contained all the users code and data
in a multi-tenanted environment and it was relatively trivial to live
migrate from one instance of the service to another (we had this as a
one click operation). We demonstrated this in 2007.

The purpose of open sourcing the entire platform (which was to be
under GPLv3) was to enable multi-providers of the service to quickly
establish. You could consider the platform to be an open sourced
standard (i.e. the standard for the service was an operational open
sourced stack). By using GPLv3 it would also enable providers to make
operational improvements to the platform without releasing them back
to the community (exploiting the SaaS loophole for operational
advantage).

Portability in this case would be ensured through the use of an open
sourced standard and monitoring compliance against it.

The pricing mechanism we used to use was JSOPs (JavaScript
operations), bandwidth consumption (MB) and storage (Mb daily max) and
the system was designed to allow a marketplace with competition based
on price vs QoS (quality of service).

Unfortunately though the system worked and had growing users, for
various reasons the system never got out of beta and is now defunct

Portability, marketplaces and exchanges in the cloud computing world
are more than possible at all levels of the computing stack. However,
to achieve this the standards have to be operational pieces of code
and not specifications because you need to ensure not only compliance
to a standard but that no provider exceeds the standard
(differentiation is the enemy of portability).

I did a very light-hearted and simplified talk about this at OSCON in
2007 (see http://blip.tv/file/414050).

Also regarding the point about bricks and commoditisation. Yes, bricks
are commodity-like components and whilst that enables us to more
quickly build houses through the use of standard components, the
commoditisation of a lower order subsystem doesn't necessarily result
in commoditisation of higher order systems.

Commoditisation is a result of an activity becoming ubiquitous and
well defined. So whilst bricks, plumbing and electrical connectivity
are in general ubiquitous and well defined activities, the higher
order systems (houses built from bricks etc) dare not necessarily need
to be so.

However, there are plenty examples of standard box like house
designs.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to
cloud-computing-unsubscribe@googlegroups.com
To post job listing, send email to jobs@cloudjobs.net (position title, employer and location in subject, description in message body) or visit http://www.cloudjobs.net
To submit your resume for cloud computing job bank, send it to resume@cloudjobs.net.
For more options, visit this group at
http://groups.google.ca/group/cloud-computing?hl=en?hl=en
Posting guidelines:
http://groups.google.ca/group/cloud-computing/web/frequently-asked-questions
This group posts are licensed under a Creative Commons Attribution-Share Alike 3.0 United States License http://creativecommons.org/licenses/by-sa/3.0/us/
Group Members Meet up Calendar - http://groups.google.ca/group/cloud-computing/web/meet-up-calendar
-~----------~----~----~----~------~----~------~--~---

No comments: