April 2007 - Posts
John Musser over at ProgrammableWeb.com has summarized the various ways (he's outlined 12) API providers can control access to their web services. As John says,
"There are good reasons for this ranging from preventing abuse, controlling costs, or other business-driven reasons."
John triggered a few thoughts for me with his post...Thinking out loud now...
7 Thoughts on the Business of API Throttling
1. Web APIs will be a key driver of future of the networked, services-based economy
2. The science of web API throttling is set to become a core business competency - not just a technical competency - for (hundreds of) thousands of businesses
3. Businesses need to learn about the business of API-based business models (an area where there is some experimentation and learning is going on today, but not enough)
4. Business expertise in designing and evolving API-based business models will be a highly valued skill / commodity
5. Standardized business models need to (and will) emerge regarding web APIs, similar to how there are standardized business contracts today
6. API throttling will become exponentially more complex to execute and operate
7. A significant number of small and medium-sized business (the long tail of today's economies) that want to thrive in the networked economy will need to make a decision in the near future: "do we spend large amounts of resources in the technical operation of API service delivery and throttling expertise in-house, or should we outsource this?"
If you are going to be at the Web 2.0 Expo in San Francisco later this month, let me know - would love to hook up.
It's going to be an exciting time for us at Bungee Labs as we'll be revealing our product to the world and formally opening up applications to our early access beta program. We have some space at the Expo Hall where you'll be able to get hands on with our gear, so drop by - you won't be dissapointed :-)
Also, our CEO Martin Plaehn (now he's an interesting guy...more on Martin later) will be introducing Bungee Labs at a session on Wednesday (April 18) morning.
--
If you're not heading to the expo but want to get in touch anyway, you can contact me here: 
Danny dropped by and asked me: "Hi Alex, do you happen to know of any half-decent definition of "the cloud"?"
I know it sounds corny, but 'good question'!!
So I'll give it a go.
Now, I could get textual, but I'll first try to answer with a few pics...
Maybe I see the 'cloud' as over-developed green jellyfish layer that's growing over the surface and orbit of Earth?
Hmmm, maybe not.
Or is it more like a cliché?
Maybe it's more like one giant thought-bubble in the sky?
Or a memecloud perhaps...
Or, and I do like this one, a cloud of APIs:
Enough pics.
Let's get textual now. Here are some that allude to the half-decent definition you're asking for:
"the Internet cloud, where massive facilities across the globe will store all the data you'll ever use" - George Gilder
Good, but limiting. The cloud is much more than 'just' all the data in the sky. Next...
"Like a cloud, the Net can't be pinned down - it's alive, unpredictable, and, as innumerable startups learn, can prove a funnel cloud or even a Bengali typhoon. When the Internet is depicted as cumulus humilis, it's dead wrong...It's much more altostratus - intense, rapid - and a failure to give it proper respect can result in disaster." - John Chambers
Yeah, kind of, but not particularly helpful in terms of understanding what is meant by 'cloud' (and, frankly, a little over-dramatic for my taste).
The next is more like it:
"Once your software becomes a service in the cloud, it opens up the potential to link it up with other services that are out there. For many vendors and users this is still a barely dawning realization, but it's of fundamental importance. In many ways, the Internet cloud is one great global SOA — still very rudimentary in many ways, but flexible enough to accommodate different levels of sophistication, and evolving fast." - Phil Whainewright
Descriptive, yes, and with the right keyword: services, but it's not really the definition I think you might be looking for.
So I'll have a go this time. Consider this a mesh-up (and I mean 'mesh') of the above definitions:
The Internet cloud, where the distributed and programmable network of services across the globe will serve all the data, resources and functionality we will ever use.
I grant, it's more of a prediction than a definition as I'm using the future tense ('will') rather than the present tense ('does'). But we're all going there. It's just a matter of when.
How's that?
If you don't like roller-coasters, do not check out this interpretation of US house pricing data (adjusted for inflation) since since 1890 to today.
Via information aesthetics.
Yesterday Matt Asay of the OSI visited Bungee Labs. We invited Matt to provide us advice specifically on the issue of the licensing options we're planning to use when we open things up for wider beta program and beyond. It was a fascinating discussion - we all agreed that today's current licensing options we have available to us are, as he put it, not yet '21st Century-ready'.
Given the food for thought, Matt shared his thoughts here yesterday. I absolutely agree with Matt that the cloud-based future we're heading to will cause an invigorating and necessary debate within the industry on the topic of licenses in a purely networked computing environment:
"I believe we're on the cusp of a hugely disruptive change in the way open source software is licensed. The OSI, of which I'm part, is against license proliferation. But the community and OSI will need to figure out how to make open source relevant to the online world, without stifling the creativity that has built it. This is a non-trivial problem, and it is a problem."
Two long--but excellent--days settling here in Utah. The team is making me feel very welcome since arriving and helping me nagivate my new environment.
Lots of energy here. Definitely getting the sense of urgency and excitement from everyone (30+ of us) as we ready for our first public showing later this month (more on this later).
Here are the offices in Orem:
The views around here really are fantastic - mountains everywhere. Here's the view from my new office:
Even the car park has its vistas...
;
Here's a sunset over Orem lake -
And my temp home for the next three months has mountainous surroundings...
And of course, I've located the only Starbucks in a five mile radius from home - an oasis in a 'dry' state...
This morning I caught a flight from Seattle to Salt Lake City for my first day at Bungee Labs and needed to park the car somewhere.
What more fitting a venue could there have been than to use the facilities of 'Ajax Airport Parking'?
Josh Ledgard, a program manager in Microsoft's Developer Division, has posted some details on the challenges in supporting the large number of Microsoft developers. What strikes me here is the 'transparency' of Josh's post in terms of publicly stating the some of the goals set for the team, the specific metrics being tracked across the product groups and the sharing of actual vs. target data:
"The reply rates are around 95%, but our goal with the answer rate is to get to 80% for the seven day rate and 60% for the on day rate. You can see some significant improvements since December. We've also seen more significant uplift in specific technologies where engineers where hired first. Since we haven't hit our goal yet I'll point out that the support engagement is only designed to get us so far."
Josh has also provided snapshots of the internal slides he presented that articulate some of the broader support goals for Dev Div and charts showing the over-time data. Have a look.
The MSDN Forums were launched around two years ago to replace some of (but not all) the traditional support newgroups and have had over 1 millions posts there since. Not everyone was happy when the transition began (for some MVPs, moving from traditional newgroups to web-based Forums was percieved to be a step backwards)
The product teams I used to take care of really had to conciously priotitize forum engagement by actual product group members (PM, dev, test) to meet our targets (response rates). A benefit of this approach is that product teams (and support groups) become aware of the issues customers are facing on a daily basis and this participation creates superb input for future product planning.
But it only takes you so far. For our team at least, the only way to truly scale (while being cost effective) in answering the steady (and increasing volume) of technical questions was to encourage customers themselves to provide the support network and have these answers viewable by all. This is a key concept in the notion of 'community'. If you are interested in this topic, I recommend you subscribe to both Josh Ledgard and Joe Morel who blog frequently and openly on Microsoft's progress and challanges in this area.
Werner Vogels, CTO at Amazon.com spoke at Supernova 2006 on the topic of Scalability at Amazon and the talk is available as a podcast at IT Conversations (thanks to James Governor for the link).
I made some notes as I listened this morning and thought I'd share:
A services business. Amazon.com is a platform. NBA.com is an application built on Amazon.com
If your online business is successful and you experience a 1000-fold increase in traffic you want your site to stay up! Building, operating and maintaining infrastructure that can be ‘always on’ and scale and is hard. Wouldn't it be nice to pay-as-you-go, rather than investing your capital up-front?
You need infrastructure that can incrementally scale. In 1995 Amazon.com had 1m books in its catalogue. That was the beginning. Now it has 35 different stores, not just books. Growing our business is not just a matter of buying bigger databases. Amazon has gone beyond that point.
Internally, Amazon is now a completely service oriented architecture (SOA).
A single Amazon.com page is made up of 100 to 150 individual web services.
What does 'scalability' actually mean? It means that if you add resources to the system the performance needs to increase proportional to the resources that you’ve added. Many of the academic algorithms don’t work like this. Many of the two-phase commit traditional transactional stuff doesn’t work like this. In general, the load on the network relevant to the application increases more than the magnitude of n. It doesn’t mean just handling more requests, it also means handling larger datasets. It needs to be able to add nodes to the system to achieve fault tolerance. It means that if you add bigger nodes you should be able to take advantage of more processing and more memory. It means that the more bigger nodes you add, the fewer people you require to actually maintain them and that as you add more nodes that system should not become more unstable. It means being more cost effective.
Target came to us and asked 'we really love what you've done with Amazon - can you do that for us?' Our interaction with Target made us realize we could become a platform rather than just a single application. Different sets of Amazon Enterprise web services: content generation and discoverability; identity; inventory management; fulfillment and customer service; order processing, payment and fraud protection. You can mix and mash these services.
Those services that are consumed by partners are guaranteed as 'always on'.
Cost effectiveness is scale.
Unexpected uses and applications built on top of our web services that we couldn't predict.
Our goal was expose all the atomic pieces that Amazon was really good at and to do that at scale and as web services.
More Posts
« Previous page