I hear enterprise organizations say that they need a single service provider to offer a bundle of services that meets all of their needs. I’d say this is the result of years of being told by analysts and API management providers that they were in need of a one size fits all tool. There is this strange dance that exists between enterprise leadership, analysts, and API service providers that evolve these narratives, leaving them as truths when it comes to infrastructure procurement. Sure, you have your bedrock solutions like source control, CI/CD, gateways, APM, and other infrastructure, but the myth that you can have one vendor provide you with everything you need to produce APIs just demonstrates your weakness in identifying yourself as an API consumer. You see, in order to find balance across the API lifecycle and API operations, you have to strike a balance across your existence as both an API producer and an API consumer.
If your head is stuck in API producer mode you just one one solution to manage your APIs—give me everything I need in one bundle. If you are an API consumer, you want exactly the resource you desire, and you want it to be reliable and cost effective. You see the imbalance that exists if you only live as an API producer? You see this same illness with API management and other service providers, in that the ones who also have their own APIs will outlast the ones who do not. To make it in this business you have to be both API producer and consumer. You have to see the API lifecycle as something that is shared between both API producers and consumers, both inside the enterprise, and out on the open web. The belief that you should have one vendor to solve all of your problems is lazy from the perspective of the enterprise, and greedy from the perspective of the API service provider selling to the enterprise.
Now don’t get me wrong. As the Chief Evangelist for an API service provider who offers solutions across every single stop along the API lifecycle, you still want to get as many of your API hooks embedded into the enterprise as possible, and this often times comes with some bundling voodoo and jujitsu. In an API-first world, you don’t want to be paying for digital resources and capabilities you don’t consume, and as an API producer you don’t want to operating APIs that nobody is consuming. I know that we come from a long history of bundling extremely useful products and services with lesser useful products and services to maximize our business, but you have to be more creative in a digital marketplace. For me, an API-first world offers a more honest look at how we can do business. It offers a more efficient and pragmatic way of making our products and services available, and then iterating upon them based upon actual need—not just cause we think it is cool, or someone might come along and buy it.
Over the last decade of working in the API space I have heard a lot of API service providers tell their customers that they need to be more modular, so that they can be agile, nimble, and more efficient—while not practicing what they preach. You will find 3-5 blog posts over the years with me ranting about this reality, and complaining that API service providers need to have APIs. While there will always be plenty of people who do not get the business composability of being API-first, and there will always be plenty creative virtual bundling when it comes to API service composition, I am confident that the days of thinking that there is one API service provider to do it all, or API service providers thinking they can do it all, are behind us. Reusability, composability, as well as federated and distributed approaches to doing business are here to stay, and we’ll compete more on our ability to deal with change and complexity. In the end, you don’t want a single provider to do everything you need across the API lifecycle, and what you really needs is a handful of cornerstone providers who all support API, Git, and CLI, and then fill in the gaps of everything else you need with an ever evolving mix of API-driven capabilities.
