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:
- Free
- Consumer Pays
- Consumer Gets Paid
- Indirect
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).
Presales Consultant for CA Southern Africa at Hyperion Holding Pty Ltd
Real User
Dec 7, 2021
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.
The next consideration is whether the APIs are purely internal or public-facing. Public-facing ones are going to need more than just a portal offering the open API spec. If you want to see what a good public API provides review a good public API like Google Maps. You’ll see things like dev guidance, examples, plus legal stuff like terms of use.
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).
Vice President - Digital Integration at Kellton Tech Solutions Limited
Real User
Sep 29, 2021
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.
API Management solutions provide a comprehensive framework for developing, publishing, maintaining, and securing APIs. These solutions help streamline the interaction between different systems, improving digital connectivity and service delivery.
API Management caters to organizations seeking enhanced control over API lifecycles. It enables the creation of scalable APIs, ensuring secure access and usage tracking. This approach facilitates collaboration, innovation, and maintenance of...
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:
- Free
- Consumer Pays
- Consumer Gets Paid
- Indirect
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).
@Oleksandr Gaysin thank you so much for your in detail answer.
Would you mind posting it as a separate "How to..." article? from here: https://www.peerspot.com/articles/new?
This way your response will be exposed to a much wider audience.
Thanks in advance.
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).
@Ronald D'Souza thank you for this great answer! It is very detailed and I think it's worth creating a separate article here.
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.
The next consideration is whether the APIs are purely internal or public-facing. Public-facing ones are going to need more than just a portal offering the open API spec. If you want to see what a good public API provides review a good public API like Google Maps. You’ll see things like dev guidance, examples, plus legal stuff like terms of use.
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).
@Phil Wilkins thank you for sharing your professional opinion!
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.
@Ram Kanumuri thank you so much for your answer!
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!