Web Services, API's and Mash-Ups
When we talk about Web services, we are generally referring to companies which offer services to end-users over the Internet. The end user can be anyone from an individual, to a large corporation. These services can either be publicly accessible, or private services used within an organization, providing features such as data access, electronic mail, data storage and productivity tools which a user would interact with directly, or these services could be provided in a form of an API for application developers.The benefits of providing such an interface to software are multi-fold. Providing an API sets a standard for other software to interact with your applications, a standard which you control – discouraging the screen scraping of data which you would not necessarily wish to make available. In some cases access to a Web service may be a commodity which has a monetary value.An API can serve to turn an application into a platform, upon which others can build their own applications; this adds value to the Web as a whole, by opening up software functionality data sources. In doing this the, as a service provide, you would also be making your data more useful as your consumers and third parties could utilize it in such a way as to bring additional value to the end user. Successful applications built upon an API provide a means of driving users to a Web application, and build community around a product.There is also potential profit which can come to having an API. Imagine you own a data source which is commercially valuable, if you can make it accessible by 3rd parties using an API then you could probably find people willing to pay for access. The same is true if you are providing some kind of service. Here in the UK, the Royal Mail allows people to lookup addresses based on postcodes, for a small fee. As an address database is expensive to maintain, so it makes more economic sense to acquire the data you need – as you need it – from another company.
"We know we don't have a corner on creativity. There are creative people all around the world, hundreds of millions of them, and they are going to think of things to do with our basic platform that we didn't think of. So the mash-up stuff is a wonderful way of allowing people to find new ways of applying the basic infrastructures we're propagating. This will turn out to be a major source of ideas for applying Google-based technology to a variety of applications" Vint Cerf, Google
Open API’s are transforming the Web, and is fuelling the resurgence of innovation and excitement amongst developers – a
“mash-up”. A mash-up is a Web application which transparently combines data from two or more sources to provide a new user experience. Data is usually pulled from product API’s, or from syndicated feeds. As data is easily accessible, the process of creating a mash-up is straightforward, and there are many examples on the Web, such as:
Availability Questions
As more and more people adopt Web services and applications, their availability becomes increasingly more important. Most users would want to be able to access them whenever necessary, without any service disruptions – especially, for example, if you are using something like Google Mail for important communications or Google Calender to manage your hectic social life.In the Terms of Use for both Google Mail and Calendar, the company categorically state that these services are provided as is –
“Google disclaims all responsibility and liability for the availability, timeliness, security or reliability of the Service. Google also reserves the right to modify, suspend or discontinue the Service with or without notice at any time and without any liability to you”. In March, Amazon launched S3, a simple Web service interface which
“can be used to store and retrieve any amount of data at any time”. What this means is that Web application developers can use S3 as a data source for their Web application, negating the need for them to have their own hosted database. Unlike other Web services, S3 is notable as being one of the few commercial ventures – developers pay $0.15 per gigabyte of storage used each month, and $0.20 per gigabyte of bandwidth consumed.S3 seems like the perfect platform to build a Web application, but hidden within the Amazon Web Services Licensing Agreement is a cause for concern. Amazon provides no guarantees of uptime or availability for any of their Web services, including S3. They also reserve the right to withdraw them at any time. On April 1st 2006, S3 was unavailable for nearly 7 hours. Amazon engineers updated users of the efforts to restore the service on the developer forums , reassuring irate users that Amazon places a high priority on service availability and that engineers were working on issue resolution.Such lack of reassurances reduces the comfort level of a developer who is using a particular platform, and also hinders the uptake of a platform. If developers building commercials Web applications based on services such as S3, would be hard to justify using such a platform if it were not backed by a service level agreement of some sorts, especially since consumers would be paying for use of such a service. For every minute the service was down, the consumer could potentially be losing revenue. The service may go down whilst the dependant application was being demoed to potential customers or investors.Amazon argue that there is no need to make a formal service level agreement to users of its API, simply because its services are used so much internally, that if they were down it is likely that it would hurt Amazon more than anybody else. Although the goals of both the API consumer and the API supplier are aligned, what if the supplier is not able to provide the level of reliability which they strive to offer? If a supplier was able to provide a certain level of reliability, would they not want to agree to this?Of course not all Web services come with such lack of guarantees and service agreements. For example, Worldpay, a company which provides e-commerce customers with payment processing facilities offers a guaranteed service level of 99.9% uptime for all of its Web services. Royal Mail, who offers a postcode lookup Web service, makes similar guarantees. Interestingly, both of these companies have been operated Web services for close to a decade compared Google and Amazon who have been providing public Web services for around half this time.Commercial Web hosting companies generally offer customers a service level agreement. In the case of Site5, my current host, they guarantee 99.9% uptime – this equates to less than 45 minutes downtime per month. Anything beyond that leads to the customer receiving compensation, up to a full refund of the monthly fee should uptime drop to below 95%. Obviously there are the usual caveats which indemnify the company in the event of act of god and failures beyond the company’s ability to control, but users know they can expect their sites to be available for most, if not all, of the time and that if the company fail to meet this then they can claim compensation. There is substantially less risk if, for example, the hosting is used for a business web site.If a service is being consumed which is critical to the availability of a business function, be it an internal service providing an interface to a legacy system or a 3rd party service offering credit card processing functionality to an e-commerce Web site; it is absolutely critical that it is reliable and can meet availability requirements. Although Web services such as those provided by Yahoo, Google and Amazon offer very powerful and useful features, if there is guarantee of reliability then companies will be reluctant to use them in their software products. Interestingly, it is only the more mature providers such as Worldpay who offer such guarantees.Part of this could be because Worldpay make a lot of money from companies who use their service, and it would be suicidal for them not to offer a service level agreement to its customers. It could also be due to their singular focus on payment processing, it is the company’s core competency and they can devote a lot of effort and money into ensuring its reliability. Google and Yahoo seem not to be able to make their minds up as to what their core competencies are, instead dabbling in many different areas at once – search, mail, advertising, calendaring, mapping etc. With many of their services perpetually in ‘beta’, a result of internal side-projects. Although this approach breeds innovation, and gives the brands broad coverage, it makes it more difficult to ensure reliable services. It is further hindered by the costs associated with providing reliable services.In order to make it economically viable to offer a “good” service level agreement, a company needs to be bringing in enough revenue to cover the costs of this. And, to do this a company needs a business model capable of generating this revenue. If we look at Web hosting, we can see that consumers pay a subscription fee, which enables the hosting company to invest in backup servers, processes which ensure reliability and continuity of service.When we look at Web applications and services, the business models are either not there – with many of these applications and services being freely available – or they simply not effective. Google’s AdSense programme generates a substantial amount of income for the company, but this income is not directly linked to “clicks” from a Google Mail user. It is very much indirect.
Business Models
There is clearly the need to establish new business models around Web services and applications. With the second dot-com boom, focused around the Web 2.0 phenomenon, on the horizon, this need is greater than ever if the existing players in the industry are to maintain a competitive advantage. The major players, Yahoo and Google, have not done anything at present – perhaps because their current revenue models are based upon direct sales. Any Web application which makes use of the Google, or Yahoo, API’s would be considered an indirect sale, as would revenue generated through contextual advertising. There is no model built around this, and companies such as Google and Yahoo cannot quickly adopt a new business model for this channel.One possible solution for service providers is to stop focusing on individual users as the primary consumer of a service, and instead focusing on the developers and/or companies as the consumers of a service. There are many existing monetary models which could be leveraged, in order to generate income. These include:
- Charging based upon bandwidth usage
- Charging based upon disk space used
- Per-use charging
- Time limited subsciptions
- Per-Feature charging
All of these could serve to generate a sustainable revenue stream which would support the maintenance and upkeep of these services, making it viable to offer service level agreements to consumers.Web application providers could use similar models to also support service levels. It is harder to perhaps charge for bandwidth and storage space, simply due to the fact that a consumer who users your calendar probably will not understand how bandwidth usage maps to their use of the application, but it is certainly a lot easier to apply subscription or feature-based revenue models.Mash-ups will at some point move from being interesting distractions to enterprise level services, especially as companies move towards service orientated architectures for their internal systems. If the larger players in the arena do not provide a model for providing specified service levels then they may lose the opportunity and be super ceded by companies which can provide enterprise level Web services to support mash-up authors.
