Integration drives Red Hat 3scale API Management platform roadmap

Nothing stands still in technology, so Red Hat API Infrastructure head and Senior Director Steve Willmott has a full plate. On his immediate agenda are the alignment of 3scale with Red Hat JBoss Fuse integration platforms, API gateway evolution and the disruptions driven by service mesh technology.

In 2016, Red Hat acquired 3scale to extend its management capabilities to address the increasing number of public APIs and the expanding use of internal APIs in containers and microservices. Willmott, 3Scale's founder, laid out the key components of Red Hat 3scale's roadmap, compared 3scale with competing API management platforms and offered advice to IT professionals on how to craft API management strategies in this Red Hat Summit 2018 interview.

Which technology areas are important in the 3scale API Management Platform roadmap today?

Steve Willmott

Steve Willmott: The API gateway story is changing because there are now different gateway needs in different environments. This evolution is driven by widespread adoption of container, orchestration and microservices technologies. The interplay between this service mesh technology and API management will change how gateways are used.

Red Hat has invested heavily in Istio, a service mesh platform. This will help us make 3scale's perspective plug in to all of those services and provide a view into how APIs and the different levels of services connect to each other. The result will be better control of APIs and services than we have today.

In the integration area, we'll create higher-level connections with Fuse integration environments. The Fuse customer base is shifting to include both developers and citizen developers. For 3scale, the future will call for tracking APIs and managing the software code behind them for both groups. We have to think about empowering more people to be productive with the IT assets. The more you can surface technology to other people to be productive, the better.

What are best practices for forward-looking enterprise API management strategies?

Willmott: Organize your API team as an enabler team, not as an owner team. If your API team does the APIs for people, owns them, does the management and keeps control of it, that team will become a bottleneck. Instead, empower different groups throughout the organization to create their own APIs, manage them and consume them. Provide tools, and enable them with knowledge and guidance.

In an API-first initiative, do not try to rewrite and put APIs everywhere at once. Look at the business and IT roadmaps. Look at your API's full lifecycle. Then, identify projects that will benefit from an API-first approach the most. Make it a gradual process.

Don't just create APIs galore. We've seen a few companies create a bunch of APIs that now don't get used. This is a waste of engineers' time.

How does open source differentiate 3scale from other API management platforms?

API management touches almost every possible system the customer has.

Willmott: By this summer, everything inside 3scale will be open. Being open source is a big thing because the majority of enterprises use open source software now, and API management touches almost every possible system the customer has. With open source inside, 3scale can improve interoperability and integration between APIs and other endpoints.

Innovation opportunities are another advantage of open source software. We already have 3scale customers contributing to the code base, and we anticipate that growing. This collaboration will be meaningful in tapping into the community's creations and, in many cases, putting them it into the product.

In what other ways does Red Hat 3scale differ from other types of API management platforms?

Willmott: Some vendors -- such as Google Apigee, Axway and CA -- focus on gateway-centric API management. There's value in this approach because API gateways supply the programming that enables many capabilities, from traffic filtering to monitoring and more. That said, the gateway-centric focus can be problematic if you want to manage APIs across your entire organization.

Red Hat 3scale's approach is to separate the data plane from the control plane. This enables flexibility in how organizations deploy API management, distribute gateways and deploy the right gateway in the right form factor. The gateways are free, and you can deploy as many gateways as you want. They're based on the Nginx web proxy. This is a similar approach to the service mesh and will be useful as it evolves.

An enterprise service bus [ESB]-centric model focuses more on integration with an API spin. This has value if integration is the most important part of an API strategy. The challenge here is that people may end up routing their traffic through some complicated loops. Also, traffic may become too centralized, as in all mobile app traffic suddenly going through the ESB.

Red Hat 3scale's approach is different. We allow the customer to deploy as many gateways as they like, but we still give them a view across everything. Each of those gateways can work autonomously. It's an architectural difference.