Unbundling API Management: When Is It Worth It?

‘Unbundling’ is a term that has seen wide use across the API management industry in the last few years. But what actually is unbundling? What bundles are being deconstructed? Where did this issue even come from?

Below, we’re going to look at API management unbundling. We’ll first explore what led to the creation of holistic API management platforms and then consider if and when it makes sense for organizations to unbundle or use fit-for-purpose tools to manage their APIs.

API Management and The Monolith Paradigm

To understand what unbundling actually is, we should first talk about API management. API management is a catch-all term for the services and systems that help manage the lifecycle and maintenance of an API product. This management usually stretches across a good amount of time, starting in the early stages and ending with eventual deprecation or conversion into a new product.

While these services are very helpful, they have evolved to present a bit of a conundrum. For providers, it quickly became clear that API management was a veritable goldmine if managed correctly. In the same way that megabox stores found success combining groceries with pharmacies and toy stores, API management vendors found great success in combining many offerings into a single service. For API developers, this seemed like a great idea. After all, why spend time digging into a bunch of competitors, alternative methods, toolsets, and requirements when you could just buy a single subscription?

This was the birth of the API management bundle. API management providers benefited dramatically from this exchange, offering tools to users who could sign on for several-year contracts, generating sustainable revenue. API developers benefited as well, as they had a simple service to achieve basic functionality.

A Bundle of Issues

There is, of course, an issue with this approach. API management providers were not necessarily incentivized to make individual functions truly best-in-class. This would lead to what some developers saw as stagnation of the toolset. On the API developer side, bundled solutions gave a one-stop solution, but at a cost — many developers were locked into several years’ worths of contracts, either through contractual agreements or through the lengthy processing and integration that often hid in the finer details of these bundled solutions.

That’s not to say bundled solutions were all bad, they just weren’t the utopian universal solution that they promised to be. For everyone, these bundles presented one of two realities — a “good enough” implementation that was useful as long as you didn’t need top-of-the-line solutions to every issue or a locked-in implementation that didn’t meet your needs.

In many cases, the purported benefits of these one-stop solutions actually became undermined by the very nature of this monolithic bundled solution. While API management platforms offered specialized solutions, the design paradigm of building a complete toolkit meant some generalization was necessary, resulting in reduced optimization for specific use cases. This also resulted in increased cost — while in theory, developers saved money and time by using a monolithic solution, the need for custom tooling for variations of existing solutions just meant more cost on top of the subscriptions.

What is API Unbundling?

Unbundling, therefore, is the alternative to this approach. Instead of looking for a single all-in-one platform for API management, unbundling involves finding best-in-class tools on an a la carte basis. Choosing to prioritize the specific tools for your needs as opposed to buying into a bundled service allows you a significant degree of freedom, control of cost, and heightened efficiency.

Kin Lane, the API Evangelist, has made the argument that unbundling is more the result of marketing and advertising response than an intrinsic quality of consumers:

“As a consumer I don’t approach my day considering what I want to unbundle. I go out in the world and obtain what I need. The fact that many of us fall for the bundling of all the products I need into a single grocery store, or fast-food chain, does not make bundling or unbundling a thing… I do not want the resources I need for my API platform, operations, and governance from a single bundled provider any more than I want the resources I need for my web, mobile, and device applications from a single provider.”

Others, such as Erik Wilde, have echoed this mentality, noting that while bundling simplifies choice, it often becomes a limitation, especially within the context of older bundled solutions that are not built to be open or interconnected:

“For API providers to be able to get the most out of this development, we have to make sure that we’re not painting ourselves into any corners. Pro tip: If you do POCs, always involve multiple tools so that you get an idea how open things are.”

When Does Full API Lifecycle Management Make Sense?

This is not to say there is never a situation in which bundled solutions make sense. Full-lifecycle API management tooling can sometimes be the right fit, assuming you fit into a few specific considerations.

First, not every service is going to be eternally evolving and expanding. For some API products, the v1 will be the final version, and in such a case, it may make sense to use a solution that is “good enough” for the current needs. This is especially true for small APIs that need multiple solutions. While optimization and efficiency are good to work towards, not every service must reach the lofty goals of having a fully bespoke, highly efficient toolset.

In some cases, pure resource limitations make the bundle an ideal solution. When you are a small team dealing with a complex API, you may not have the time to dig into individual solutions and potential integrations, and the minimum expectation of your API platform providers may be effective and appreciated. While this may become a problem later as you grow and scale, some costs cannot be eaten up front, and this shifting of decision-making may be valid. Organizations with limited technical, financial, or expertise resources may find the overhead of managing multiple independent systems simply too burdensome, no matter how much benefit can be reaped by their use in the long term.

Also read: How Gen AI Is Evolving API Management When Does It Make Sense to Unbundle?

All of that being said, however, unbundling remains a strong option for most use cases. Unbundling is particularly helpful for APIs seeking a single tool or solution. After all, not everyone will need the entire feature set of an API management platform, no matter how alluring it might be. In such a case, where you’re only trying to solve a single problem, adopting a platform solution is the wrong fit. Adopting an a la carte unbundled approach allows you to find your current need, its current solution, and the most efficient route to implementing said fix.

Christian Posta, VP, Global Field CTO at Solo.io, refers to this principle as avoiding YAS, or Yet Another Silo. In this view of lifecycle management, the adoption of a platform solution creates a silo that locks developers into a single stack that is hard to operate outside of. When developers are locked into a single stack of solutions, they have to develop within the confines of their tech stack rather than within the confines of the use case or business environment.

There are also many situations in which industry-specific APIs will find that platforms just don’t fit their need in the first place. Many APIs in such a scenario would need to use most of a platform, or segments of a platform, cutting out the rest that are not compliant with their specific industry regulatory rules or requirements. In such a case, unbundling makes the most sense. If you’re only using 50% of a platform, just don’t use any of it and only use the pieces you need!

All of this is an estimation of the preferred approach, but the real world has many factors that can limit developer options. Startups and smaller organizations may find this unbundling approach easier, as their organizational structure is naturally more agile and keyed towards rapid iteration. Larger organizations, especially in the enterprise, may find this difficult, as the use of multiple external partners can result in discrepancies between teams and a larger body of documentation to maintain.

This also says nothing about organizations already currently bundled — half of the battle them is moving off of that platform, and in a business environment where success is measured in weeks and budgets are growing ever-tighter, this can be a hard sell to leaders.

Is It All or Nothing?

The good news is that this is not an all-or-nothing discussion. Platform providers have seen the writing on the wall, and there is a recent spate of platforms offering piecemeal implementation in addition to platform solutions. Kong refers to this as the incremental buy-in product principle:

“Kong’s incremental buy-in product principle is designed to empower organizations to start with what they need and expand their toolset organically as their requirements evolve. This approach isn’t about offering a one-size-fits-all solution but providing a suite of best-in-class capabilities that cater to different aspects of the API lifecycle and its stakeholders, including application teams, infrastructure teams, platform teams, and API product owners.”

Solutions such as Gravitee have also shown that there is interest on the other side of the equation, providing connectivity between APIs regardless of their paradigm or stack. This helps eliminate the restrictive nature of the platform, which often uses a sort of soft power to ensure that the platform is easier to use than the piecemeal solution.

Conclusion

Unbundling is not just a trend. It’s a core rethinking of how organizations can better use their resources in the greater API economy. While much has been said about the value of API platforms — and to be clear, there are major benefits to be had in a singular platform — many organizations will find that the strictures and control placed upon them by a monolithic solution is as dangerous a monolith as the non-microservice monolith was for web APIs. In a similar way, this movement towards best-in-class bespoke solutions rather than a one-stop shop is the next stage in API market innovation, offering greater agility and freedom.