To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "What’s the future for API management?" Here's what they told us:
Lifecycle Management
- Deeper integration of all of the tools across the entire API lifecycle will further improve the speed of the lifecycle and more importantly the delivery of APIs that meet the consumer’s needs. This goes hand-in-hand with process improvements in the lifecycle of APIs. We see this starting to happen as organizations start treating APIs as products with product managers guiding the lifecycle.
- I see more growth around monetization. All these API gateways are focused on the infrastructure side. As someone who publishes APIs to customers, I’d like to have analytics go one step further to monetize APIs as well. Some are more expensive others are less expensive. Be able to do manage monetization without building custom systems would be a nice thing to do.
Microservices
- A number of big shifts are taking place at the moment. API lifecycle — everyone talks about it, but a lot of the time do you have tools for each phase versus providing an integrated approach to make it easier for the developer to design, implement, deploy, and have it managed in an automated way. I don’t want to have to do a design document and wait months to see if the API meets the design. Developers want to be more iterative and support an agile development process. We’ll ultimately automate the DevOps of APIs, but we’re not there yet.
There will be a continued emphasis on the developer and recognizing the developer is king and making the job easier for them. We understood this for the public, but we still need to improve internally. In the form of a service catalog for internal developers to make it easier for them to ramp up and get benefits of existing APIs. New architecture — Everything is driven by containers, container platforms, and K8s is leading to microservices architecture with new approaches to control traffic with sidecar approaches to manage traffic like Envoy and Istio to provide service mesh to manage applications within the container cluster.
As these things come up, there will be a proliferation of types of control points with multiple form factors. We embrace Envoy as the new gateway. Right now we live in a mixed world and it’s important to consider how service mesh and API management will overlap. API management is about the relationship of providing a service and multiple consumers of that service. The more scale, the more important the formal API management platform.
If controlling API access for a single user or developer team using an API rather than a shared library, a service mesh is fine a way to secure communications between two endpoints. A service mesh provides an intelligent network to help developers connect with other services within the mesh. Developers are at ground level in learning how to create distributed applications that work on a container, microservice environment, and service mesh will help developers with this. - Modernizing applications based on microservices-based architectures is central to digital transformation initiatives. The greatest opportunity lies in the API management of microservices. Solutions with a small footprint that is flexible, portable and can operate on any infrastructure (bare metal, VMs, and containers, public cloud, and private cloud) are needed for managing APIs that are used by microservices.
- Now in the last year or two, there is a huge trend toward service mesh. Take API management and bring to every microservice. Ensure the ability to applications and microservices to talk to each other. Instead of API gateway also put proxy at the edge to trick microservices to only talk to the proxy.
- I think the market’s ready for SaaS solutions to provide authorization and API delivery options for customers who want to bring microservices APIs directly to their customers. We aren’t the only business facing these challenges, and it’s a shame that my team has to spend so much time building proprietary solutions to what feels like commodity problems.
It’s no surprise that Amazon, who builds each component of AWS as a microservice directly addressable by customers, is the closest I’ve found. You can write custom authorizers that take in OAuth bearer tokens and convert these into access decisions based on IAM policies.
This is really slick stuff, but it does require a lot of configuration and customization on the part of the AWS customer. I think the market need is great enough that someday we’ll see a standards-based, resource-aware API authentication and authorization product from Amazon delivered as a first-class, named product, not an orchestration tucked away in a tutorial.
Other
- More about the discovery of the APIs out there and simplifying communication with them if I’m a consumer, knowing it’s out there and getting up, running and communicating as fast as possible. We're starting to see this with open-API specification.
- The tools are getting there. It's more about the industry maturing, getting there, ready to support APIs. Making tools easier and more accessible. Tools become more integrated.
- Having a fleet of various APIs doing a specific job and doing it well is aligned with the Unix philosophy. This will give room for developers to focus solely on their core project and delegate redundant work to an already well-working service that will ensure quality and efficiency. The drawback is that often, these APIs won't be free and adding many of them might increase the monthly bills significantly.
- Smaller, more efficient, have to be multi-language, there are opportunities for using some styles internally versus externally. GRPC a binary format developed by Google is a much more efficient way to communicate internally. Externally you still need something like REST that’s more agnostic and user-friendly. More adoption of GRPC and APIs internally. We'll see APIs presented in multiple formats – one in internal and one in external formats.
- In the short-term, HTTP/2 will quite probably have a broader impact than it currently has, on the very form of APIs. Use cases that were unachievable — communication patterns that were clumsy to realize are now possible. This power is not leveraged just yet.
In the long-term, true data (and possibly compute) decentralization could seriously change the game. The tools to realize this concept are still in their infancy, though. The most advanced enabler today being the blockchain paradigm. It is awesome to see so many companies exploring how blockchain could solve better-solved problems, tackle unsolved problems — it will be full of learning. - While OpenAPI Specification (OAS 3.0) adoption is still very high compared to RESTful APIs, some companies and technologies are moving beyond SOAP/XML and WSDL/WADL-based APIs. New advances in technologies like HTTP/JSON-based RESTful APIs are being adopted and serving industries very well.
Additionally, non-HTTP-based APIs are also on the rise making gRPC, asynchronous APIs (messaging, streaming, publish and subscribe) the focus for some companies. For example, AsyncAPI specification was built to address non-HTTP-based asynchronous APIs such as MQTT, Kafka, WebSockets, AMQP and STOMP protocols. This is where the opportunity lies for API management vendors and the rise of transformers — a tool to transform API specifications from one format to another.
Another opportunity for API management vendors includes expanding offerings in API Operations (APIOps). APIOps will be applied to API in a similar way that DevOps is applied to the development lifecycle of software. For example, GitLab offers the complete DevOps tools for the API lifecycle starting from project planning, source code repository to CI/CD for monitoring, security, issue tracking features all in one place for enterprises. All of the above can be hidden behind the API management platform. - Considering the costs, or security issues that get created when the costs are not spent to properly maintain APIs, we need a better way. GraphQL, SPARQL, and data security co-resident with data offer an attractive future. It simplifies, offers additional utility, and puts data security where it needs to be in our multi-consumer world. Blockchain can be used to secure data integrity, allowing consumers to prove the origins of information. We sign the apps we download now to ensure they haven’t been tampered with, we think equally if not more critically is our data we are transmitting needs similar integrity to prove its origins and that it hasn’t been tampered with.
- In the future, most of the data would’ve to be generated, sent and received in real-time. Given that data volumes generated every day are growing at an extremely high pace, developers will soon need more cloud-native and scalable solutions for managing APIs. Legacy API management solutions are already too slow and aren’t always able to scale horizontally.
Here's who shared their insights: