APIs are not new. Software and hardware have had APIs (Application Programming Interfaces) for decades.Â However, having an API and managing an API are not the same thing.Â Recently there has been significant focus on API Management, and this is different than just supplying a programmable interface.Â With the relatively new focus on API Management, more products have provided APIs to become part of this larger API environment.Â But, this does not make these products API Management products.Â I took a pass at this positioning last year in a blog titled, â€śProviding APIs or Managing APIs â€“ There is a Big Differenceâ€ť.Â Today I want to drill down on what it means to manage APIs.
API Management is about driving the consumption of business assets securely and easily.Â That is API Management in one sentence.Â Successfully implementing API Management is extremely attractive, because unlocking the value of business assets can drive significant revenue â€“ i.e. the API Economy.Â The rest of this blog will elaborate.
API Governance and Lifecycle
To embrace the API Economy, it is important to view APIs not just as technology but as products.Â Â Organizations that build API products must consider the needs of their customers and how to make their APIs compelling to them.Â Organizations that view their APIs as products, rather than just as technology, can leverage successful patterns and mechanisms of product management to drive success.
Just as with any other products, APIs require a lifecycle and a governance model to enforce that lifecycle â€“ a key function provided by API Management.Â The API Management lifecycle consists of creating and publishing APIs, applying security and consumption constraints, socialization to internal and external developer communities, and collecting and analyzing usage metrics.Â In addition, ongoing testing and monitoring is part of the lifecycle to ensure our first notification of a problem is not a contact from an angry API consumer!
Existing provided APIs from back-end systems are frequently not easy to consume for a variety of reasons:
- How does a developer find an API? Is there a single place where a developer can go to find all the APIs?
- Does the API provide what the consumer is looking for or what the provider can do? – Frequently the consumer may want only a subset of the function but needs to understand all the complexity of the API to request what they want.Â Or, conversely, the consumer may need to combine the functionality of multiple back-end systems â€“ needing to use multiple provider-oriented APIs to achieve the desired result.
- How does a developer â€śsign-upâ€ť to use the API? Should they be allowed to?Â Can they do this without contacting the back-end API owner â€“ or anyone else?Â Is this a unique process (I use that term loosely) for each back-end API?
- Is there documentation? Can the API be tried before all the effort to consume it?
- Is there sample code to invoke the API in the programming language the consumer wants to use?
These questions outline just some of the typical challenges in consuming existing provided APIs that are addressed by API Management.Â API Management uses existing provided APIs from back-ends but addresses these issues to make it simple for the consumer to get what they want without tremendous time or effort.Â In addition, an API product manager may choose to combine several APIs that are expected to be used together into an API Product â€“ making it even easier to consume exactly what is needed.
One of the most important aspects of API Management is the ability to nurture the subscriber community.Â The focus needs to be on providing anything/everything they need to understand why and how they can/should use your APIs.
First, we need the ability to define consumer organizations.Â This allows us to target specific APIs to selected consumer organizations.Â As we publish APIs, only authorized consumers should even see that the API exists.
We might also want to control API usage. Â Specific consumers may only be allowed certain numbers of API calls per unit of time.Â This is called a Plan.Â API Management needs to allow for the creation of Plans (perhaps multiple choices) and provide the ability for the consumer to select from allowable Plans.Â This is also a mechanism to protect back-end systems from too many requests.
As part of the â€śsign upâ€ť process, the consumer needs to receive security information that they imbed in their API calls to allow for tracking of their API usage.
At runtime a highly secure gateway positioned in the DMZ is required to protect the enterprise from attacks and validate API usage rights and consumption prior to invoking anything in the trusted zone.Â The gateway should enforce any runtime policies including authentication and usage level management.
API Management Platform Requirements
An API management platform provides a comprehensive set of capabilities to cover the entire lifecycle of an API, from its creation to deployment and management. It should be an integrated creation, run time, management, and security foundation for both business grade APIs to expose core business assets and microservices to power modern digital applications.
The key capabilities for an API management platform include but are not limited to:
- Automated, visual and coding options for creating APIs: A set of tooling to rapidly design, model, develop, test, and deploy APIs in an automated continuous delivery model.
- Lifecycle and governance for APIs, Products and Plans: Productizing the APIs, packaging and cataloging them, and tracking their lifecycle are all activities that help the effective management and control of APIs as they are deployed.
- Access control over APIs, API Plans and API Products: Another key function for security is managing the access to APIs at various levels of granularity involving users and user groups in a consumer or provider role.
- Customizable, self-service Developer Portal for publishing and consuming APIs: Publishing and socializing APIs through a user-friendly portal is crucial in promoting the access to your core business and to the market reach of your brand.
- Polyglot support for creating microservices: Polyglot support is key to enable innovation and agility within different programming models required by different use case scenarios. Support for Node.js and Java runtimes, among others, is essential.
- Polyglot support for running microservices: Runtime execution is backed by platform characteristics, such as performance, scalability, load balancing, and failover.
- Policy enforcement, security and control: A high performing and scalable API security gateway is imperative in any API management platform, mainly to protect access to your back-end systems.
- Advanced API usage analytics: Analyzing API usage metrics from different user perspectives and roles help in providing a feedback loop to the API owners and developers for future improvement.
- Hybrid-cloud, Multi-cloud, and on-premise support: flexibility to support assets wherever they are and to deploy the API management components wherever you want.
- Scalability: the platform should allow you to start small and grow as large as you need. This includes API traffic, application developers (consumers), and API owners and developers â€“ each scaling independently to handle peaks as needed in that area without having to scale the entire platform.
IBMâ€™s API Management Platform
IBM has the leading API Management platform â€“ IBM API Connect.Â IDC has recognized IBM as the market share leader.Â Forrester has listed IBM API Connect as a Leader in the Forrester Wave for API Management Solutions. And, Gartner has also positioned IBM in the leaderâ€™s quadrant in their most recent Full Lifecycle API Management Magic Quadrant.
IBM API Connect supports all the requirements stated above and much more (too much to cover in a blog).Â Rather than restate all the above, I will use the diagram below to demonstrate how the IBM API Connect components support the most common API Management scenarios.
An API developer (1) can create an API (or Microservice) on their laptop and do unit testing. When ready they push the API to the API Management Server (2) for governance, lifecycle management, setting of security, rate limits, creation of API products, additional testing, and deployment. The API is deployed to the Developer Portal (3a) and the API Gateway (3b) and is ready for action. A business developer (4) signs up to use the API.Â The application they create (5) then calls the API which causes the flow through the API Gateway. (6) for security and policy checking, accesses the back-end systems of record (SoR), and returns the result. Analytics (7) from the gateway are gathered and viewed via the API Manager.Â The API Management server (2) also manages the microservice governance. When the microservice is ready for deployment it is pushed to the (8) container manager (e.g. Kubernetes) which manages the Microservice compute runtime clusters. API calls that benefit from the new microservice business logic would follow flow (9) which calls the microservice, obtains existing data from the SoR and then provides the new business logic before returning to the API caller.
The IBM API Connect product is itself built as a set of Microservices.Â As such, the components are independently scalable and can be deployed on-premise or in any or multiple clouds, all seamlessly working together.Â A single API Manager can be used to manage APIs deployed across multiple cloud and on-premise locations.
This is just a high-level view of API Management.Â IBM would be happy to take this discussion to a deeper level.Â If you are interested, please reach out to me or your IBM contacts.
To understand more about IBMâ€™s thoughts on the API Economy visit the IBM API Economy website.Â IBM API Connect is IBMâ€™s complete foundation to Create, Secure, Manage, Test, and Monitor APIs.Â You can find more information about IBM API Connect at the API Connect website.Â And you can also experience a trial version of API Connect.
If you have questions, please let me know.Â Connect with me through comments here or via twitter @Arglick to continue the discussion.