5 ms·

Pros and cons of API management platforms

2 points by varunjsr7 4y ago

Can developers here share their experiences (positives and negatives) and/or frustrations with API management platforms? We’ve a ton of players in the market from the likes of apigee, mulesoft, tyk, Kong, azure API, to swagger, AWS cloud trail. All of these platforms are more or less trying to do the same thing and are trying to build bigger and better features than others. Are they even trying to solve a problem that exists in the market?

rawgabbit 4y ago
I can only speak about Mulesoft. It is expensive. If you are running mission critical stuff then you can justify the cost. That is we outsourced disaster planning and recovery to them. They are essentially hosting APIs for you. Personally I believe APIs peak has past. Developers want to deliver functionality quickly. Seems to me, people are looking for ways to bypass APIs. E.g., webhooks, event architectures like Kafka. etc. That is instead of exposing an API for the entire internet to hit. Modern architectures are more selective or direct or has less intermediaries.
- Mandatum 4y ago
  Do you mean RESTful and RPC-based APIs peak has past? Because in the backend, everyone's still using and building those, it's just the way they're advertising and mainly doing integration is event-based (which sometimes is actually just RPC wrapped in a long-polling mechanism). Or do you not see event-based architectures as APIs?
  - varunjsr7 4y ago
    Looks like we are saying the same thing :)
  - rawgabbit 4y ago
    Sorry, let me try to be more clear. I believe people are exploring ways to move beyond and no longer have the need for APIs. Webhooks and event architectures are, I believe, stepping stones towards that goal. That is instead of an architecture that relies on multiple APIs to interact in near real-time. I believe the direction is fewer services that interact with each other asynchronously. And their coordination will be by a Kafka type event log.
    - Mandatum 4y ago
      I agree, once we've removed the functional, silo'd data stores that have currently been built as services and we migrate from proprietary or silo'd service to centralised event-log we've.. Come full circle and arrived at fucking event bus' from the 80s. Sounds like SOA on MQ.
- varunjsr7 4y ago
  I 100% agree with your opinion and it makes total sense to go with minimal intermediaries! I'm trying to decipher your comment around "bypass APIs" - the webhook and event streaming arch. makes sense for any net new applications being built from now (or for the past few years). A typical small to medium enterprise would still have hundreds of APIs (internal and external) that still need a platforms to take care of API lifecycle events. My follow-up question is as follows - Is there a market for another API management tool that is 1. Less expensive, 2. Encourages collaboration between internal dev teams, 3. Curation i.e. takes care of the lifecycle management i.e. design, arch. approval, development, test, release, production, versioning, monitoring, deprecation. 4. Compliance - PCI compliant and manage clientIDs and secrets (rotation included) 5. Be multi cloud-native
  - rawgabbit 4y ago
    I believe the trend is micro services using Kafka based event messaging with minimal APIs.
Mandatum 4y ago
What solution are you trying to solve with an API Management Platform? AWS, Google, Azure all offer products, or a collection of products to fill most needs that a typical platform would provide. You can self-host and try open-source products (some of which have a commercial/Enteprise offering too), but it really depends on your use-case and organisation. If you're buying a product like Apigee, Tyk, Kong, MuleSoft, etc - it's usually to solve a specific purpose, but the product just happens to serve a few other use-cases (like out-of-the-box Authorization integration with AD for example). Most customers I see going to market for these types of products really don't need functionality beyond network isolation, authentication and rate limiting. AWS API Gateway's free tier would probably meet the need of most of MuleSoft, Apigee, Kong and Tyk's customers - but consultants and sales people got involved.
- varunjsr7 4y ago
  Ah! I see your point, Thanks for sharing your perspective. [I'm not 100% sure if you saw my response, apologies if this is repetitive] Below are a few differentiators than existing solutions 1. Less expensive, 2. Encourages collaboration between internal dev teams by connecting to active directory (or source of authentication & authorization), 3. Curation i.e. takes care of the lifecycle management i.e. design, arch. approval, development, test, release, production, versioning, monitoring, deprecation. 4. Compliance - PCI compliance and app management (generating clientIDs and secrets, rotation included) 5. Multi cloud-native 6. Simpler UI/UX experience 7. API based role access. Fully understand that these feature sets may overlap with existing players.
  - Mandatum 4y ago
    Wait, so that list is things you WANT? To be honest it sounds like you've read what's on the back of the box of some proprietary integration platform sold by IBM in the 90s. It's a bit like when a vendor writes an RFP. You're not telling me anything about the problem you're trying to solve, you're giving me a list of solutions. Based on your list of features - let's think about what would be a good option.. 1. Less expensive Than what, a private jet? 2. Encourages collaboration between internal dev teams by connecting to active directory (or source of authentication & authorization) Authentication, pretty much every paid platform has this. Some take more setup. Where does your AD sit, if you're a Microsoft shop, Azure might serve the best products. Having said that, there's out-of-the-box integrations with AD with many major platform providers. Secondly, is this for internal access only - or is this AD environment also serving external users and partners? Maybe you're looking for AD integration because that's all you know to support RBAC. 3. Curation i.e. takes care of the lifecycle management i.e. design, arch. approval, development, test, release, production, versioning, monitoring, deprecation So you want an API platform product that supports the end-to-end SDLC in a single product? Why? What is the the "solution" to? Also you're asking for "approval", so you're expecting an API Manager Platform to also have a baked in release process.. But based on requirement 5 - you can't go with a single cloud vendor. 4. Compliance - PCI compliance and app management (generating clientIDs and secrets, rotation included) Any commercial or Enterprise provider will provide this, however if you're building a solution which touches card data - you're going to need to re-certify the end-to-end solution. Expect to pay an auditor for this. 5. Multi cloud-native OK, this is the first thing on the list that would actually be useful in driving you towards a decision. You want something you can download and host on a server. This takes away all SaaS options and really only leave self-hosted options. You've removed all cloud providers and all proprietary providers with this decision. There is only open-source (and NOT that bullshit "open-source heritage"). 6. Simpler UI/UX experience Than what, a TI-84 graphing calculator? 7. API based role access. All major cloud providers will have this well supported. However I'd likely set up SAML integration with an IdP, and outsource the authorization and administration of users and roles to a purpose-built stack or SaaS - and not some crappy afterthought implementation that'd been strapped on top of an API Manager product. Think Okta.

2 points by varunjsr7 4y ago

rawgabbit 4y ago

I can only speak about Mulesoft. It is expensive. If you are running mission critical stuff then you can justify the cost. That is we outsourced disaster planning and recovery to them. They are essentially hosting APIs for you. Personally I believe APIs peak has past. Developers want to deliver functionality quickly. Seems to me, people are looking for ways to bypass APIs. E.g., webhooks, event architectures like Kafka. etc. That is instead of exposing an API for the entire internet to hit. Modern architectures are more selective or direct or has less intermediaries.

Mandatum 4y ago
Do you mean RESTful and RPC-based APIs peak has past? Because in the backend, everyone's still using and building those, it's just the way they're advertising and mainly doing integration is event-based (which sometimes is actually just RPC wrapped in a long-polling mechanism). Or do you not see event-based architectures as APIs?
- varunjsr7 4y ago
  Looks like we are saying the same thing :)
- rawgabbit 4y ago
  Sorry, let me try to be more clear. I believe people are exploring ways to move beyond and no longer have the need for APIs. Webhooks and event architectures are, I believe, stepping stones towards that goal. That is instead of an architecture that relies on multiple APIs to interact in near real-time. I believe the direction is fewer services that interact with each other asynchronously. And their coordination will be by a Kafka type event log.
  - Mandatum 4y ago
    I agree, once we've removed the functional, silo'd data stores that have currently been built as services and we migrate from proprietary or silo'd service to centralised event-log we've.. Come full circle and arrived at fucking event bus' from the 80s. Sounds like SOA on MQ.
varunjsr7 4y ago
I 100% agree with your opinion and it makes total sense to go with minimal intermediaries! I'm trying to decipher your comment around "bypass APIs" - the webhook and event streaming arch. makes sense for any net new applications being built from now (or for the past few years). A typical small to medium enterprise would still have hundreds of APIs (internal and external) that still need a platforms to take care of API lifecycle events. My follow-up question is as follows - Is there a market for another API management tool that is 1. Less expensive, 2. Encourages collaboration between internal dev teams, 3. Curation i.e. takes care of the lifecycle management i.e. design, arch. approval, development, test, release, production, versioning, monitoring, deprecation. 4. Compliance - PCI compliant and manage clientIDs and secrets (rotation included) 5. Be multi cloud-native
- rawgabbit 4y ago
  I believe the trend is micro services using Kafka based event messaging with minimal APIs.

Mandatum 4y ago

What solution are you trying to solve with an API Management Platform? AWS, Google, Azure all offer products, or a collection of products to fill most needs that a typical platform would provide. You can self-host and try open-source products (some of which have a commercial/Enteprise offering too), but it really depends on your use-case and organisation. If you're buying a product like Apigee, Tyk, Kong, MuleSoft, etc - it's usually to solve a specific purpose, but the product just happens to serve a few other use-cases (like out-of-the-box Authorization integration with AD for example). Most customers I see going to market for these types of products really don't need functionality beyond network isolation, authentication and rate limiting. AWS API Gateway's free tier would probably meet the need of most of MuleSoft, Apigee, Kong and Tyk's customers - but consultants and sales people got involved.

varunjsr7 4y ago
Ah! I see your point, Thanks for sharing your perspective. [I'm not 100% sure if you saw my response, apologies if this is repetitive] Below are a few differentiators than existing solutions 1. Less expensive, 2. Encourages collaboration between internal dev teams by connecting to active directory (or source of authentication & authorization), 3. Curation i.e. takes care of the lifecycle management i.e. design, arch. approval, development, test, release, production, versioning, monitoring, deprecation. 4. Compliance - PCI compliance and app management (generating clientIDs and secrets, rotation included) 5. Multi cloud-native 6. Simpler UI/UX experience 7. API based role access. Fully understand that these feature sets may overlap with existing players.
- Mandatum 4y ago
  Wait, so that list is things you WANT? To be honest it sounds like you've read what's on the back of the box of some proprietary integration platform sold by IBM in the 90s. It's a bit like when a vendor writes an RFP. You're not telling me anything about the problem you're trying to solve, you're giving me a list of solutions. Based on your list of features - let's think about what would be a good option.. 1. Less expensive Than what, a private jet? 2. Encourages collaboration between internal dev teams by connecting to active directory (or source of authentication & authorization) Authentication, pretty much every paid platform has this. Some take more setup. Where does your AD sit, if you're a Microsoft shop, Azure might serve the best products. Having said that, there's out-of-the-box integrations with AD with many major platform providers. Secondly, is this for internal access only - or is this AD environment also serving external users and partners? Maybe you're looking for AD integration because that's all you know to support RBAC. 3. Curation i.e. takes care of the lifecycle management i.e. design, arch. approval, development, test, release, production, versioning, monitoring, deprecation So you want an API platform product that supports the end-to-end SDLC in a single product? Why? What is the the "solution" to? Also you're asking for "approval", so you're expecting an API Manager Platform to also have a baked in release process.. But based on requirement 5 - you can't go with a single cloud vendor. 4. Compliance - PCI compliance and app management (generating clientIDs and secrets, rotation included) Any commercial or Enterprise provider will provide this, however if you're building a solution which touches card data - you're going to need to re-certify the end-to-end solution. Expect to pay an auditor for this. 5. Multi cloud-native OK, this is the first thing on the list that would actually be useful in driving you towards a decision. You want something you can download and host on a server. This takes away all SaaS options and really only leave self-hosted options. You've removed all cloud providers and all proprietary providers with this decision. There is only open-source (and NOT that bullshit "open-source heritage"). 6. Simpler UI/UX experience Than what, a TI-84 graphing calculator? 7. API based role access. All major cloud providers will have this well supported. However I'd likely set up SAML integration with an IdP, and outsource the authorization and administration of users and roles to a purpose-built stack or SaaS - and not some crappy afterthought implementation that'd been strapped on top of an API Manager product. Think Okta.