The Abstract Truth

The Widget Application Server

Posted by rbpasker on April 8, 2008

I’m following up to my post of earlier today because I want to flush out another level of detail on what GAE, AWS, and competitors will eventually require. I’m tentatively calling these kinds of systems Widget Application Servers, because they will first and foremost be used as the back-end for widget-style applications that can be embedded on a page or on your desktop built for various platforms, such Facebook and OpenSocial apps; Google Gadgets, Yahoo! Widgets, and AOL’s Your Minis.

There are three key pieces to the Widget Application Server puzzle: application development, application management, and business management. Right now, one could cobble together all of the pieces from a variety of different Saas platforms, but I think the major players will emerge with an implementation of the whole thing.

Application Development support includes all of tools necessary for building and testing the application itself, including:

  • multi-language support: py, php, ruby, js, maybe even Java
  • libraries of reusable functionality
    • Social networking libraries for OpenSocial and Facebook
    • IMAP4/POP3/SMTP access libraries
    • parsers and generators for microformats (vCard/hCard, vCalendar, KML, etc.)
    • parsers and generators for interchange formats (XML, JSOn, Atom/RSS)
    • graph and chart generators, etc
    • bound controls for MVC-style design

  • testing tools — unit, system, performance
  • source code control/versioning — Git, svn
  • authentication and user management — OpenID, X409
  • data access — key/value indexes, tuplestores, relational systems, queueing systems
  • internationalization
  • session management

Application Management

  • application life cycle management
  • content management
  • load balancing
  • backup and recovery
  • migration
  • storage management
  • DNS management
  • logging, tracking
  • localization
  • issue/bug/support tracking

Business Management


  • ad management
  • revenue optimization
  • multivariate testing
  • eCommerce
  • accounting and billing
  • payments

With all of these pieces in place, the application developer would be free to build the application and load it up into the cloud, and not have to worry about many of the time-consuming and tedious management and operational issues.

Advertisements

8 Responses to “The Widget Application Server”

  1. Add to business management:
    – behavior tracking
    – analytics

  2. Very interesting. The Google App Engine is a step in that direction. It will be interesting to see if a more open alternative will emerge.

  3. Seth said

    Bob great read…I’m thinking the Application Development part is already solved for the most part with frameworks like Rails or Django.

    However, it’s odd to me that AWS or GAE neither have a robust Application Management setup yet. No off the shelf backups, DNS management, recovery, etc yet.

    I was looking into Amazon’s offerings last night and was impressed by the depth of the services they’re starting to offer. Too bad their documentation is a little sparse. DevPay in particular caught my attention with all of the stuff I’m currently working on.

  4. This is pretty interesting. You should probably add OAuth to the AuthN/IdM list. Since all the major AuthN providers support some kind of token exchange, this is likely to become more important over the next 3-5 years.

    Some of the items on this list should be handled by the “substrate” (the Fountain layer in your other slide set), and the rest should probably be part of a platform for social applications (which I don’t think are limited to widget/gadget). The widget/gadget architecture limits the possibilities of apps by running everything in the browser. The Facebook architecture is a little more interesting, since the application really looks like a traditional component in a platform stack. Interesting in how disruptive it is, too, taking over ground that was previously occupied by more complex technologies like WSRP (that never really went anywhere).

    I certainly hope that the business management layer is about more than ads, though. I’ve written myself about how the business of applications needs to be more than just ad-supported, since traditionally applications compete with the networks that host the apps for ad space and mindshare (talk about channel conflict…). There will be opportunities eventually when social networking technology is more pervasive and more sites are able to integrate social applications into their core web presence.

    @Seth I think the app dev parts are _mostly_ solved. The interface with social networks is currently limited to those actions the social networks are interested in supporting. There’s nothing inherently wrong with that, but applications might be interested in having more services provided by the networks they attach to. This is more than just Rails, etc.; it’s about how social context is passed around the Web.

  5. Seth said

    @Jason ….OpenID solves that problem quite nicely I believe. Now if everyone would just jump on board (myself included :)…

  6. rbpasker said

    @jason what do you think limits this scenario the browser? I specifically call out “desktop” in the first ‘graph, and I should have also said “mobile,” as it could be used as the back-end for iPhone apps (web-based or iPhone SDK) and for Limbo Magic apps (http://primezone.com/newsroom/news.html?d=103927).

    also, I’m not arguing that pieces are not done (eg Heroku), but rather than developers will come to rely on a suite of technologies to successfully develop, run, and possibly monetize their work.

  7. @Jason – I agree that the money is not just in ads. CPMs are running in the $.10 to $.20 range for apps right now. Fred Wilson recently put together a giant list of monetization mechanisms, but the problem is: how many of those justify some sort of management dashboard like this? I suppose if customers ask for it, it can be built.

  8. @Seth I agree OpenID has a nice architecture, but I have to wonder if the critical mass of portals and social networks won’t have the momentum to consolidate the Web authentication model into, say, 3 major authenticators (or perhaps 3 protocols with possibly many implementations). I don’t know if the general public is convinced that OpenID solves a problem they experience on a daily basis or whether it solves it significantly better than logging in via Google, Facebook, etc.

    @Rbpasker I didn’t mean to imply this architecture stack was limited to browser scenarios. I suppose I meant to say “client”. Delivering and running code _solely_ in the browser/client limits security and authenticity. This isn’t to say there are ways to improve the environment, but as soon as code is downloaded as source and executed (i.e. JavaScript), additional mechanisms need to be in place to ensure authenticity of requests, even if it’s just secure pipes (HTTPS/TLS/SSL). I agree that platforms that include a monetization component are key (and clearly more than just ad network integration). Imagine an e-commerce offering without a shopping cart and credit card processing; it seems absurd to think of it now! The market may be a bit immature yet, but I do think serious applications of the technology will emerge that will provide their own value to the market, driven by engagement via social networks and social applications that will continue to emerge across the Web.

    @Chris Based on what I’ve heard (especially from e-commerce companies), I think you can’t help but have a monetization dashboard. No matter which of a dozen ways your particular app/gadget/widget can make money, it needs to be measured and tuned. If you choose to, you can also expose some of these statistics to the users. There will always be someone who won’t sign up until the ROI is justified, and without any kind of measurement, that’s going to be a tough sell. Some of the monetization models may augment or even replace other interactive marketing and advertising models as well, and we know those are highly metrics-driven. Bob Bickel wrote a good blog or two on that topic, comparing social application engagement to traditional keyword advertising here:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: