How can CIOs manage the invasion of -- and demand for -- public application programming interfaces (APIs)? Gary Olliffe, analyst at Gartner Research Inc., set out to answer that question during his session Using Public APIs: Manage the Risk to Reap the Reward at the recent Gartner Catalyst conference.
"They're popping up like weeds," he said. "And the challenge is that not all APIs are created equal."
APIs, a set of regulations that enables one program to interact with another, are in high demand among business and IT users alike for a whole host of reasons, Olliffe said. APIs offer accessibility, ease of use, platform independence and an attractive cost structure. Moreover, APIs are an operational expenditure, which means developers, architects and even the business can bring new capabilities into the enterprise without "a big approval from the CIO," he said.
But along with this new API abundance come new complications. "Of the 13,000 APIs that have already been listed on the ProgrammableWeb, more than 10% of them are already dead," Olliffe said. Startups go bust, companies decide to change directions (as is the case for Netflix), and a public Web API could easily disappear.
As the API economy continues to grow, figuring out how to manage this new portfolio is key. When it comes to public APIs, "you need to understand the providers of those APIs in detail so you can marry up the risks associated with APIs to your risk profile within your organization," Olliffe said.
Here are four tips:
1. Collect and maintain API knowledge
First and foremost, Olliffe advises CIOs to perform an internal audit. Start by speaking to developers and architects who can help draft an internal directory of APIs. "If that becomes a challenge, then mining your code assets, mining your configuration data, looking for potential dependencies on APIs, looking for URL streams, looking for code constructs invoking APIs is a backup," he said.
Culling that information will lead you to public API providers who can answer questions about contracts, functionality, service-level agreements (SLAs), security policies, compliance certification, who gets notified if the service goes down and how the interface functions.
"Once you've done the audit, it's important to establish a process for the future state," Olliffe said. "You want to establish a policy and a lightweight process for capturing new dependencies as they're introduced."
Next, apply the lessons learned from procuring cloud services. "When cloud services first started appearing, businesses would sign up for services -- and they still do," Olliffe said. "But where those services are critical for the business, there's a lot more discipline about the questions asked." As with cloud services, questions should include these:
- Where is the data being processed?
- What are the costs associated with it?
- How does the commercial model marry up to the usage model?
- What's the roadmap for support?
- What is the application versioning strategy?
- What's the geographic distribution of the infrastructure?
- Whom do you call for support?
"With this information, you can build a picture about the robustness of the API provider, and that feeds into your decision-making process," Olliffe said.
2. Balance and manage risk vs. reward
Understand the risks involved with SLAs, availability and the security profile of the provider when integrating APIs into enterprise processes, Olliffe said. And balance those risks against the opportunities they provide. Because risk versus reward can look different from project to project, the assessment should be done on a case-by-case basis. When an API goes bust, there will be a lower risk for an innovation project, for example, than for a mission critical process, so IT needs to be discerning about their use of APIs. "If it's built into a core process within your business, you need to know you can trust the data, its availability and its timeliness," he said.
3. Build a defensive architecture
CIOs also need to build in a way to react to an API that starts misbehaving. Olliffe said the most common architectural pattern is called a circuit breaker pattern. "In an electrical circuit breaker, when there's a surge, when there's a problem with the supply, the circuit breaker will flip to protect the devices and the appliances connected to that circuit until the issue has been resolved," Olliffe said.
The same principles apply when using this architectural pattern. When the circuit breaker is closed, the system runs normally, but "invocations to the API" are monitored. If the commands deviate from a set of predetermined parameters, the circuit opens, building in a chance for IT to respond. That response will change based on how the API is being used -- from simply informing the business to looping in an alternative provider so there's no disturbance of service. While the circuit is open, the system will run periodic tests, leaving it open if a problem is still detected or closing it if the problem has been alleviated.
4. Monitor your APIs
"Don't rely on your developers or your operations team to visit and manage individual monitoring relationships or monitor manually across the API providers," Olliffe said. "Don't rely on the API provider to tell you when there's an issue." Help may be on the way. He pointed to emerging service providers in the market that specialize in managing APIs. The vendor services fall into two categories:
- Monitoring consumption. "They give you a mechanism to very quickly provide a lightweight proxy to the services you were using but let you see the traffic going through, the volume, the latency, and they give you intelligence into what's being used through those services, he said."
- Web monitoring platforms specifically for APIs. Vendors "are providing a platform that enables you to set up synthetic transactions against APIs so that you can understand their performance and latency over time, that you can be notified of those services that go down and allow you to have a single source of that intelligence rather than having to visit each of the API provides, developing portals or status pages to see what's happening across a portfolio of services," he said.
Amy Reichert, a software quality and testing veteran, explains how to secure REST API endpoints for cloud applications.