I work for a large governmental organization.
We are building up SDDC using VCF now and considering an API management tool to provide API service to clients. What is the best API management tool for our case?
Thank you for your help.
The Broadcom Layer 7 API platform is a robust and highly technical solution that gives you several options for building out APIs and can sit well with the portal. I have set the gateway up using Helm charts into Kubernetes (Plain, EKS, and AKS) as well as OCP. All are fairly easy to implement with their new approach to deployment that they have developed recently.
Most of the API solutions now run in containers (Kubernetes) like the one described by Derek but if you want to avoid the burden of having a container supervisor on top of a VM supervisor my recommendation is that you look for a solution that runs plain on VMWare. One option is IBM API Connect. It includes:
1. API Manager which provides a user interface that facilitates the promotion and tracking of APIs
2. API Gateway which enforces runtime policies to secure and control API traffic, provides the endpoints that expose APIs to the calling applications, and provides assembly functions that enable APIs to integrate with various endpoints
3. Developer portal which provides a customizable self-service web-based portal to application developers to explore, discover, and subscribe to APIs.
4. Analytics server
All of them as VMware images.
Dear PeerSpot community members,
Welcome to the latest PeerSpot Community Spotlight, where we sum up the most relevant recent postings by your peers in the community.
Check out the latest questions, articles and professional discussions contributed by PeerSpot community members!
Here are some topics that your peers are discussing at the moment:
What is your recomme...
What is software extensibility?
Extensibility is the ability of the software system to allow and accept the significant extension of its capabilities without major rewriting of code or changes in its basic architecture. Extensible systems provide technology, tools, languages designed so that developers can expand or add to their capabilities.
What are some of the benefits customers get ou...
As with any big enterprise solution the main goal and the driver for building the proper solution architecture it’s a properly identified set of business cases. In the case of API Management, the general question would be about 2 topics to kick start the relevant discussion - the API monetization strategy on one hand and the cost of underline infrastructure and its support in the future on another hand. Also always mandatory to understand the timelines requested by the business so it will drive the decision of bye vs build.
I would suggest trying to make this exercise together and to better understand the API monetization strategy would be good to structure APIs on 3 generic categories:
- Internal (private) APIs
* Concentrate on the internal operations of the enterprise
* Assist in enhancing efficiency and productivity
- Partner APIs
* Exposed to facilitating integrations with partners and customers
* Assist an enterprise in reinforcing external relationships and expanding its presence
- Public (open) APIs
* Available publicly and can be utilized with minimal restrictions
* Let third-party developers create applications that fetch the enterprise’s capabilities and data and integrate them into their use case
The next step would be to identify the main participants in the API value chain, like API Provider, API Consumer, and End User.
The API Provider might expose some digital assets and define terms and conditions including the monetization model for accessing the API
The API Consumer as an example might build some apps on top of the exposed APIs, so the End User will pay for the services as result.
The illustrated criteria above are only the beginning of the story on the way how to successfully start getting value from the APIs and underline products or data behind them.
Continue talking about the exact API monetization models and looking at the previous sample related to potential main participants in the flow, generally, I would state the following:
- Consumer Pays
- Consumer Gets Paid
In the Free API monetization model, money is not exchanged directly. It is usually used when low-valued assets are exposed to meet a certain business objective.
Companies can provide APIs for free for several reasons including driving the APIs’ adoption, enhancing brand loyalty, and penetrating new channels easily.
Consumer Pays Model might be divided into pay-as-you-go, fixed quota freemium, where the basic features are provided for free and advanced features are priced.
Consumer Gets Paid Model might work very well in the scope of affiliate and revenue-sharing concepts.
Well, an indirect model will host everything else like B2B, SaaS, content acquisition, etc.
At the end of the day, the first things first due to the general goal being to make sure that the solution is designed to bring value as result, whatever the final goal might be, like the new one or extension or even the transformation of the existing solution
The best practice in order to make a correct decision, first of all, to go through a monetization checklist.
For example, a set of questions that can assist you in identifying the most suitable monetization approach you can use:
- How will the exposed asset provide value to the target audience? Will it be easy to use, well documented, and properly supported?
- Will you be able to generate profits by charging directly for the API’s use?
- Is it possible to generate revenues indirectly by exposing the API?
- Who will own the customer relationship journey—is it you or the API consumer?
- Which API monetization platform will you use to measure success?
To establish a roadmap for monetization. These are the five steps you can follow when releasing your APIs:
- Start by creating internal APIs to establish your business case and provide initial proofs of concept.
- Promote internal consumption and enhance the APIs’ capabilities.
- Choose a comprehensive API management platform to help you with governance, monitoring and analytics, and many other tasks.
- Expose the APIs to partners and identify how to deliver new market propositions.
- Expose the APIs to the public with a predetermined monetization structure.
To implement an effective pricing strategy, these are the three factors to consider to help you in pricing your API well:
- Cost—you need to evaluate your business expenses and the costs for fulfilling an API request. Then, price your API such that you’re able to make a profit at the end of the day.
- Competition—you need to consider how others in the industry are pricing their APIs. Also, examine if the market is already saturated with several alternatives or if there are just a few. Your selected price should be as competitive as possible.
- Capability—you need to assess the capabilities that your API will provide to the target audiences and if they will be comfortable paying for it at the stated price.
Implement a mix-and-match approach and combine the models together.
Routing back from the end to the beginning would be also good to mention several business drivers below for API monetization from where the story might begin:
* Create a new revenue opportunity
* Gather data from API consumers
* Build customer loyalty
* Create new product capabilities
* Maintain product relevance
Besides the business part in order to properly select the API Management platform or open source solution, there are also a lot of technical aspects to consider, like the post-production solution lifecycle, which will drive the DevOps-related instruments to be used. Then selected platform or open-source implementation will force to select the engineer's skill set, whatever it might be, like Java, Python, Golang, etc. And this engineer's skill set also should be selected very carefully, because in several years this type of engineer should be still available on the market and their cost would be good to be polite.
Why all mentioned before is very important? Because all of this will drive the 1 single API request cost.
Regarding the API Management Solutions available on the market there is really a lot, but I would like to state several as I know the most popular: Azure, AWS, Apigee, Mulesoft (this list came to my mind on my own opinion and experience only).
The basic idea for Microservices would be getting your service to do just one or a few functionalities to expedite the development and also ensure although the service is loosely coupled you still can relate the service to make a holistic app with many such microservice.
The drawback would, however, be on the security level and on the management level, because the service is only purposed to cater to only a specific requirement trying to incorporate security will end up you building a full fledge service although that is always the end goal. The need to make your service extend to existing Open Standard security standard ensure your service is reusable is more adaptable.
E.g. Having google Sign Sign-On using Oauth 2.0 for Access Delegation or using JWT based authentication and authorization based on the Scope reduces the need to create user login on your app/website using the service and storing user credentials on your system and also ensuring the capability to revoke access when not require or need to discontinue the access to the service. Your rights are determined by what access you have given. Providing users the granularity to control access to the API and also providing restrictions based on subscription with Providing rate limiting based on Client Subscription and various other possibilities.
The challenge here is you can build your service using Open Source but then you would want to try and test every functionality from bottoms up. Open Source is a good thing but it also comes with an added cost of development and maintenance and time to deliver in the market. The slower you deliver the less niche the market becomes.
They are products that have a community edition that will help build your microservice but your securing the service would add the need to have additional infrastructure requirements.
Commercial services do cater assist you with dealing with your security and limiting requirements to provide a complete Authentication and Authorization scope in one container without the need to have multiple thread points and reduce the overall base to troubleshoot.
Some products provide you the drag and drop feature with values as inputs to provide a particular function like Routing to a local backend service.
Commercial product TCO may be higher but build time is lower are there are plugins and modules available to meet those requirements and also come with enterprise-type support to assist you when you are stuck rather than wait for a long time to get feedback on an issue that would be a zero-day one or a bug.
Factors for exposing API services:
1. Subscription and Rate Limiting.
2. Micro Service API Discovery and Access using Open Standard.
3. Interface to share the information with user/client who consume your service.
4. Concentrate on function only not Security and management via the Life cycle journey.
5. OWASP protection to your microservice to prevent issue because of ignore escapes.
6. Capability to scale up or down based on load on the service.
7. Capability to automate the deployment and configure it base on the environment and end up making a no change or read-only production environment with everything managed through Configuration variables.
So "yes", open-source and community has grown over period of time but at the same time, commercial products in the API domain are more and more inclined towards meeting the open security standards that are easily developed and runtime ready.
Some noteworthy winners in the APIM space:
1. Broadcom Layer 7 APIM Suite
2. Google Apigee API Management
3. Kong API Management (comes as open-source with limited interactive UI).
Whether to adopt an open-source question is more about an organization's view on the use of OS. A lot of organizations I’ve dealt with feel it is necessary to have commercial support to fallback on. This comes back to things like, if a vulnerability is discovered who can you hassle to get it sorted. Open source, the community will apply the fix, but how quickly will that come. If you have people able to dig in and commit fixes if necessary then you in a good place.
For internal use, you can relax a bit on the support considerations. But the more your portal enables self-service, the better for you.
What goals as you trying to achieve with APIs? Security, usage measurement, bulkheads and consumption limits? Or is it more about abstraction so people don’t see whether they’re connecting to legacy systems to be replaced by shiny Microservices? Kong has a nice article about this.
In addition to the suggestions @Ram Kanumuri mentioned, depending on answers to the above, you could consider Ambassador, Kong, Oracle (have some options). Most major integration vendors will have something in the API space. So that includes Boomi.
Are your APIs going to be deployed in a hybrid, on-prem, single cloud or multi-cloud model? This can impact how the gateways are placed and managed.
I would caution on Mulesoft as it tries to offer itself as an API gateway and API implementation solution - you mentioned microservices, so might not get the full value from Mulesoft.
Last, I heard IBM Connect has its origins in a hardware solution, which will mean it is more of a black box solution (plus in terms of security-hardened and minus in so far as deployment options and scaling may prove to be restrictive).
The two important sides of API Management are:
(a) "Portal" for API Life cycle management that allows for continuous change for innovation, extensive developer/consumer collaboration, and all the nice features that support the best design/development time maturity to your development teams.
The other side is all about
(b) "Gateway" runtime/gateways, their ability to provide service-mesh/service-grid/side-car architectures for API to support various microservices patterns, extensive/elastic scalability, portability, net/cloud neutrality and of course containerizable, etc.
That being said, we have to introspect into our own requirements of Application development in Micro-services architecture: what are our patterns? what are application agility objectives? how fast/often do we change services/APIs, security and access control? do we need an associated iPaaS? how is the infrastructure deployed (container architecture) for application micro-services vs data services? are we cloud-neutral and multi-cloud?
All these factors will need to be vetted out to devise a comprehensive API management strategy that will help in choosing the right API management platform.
Open-source solutions are a good beginning for testing waters in a tactical approach, but for big enterprises and long-term strategic approach where APIs are not only for Microservices but usually also for many other areas (like SaaS integration, Data/Analytics-as-a-service architecture, Legacy Modernization and Hybrid Integration) a well established COTS platform will be a better choice.
For Strategic platforms - Software AG webMethods, Google Apigee, IBM API Connect, WSO2, Axway and MuleSoft are the top considerations.
Hello @Viktor Dolyna, @Igmar Rautenbach, @MichaelSukachev and @Phil Wilkins.
Can you please assist here with your expertise and let other peers know your thoughts?
Thanks for the help!