Reliability in the face of rapid change
Bad protocol, bad politics
A discussion with Kiran Prasad, Kelly Norton, and Terry Coatta
"Not invented here" syndrome is not unique to the IT world.
A proposal to improve the performance and availability of streaming video and other time-sensitive media
A study of the technology and sociology of Web services specifications
Instead of simply imagining what your users want or need, it's always a good idea to first get their input.
Google Maps, Yahoo! Mail, Facebook, MySpace, YouTube, and Amazon are examples of Web sites built to scale. They access petabytes of data sending terabits per second to millions of users worldwide. The magnitude is awe-inspiring. Users view these large-scale Web sites from a narrower perspective. The typical user has megabytes of data that are downloaded at a few hundred kilobits per second. Users are not so interested in the massive number of requests per second being served; they care more about their individual requests. As they use these Web applications, they inevitably ask the same question: "Why is this site so slow?"
When it comes to achieving performance, reliability, and scalability for commercial-grade Web applications, where is the biggest bottleneck? In many cases today, we see that the limiting bottleneck is the middle mile, or the time data spends traveling back and forth across the Internet, between origin server and end user.
At the foundation of Amazon's cloud computing are infrastructure services such as Amazon's S3 (Simple Storage Service), SimpleDB, and EC2 (Elastic Compute Cloud) that provide the resources for constructing Internet-scale computing platforms and a great variety of applications. The requirements placed on these infrastructure services are very strict; they need to score high marks in the areas of security, scalability, availability, performance, and cost effectiveness, and they need to meet these requirements while serving millions of customers around the globe, continuously.
In the early days of the Web we severely lacked tools and frameworks, and in retrospect it seems noteworthy that those early Web services scaled at all. Nowadays, while the tools have progressed, so too have expectations with respect to richness of interaction, performance, and scalability. In view of these raised expectations it is advisable to build only what you really need, relying on other people's work where possible. Above all, be cautious in choosing when, what, and how to optimize.
Can AMQP enable a new era in messaging middleware? AMQP (Advanced Message Queuing Protocol) was born out of my own experience and frustrations in developing front- and back-office processing systems at investment banks. It seemed to me that we were living in integration Groundhog Day - the same problems of connecting systems together would crop up with depressing regularity. Each time the same discussions about which products to use would happen, and each time the architecture of some system would be curtailed to allow for the fact that the chosen middleware was reassuringly expensive.
Learning from the Amazon technology platform: Many think of Amazon as 'that hugely successful online bookstore.' You would expect Amazon CTO Werner Vogels to embrace this distinction, but in fact it causes him some concern.
Tim Bray's Waterloo was no crushing defeat, but rather the beginning of his success as one of the conquerors of search engine technology and XML. In 1986, after working in software at DEC and GTE, he took a job at the University of Waterloo in Ontario, Canada, where he managed the New Oxford English Dictionary Project, an ambitious research endeavor to bring the venerable Oxford English Dictionary into the computer age.
Stu Feldman, Queue board member and vice president of Internet technology for IBM, interviews the chief executive officer of the nonprofit Internet Archive.
Google is one of the biggest success stories of the recent Internet age, evolving in five years from just another search engine with a funny name into a household name that is synonymous with searching the Internet. It processes about 200 million search requests daily, serving as both a resource and a challenge to developers today.
In the face of unreliable connections and low bandwidth, caching may offer reliable wireless access to Web services.
As web services become increasingly sophisticated, their practitioners will require skills spanning transaction processing, database management, middleware integration, and asynchronous messaging.
The changes that are going to be driven by web services will result in a major language extension.
Common wisdom has it that enterprises need firewalls to secure their networks.
Much of web services' initial promise will be realized via integration within the enterprise.
The name of the game is web services.
Transforming Integration With XML Web Services