The next frontier for cloud providers is the “[insert something usually offered as an infrastructure appliance here] as a service." From security-related providers like SkyHigh and Adallom, to application migration services like AppZero, if it's traditionally been deployed as a data center appliance, you can likely find it "as-a-service."

These offerings share a common theme: an API. Data that used to be extracted or shared via SNMP, syslogs, or prepackaged integration is now made available via an API, most often modern RESTful one. If it isn't, this should be a big red flag that the service is not ready for enterprise consumption. Without an API, integration across the Internet, let alone over the datacenter perimeter, will be a painful process. Just ask your enterprise application integration experts — if you can get them to uncurl from that fetal position in the corner where they've been hiding since the last major EAI implementation.

But don't be lulled by the mere existence of an API, or of reports generated ad-hoc online via said API. While those are selling points, you need to dig deeper. Evaluate whether a particular as-a-service offering will not only integrate well with (and provide value for) existing processes and systems, but whether it will continue to do so over the long haul.

[As web-based integration wins, it's dawning on enterprises that they need a more sophisticated API strategy. Here's how to develop one.]

At a minimum, ask the following questions before you sign on the dotted line:  

1. How will we leverage and integrate data from the provider into our existing operational processes?
Data resident in these services tend to make great eye-candy charts. While fancy reports can be valuable (recently the CIO reminded us that finance requires rollups to make some decisions) you aren't paying the service provider for charts. You're paying for data and the ability to act on that data. Ask: Will the format work with the internal systems we need the service to work with? Can we use data generated by the provider without a lot of internal gymnastics? That’s imperative to determining whether the service is worth the price or not.

2. How often are the APIs changed and, more importantly, deprecated?
APIs, especially modern RESTful APIs, are a beautiful creation that can certainly simplify and speed up integration efforts, making it more likely you'll be able to take advantage of data. But APIs can, and do, change for all kinds of reasons, sometimes abruptly. In that respect, RESTful APIs are no different from conventional integration methods. If an API call is deprecated and disappears, then your process will break. It's important to understand how often the APIs you'll rely on change or are deprecated. What triggers a change?

3. What is the provider's deprecation/change process?
Perhaps even more important than knowing how often APIs are changed or deprecated is understanding what procedures are used to communicate and manage the changes. How long is a deprecated API supported? What's the process for informing customers of the change? Can you easily generate a list of changed and/or deprecated API calls on a daily/weekly/monthly basis to ensure compliance? Deprecation is always painful, but with the right processes and enough communication mechanisms, it can, at least, be manageable.

4. Does the provider use (at least de facto) standards for access and identity?
As the "as-a-service" market has matured and sought adoption by enterprises, it has slowly but surely come to understand that enterprises require control, particularly over users and access. To that end, most enterprise-class service offerings enable federation of identity and access through standard methods like SAML or, increasingly, Oauth. If the offering relies in part on identifying users, federation should be a requirement to ensure IT — not the provider — maintains control over users and access.

5. What are the limits on API use? What do you expect your usage to be?
Many an organization has been bitten by hitting limits on API usage that IT didn't realize existed. Investigate (or just outright ask) about quotas and how the provider enforces them. Many offer a limited number of queries per second (or day) as part of a standard offering, and then push add-on API packages to enable more access — for a fee, of course. Try to estimate your usage and understand how that will impact the overall cost of the offering. Whether this will be a problem depends in large part on how data is leveraged (see question 1), but there’s no reason the provider can’t give you a good ballpark. Getting caught by a quota and effectively cut-off because of budget limitations will render the service (and any system or process depending on it) virtually useless.

The growing number of infrastructure functions offered "as-a-service" matches the increased appetite organizations have for offloading functions to the cloud. While these services can offer significant value, it's important to understand how you'll use the service and its data and how that use might impact your existing systems — and your bottom line.

Lori MacVittie is a subject matter expert on cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite.

InformationWeek Conference is an exclusive two-day event taking place at Interop where you will join fellow technology leaders and CIOs for a packed schedule with learning, information sharing, professional networking, and celebration. Come learn from each other and honor the nation's leading digital businesses at our InformationWeek Elite 100 Awards Ceremony and Gala. You can find out more information and register here. In Las Vegas, March 31 to April 1, 2014.