One of my hobbies is photography and when I bought my first camera it was a compact camera. I soon realized and experienced that I needed a reflex camera (SLR), because the resolution, speed and quality was far more better. I did not realize it until I really used the product. Again after a few years I noticed that I did not use my camera a lot. Why was that? Because the camera was pretty big and unpractical to take with me all the time. Then I read about a system camera, which has the advantage of being small, but you still have the possibility to switch lenses. I never regretted my choices, because at the time it seemed to be the best choice. Today there are a lot of camera’s with a lot of possibilities and specifications. Which one to pick? It depends on a lot of factors and what you want todo with the camera, like portret-, landscape-, sport- and street photography.
The same holds when selecting a software application, in this case an API manager. In my opinion there are 3 options to select a product:
1. Just go with your gut and select one
You think you know that you decide for yourself but your subconsciousness has already decided for you. Go with your feelings
2. Try-out period
In this case you try-out a product for a couple of months. Using it the way you think and start experience the capabilities you really need
3. Thorough investigation of capabilities
Start a trajectory with collecting requirements, make a long-list, make a short-list, arrange demo’s, rating the products, selecting the most suitable, install- and configure the product, defining the governance around it and start using it.
The difference with a camera is that you are the only one to decide (most of the time). In case of a software selection, you can be tided by regulations and a lot of other persons have different feelings and meanings. In case you need to go for option 3 this blog will give you 10 categories of requirements to think about.
A camera has several important components, like the body itself, the light sensor and the lens. An API manager also has different logical components which are:
API Publisher
A component where APIs are described, policies are defined and APIs are published to the gateway(s)
API Gateway
The API gateway is the runtime component that will process the API calls. It will validate the policies that are defined for the API and it is the most important component to secure your gateway to the backend systems.
API Portal
The component where consumers can search for-, test-, read documentation about- and subscribe to APIs.
API Analytics
A component to store data about the API usage, metering and monetizing capabilities.
So what are the 10 categories of requirements you need to think about when selecting an API manager? Here we go
1 – API definition
Most of the API Managers will support the contract first paradigm.
Do you need the capability to define your API using an editor (for example Swagger(OpenAPI), RAML or a proprietary form.
Do you need to import existing API files? Import WSDL?
Add documentation? Which formats do you want to support for adding documentation?
Do you want connections to other content management systems?
2 – API Gateway
Do you need a separate gateway for internal- and external usage? This can be interested for example in case the security policies are more strict for external use or the performance for internal traffic must be different.
Do you want to have horizontal scalable- and central managed gateways?
Do you need micro-gateways that are even more distributed than the full blown brother gateways? Microgateways can be interested for Microservices architecture.
Do you want mediation capabilities or do you use other products to do the mediation and is the gateway purely used to pass on the messages and only checking the policies?
Which protocols do you want to support? HTTP or also JMS, MQTT, Websockets or AMQP?
3 – Deployment
The deployment possibilities are important capabilities of the product. There are several possibilities: Cloud (SaaS and/or own DC), on-premise, hybrid.
Do you want to have the flexibility to be cloud agnostic? So deploy possibility on Google Cloud, but be able to migrate to AWS or Azure?
Deploy possibilities on OpenStack, Apache Stratos or docker containers?
Another important aspect is if the components are separately deployable and scalable. A gateway may have other scalable requirements than an API portal and also have other availability and security requirements. It is a pre that the API manager product can support this kind of deployment options.
How is the product handling patches and upgrades? Does it require to shutdown the components or are rolling upgrades possible with zero downtime? Note that this is more important for the gateway component than for the portal and publisher components.
What kind of authentication/authorization do you need?
Do you need connection to your internal IAM, or maybe even to an external IAM?
Do you want social authentication possibilities like OpenID and Facebook.
Do you need multi-tenant support, so that you have clear separate isolated environments with your own users and access rights.
In case external database storage is used, which database(s) do you want to be supported.
4 – Policies
- There are several categories of policies:
- Traffic/routing policies (i.e. caching and rates/quotas)
- Mediation policies (data mapping)
- Security policies (note: these are described in the security section)
- Extension/custom policies
Next some capabilities to consider:
- How are the policies managed? Are they centrally managed within the API publisher and can they be dynamically updated?
- Can the policies be externally stored in a configuration management tool and integrated within CI/CD street?
- What is the granularity of the policies? For example: on key, subscriber, application, product, api, api method.
- Is it possible and easy to add custom policies.
- Do you need mediation policies like data- and protocol transformation or is this done by another functional component within your architecture.
5 – Analytics
One of the capabilities of an API manager is the metrics about the APIs. You can think about:
- API usage per subscription, application or API
- API latencies
- API response times
- API errors
- SLA
- Security
The following is a list of capabilities you can think of when analyzing the analytics requirements:
- Some products will have dashboards out-of-the-box which are dynamically updated. Some only have logs on which you can implement your own reports.
- Do you need monetization capabilities or use your own mechanism to implement this.
- Is it possible to define your own custom dashboards and is this easy task.
- Is it possible to export your analytics data and in which formats (for example CSV, XML, PDF, Word).
- Is it possible to automatically export the data to a datalake or 3rd party analytics (like Splunk or Google analytics).
6 – API Portal
The API portal is the frontend for developers and consumers of your API. APIs can be found, tested and subscribed on. In fact it is your shop that is the entry into your API world.
- Should the portal be customizable to your own brand theme.
- What should the access control and visibility of the partner-, public- and internal APIs be.
- Should it be possible to add your own custom flows or hooks when some important events occur, like a subscription must be approved before it can be used, or some special actions must be taken in case a new application or product is created.
- Do you want community support, like discussion forms and FAQs, where consumers can help each other and ask questions. Or maybe to enter problem reports in case there are troubles with using the API.
- How fancy do you want to have your sandbox to test APIs.
- Generation of client code for all kind of languages like python, nodejs, .net or java.
- Do you need connection with your own content management system, for example office 365.
- Internationalization can also be an important aspect to consider in case you need Multilanguage support.
- What should be the search capabilities, will it only be based on tags or text content, or do you need more fancier capabilities like proposals based on earlier subscriptions.
7 – Product
The price of the product is also important of course, but there are also very important other items to think of (I think even more important):
How is the support? Is there support within your country and do they speak your language.
How is the customer base within your country so that you can learn and ask help from those customers as well. They have already practical experience with the product so that they can indicate where the pitfalls are.
Do they have a good and clear vision with the product or is it almost end of game.
You can also look at the Gartner and Forrester reports of course but local support can be very vital for your company.
8 – Security
One of the key aspects to buy an API manager is the security of the data and services of your organization. There is a lot to read about this so I only mention a few of them.
Which kind of token support do you want, for example OAuth 2.0, OpenID, normal keys.
How do you want to protect your backend, e.g. two-way-ssl, basic authentication, payload encryption to have end-to-end data security.
Integration with your internal IAM and/or external IAM system.
Single-sign-on in the form of SAML tokens.
Role based access for example XACML or OAuth 2.0 scopes.
Black and white listing of IPs so that only explicit set of IPs and domains are able to access the APIs.
The security keys and identities need to be protected too.
Support of federated identity in the form of JWT.
VPN connection to your IT servers in case the solution is public Cloud based.
The product is secured and protected for large payloads, DDOS attacks and SQL injection.
Is it needed that the product is certified and compliant with a security standard, like PCI DDS, HIPAA, SOC1 and SOC2.
9 – Operations
The last item on the list is how the product is operated. Do you need real-time monitoring of your APIs and be proactively alerted in case something happens. Examples are out of resources, APIs are not reachable anymore, the latency becomes too high, SLAs are not met. Do you need the possibility to inform users in case the state of an API changes, e.g. the API will be deprecated or becomes obsolete. What are the disaster recovery capabilities and corresponding RTO.
Conclusion
There are a lot of items you have to think about when selecting an API manager and you can make it as complex as you want. From following your feeling to a broad investigation and analysis trajectory. Take your pick and do what is necessary within your organization.
Be aware that the API manager journey does not end here. Just when you selected your camera you have to use it, start to experience how you use its functionality in different situations. How the photos are governed and how you setup a whole photo project.
You need to define the governance processes around the APIs as well, but that is a whole different story.
Feel free to give feedback on this blog, or contact me when you have questions and remarks, or if I can help you with the process!
Published on Java Code Geeks with permission by Roger van de Kimmenade, partner at our JCG program. See the original article here: 9 items to consider when selecting an API Manager Opinions expressed by Java Code Geeks contributors are their own. |
