Entries in API (5)

Friday
Jun052009

SSL RPC API Scalability

Hi all!

So nice to start discussing cool things in this even cooler forum :)

I am having a problem .. which i believe is already solved but i would love someone confirming actual experience with the same topic.

We are building a client / server architecture, consisting of a web server part and many clients.
Transport will be provided as either XML-RPC / SOAP / JSON or all at once.
All of the communication has to be encrypted and passed within SSL3.

We expect a high load when the application starts (> 2000 concurrent requests).
Combine this with xml parsing for the rpc api, things really look ugly :)
So it's a big mess :)

It will not be that much database bound behind the api - mostly files will be transferred from the server to the clients and simple api for control.

So it's pretty much a matter of 'what-to-do-with-ssl'.

I was thinking of hardware - NetApp or a similar application accelerator.
Can anyone give examples of a hardware piece that combines: Load balancer / SSL accelerator?

I have also been reading about open source software Load Balancers but i really doubt it would meet the needs. Anyone having the same experience (or had) ? :)

Thanks, all!

Tuesday
Mar242009

Scalability Perspectives #6: Lew Tucker – Virtual Data Centers in the Open Cloud

Scalability Perspectives is a series of posts that highlights the ideas that will shape the next decade of IT architecture. Each post is dedicated to a thought leader of the information age and his vision of the future. Be warned though – the journey into the minds and perspectives of these people requires an open mind.

Lew Tucker

Lew Tucker is the Vice President and CTO of Sun Microsystems’ Cloud Computing initiative. Lew’s career has been focused on scalable computing and web development. Lew worked at Sun Microsystems through the 1990’s. In 2002, Lew joined Salesforce.com and led the design and implementation of App Exchange. After Salesforce.com, Lew was CTO at Radar Networks, where he focused on the scalable design and build out of its semantic web service.

The Sun Cloud API

Sun has recently announced its open RESTful API for creating and managing cloud resources, including compute, storage, and networking components. Lew and his team is busy implementing Sun's cloud offering. His background and experience from the creation of Salesforce App Exchange has helped the team to create a simple but flexible set of APIs. Lew envisions open, interoperable clouds based on community standards such as the Cloud API.

Your Own Virtual Data Center in the Cloud

Lew Tucker has demonstrated the use of the Sun Cloud by building a Virtual Data Center built of virtual servers, switches and storage. He commented on the announcement in this interview. Check out the information sources below to understand the perspective of Lew Tucker on Cloud Computing and learn more about the relationship of the Sun and the Clouds. The TechCrunch roundtable is especially interesting.

Information Sources

Click to read more ...

Tuesday
Mar172009

Sun to Announce Open Cloud APIs at CommunityOne

One of the key items Sun will be talking about in today's cloud computing announcement (at 9AM EST/6AM PST) will be Sun's opening of the APIs that we'll use for the Sun Cloud. We're making these available so that those who are interested will be able to review and comment on these APIs. Continuing our commitment to openness, we're making these APIs available via the Creative Commons Version 3.0 license. ...

Click to read more ...

Monday
Nov242008

Scalability Perspectives #3: Marc Andreessen – Internet Platforms

Scalability Perspectives is a series of posts that highlights the ideas that will shape the next decade of IT architecture. Each post is dedicated to a thought leader of the information age and his vision of the future. Be warned though – the journey into the minds and perspectives of these people requires an open mind.

Marc Andreessen

Marc Andreessen is known as an internet pioneer, entrepreneur, investor, startup coach, blogger, and a multi-millionaire software engineer best known as co-author of Mosaic, the first widely-used web browser, and founder of Netscape Communications Corporation. He was the chair of Opsware, a software company he founded originally as Loudcloud, when it was acquired by Hewlett-Packard. He is also a co-founder of Ning, a company which provides a platform for social-networking websites. He has recently joined the Board of Directors of Facebook and eBay.

Marc is an investor in several startups including Digg, Metaplace, Plazes, Qik, and Twitter. His passion is to create new technologies, to start new companies, and to scale them up.

Internet Platforms Rule the Cloud

From Marc's Blog Post on the Three Kinds of Platforms:

One of the hottest of hot topics these days is the topic of Internet platforms, or platforms on the Internet. However, the concept of "platform" is also the focus of a swirling vortex of confusion -- lots of platform-related concepts, many of them highly technical, bleeding together; lots of people harboring various incompatible mental images of what's about to happen in our industry as a consequence of various platforms. I think this confusion is due in part to the term "platform" being overloaded and being used to mean many different things, and in part because there truly are a lot of moving parts at play that intersect in fascinating but complex ways.

Marc attempts to disentangle and examine the topic of "Internet platform" in detail. He has identified three distinct approaches to providing an Internet platform and shows us where each of the three approaches could go.

Internet Platforms Defined

A "platform" is a system that can be programmed and therefore customized by outside developers -- users -- and in that way, adapted to countless needs and niches that the platform's original developers could not have possibly contemplated, much less had time to accommodate.
...
The key term in the definition of platform is "programmed". If you can program it, then it's a platform. If you can't, then it's not.

The Internet gives rise to three new models of platform that is playing out in the Internet industry today. Marc calls these Internet platform models "levels", because as you go from Level 1 to Level 2 to Level 3, each kind of platform is harder to build, but much better for the developer. Further, each level typically supersets the levels below.

Level 1 Platform - "Access API"

This is the kind of Internet platform that is most common today. This is typically a platform provided in the form of a web services API -- which will typically be accessed using an access protocol such as REST or SOAP.

Architecturally, the key thing to understand about this kind of platform is that the developer's application code lives outside the platform -- the code executes somewhere else, on a server elsewhere on the Internet that is provided by the developer.

Examples: eBay, Paypal, Flickr, Delicious

  • The entire burden of building and running the application itself is left entirely to the developer
  • The easiest kind of Internet platform to create

Level 2 Platform - "Plug-In API"

This is the kind of platform approach that historically has been used in end-user applications to let developers build new functions that can be injected, or "plug in", to the core system and its user interface.

In the Internet realm, the first Level 2 platform that I'm aware of is the Facebook platform.

When you develop a Facebook app, you are not developing an app that simply draws on data or services from Facebook, as you would with a Level 1 platform. Instead, you are building an app that acts like a "plug-in" into Facebook -- your app literally shows up within the Facebook user experience, often as a box in the middle of a page that Facebook otherwise defines, such as a user profile page.

  • The third-party app itself lives outside the platform
  • The entire burden of building and running a Level 2 platform-based app is left entirely to the developer
  • Unlike a Level 1 platform where the burden of exposing the app to users is also placed on the developer, Level 2 Internet platforms -- as demonstrated by Facebook -- will be able to directly help their developers get users for their apps
  • Level 2 platforms are significantly harder to create than Level 1 platforms

Level 3 Platform - "Runtime Environment"

In a Level 3 platform, the huge difference is that the third-party application code actually runs inside the platform -- developer code is uploaded and runs online, inside the core system. For this reason, in casual conversation I refer to Level 3 platforms as "online platforms".

In addition, it is highly likely that a Level 3 platform will also superset Level 2 and Level 1 -- i.e., a Level 3 platform will typically also have some kind of plug-in API and some kind of access API.

Put in plain English? A Level 3 platform's developers upload their code into the platform itself, which is where that code runs. As a developer on a Level 3 platform, you don't need your own servers, your own storage, your own database, your own bandwidth, nothing... in fact, often, all you will really need is a browser. The platform itself handles everything required to run your application on your behalf.

Obviously this is a huge difference from Level 2. And this difference -- and what makes it possible -- is why I think Level 3 platforms are the future.

  • Level 3 platforms are much harder to build than Level 2 platforms.
  • The level of technical expertise required of someone to develop on your platform drops by at least 90%, and the level of money they need drops to $0
  • The Level 3 Internet platform approach is much more like the computer industry's typical platform (PC) model than Levels 2 or 1.

Who is building Level 3 Internet platforms?

Marc has built one - Ning has been built from the start to be a Level 3 platform.

Other Level 3 platforms include:

How will we see the new platforms of the future?

We are used to seeing platforms ship as products -- you buy and install a PC or a server and you build an app that runs on it, or equivalently you download and install an open source platform such as Perl or Ruby and you build an app that runs on it.

The platforms of the future won't be like that. The platforms of the future will be online services that you will tap into over the Internet, perhaps with nothing more running locally than a browser. They won't have anything you download, or even an SDK. They will look more like services than software. To paraphrase the Book of Matthew, "you will know them by their URLs".

Read Marc's full blog post for more details! Can you add more Level 3 Platforms?

Information Sources

Tuesday
Nov272007

Solving the Client Side API Scalability Problem with a Little Game Theory

Now that the internet has become defined as a mashup over a collection of service APIs, we have a little problem: for clients using APIs is a lot like drinking beer through a straw. You never get as much beer as you want and you get a headache after. But what if I've been a good boy and deserve a bigger straw? Maybe we can use game theory to model trust relationships over a life time of interactions over many different services and then give more capabilities/beer to those who have earned them? Let's say Twitter limits me to downloading only 20 tweets at a time through their API. But I want more. I may even want to do something so radical as download all my tweets. Of course Twitter can't let everyone do that. They would be swamped serving all this traffic and service would be denied. So Twitter does that rational thing and limits API access as a means of self protection. As does Google, Yahoo, Skynet, and everyone else. But when I hit the API limit I think, but hey it's Todd here, we've been friends a long time now and I've never hurt you. Not once. Can't you just trust me a little? I promise not to abuse you. I never have and won't in the future. At least on purpose, accidents do happen. Sometimes there's a signal problem and we'll misunderstand each other, but we can work that out. After all, if soldiers during WW1 can learn how to stop the killing through forgiveness, so can we. The problem is Twitter doesn't know me so we haven't built up trust. We could replace trust with money, as in a paid service where I pay for each batch of downloads, but we're better friends than that. Money shouldn't come between us. And if Twitter knew what a good guy I am I feel sure they would let me download more data. But Twitter doesn't know me and that's the problem. How could they know me? We could set up authority based systems like the ones that let certain people march ahead through airport security lines, but that won't scale and I have feeling we all know how that strategy will work out in the end. Another approach to trust is a game theoretic perspective for assessing a user's trust level. Take the iterated prisoner's dilemma problem where variations on the tit for tat strategy are surprisingly simple ways cooperation could evolve in API world. We start out cooperating and if you screw me I'll screw you right back. In a situation where communication is spotty (like through an API) there can be bad signals sent so if people have trusted before then they'll wait for another iteration to see if the other side defects again, in which case they retaliate. Perhaps if services modeled API limits like a game and assessed my capabilities by how we've played the game together, then capabilities could be set based on earned and demonstrated trust rather than simplistic rules. A service like Mashery could takes us even further by moving us out of the direct reciprocity model, where we judge each other on our one on one interactions, and into a more sophisticated indirect reciprocity model, where agents can make decisions to help those who have helped others. Mashery can take a look at how API users act in the wider playing of multiple services and multiple agents. If you are well behaved using many different services, shouldn't you earn more trust and thus more capabilities? In the real world if someone vouches for you to a friend then you will likely get more slack because you have some of the trust from your friend backing you. This doesn't work in one on one situation because there's no way to establish your reputation. Mashery on the other hand knows you and knows which APIs you are using and how you are using them. Mashery could vouch for you if they detected you were playing fair so you get more capabilities initially and transit the capability scale faster if you continued to behave. You can obviously go on and on imaging how such a system might work. Of course, there's a dark side. Situations are possible like on Ebay where people spend eons setting up a great reputation only to later cash in their reputations in some fabulous scam. That's what happens in a society though. We all get more capabilities at the price of some extra risk.

Click to read more ...