Consuming APIs as a Managed Service

The wide-scale adoption of cloud-native development methods for creating applications relies heavily on APIs. And as such, businesses need to better manage their APIs to ensure interoperability, security, and reliability. These efforts take time and require certain skills. Rather than diverting valuable time from developers and IT, many companies are looking to an approach where they consume APIs as a managed service.

Why is this happening, and why now? The main reason is the elevated role of APIs in application modernization and digital transformation. Microservices and container elements make use of APIs to expose business processes and data to other application components. They help developers do everything from quickly providing a new mobile app with access to account data to integrating legacy systems into modern applications.

As such, many companies have shifted to what many call an API-first strategy. Such a strategy enables digital transformation, accelerates innovation, and lets the business tap a broad ecosystem of third-party services, expertise, and applications.

An API-first strategy greatly changes how APIs are created, consumed, and managed. In the past, many APIs were created for a single purpose. For example, a new API would be built when developing a new front end, say a mobile version of an existing application. That API’s only purpose was to connect the new front end to back-end services and data. It would most likely never be used again. If another application needed a similar mobile front end, a different API would typically be created.

That approach is now losing favor. Businesses find that APIs are most valuable when they are standardized so that they can repeatedly and easily combine data and business logic to create new applications and services. And they must be managed so that developers know enterprise-class capabilities (security, availability, scalability, etc.) have been addressed and are available.

Creating and maintaining APIs for reuse helps developers more easily leverage internal assets (e.g., data and processes) to develop new digital products. And it lets businesses share digital assets with partners. For example, a bank might expand its offerings to customers by partnering with a FinTech company through API-driven integration of their respective platforms.

The case for managed APIs

Developers can efficiently reuse existing assets by connecting to an API. However, the interface to all APIs needs to be consistent for this to occur. Additionally, traffic, security, and policy enforcement must be monitored and managed at the API level.

Developers and IT staff need to manage things like API access, policies, and traffic controls. They must restrict traffic based on policies, protect back-end services, impose rate limits, and create access tiers to manage and control flow.

A managed API strategy can bring all of these factors under control. Doing so enables some core use cases, including:

Legacy system modernization: By adding API access to legacy systems, teams can build microservices-based applications while also using existing APIs, applications, and systems.

Monetizing shared services: Businesses can expose services built for internal use to partners, in many cases deriving new revenue from those services.

Innovation acceleration: By using APIs, teams can make all assets–from legacy systems to modern microservices–available in one place where developers can easily access them through consistent interfaces.

The role of a managed service

Businesses can manage APIs on their own or, as is the case with many other infrastructure technologies, they can opt for a managed service. Such a service would allow businesses to:

• Deploy, monitor, and control APIs throughout their entire life cycle
• Create policies governing security and usage
• Use existing identity management systems through a declarative policy without requiring custom code
• Gain insight into health and use of APIs
• Discover and share APIs by publishing to internal or external developer portals

Such a service would provide a streamlined developer experience for building, deploying, and scaling cloud-native applications. Developers using such a service can self-provision the API service and get a fully managed environment in minutes configured to meet their needs in a public cloud.

Ideally, such a service would include a user-friendly interface for configuring, publishing, and monitoring APIs. It also lets users avoid administrative tasks and promotes consistency across all services.

Red Hat recently introduced such a service. Red Hat OpenShift API Management supports teams that want to take an API-first approach to building microservices-based applications so they can modernize existing systems, increase developer productivity, and deliver new applications faster.

Red Hat hosts, manages, and provides dedicated support for OpenShift API Management, including configuration, maintenance, and upgrades, so teams can focus on development rather than managing their Kubernetes infrastructure.