Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter

Expert Texture

The blogged wandering of Robert W. Anderson

Cloud Services Continuum

I have found myself talking about cloud services a lot recently.  We have been talking about them here — there is an obvious synergy between what we do at Digipede and cloud services.  And I’ve been talking about them externally too: at the recent CloudCamp, on the Gillmor Gang, and in all sorts of other interesting contexts. 

Note that I refer to cloud services, not to the cloud.  I am not interested in defining cloud as a term, because I don’t think it very useful.  For those of us in the distributed computing space, cloud is the latest buzzword to compete with the word grid in terms of utter ambiguity.  I think the ship has already sailed on this one and I’m not going to try to call it back.

So, everyone is talking about cloud services and much of the conversation centers on understanding them and how they are changing the landscape.  Of course, cloud services are not one thing.  I find it helpful to think about them as parts of a continuum.  This seems useful regardless of the technical level of the people with whom I’m speaking.

imageThe diagram to the right shows this continuum from infrastructure to platform to software.   Brief definitions of these parts are:

  • Infrastructure includes provisioning of hardware or virtual computers on which one generally has control over the OS; therefore allowing the execution of arbitrary software.
  • Platform indicates a higher-level environment for which developers write custom applications.  Generally the developer is accepting some restrictions on the type of software they can write in exchange for built-in application scalability. 
  • Software (as a Service) indicates special-purpose software made available through the Internet.

I have indicated several companies that play at different parts of this stack.  This list is not comprehensive nor does it attempt to represent motion across the stack.

One scenario in which I find myself talking about the continuum is when people equate Amazon EC2 with Google App Engine.  EC2 is a flexible / scalable virtual hosting platform with provisioning APIs.  It allows you to dynamically scale the number of instances of your OS (i.e., Linux).  What you do with those instances is up to you.  Google App Engine operates at a much higher level in the stack.  It is a new software platform with specific APIs.  It requires developers to build for this specific platform.  yes, they are both in the cloud, but they are very different services. 

Another scenario in which the continuum is useful is in thinking about what vendors and new entrants might be up to.  The continuum makes one thing even more clear: many vendors that operate higher in the stack are relying on their own internal lower-level infrastructure or platform.  This begs some questions: which vendors will expose lower-level interfaces?  And of course, which vendors will move up the stack? 

  • SalesForce is already moving down with their PaaS offering. 
  • Any chance Google will expose its infrastructure stack?  I doubt it, but I do expect them to move down a little. 
  • Some of the readers of this blog probably know better than I where Amazon and Microsoft are planning to go.

Yet another way it is useful is in comparing vendors inside of a particular category.  Maybe I’ll write more on that later.

Is the continuum obvious?  Using the definition of obvious from patent law, yes, but I think it a useful paradigm.

Tags: , , , , , , ,

Google I/O Day 1

Quick notes from Google I/O today. 

Best things I saw were (in order):

  1. Android.  Very disruptive.  It will force the iPhone to be more open.  It will further commoditize the hardware (driving down prices).  It places Symbian, RIM, and WM into filling niche roles.  Of course the other mobile OSes aren’t sitting still, but they are already playing catch up.  This will put them further behind.
  2. GWT.  JavaScript apps written in Java with familiar tools.  Cool.  Interesting how Microsoft and Adobe are solving the JavaScript-dev-maint problem with rich containers (Silverlight and Air / Flash) while Google is solving it with a Java to JavaScript compiler.  The former are working outside
  3. OpenSocial.  The fundamentals of this API and Friend Connect are to allow social applications to interact across silos.  To me this means user control.  This will ultimately force silos (like Facebook) to open up.  I like it.

Participated in the ongoing argument between Robert Scoble and Steve Gillmor regarding FriendFeed.

Met a man dressed in a pirate costume.  Or Ben Franklin costume.  Pano Kroko.  Fascinating guy.  Checkout www.churmo.com.

Ran into an old friend, Julian Wixson.  Hadn’t seen him for at least ten years.

Went on a trek with Robert, Steve, Pano, Julian, Vincent Nguyen of Slashgear, Mark Lucovsky  and a student to see Gary Vaynerchuk talk about his new book.  I learned two things:

  1. It is about a 15 minute walk from Moscone West to Union Square. 
  2. Don’t drink the same varietal twice.

Got back to the Google party just in time to see Flight of the Conchords.  Those guys are very funny.

Tags: , , , , , , , , ,

OpenID isn’t ready for prime time

The other day, I wrote How many OpenIDs do I need?  The premise was that the Identity Community needs to help educate users on the choices surrounding the use of OpenIDs.  Having bought into the hype of OpenID I have since:

  • Read various critiques and articles supporting OpenID.
  • Added OpenID comments to this blog. 
  • Got an i-name, =rwa, to act as my public OpenID.
  • Began tracking OpenID on Twitter.
  • Participated in discussions about OpenID in financial services.
  • Tried to Demand OpenID, only to find my OpenID verification failed : (

All together, I’ve come to a few conclusions.

Users assume OpenID has a trust layer

Track OpenID on Twitter and you’ll see what I mean.  Here is one example:

  • (leighhouse): Bill: OpenID also insures you’re not a machine / spam, creates acess #iCitizen
  • me: @Leighhouse: openid does not prove you are not a robot. Anyone can create a Provider that accepts arbitrary IDs.
  • (leighhouse): @rwandering Can if authenticated? Can eventually? Or Can’t period.
  • me: @leighhouse: it depends on the Provider. Services need to evaluate trust of Providers (which is already too hard).
  • (leighhouse): @rwandering Can if authenticated? Can eventually? Or Can’t period.
  • me: @leighhouse: you are asking the wrong question. OpenID is only authentication piece, trust of IPs is a bigger question outside of tech OpenID standards.

OpenID is intended to provide identity, but without trust.  Search around the Internet and you will find an OpenID Identity Provider (OP) that takes this to the extreme: it accepts arbitrary URLs with no authentication at all.  It reports “trusted” to anyone who asks.  Granted, this OP exists to demonstrate a point, a kind of “white hat” OpenID hack, but it leads into my next point.

Relying Parties don’t have any reasonable way of determining trust levels for Providers

Some OpenIDs can be trusted (e.g., Google, Yahoo, myopenid, etc.), others cannot.  I want to be clear that I’m only talking about trusting Google (or some other Big-Co) as an OP.  That means that they manage user authentication in a reasonably secure way.  I am not talking about trust outside of that relationship, or even if it makes sense to trust Google as the center of your identity.

So some can’t be trusted.  In addition to the example OP above, what about the numerous self-hosted OPs that are springing up? 

How is a Relying Party to distinguish between all these different OPs? 

It appears the OpenID authors intended to delegate this issue to a 3rd party (e.g., VeriSign or perhaps a community-based foundation).

Fair enough, but how are services to deal with this issue today?  I don’t think they have a reasonable way to do it, except to maintain their own list of trusted OPs.  But that is a brittle system to say the least.

And more

On top of this, there are many technical issues that are being raised about OpenID.  These range from security issues to privacy issues and much more.  A good round up can be found here: The problem(s) with OpenID.  Some of these issues are at the heart of why users shouldn’t want one ID on the Internet.

OpenID isn’t ready for prime time

OpenID shows a lot of promise and has real value in some current use cases.  Google Friend Connect stands out,  as do any applications that are built on top of services published by OpenID providers (e.g., if you want to build a service that interacts with WordPress.com, OpenID might make sense).

The OpenID hype is getting way ahead of what the technology can deliver.  People are rushing out to get OpenIDs and people are demanding that their services become Relying Parties, but the technology is just not ready for general adoption. 

The leaders in the identity community (the Identity Commons?) need to slow this down and get these issues sorted out, otherwise I think OpenID will end up a big failure.

It just isn’t ready for prime time.

Tags: , , , ,

Come on Google, support i-names for OpenID!

Playing with the Google Friend Connect demos last night, I found that my i-name doesn’t work as an OpenID.  No big deal, after all it is a preview release.

Today I went to add a comment on a blogger.com blog and tried my i-name there.  Nope.

image

What’s up, Google?  Why aren’t you supporting i-names?  Oversight, planned for release, bug, or politics?  I really hope it isn’t the latter.

Tags: , , ,

Google Reader or TypePad getting confused?

Today while using Google Reader, the feeds for Recognizing Deven (http://munjal.typepad.com/recognizing_deven/index.rdf) and flow|state (http://miksovsky.blogs.com/flowstate/index.rdf) have both been serving the London Blog (which I have no interested in reading).

Is this a bug in Google Reader or TypePad?  Anyone else experiencing this?

image

And congratulations to Mr. Farrell for giving up the drink.

Tags: , , , ,

Google Reader Misappropriated Our Shared Items

image_thumb[1]Earlier in the week I stopped using Google Reader for a few days.  Every time I started it, I would be reminded of their new sharing features (see the dialog on the left).  Then I would close the browser tab. Why?

Google changed the Reader user-contract with no notice.  This rankles me.  I’ve lost control of my shared items.  This is a dramatic change with only the weakest of opt-outs.  What’s more, any opt-out is too late.  My items have already been shared.  What kind of opt-out is that?

Oh, but there are more options.  They give us the ability to manage who gets to see our shared items.  But only after others have a chance to read them.  For example, I can hide my items from my “friends” who are on Google Reader.  Other “friends” that start using Google Reader will get to read my shared items immediately.  The onus is on me to make sure I actively manage the list. 

And the icing on the cake?  “Friends” wasn’t a word in use by Google Reader before.  Now it has been defined to mean my Google Talk contacts.  No fair.  This is not analogous to Facebook “friends”.  In Facebook, I accepted people as “friends” based on the Facebook definition.  Now my Google Talk contacts are my “friends” based on Google’s new definition.  This is clearly backwards. 

Is Google breaking their terms of service?  Almost definitely not, but they are changing a basic part of the user-contract: that user data won’t become more public without user consent. This is a perfect example of the “User-Beware contract“, summed up as: “we’ll change the user contract whenever we feel like it.”

What’s next? 

Your email contacts have been shared with your friends

Your emails have been shared with our advertisers

You calendar entries have been shared with your . . .

You get the idea.  This may seem like a joke, but frankly I don’t know what is in store for the user contract.

Steve Gillmor suggests this is arrogance on Google’s part, and he’s probably right.  Yet mostly people are ignoring this or don’t get it (e.g., Scoble doesn’t seem to get why anyone would care). 

Why is the blogosphere giving Google a free pass on this one? 

Tags: , , , , , ,

OpenSocial payback?

Many are calling Google’s OpenSocial play an apparent retaliation against Facebook for their recent Microsoft deal.  The reasoning is that both Microsoft and Google were bidding for a Facebook ad deal.  Microsoft won, so Google is going to make Facebook, and by extension Microsoft, pay.

Perhaps it is payback, but certainly the OpenSocial strategy predates the Microsoft agreement.  Not even Google could pull this whole thing off in just a few weeks.

This begs some questions:

  • Did the losing proposal from Google include OpenSocial?  Did it require that Facebook adopt the APIs?  Did that push Facebook to Microsoft?
  • Alternatively, was Facebook threatened with OpenSocial as a retaliation?  That is, did Google offer to shelve OpenSocial if Facebook accepted a Google deal?

It isn’t yet clear (to me anyway) whether or not Facebook was briefed on OpenSocial.  Google said yes, then no.  Facebook said no, but some evidence points to them actually having known. 

  • Are these differing stories rooted in non-disclosure agreements dating from the failed negotiation between Google and Facebook?

Final question:

  • Does anyone really believe that Google would have shelved the OpenSocial strategy just for an ad deal with Facebook? 

I for one do not.

For an excellent post on Facebook / OpenSocial, read Dan Farber.

Tags: , , , ,

Good Lawford

Steve breaks radio silence and admits he is a pooka (from Bad Sinatra).

A lot of good stuff in this post, but I want to highlight one part. 

I posted the other day about the deprecation of the Google API.  My take: good for the Google; bad for the gaggle (i.e., the application developers).  Fun to talk about, but there are pragmatic solutions to this.  Something to be scared of?  No.

We (the users) needn’t be scared of vendor choices like this.  Why not?  Because nobody is forcing us to use these services.  As Steve says:

Who am I supposed to be scared of? Google? Nope, if the Ajax API and the terms of service around including unaltered adsense are so counter to user interest, that will precipitate a decline in usage and therefore less adoption of Google properties. Seems self-correcting to me: user votes, user wins. Why do we need saving here?

Exactly.

Tags: , , , , ,

Don Box and Dave Winer agree

Two guys who know a thing or two about web services and APIs think the new Google Search API is a step backwards.  I agree.

My guess is that some high up at Google thinks of it as a step forwards.  Perhaps someone asked the question:

Why are we providing search results into arbitrary applications, when in fact, we are in the business of serving ads on Web pages?

An AJAX-only API is a fine way to do just that; but like Don Box says:

No matter how you define “web service,” I don’t think this newest offering qualifies.

I’m hoping this is just an anomaly and not a trend, lest we all fall back into the world of opaque/closed protocols.

Google doesn’t have to provide open and interoperable APIs to the world; but, I bet others will. 

Tags: , , , , , ,

Google and the honeymoon

A lot has been said about Google complaining to the government about IE7 (from NYT).

Don Dodge says that Google’s honeymoon is over. Perhaps this is true. Their complaining about the way search is handled in IE7 does seem disingenuous.

In the past I’ve said that Google’s goodwill will wane. From Dave Winer’s Geek Dinner for Scoble with relevant excerpt here:

Google has enjoyed a great deal of popularity as an answer to Microsoft’s dominance. They have a stockpile of goodwill and trust from people simply because they are not Microsoft. This is not permanent. The bigger they get, the more profitable they are (if that’s possible), the more people they piss off with their own kind of over-reaching, the more this is going to wane.

Google has some great products, of which search is #1. But, please Google, don’t try to lock in your users by complaining. Do it by making your products better.

Tags: , , ,

Next entries »