Balancing What Your Customer Wants Versus What They Need As An API Service Provider

I always enjoy conversations about API management providers or more specifically what API gateway providers should or shouldn’t be providing as they work to specialize or be everything to everyone. Today’s post was triggered by my friend James Higginbotham Tweeting about API gateway providers trying to do everything, but this narrative also reflects what I see over and over as I talk to different enterprise organizations about their API operations. As an API platform provider, I see enterprise organizations asking for more features, while in the same breath complain about the bloat, complexity, and lock-in of other solutions. I think we like to poke at API gateway providers for trying to do everything, but they are just doing this in response to customer request, as well as analyst expectations—granted. Enterprise organiations should learn to say no from time to time, but I think we should be poking at enterprises unwillingness to do the hard work needed, as well as investor pressure on API service providers to deliver what customers need.

API gateways are loaded with the ability to transform and add business logic because companies have asked for it. Enterprise teams aren’t always interested in doing the hard work to design and refactor their legacy APIs to properly take advantage of modern gateways, and gateway deployment patterns. It is interesting to watch each wave of API gateway providers fall for the same influences from their customers, investors, and analysts that push them to add more features into the gateway. As gateways are commoditized, their footprint has become smaller, not just the installation footprint, but also the feature footprint. The goal of many enterprise organizations is to have a single centralized gateway solution that has all the bells and whistles, but depending on the API, its visibility, applications, consumers, and other considerations you are likely not going to care about all of the features the leading API Management solutions offer. Increasingly teams are just wanting core gateway capabilities in simple easy to use on-premise or cloud solutions. However, depending on who you talk to in the enterprise, you will find different opinions about just what a gateway should do.

I am fascinated by enterprise leadership wanting more capabilities from a single vendor, while also complaining about vendor lock-in. I am fascinated by investors pushing startups to deliver what enterprises are asking for rather than leading us to what is next, or doing the hard work to evolve our infrastructure and applications. I am fascinated by how so many enterprises, vendors, and investors are blind to the API opportunity when it comes to interoperability, composability, and flexibility. It seems like we lack the imagination to map out a path forward, so we tend to resort to lock-in via proprietary and complex solutions. Distributed systems aren’t easy, and I don’t want to oversimplify an API-first approach to operating large enterprise organizations, but the interoperability, composability, and potential resiliency of distributing businesses across many services developed internally, by partners, and 3rd party infrastructure and SaaS providers just makes good businesses sense. Bringing us back to the gateway discussion, it is clearly a multi-gateway reality across enterprise organizations today, so it makes sense that we end up with a diverse buffet of gateway solutions that help us deliver APIs across internal, partner, and public dimensions. To accomodate an API-first reality we need a robust suite of scalable, but small footprint API gateway and other lifecycle solutions to weave into operations and achieve the business outcomes we desire.