API Academy

Sponsored by Layer7

A group of people sitting at tables with computers.

Five Factors to Consider When Selecting an API Management Provider

By Bill Oakes, CISSPPosted on

Recently, INOVIS, a strategic intelligence and research firm, published a new report on Five Factors to Consider When Selecting an API Management Provider.  I’d like to share more about these five factors, and why they are important when evaluating an API Management solution. The five factors for evaluation include:

  • Ease of use
  • Scale
  • Security
  • Flexibility
  • Breadth

Let’s take a deeper dive into each of these.

1. Ease of use

At first glance, “ease of use†would be about how easy it is to get up and running – and yes, that’s relatively important. However, there are other issues that are tied to this factor.  For instance, is it easy for a developer to utilize – to discover APIs, to see the value of those APIs, to learn how to use those APIs, and perhaps, even, get code generated for the development tools he or she is utilizing?  Is it easy for an administrator to manage those developers?

Will the API management solution easily integrate into the existing infrastructure?  Will it integrate into the existing application infrastructure, and provide connectivity across data sets?  Let’s face it – using data in new ways is not only empowering, but has created (and destroyed) entire industries – think Waze, Yelp, Uber, and AirBnB as great examples of this.

2. Scale

Scalability is another factor that can be imperative for many organizations – and like “ease of useâ€, scale has multiple issues that should be examined.  As an example, scalability certainly means the ability to easily handle high-volume transactions, but the API management solution should also be able to handle that scale across platforms – on-premises, SaaS, and/or containers.  Tools should be available to ensure specific APIs can scale at the appropriate priority, including throttling, prioritization, and routing.

The key to successful API architecture is ensuring your APIs are scalable and evolvable—able to grow with your business and adapt to changing requirements over time. This is not just about scaling up to a maximum capacity. It’s about right-sizing the interfaces and the API infrastructure, and maintaining the flexibility needed to support changing business and technical needs.  A great example of scaling flexibility is the ability to for an online retailer to be able to dynamically scale up (and down) servers at times of extreme activity (think Boxing Day in the UK, Black Friday in the US), versus standing up equipment that would be idle most of the year (a rather expensive CAPEX proposition).

3. Security

As a CISSP, I tend to spend more time than many on security, so bear with me.  Security has MANY issues that tie into this factor. Let’s start with the basics – does the API management solution provide strong single-sign on (SSO capabilities, including integration into existing identity and access management (IAM) systems?  Are policies available to:

  • Protect against web-based threats
  • Mandate SSL
  • Disable login if VPN isn’t on
  • Protect against OWASP Top Ten vulnerabilities?

Questions you should consider include:  is there support for OAuth and/or OpenID Connect, as well as integration of same into the IAM SSO mentioned above? Is there social login (imperative today for consumer mobile apps)?  How about FIDO certification for mobile biometrics? Is there a mobile SDK so that developers can integrate secure calls into their apps to enable enterprise-grade SSO, as well as enable dynamic creation of secure containers on mobile devices for data that requires that level of security?

It used to be that regulated industries required a bit more proof of the level of security – Common Criteria, FIPS 140-2, PSD2, or PCI-DSS compliance. But in the upcoming reality of the General Data Protection Act (GDPR), any company that does business in Europe will be required to comply to a very strict set of rules on data security.

Organizations, public and private sector, that deal with (personal) data on a global scale will therefore need to review their data lifecycle and data management practices, requiring them to put in place processes and technology to be compliant.  Businesses need to also look at the GDPR as an opportunity to further invest in technology that enables trust and loyalty with their customers, rather than a liability.

4. Flexibility

Flexibility once again has several issues that should be evaluated as a factor. Deployment flexibility – on-premises, SaaS, or a hybrid of the two is one area to examine, based on enterprise requirements.  Form factors is another – do you want your API management solution on hardened appliances, virtual appliances, as software, or in containers?  Is it cloud agnostic?

Another way to look at flexibility to is breakdown API management into two modules:  runtime and design time. 

Runtime (aka the API Gateway) is all about API data and services such as transformation and composition, routing, traffic control, managing security (including authentication/authorization, SSO/OAuth/OpenID Connect, attack preventions, managing policy enforcement, and managing API health and performance (including reporting).  Runtime is grunt work, typically high volume, typically touching important data and systems, and often considered mission critical. Latency is invariably very important. As such, runtime (the API gateway) is often located behind the firewall on-premises.

Design time (aka the developer portal) introduces and maintains the business relationship with app developers, providing the tools the developer needs to consume an API – documentation, tutorials, samples, and sometimes even code generation.  Latency has very little bearing, and while uptime is important, design time is hardly mission critical.

So why am I describing this?  The flexibility to have some components of your API management solution on-premises (runtime), and some components either on-premises on in a SaaS implementation (design time) is a key issue in this factor.

5. Breadth

Finally, let’s consider breadth – how comprehensive is the API management solution being evaluated?  Does it just do API management, or does it cover multiple components of full lifecycle API management? Those components include two phases – the API publisher and the API consumer (the developer and/or deployment). 

For the API Publisher, the components include: design, create, test, secure, and manage. An API management solution should be able to address these components.

For the API Consumer, the components are: discover, develop, consume (deploy) and monitor. Many enterprises also include another step between develop and consume – another variant of test, but to ensure the appropriate level of security has been put in place.

The solution being evaluated should address most, if not all, of the full lifecycle API management model.

INOVIS, truly did pick the most meaningful five factors to consider when evaluating an API management provider. I recommend that you break down each of those factors as I describe above to ensure that you have covered all aspects of each of the factors.