Whether you are just beginning to think about an API initiative or have already started one, now is the time to think about an enormous potential problem – SUCCESS!
Even in the initial stages, it is important to think ahead and plan for success. Starting with a view of only the first project or two may lead to a dead end. By picturing what success will bring, we can better prepare.
Expanded Usage
The first is obvious, after initial API successes come requests for more projects and more APIs. Perhaps you started simple with some basic APIs and internal integrations, but as you progress the usage patterns expand. API traffic will come from outside the enterprise (e.g. mobile), next come Partner projects, and eventually public APIs.
How can your API management solution support multiple models and drive
speed to market (a key business driver)? The answer - API
Governance. The need for speed in creating and managing APIs requires different governance than changes to the Systems of Record (SoR).
Some vendors have built their API management solution on their traditional Enterprise Service Bus (ESB), but how do you govern APIs and SoR assets differently with one solution? You cannot. (See -
Is a Combined ESB and API Management a Good Idea?) APIs need to be governed separately from SoR assets (see
security later as well) to support necessary speed for APIs and availability for SoR assets.
Growth 
Another result of success is increased use. This could be more API calls, more consumers accessing your developer portal, more APIs needing to be managed, more visibility into the analytics, or any combination. And, each may spike independently.
Microservice architectures support the automated scaling of resources as requirements increase and reduction as usage lessens. Recognizing this requirement, IBM API Connect V2018 was rearchitected as a microservice solution. This allows any component to scale independently as its usage increases without the need to scale the entire platform. No other major API Management vendor has a complete microservice implementation. Some may supply a part of their solution as microservices, but if the usage increases for other parts then the entire monolithic solution needs to be scaled. And, in a worst-case scenario, this might include your back-end ESB as well if the vendor has implemented a combined solution.
Change Happens
Sooner or later change is going to occur. New function is implemented, a back-end application is changed or upgraded, you merge with another company, etc. Previously I have discussed the value of consumer oriented APIs to create more backward compatible APIs (see
here). But, even the best APIs occasionally require a non-backward compatible change. Having an API Management solution that supports this lifecycle (including creation of the updated version, consumer notification of the migration timeframe, allowing both versions to execute while not allowing anyone new to subscribe to the previous version, and finally retiring the old version) is of course extremely important. Many, but not all vendors, support this type of planned version migration.
A larger and more damaging issue is when a change occurs that causes an API problem and you have not planned for it. Our first notification must not be customers complaining. API
test and monitoring capability is available for IBM API Connect to help alleviate this issue. You can monitor API payloads to ensure results are as expected and remain as expected. If something abnormal occurs appropriate personnel are notified. Test suites can be created for your APIs automatically with no code and scheduled for periodic execution to ensure API quality remains consistent.
Flexible deployment 
What is your cloud strategy? Planning for cloud may include:
- Private clouds,
- Moving a few SoR applications to a cloud,
- Using SaaS applications, and
- Deploying cloud test environments with more usage later.
Certainly, SoR applications will exist on premise for a long time too. There are many unknowns here. When will you move to the cloud and what will move? Which cloud provider(s) will you use? How can you maintain portability between on-premise and any cloud provider so that you can be prepared no matter what cloud choice is made or if cloud providers are changed or added?
As mentioned, API Connect has a microservice architecture which also provides deployment flexibility. API Connect can be deployed on premise or on any of the major cloud providers. Any individual component can be deployed on any cloud and maintain a single management component (on premise or in any cloud) that manages the solution across all locations. Compare this to other vendors who require a management component deployed in each location or some vendors who have different implementations between cloud and on premise or support only a small number of cloud providers or none. As stated, there are many unknowns. With API Connect we support your deployment flexibility.
Security
Security is important from the beginning. But, as your initiative grows there are more scenarios that need to be handled.
Here are two principles which most enterprises follow:
- Security checks and business logic should not be mixed. In fact, having the capability to run business logic where security is being checked is a security exposure.
- Security should be handled as soon as possible, and certainly before outside traffic reaches the trusted zone.
APIs should enable secure consumption of business assets. But, APIs should not be the actual business asset. This allows the API to perform the necessary security functions to check for authentication, authorization, rate limits, etc. and if these checks are successful perform minor integration logic to access a business asset inside the SoR. Many API Management vendors supply API Gateways built with standard off-the-shelf components such as Java. If your Gateway is executing Java at the same time it is checking security, you are exposed.
As APIs are called we need to ensure security as early as possible. For traffic coming from outside the enterprise (e.g. a mobile App, a partner) this means enforcing security in the DMZ – before entering the trusted zone. But, if an API gateway was built using Java, it should not be deployed in the DMZ. This has led to a convoluted multi-gateway architecture which does some initial checking in the DMZ and then the remainder of the security checking in the Trusted zone. All the security checking should be done in the DMZ before letting transactions into the Trusted zone. If transactions reach the Trusted zone unsecured, Java or another programming language can be exploited.
IBM API Connect’s Gateway – DataPower is a self-contained gateway appliance reducing the attack vector, providing a more secure platform, without requiring any OS, Java, or database components. DataPower is available in many form factors including physical, virtual, and microservice containers. It can be deployed in the DMZ or in any cloud providing the highest level of API protection available. Many businesses also run a separate instance of DataPower in the Trusted zone for internal traffic.
At the beginning of the blog I said you should not be afraid of success. Okay, then what should you be afraid of? Easy - the fear that a competitor is executing an API initiative addressing these concerns - growth in projects and scale, planning for change and hybrid deployment, and implementing a strong secure API management solution. Please contact IBM to discuss how we can remove your fear of API success and make you the competitor to be feared.
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, Run, Manage, and Secure 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.