3scale Shows Five Ways To Scale Your API Without Touching Your Code

Mark Boyd
May. 20 2014, 11:26AM EDT

This article is part two of a series looking at API maturity and API lifecycle management in the enterprise. Part one reviewed the Industrialized API model developed by business consultancy Accenture. Part two now looks at how businesses can move from an individual use case approach to embedding scalable API architecture, without significantly increasing IT resources or rewriting an entire API. Part three will look at how APIs are also altering the traditional enterprise application lifecycle management sector.

API Maturity and lifecycle management in the business environment is progressing faster than ever. As enterprises build new apps and interfaces for their workforce and partners, they are quickly seeing the potential to scale these products to a wider audience.

This often means moving their APIs over the firewall and enabling third party developer access. If this is done effectively and efficiently, API growth increases quickly, requiring scaling tactics that handle the industrial-strength level of calls that may be being made on an API provider’s servers. Business consultancy Accenture encourages thinking about API maturity as an industrialized API Strategy.

API Maturity Trends

Managing this growth is an API management issue facing an increasing number of providers, says Steven Willmott, CEO of 3Scale, who spoke recently at API Strategy and Practice on techniques to help providers scale their APIs more efficiently.

Secure enterprise mobile management platform, Good Technology is seeing quarter-on-quarter growth in enterprise application development, many powered by APIs.

“Given the incredible diversity of Good Technology’s customer base, it’s difficult to make definitive statements on how organizations are approaching custom app development, but in the majority of cases we see custom app development as a secondary step, not the first step,” says Good Technology’s VP of Marketing, John Dasher. “Most of our customers lead with identifying a need within their organization and deploying one or more Good-secured apps (from Good and/or ISVs) to address that need. Quick, cost-effective wins tend to happen first.

“They often then come to the stage of building their own apps to either augment the workflows they’ve purchased, or to realize their broader mobile strategy. Good Dynamics helps make custom app development quicker and the apps more secure; and, of course, the resulting apps can securely share data and docs with other Good-secured apps, all controlled via policy,” Dasher says, describing the maturity trends and application needs he is seeing for enterprise.

Dr Teresa Tung, from Accenture, sees a similar maturity pattern amongst those developing applications internally as much as Good are seeing it happening with their customers. The problem that she sees is that this is leading to a complex web of APIs, with each API created for an individual application use case rather than a business identifying the common database stores that can resource multiple use cases.

Recommendations for API Scaling

Steven Willmott, CEO and Co-Founder of API Management Provider 3scale sees enterprise customers who are grappling with the pace of their API maturity cycles and who are concerned with scaling their API and making their systems work at high volume. 3scale customers include Skype, the US Department of Energy and content provider About: all are dealing with heavy API customer usage.

Willmott argues that API providers need to reorient their definition of scaling from ‘how to handle more transactions per second?’ to ‘how many more customers can I make happier per second while using the same resources?’

By changing to this mindset, the focus moves beyond scaling tactics such as decoupling layers, compression and streaming to customer satisfaction. So API providers are more likely to ask if it’s possible to restructure an API to make less calls, or whether there are ways to encourage third party developers to write better code.

For enterprises looking to move to an industrialized API strategy without increasing their hardware resources, Willmott makes five key recommendations.

1.Assess API Design

Willmott drills down into a nuance that could be missed in Accenture’s Industrialized API model. In the rush to move beyond a use case-driven approach, enterprises could instead move too far into an “expose the database” mentality. Willmott argues for a middle path: “Actually thinking about what use case you are hitting can reduce the number of calls and cost of calls on your backend,” he told an API Strategy and Practice conference audience in Amsterdam in March.

Willmott admits there may be some rewriting of code required in this first tactic, at the very least some removal of methods, but that these alterations should not impact the core of a provider’s API.

“Often, it is about unbundling and rebuilding different functionalities to meet use cases”, Willmott says.

Taking on board both Accenture’s model and Willmott’s advice may mean identifying the use case first, noting what enterprise databases this would require to be opened via API, and then ensuring that the API structure provides methods to access the data and functionality developers need, while still enabling innovative, efficient use cases to emerge.

2. For Heavy Use, Consider API Call Aggregation

Willmott describes a Netflix technique of adding a Groovy Java layer to their API so that, for example, “if you were using the Netflix Playstation application, then to build a home screen is essentially one call from the UI to the Netflix server, then a bunch of magic happens, it recomposes everything and brings a whole home screen back. So what’s really nice about their architecture is that they still have the API in general, so you can build any type of client, combining things randomly as much as you want, but once they have heavy usage on a particular usage pattern, they actually pre-compile that into an aggregated set of calls which is much faster for the customer and they get to control how that’s done.”

3. Rate Limiting

Both the above recommendations assume that API providers are using their analytics to review what calls are being made to their APIs and to identify patterns of heavy usage. Willmott recommends that as part of this analytical approach, that rate limiting be put in place.

“Setting rate limits gives sanity in terms of usage,” Willmott says. “This is a ‘no code’ approach and you really need to do this,” he says, indicating how easy it is to implement. (Rate limiting/metering is seen as part of the fourth or mission critical stage of API industrialization in the Accenture model.)

Setting rate limits means reviewing the API’s core use cases and defining rate limits that will still allow these use cases to function for the majority of customers.

4. Offboarding calls

While some API providers prohibit caching data on the client-side for fear that customers will have access to all of a business’ database (“They are downloading all our data!”), Willmott points out that “The truth is that if the data is useful to the end user, let them keep it.”

To overcome fears of data access, caching can be temporary, such as only allowing access for a 24 hour period. But for the end user, the speed of transactions and data requests significantly improves the user experience without impacting the API provider’s server.

“It’s still relatively rare that people use caching headers in their APIs,” says Willmott (although recent research by ProgrammableWeb into public transport APIs shows that some city governments and transport providers like the New York City’s Metropolitan Transit Authority are insisting on client-side caching in order to avoid overburdening their servers).

Willmott describes how 3scale offers API providers a caching capability:

“We have a lot of customer growth, our standard system uses Nginx which customers deploy and that synchronizes with our backend and API. What we did, when customers were going into 40 or 50 million transactions a day or more, we actually gave them, the means to do this with a Redis cache on their side too. So you can really push more and more functionality over to the customer in a lot of scenarios.”

5. SDK Provision

While often not suited to production applications, SDKs play an important role in helping developers get to ‘hello world quickly’ and gives them the opportunity to test the potential of an API. Willmott also argues that this can help train developers to use best practice coding approaches when they do get around to a production deployment built directly off an API.

“Often, if it is a very widely used API, the skill level of third party developers is not that high, so they are going to hit your API in ways that are unusual. Providing them with SDKs helps them get it right and do things more sensibly,” Willmott recommends.

Scaling APIs in the New Enterprise Environment

In a recent white paper for MuleSoft (the parent company of ProgrammableWeb), technology evangelist and business adviser Ben Kepes reflects on the new enterprise environment, which is seeing a greater workforce demand for connectivity and flexible technological tools, a tectonic shift towards the cloud, and a business environment that requires iterative, fast-to-market agility. As this business landscape rapidly becomes the norm, the capacity of API providers to scale effectively, provide a pleasurable user experience, and allow access to an enterprise’s data and services without downtime will become increasingly important.

Managing API maturity by ensuring APIs can scale as a business enters new markets and reaches new customers will be essential to future success.

All images from Steven Willmott’s Speaker Deck Five Ways To Scale Your API Without Touching Your Code

In the next and final part of this series on API Maturity, we look at how APIs are transforming the traditional enterprise application lifecycle management sector.

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities. I can be contacted via email, on Twitter, or on Google+.

Comments