Your customers expect API excellence. Can you deliver?

To meet performance, security and reliability needs, modern app architectures need to reimagine API management

Sponsored When your app runs smoothly, the user is experiencing API harmony. Under the hood of modern applications, engineers have architected and implemented dozens of APIs that talk to each other.

Those APIs scale up and down, request information, and, when they are working properly, deliver what looks to the user like a lightning-fast and intuitive application experience. Consider a popular app like Lyft. Under the pretty customer interface, Lyft pulls together numerous API connections: for payment, for geolocation, for voice calling, for images. Lyft also includes a “Concierge API” that allows developers of other applications to build a button to call for Lyft rides into their own application experiences.

Truth be told, APIs have long played a crucial role in application delivery. From football results to flight status data to threat intelligence or AWS instance memory utilization rates, most application teams rely on third-party or internally served APIs to make modern apps shine. The difference is in the degree. In the past few years, APIs have moved from part of application design to becoming nearly the entirety of application design. APIs control every aspect, from the shopping cart to traffic management for East-West traffic in the data centre. In that regard, we have entered new territory with APIs.

With the rise of Kubernetes, containers and microservices, modern application architectures have shifted orientation. In Kubernetes and microservices, decoupled functions talk to each other via API. (Kubernetes is built as an API-first orchestration engine.) In this new realm, API design and management becomes critically important. Your APIs are your microservices are your apps. Your design and management approach to APIs is just as important as those for data, privacy, compute and networking – and is crucial for the success of any of these areas, as well.

Designing an API experience 2.0: Four principles

This presents both challenges and opportunities – something we call a journey toward API Experience 2.0. We all know the terms UX, DX and CX. It’s time for us to recognise and define another term – API Experience or APIX. Going forward, because development teams will spend so much time working with and around APIs, how they experience those APIs will become as a key requirement and evaluation criteria item for DevOps and GitOps teams. APIX also directly impacts users, both internal and external. When APIX is anything less than great, users will experience less than perfect user and application experiences.

APIX 2.0 begins with a reflection on what can be improved in the way APIs are being architected, implemented and managed. Core to this journey is transforming API management (APIM) and modernising API gateways to keep in step with emerging and evolving application architectures. This must be done from a user-centric point of view, both for end-users and developer-users. All APIs hide business complexity to some degree and take something that would have been hard to build and make it easy to consume. The challenge is making sure APIs are uniformly and securely designed, easy to use, and performant.

Principle 1: Design a uniform experience based on explicit guidelines

Every enterprise building and consuming APIs at scale should consider creating API design guidelines and an API evaluation checklist. This allows your team to standardize the design and consideration of APIs for adoption and use. In the era of distributed teams, driven by microservices, numerous service owners are responsible for the design and maintenance of their APIs. Applying common rules relating to API standards and policies enhances the efficiency of planning and designing, developing, testing, deploying and retiring an API. This can be boiled down to pretty simple questions like: Is the API well documented? Does it have a specific security policy? What is the capacity of the API? Does the API have a clear owner? Can you manage the usage of the API with common API management tools or gateways?

Having these principles alleviates complexity that previously accompanied managing API lifecycles. Managing API lifecycles is a daunting challenge because the governance aspect imposed by security and enterprise architects are typically not considered by the developers. This API lifecycle management entails collaboration among developers and consumers as iterations of APIs are versioned and packaged into multiple products for distribution. Too often, companies try to bend APIM tools to accommodate diverse APIs – effectively “bolting-on” API management. This creates complexity, edge cases, and problems. In fact, the reverse is preferable, where the API is designed or redesigned to match the guidelines. Doing it this way will deliver better APIX results.

Since APIs are used across mobile, cloud and on-premises apps, API gateways can provide a central point where organisational leaders and stakeholders enforce best practices and controls or ensure the correct policies are applied to each set of APIs.

This journey to APIX 2.0 does not necessarily require your organisation to lift and shift your legacy applications to the cloud. For instance, instead of shutting down or rebuilding a back-end legacy core system, a bank can develop APIs that enable modern apps to access its data. In Singapore, Deloitte worked with the Association of Banks and the Monetary Authority to identify and map 5,636 system and business processes common to financial services firms to a collection of 411 APIs. These APIs help to accelerate development of solutions ranging from blockchain-driven trade finance to a virtual-reality retail branch experience.

All of this is greatly improved when an organisation creates explicit guidelines for API design and approval.

Principle 2: Formalize service ownership

Beyond the software development team, any part of the organisation can publish its own APIs or use third-party APIs. Hence, inventorying APIs in use is a critical first step toward establishing adequate API controls that can be centrally managed and even automated.

APIM tools can make APIs more discoverable by incorporating an inventory of services or a service catalog. With thousands of APIs running at any one time, it’s very difficult to track how many services there are and what they do. In other words, a key enabler of consistent APIX 2.0 is the service catalog. The catalog’s record of service ownership also provides the visibility to manage the API lifecycle since APIs are operated in a distributed way.

In the catalog, a team or an owner must be defined for each service or group of services. Without establishing service ownership, managing the API lifecycle is not possible. Miscellaneous APIs may be left to run unattended for years; remaining active but forgotten. An abandoned but active API poses a massive security risk; APIs are increasingly targeted by criminals for attacks on financial services institutions, for example.

Integrating the service catalog concept into the APIM tool enables the enterprise to get a full picture of how services are performing and who is using them, and to make smarter decisions about which APIs to keep and which ones to cut. For instance, it’s probably wasteful to run a service that is only taking 10 requests per day. Instead, you may decide to bundle APIs from different lines of business (LOBs) or business units (BUs) as a product. But without explicit ownership of APIs, then these considerations are time-consuming and painful.

Bottom line – an API without an owner may be worse than no API at all.

Principle 3: Design for economies of scale, economies of scope, or both

Other key factors in the APIX 2.0 conversation are economies of scale and economies of scope. Companies like Netflix may be narrowly focused on streaming but the scale at which they operate is astronomical. Such companies need to be able to deliver APIs and services at scale. They benefit from a lower average cost of managing the lifecycles of an increasing volume of services.

On the other hand, banks usually need to focus on greater economies of scope to support their many products and business units. These companies prioritise functionality over scalability. They benefit from lower average costs when costs are spread over a wider variety of services. Organisations designing to optimize APIX and deliver a premium API 2.0 experience must recognize which economy of design they are striving for in each API, and consider that in decisions on bundling, scaling, securing internal APIs or pulling in external APIs.

In other words, know what economy you are building for or trying to emulate and use that to guide your API design and choices.

Principle 4: Make it easy to manage

To deliver APIX 2.0, CIOs must also deal with the tyranny of complexity in today’s application environments. API gateways are designed to tame this complexity. The gateway needs to manage third-party APIs, APIs from microservices and lightly exposed APIs buried inside monoliths.

While APIs make microservices easier to build and manage, traditional APIM solutions are not designed to handle containerised, cloud-native and multi-cloud environments. Sophisticated APIs often require interactions between multiple applications and services, with complex business logic. This complexity and chain of nested dependent interactions increases security risks and exposure of sensitive data.

For this reason, the NGINX Controller API Management Module features an innovative architecture that reduces complexity. By decoupling the data plane (NGINX Plus) and the control plane (the API Management Module), API runtime traffic is isolated from APIM traffic to enable more deterministic and efficient processing.

As a case in point, after deploying NGINX as its API gateway, CapitalOne was able to decommission three commercial gateways and still process 12 billion requests a day at latencies as low as 10 milliseconds.

Conclusion: You are already on the journey to an awesome APIX

Whether you said it or not, chances are you and your team are already on the journey to building an APIX 2.0. This is the natural outgrowth of adopting and growing into APIMs and API gateways. Effective APIM and gateway management helps businesses to integrate internal systems and break down silos, foster collaboration between developers and functional teams, and connect microservices. APIM can make visible key ownership and security properties of APIs. By effectively deploying APIM and gateways based on the guidelines you have created, you and your team can deliver a uniform experience throughout the lifecycle of your apps hosted in any location. You can do this whether they are cloud-native project or legacy apps running in on-premises data centres.

That said, a great APIX does not simply happen. It must be a conscious effort, carefully guided and managed. We hope the four principles I have laid out here, with the assistance of a number of key API experts in F5, can give you a solid foundation for designing a better API experience for your developer, customers, partners, and users. APIs are now the roads and bridges that make modern application architectures possible. Maintaining and building out this virtual API infrastructure will play a big role in determining the success of your applications – and by extension, that of your company.

Sponsored by NGINX (part of F5)