Josh Gentry recently asked me, in email:
One of my main concerns about web services is vulnerability to denial of service attacks. Flickr seems to be one of the current darlings. What happens as millions of people make calls to the Flickr API as part of some app or service of their own, and then there is a DOS attack on the Flickr API?An expanded version of the same question appears on his blog. I think there are two general answers: authentication and pervasive intermediation.
Most API-accessible services -- Flickr, Amazon, Google -- require authenticated use. That raises the bar somewhat. Anonymous attackers can pound on the front door, but only registered users can invoke the services that make the app server and database churn.
Registered users can make trouble too, of course, and not necessarily in a malicious way. From the perspective of the machine that's getting hammered, it's hard to tell the difference between intensive use and abuse. So the general question becomes: How do Web services scale? And the answer, in general, is: The same way the Web does.
The notion of pervasive intermediation is fundamental to the Web's ability to scale. I talked about this with Brendan Eich on last week's Gillmor Gang show, and that clip itself is an interesting demonstration of my point. The home page for the episode is here, and the download page is here. When you visit the download page, it says:
The CDN (content-delivery network) in this case is Limelight Networks. I'm not familiar with the details of their implementation, but typically two kinds of intermediation work together in these scenarios: DNS redirection and proxy caching. As ITConversations grows in popularity, these strategies should ensure a smooth flow of bits.Do not hyperlink directly to the above URLs as they are likely to change. (They're dynamically generated for our content-delivery network.) Instead, please use the following permanent URL (permalink):
But what about the clipping service I used to excerpt six minutes from the show? It's a kind of Web service -- in this case, a PHP script running on Doug Kaye's server. I'm not expecting huge demand for that service anytime soon, so the inherent scalability of PHP is probably sufficient. But suppose you do need to decentralize the delivery of a service in the same way that a CDN decentralizes the delivery of content. Here's where I think SOAP-based Web services will play a crucial role.
Way back in May 2002 InfoWorld reported on Akamai's EdgeSuite for Java, which does for Web services what a content delivery network does for content. It was an early vision then, and even today isn't widely implemented. Meanwhile we see lots of people asking whether we really need SOAP-based Web services. Reasonable people disagree, but my take is that we will need them. DNS redirection and HTTP proxying are potent techniques that will continue to give us plenty of mileage. But the notion of a Web services "fabric" -- with self-describing headers and payloads -- is potent too. Nobody will have to use that approach. But if you want the services you produce or consume to have certain properties -- e.g., security, availability, auditing, metering, billing -- you'll want those services to conform to the standards that enable the fabric to add such properties transparently.
Update: InfoWorld reports today on a couple of edge service announcements from Akamai and Speedera.
Former URL: http://weblog.infoworld.com/udell/2004/10/18.html#a1097