Cloud computing has arrived. You can scarcely open a computer magazine or business journal without coming across an article about this transformative new approach to providing web-based services. Cloud computing is undoubtedly shifting the landscape. But what many observers miss is that, while cloud computing has arrived, only through APIs will its full business potential be realized.

A few years ago, Google capitalized on the idea of using huge clusters of cheap computers and building software with a high fault tolerance, so that when its machines would go down, the overall system would still function properly. Amazon used the same approach, with a twist. The company's vast, distributed architecture lent itself to a standardized provisioning of computing resources. As the provisioning process became more standardized, and it became easier for Amazon to roll out new services, the company started selling on-demand access to its massive, distributed computing infrastructure.

The rest is history. And more cloud computing providers have appeared, each with its own approach. GoGrid, for example, offers flexible server specifications and interconnection options. Salesforce.com provides an application infrastructure with database, security, workflow, and other capabilities already in place. Ning emphasizes simplicity, giving its users the ability to roll their own social networks without any programming knowledge.

Without APIs, There Is No Cloud Computing

Cloud computing is not simply another type of application service provider (ASP) offering. The ASP and hosting providers of years gone by offered a set of software services from within a walled garden. These services were tied to specific hardware and software configurations.

In contrast, cloud computing draws its strength from its connections to the outside world, through APIs. These APIs fall into three general categories:

• Control APIs, which allow cloud infrastructure to be added, reconfigured, or removed in real time, either by human control or programmatically based on traffic, outages, or other factors
• Data APIs, which are the conduits through which data flow in and out of the cloud.
• Application Functionality APIs, which enable the functionality that end users interact with, such as shopping carts, wikis, and widgets.

Control APIs: The Key to Cloud Computing Flexibility

Nearly all cloud services allow (or even require) deployment and configuration through APIs. When you use Amazon's EC2 service, you are using the EC2 API to dynamically configure virtual servers. When you use Google's App Engine, you are using an API to run your web applications on Google's infrastructure. These control APIs are integral to the capabilities of all cloud computing providers, performing functions similar to those of a conventional data center dashboard. In fact, some observers believe a significant reason for the failure of Sun's network.com cloud (which has been taken down) is that it could not be controlled through APIs and therefore lacked the flexibility that developers expect from cloud services.

At first, control APIs were limited to individual cloud providers, but that is starting to change. GoGrid has made its Mashery-powered control API available under a Creative Commons Share Alike license, so that other cloud providers can use and modify it to suit their needs.

Data APIs: Essential Conduits for All Cloud-Based Applications

This is an exciting development, but the real magic in cloud computing happens when data interchange APIs move between clouds. The web itself provides the underlying infrastructure, while applications, data, and services are delivered via interconnected clouds.

We are now starting to see some of the benefits of cross-cloud applications. For example, Lasso2Go, an impressive contact information service, makes use of Amazon and Salesforce.com's clouds, as well as the APIs for the iPhone and other devices. The Amazon data interchange APIs have been merged with other data interchange APIs, enabling a seamlessly integrated cross-cloud application.

In a completely different market, soundpushr demonstrates the power of APIs. Using APIs from Amazon, Flickr, the Hype Machine, Last.fm, and YouTube, soundpushr gives music enthusiasts the ability to search for and instantly find music, videos, and photos of artists they like. The search tool does not use bots to crawl the web. Instead, it connects directly to data sources in the Amazon and YouTube clouds, as well as ones at Flickr, the Hype Machine, and Last.fm.

Application Functionality APIs: The Final Layer

Application platform APIs provide functionality beyond data access. For example, they give Ning the ability to provision configurable social networking sites from an array of centralized services. But application platform APIs can do more. The social shopping site Kaboodle leverages the Shopping.com API to provide product information, and then adds its own social networking features. The possibilities for application functionality integration are already being explored, and as more APIs become available, we can expect even more exciting combinations.

A Thrilling Future

Over the last six months, we have seen an amazing transition in Web 2.0. Organizations ranging from retail giants like Best Buy to content providers like the New York Times to service providers like Netflix to powerful institutions like the World Bank are opening their content and services to developers and partners.

We are witnessing a revolution. Content and services that were previously trapped in systems that required great effort to get pushed out to the web are now part of a much larger set of connected cloud eco-systems. Information, functionality, and services can now be delivered at the point and time that users want it. And APIs are the foundation that makes this all possible.

If you enjoyed this post then check out Mashery.com, the leading provider of API management services.

When publishing an API, there are two preparatory steps to take before jumping into implementation. First, create metrics for determining the success of your effort. Secondly, take a good look at what you already have so that you can find out what you need to do before you publish.

In helping dozens of customers prepare their APIs for publishing, Mashery has observed what works, what doesn't work, and what is on the horizon. Here are some of the lessons we have learned.

Get Your API Ready

It appears that beyond the enterprise, SOAP is being left in the dust. REST is now the dominant approach in API publishing. The advantage of REST is that it is explicitly built on top of and leverages HTTP in ways that web developers are already comfortable working with. This makes development faster and easier. JSON-RPC is exhibiting growth as developers seek to integrate natively with rich JavaScript-powered user experiences. XML-RPC appears dormant and is used less widely than SOAP and REST. The emphasis has decisively shifted in favor of making content easier to consume, and if you use an approach that allows REST or abstracts to REST, you will be making life easier for developers who want to use your API.

What does this mean if you are already internally using an API that has been built around SOAP and want to publish it? At Mashery, we use protocol transformation to allow customers to deploy a REST implementation of a SOAP-based API. There are a variety of techniques for protocol transformation, and the approach we take depends on the API and the development tools being used.

Your API may also need to be cleaned up, split from a larger API set, or both. It is not uncommon for an internal API to develop cruft over a long period of use, and sometimes calls that are fine for internal use are too sensitive for use in a public API. Larger established companies frequently have a patchwork of APIs from having acquired smaller companies over the years. In all of these cases, there are workarounds that will allow you to publish a "lite" version of your API, giving you some breathing room as you build a new and improved API. For example, method limiting or filtering can be used to strip out unwanted elements from the WSDL.

Be Careful Abstracting Network Calls

Recently there has been a big push to abstract network calls by mapping API method calls directly onto server-side object methods. This may not always be a good idea because treating server-side objects and client-side objects as equals via web services can lead to serious inefficiencies.

For example, consider exposing a data access object directly via a web service. Broad-ranging queries to that object may result in very large quantities of data being pushed back through the web service. Now imagine that web service running on a mobile application over an EDGE network. By exposing the data objects in such a way that local and remote access to the object is treated equally, the result may very well be an unusable mobile application.

Instead, invest the additional time in crafting a broader suite of web services that access data in ways that are most commonly used, so that the smallest possible payload can be returned. In fact, building an API specifically for mobile web use will help you identify potential roadblocks early. The end result will require more up-front design work on the API, but will also yield higher-performance mobile applications and blazing-fast traditional web apps.

As with any optimization approach, moderation is best. You also do not want to wind up with an over-abundance of small calls when a handful of medium-sized payload calls will do the trick. You may want to consider support for batch-style operations in your API, so that a series of calls can be sent in one request, and the result of those calls chained together can be returned as the batch call payload.

Make It Cacheable

If you can cut down the number of round trips between client and server, you can increase the overall performance of your API. The more data you can cache, the easier it will be to cut down on those round trips. So, look for places in your API where uncached data is being used and, where possible, make that data cacheable.

The payload of an API call sometimes has a lot of uncached data; for example, a key value that is passed back each time the call is used. Sometimes extra payload data is inserted for debugging purposes, particularly with JSON-RPC, but it is easy to forget to remove the extra data from the payload later. Elements and attributes that are uncached can seriously reduce the overall performance of an API, while also increasing server resource use. Strip out the uncached elements and attributes and you will likely see a noticeable performance improvement.

Mashery has implemented caching for customers who need faster response times. The results are impressive: they usually see performance improvements of 50% or better for cache-related calls. If it is cacheable, you should cache it.

Remember, a New Approach Is Always Just Around the Corner

Earlier we mentioned that REST is the most popular approach for API publishing. But nothing lasts forever, and no technology is completely future-proof. The important thing is to pick an approach and maintain metadata. It is always easier to move from more metadata to less than the other way around, so think carefully about what metadata you need now and what metadata you may need in the future.

If you are using REST, consider WADL (Web Application Description Language). It is essentially WSDL for REST. While it is arguably not as easy to use as REST, WADL provides excellent metadata, and some useful tools are available, such as REST Describe & Compile, a WADL editor and compiler. Using WADL may seem like a bother now, but at some point, whether in 5 years or 15, you will have to transition to a different format. Having an excellent set of metadata will make that transition much smoother.

Pulling It All Together

Your API can be a tremendous strategic asset to your company, but it pays to plan ahead. Define your metrics, rid your API of cruft where possible, and filter it out where necessary. If possible, stay away from high-overhead techniques like SOAP. Remember that whatever is hot now will likely be eclipsed sooner than you would like, so build in as much metadata as possible. Pay attention to these rules of thumb, create an API with useful calls, and you will be off to a great start.

If you enjoyed this post then check out Mashery.com, the leading provider of API management services.

When LongJump first launched, the PaaS (Platform-as-a-Service) model was only just taking off. Since then, we've seen Google launch their App Engine and more services than ever are taking advantage of Amazon's EC2. Today, the Sunnyvale, California-based PaaS provider, LongJump, tries to one-up those big-name sites with the launch of their new LongJump Development Suite, a tool set that helps developers extend the power of LongJump by allowing interoperability with other systems and applications.

While this ease-of-use made LongJump ideal for enterprise I.T. teams looking for fast and easy ways to build and deploy apps, allowing those apps to interoperate with data from other applications and systems was not possible until now.

About The LongJump Development Suite

With the new LongJump Development Suite, an I.T. department can build the app they need, then use the included visual browser-based UI for data and process modeling. Alternately, they could instead choose to hand of the integration of the app with another system or application to a developer (or team of developers). Finding a developer to work with LongJump shouldn't be an issue since the suite provided is a Java-based development environment complete with a plug-in to the Eclipse IDE (Integrated Development Environment), something that's used by 69% of Java developers today. LongJump also provides a set of service integration points using SOAP and RESTful APIs to connect to other external systems.

Why LongJump?

Unlike both Google and Amazon, the focus with LongJump is on application creation, not just the delivery. When you build on Google or Amazon, you still need to know how to build - you need to know code. LongJump is focused on letting anyone build without code. They aren't the only ones thinking this is the next big trend for the web, either. Earlier this year, for example, we covered an app called Iceberg whose aim was to allow anyone to become a developer.

Will this trend take off? For enterprise I.T. organizations, their bottom-line focus is usually money and time. If PaaS offerings like these mean custom apps can be built quickly and easily without needing to hire outside dev teams, there's a good chance for their success. However, they do have to fight with a number of already decent solutions out there. Thanks to the Web 2.0/Enterprise 2.0 movement, there are already a slew of business applications built and ready to go. These apps might not be perfect but are often they are often "good enough," and that's proven to be a good way to get in the door of the enterprise...just ask Google Docs.

As Facebook prepares to mark the one year anniversary of its heralded application platform and the new iPhone App Store lures developers with groundbreaking features and customers willing to pay for applications - competition for the attention of the developer community is heating up. Once again, when platforms compete for developers - users win.

MySpace announced today that it will authenticate users for third party sites that support OpenID. It's not clear how this will work yet, MySpace user profile URLs aren't authenticating and there hasn't been any mention of OpenID on the developers blog today, but we hope that usability won't be an issue here as it has often been for the OpenID world. MySpace now joins AOL and Yahoo! as major providers of OpenID accounts.

Initially MySpace will not act as a relying party, meaning you can't log into MySpace using a Yahoo! OpenID, for example. That's typical and we hope it will change soon.

Most important though is that MySpace is offering a system to verify identity across multiple sites. Verified identity allows for all kinds of interesting data mashup possibilities and that's ultimately going to be more interesting than simple authentication and single sign on. As OpenID Foundation Chair Scott Kveton told us this morning: "its great news that MySpace is not only supporting OpenID but really looking at ways to integrate data and real functionality that is beyond authentication. This will be the real driver of OpenID adoption."

Data Mashups

Already this morning a number of partner sites are taking advantage of the new ability to cache user data from MySpace. Movie review site Flixter and events site Eventful are the initial examples. Flixter users can now create an account and log in using their MySpace account via the secure standard protocol OAuth. They are then able to see movie reviews on Flixter that were made by friends on MySpace. Eventful integration will send alerts via MySpace when favorite musicians are in visiting a user's home town. Those are good and useful examples.

The possibilities here are many and remind us of the kinds of things the Google Social Graph API enables web-wide and the kind of functionality that Facebook apps are able to leverage on-site using Facebook friend networks. The MySpace functionality will let any site know who your MySpace friends are and highlight their activity on that 3rd party site and apparently 3rd parties will also be able to write to your MySpace account as well.

Profile data can now be cached for up to 24 hours at a time. Supported fields from MySpace include About me, Body type, Children, Drinker, Ethnicity, Has app, Heroes, ID, Interests, Jobs, Looking for, Movies, Music, Name, Network presence, Profile song, Profile URL, Relationship status, Religion, Sexual orientation, Smoker, Status and TV shows. Picture MTV.com noticing that you've changed your relationship status, playing a music video for your favorite song and recommending that you light up an American Spirit to celebrate. That brave new world is right around the corner!

Facebook vs. MySpace vs. Google vs. Apple

The competition is heating up from all the major social networks vying to get developers to build applications on their platforms. That means those companies are racing to offer the most advanced, wide ranging and user-seductive platform for application developers to tie their imaginations to.

The end result should be some really exciting applications. Facebook proved that a simple development environment will lead to 3rd parties building apps if not businesses inside your website. Google is embracing some standards but is also aiming for the long tail of small social networks and individual websites through OpenSocial and Google Friend Connect (iframes). Apple has proven that users are willing to pay for applications and that brand new features like a touchscreen, location awareness and mobility are hard not to fall in love with. LinkedIn is holding its upper class user demographic close to its chest and entering into selective strategic partnerships, like last night's with the NYTimes.

Enter MySpace and its large, broad base of users. Though much maligned in some circles, MySpace is evolving quickly in the face of competition and offers huge mainstream audiences.

It should be an exciting contest. We're excited to see the next steps these platforms take as they seek the upper hand and we're at the edge of our seats to see how the developer community will take advantage of what's offered. Say what you will about MySpace - it's a key participant in this era of powerful innovation.