asap. But just as it took several decades for electricity to
standardize and form utility financial models with government
regulations etc. it will take time here. I'm hoping it will be faster
for cloud computing than the decades for electricity ;-). However, I
do believe that just as the last 30 years of innovation and growth has
occurred around the microprocessor, the next 30 will be around cloud
computing - IMHO this is the most disruptive innovation since the
microprocessor - it _will_ be in the order of decades to reach today's
electric power industry. For example, today it is only extreme cases
where companies need to generate their own power (e.g. mining remote
parts of the world). There is also a maturity in the "power grid"
that allows for multiple consumers and providers to "exchange" with
little or no friction. I expect that some day we'll have a similar
ubiquity for cloud computing - where consumers are unaware of the
providers that are actually running their workloads.
Sorry for the tangential rant ;-). Early web standards were extremely
well crafted and did not happen over night. Just comparing appengine
to amazon's aws shows a big difference in services. IMHO, I like to
see things like appdrop which effectively run appengine on ec2. I'd
like to see the emergence of standard primitives upon which
applications and other cloud offerings like appengine, mosso,
dabbledb, g.ho.st, zoho, and ning can run. IMHO, AWS is a great
start. I hope eucalyptus builds out several apis including ec2, sqs,
and s3 - at least. I'm curious if all the network/firewall and storage
APIs are being implemented too? IMHO, they are critical. In fact, I
think there are other services which AWS does not yet expose which are
pretty fundamental and commonly requested - e.g. a load balancing
service. While it's true that simple "toy" implementations of
appengine have appeared on ec2, we have yet to see _real_ massively
scalable available cloud services built on top of aws. Google's AE is
built on their own, and very different, infrastructure primitives.
Salesforce, Mosso, ning, etc. have all built their own
infrastructures. I suspect that trying to build a couple of these
for real and not just a proof of concept, would expose a number of
gaps in aws. This kind of serious exercise is a great way to mature
the underlying primitives.
I'm all for standardizing the lower level primitives as quickly as
possible so long as we also put enough effort into exercising these
primitives for end applications and higher order clouds alike. I hope
this clarifies my perspective.
WRT higher order cloud services and standards, I'm referring to things
like appengine, bungee, mosso, dabledb, quickbase, ning, g.ho.st etc.
I consider most of AWS as an API for creating and configuring virtual
datacenter resources which includes x86 virtual machines and virtual
network and storage resources. I like the term Infrastructure as a
Service (IaaS) as a description of these services. SQS and simpledb
_are_ higher level and could potentially be built on the core
infrastructure primitives. Other vendors provide higher order entry
points where applications assume certain environmental constraints
like programming language, databases, and scaling/availablity
asumptions. Ning provides a very high level offering for creating
custom social networks.
IMHO, we need some core virtual datacenter resource primitives to be
standardized to start. Just as J2EE standardized an environment for
creating Java applications, we need to have a series of standard
application environments in the cloud - RoR, J2EE, .Net, Apex, etc.
This would allow developers to choose their favorite language and
"environment" for developing applications. Still higher level
services can enable non-developers to "program the web" using more
specialized offerings like ning, zoho, quickbase etc. IMHO, this is
less important to standardize in the near term. However, the growing
number of "Virtual deskops in the sky" like eyeos, g.ho.st, ODesktop,
etc. (http://franticindustries.com/2007/06/16/another-10-web-operating-
systems-reviewed/) IMHO, do warrant standardization in the near term.
By standardizing at this level, developers will be able to write
applications that can interact and interoperate with other
applications "on the desktop". Think of the old OpenDoc (aka
brokendoc ;-) or Microsoft's OLE as an analogy.
Lots and lots to do
tross
On Jun 10, 9:43 pm, randall <rand...@qrimp.com> wrote:
> > IMHO, trying to standardize too soon
> > will stifle the process. As low level primitives become
>
> "standardized" we can move up the stack
>
> > thoughts?
> > Tross
>
> I agree with you completely when you say there are many services to
> build upon. It's a very complicated issue and we've only now just
> scratched the surface, but starting the standards process now will be
> better for the industry - providers and consumers alike.
>
> Having early standards in place will spur innovation because R&D costs
> are lower for service providers. With standards, there are fewer
> worries about IP issues and there will be a committee with broad
> perspectives driving decisions. Furthermore, Open Source projects
> built on standards will be more appealing to the community.
>
> At the consumer end, standards will accelerate adoption because
> switching costs are reduced for customers who may worry about picking
> the vendor who goes out of business. A lot of companies are shy to
> jump in because they don't know where the market is going. If the
> standards were in place, they would have something firm to hold on
> to. As you mentioned about the electricity situation, more customers
> means more cash to invest and the technology will improve. In the
> beginning, standards may lack the robustness needed to suit every
> application, but this is true of HTML, CSS, JavaScript, etc as well.
>
> Those early standards for the web may just be one of the driving
> forces behind its rapid adoption and it was only after standards were
> in place that electricity was scalable enough to proliferate.
>
> To your second point, a good portion of the technologies at the higher
> end of the stack are already standards. HTML, CSS, JavaScript, SQL,
> and XML. What kinds of things were you thinking about for that end of
> the stack?
>
> - randall
--~--~---------~--~----~------------~-------~--~----~
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
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---
Posts
No comments:
Post a Comment