California is a gorgeous state, unfortunately known to the rest of the world for its wildfires, a high cost of living and, in some locations, bad traffic. But bad traffic makes for good analogies, especially when it comes to application programming interfaces (APIs). Both traffic and APIs require a bit of advance planning, so let’s consider road planning for a moment as a model for API gateways.
When the Spanish founded Los Angeles, they probably weren’t planning for a population of 12 million people geographically locked between an ocean and a desert and mountain range. So, they didn’t plan their streets for the future. Traffic, since the 1800s, has always been an issue. Public transportation hasn’t helped much. Freeways are often more gridlocked than ancillary roads. Growth and use has always eclipsed capacity. I’m sure today’s city planners wish they could start from scratch.
With APIs, we have the ability to strategically plan our routes for today and the future — acting right now to plan the digital roads that will allow for smooth sailing and avoid frequent gridlock. Once we uncover some of the crucial issues that APIs present, we can then assess the thoughtful solutions that are available to us to help us tame the traffic. Our goal is to answer the question:
“How does the world of APIs change and get transformed by leveraging the cloud?”
APIs began with the concept of simplicity. One road led to one destination. This is why APIs were developed in the first place. We needed one-to-one, easy plug-and-play connections to relieve the stress of coding issues within monolithic systems. APIs answered the question, “What if we could reduce the number of points of implementation impact by creating one-off pathways?” APIs allowed for microservices. APIs allowed us to talk to outside entities much more easily. APIs opened new doors of data that were previously difficult to ingest and consume. APIs allowed the digital world to work in real time.
The issue is that, while APIs have become commonplace, we are running into the danger of creating too many point-to-point tethered connections and losing the value that we had found in the original point-to-point idea.
Right now, much API development and administration is still point-to-point between one system and another system, multiplied by many systems and hundreds of APIs. What happens to API development and administration when you’re dealing with hundreds or thousands of separate APIs? This is like paving a separate road for every commuter where the rules for the road are all different and yet they all cross at random locations. A growing population of APIs without an effective way to manage the traffic represents an untenable future. The cloud takes this impossible situation and makes it manageable and less strenuous for everyone involved.
The stresses in the system that necessitate an API gateway
The simplest way to understand the value of an API gateway is to understand what could go wrong if APIs aren’t managed properly. Here are just a few issues:
- Poor performance and operational inefficiency.
- Lack of effective documentation, responsibility, administration and governance.
- Lack of adequate security.
See also: How API Hub Can Spark Innovation
API gateways tame the traffic
An API gateway acts as a proxy for each of the APIs that it manages.
Let's assume there are 1,000 APIs. Each API is a point-to-point interface. If there is an API between system A and system B, it is a one-to-one relationship. A gateway is a proxy, exposing the public-facing API endpoints. It then routes the incoming client requests to the relevant services. So, let’s say there is a request coming in from an outside entity that needs to go to two different systems internally. The standard process with no gateway would be that there are two calls made: one from the external system to internal system A and one from the external system to internal system B. That’s two calls. Multiply those two calls for each required function times 1,000. This is what leads to latency and traffic jams.
The API gateway not only routes the incoming client requests to relevant services, but it also aggregates the response data from a variety of different internal APIs and sends back the responses with one request. Less traffic to point A. Less return traffic from point A.
The API gateway also acts as border security for anything entering the organization. But, like a border security post, monitoring isn’t just about finding insecurity, it is about organizing tasks and proper routing. At the border, there are queues, split apart by various destinations. If you’re traveling to/from an international airport, you’ve seen how border security works to process people based upon where they are coming from and where they are going. An API gateway efficiently guards the organization’s systems from overuse and abuse by queuing properly. All of the most important performance metrics that would commonly define the success of an API, such as requests per minute, latency, errors per minute and API uptime — are threatened when APIs are distributed and disorganized outside of the gateway.
We should mention here that if an organization isn’t seeing clogged traffic just yet, they will. Insurance customers are increasingly choosing “data-heavy” products and services that will require more API integration and use, as shown in Majesco’s latest consumer research. APIs aren’t going away, and they aren’t becoming fewer in number. Remember the city planners who should have planned ahead. If you are in a position to save your company from future grief by moving APIs to an API platform in the cloud, now is the time to speak up.
API gateways avoid “chatty” outgoing client requests
With distributed APIs and no coordination mechanism, a single outgoing client request can result in multiple round-trip requests. Being able to make a single request to an API gateway, which then routes calls and collates responses is far more efficient. This also dramatically improves performance.
API performance isn’t just about traffic flow, it’s about reducing API traffic “accidents”
APIs are game-changers, so there’s no doubt that organizations are finding them useful in every respect. In some innovative organizations, there is a charter that stipulates that they need to use APIs as the primary nodes of interaction between various systems, both internally and externally. But if you’re doing that and you aren’t using an API gateway in the cloud, you’re running the risk of having a bunch of connected streets and avenues with no sense of logic or a set of rules constructed among them.
Without an API platform-based approach, you run the risk of a network of connectivity where the systems and functions are too complex to understand the impact of changes. When you end up having to either upgrade a particular API or troubleshoot it, it becomes an exercise in network engineering. Imagine being an electrical engineer, sorting through a host of painted wires that are mixed up with no schematic, and you have to literally take out each wire by itself. Simple APIs lose their simplicity as they multiply with no documentation or governance. As the network slows, the errors will grow.
The API platform-based approach brings order to the chaos. Traffic management is far easier because the system knows and understands the APIs and their relationships to one another. And, it’s smart enough to be able to share its knowledge with us, which is something we’ll discuss in a few weeks when we talk about an API gateway and its ability to automatically document the details of each API.
API gateways are cloud-based because that’s where they are effective
If we step back and look at the pre-cloud-driven services world, to implement an effective API gateway would entail a huge amount of redesign, reworking of existing APIs and then making sure that all of the connections, programming and system protocols are aligned. There are organizations that do this, but the cloud has given us a much more logical option.
What we have today is not necessarily “drag and drop” programming, but it's closer to drag and drop than to reprogramming. Cloud-based solution providers like Microsoft Azure have made the process workable and efficient. Everything that an organization would have needed to invent on their own in-house is provided as a standard part of the process. Cloud technology choices are so much simpler because of their ease of use, their pre-built functions and their simple configurability. And, of course, cloud gives us the speed that we and our customers crave in our transactions and communication. There is simply no comparison when working with APIs in-house. Those who do still find themselves turning to hybrid solutions or mirroring data on the cloud to stay secure.
See also: A Cloud Platform's Role in APIs
The “hurdle” of API migration
Of course, one of the biggest hurdles to migrating your APIs to a cloud-based solution is just the decision to do it. The actual migration itself is fairly simple. The API migration playbooks already exist. They are precise, “hands on” directions for making the switch. It’s not neuroscience. The ease of migration is actually one of the greatest motivators to do it.
Cloud providers make it possible to envelop an existing API architecture and a library of existing APIs with cloud-enabled orchestration. They have a toolkit that provides you with everything you need for API discoverability, plus a documentation library, with a system-generated capability of defining new APIs so that you don't have to unlearn and relearn how to define and document your APIs. The process is thoughtful and smart.
Things like security and load balancing are all predefined in these platforms. You simply have to customize the API gateway to your organization's needs. It’s like selecting a new Tesla. You can’t change the primary functions of the car, but you can add the various options that fit your taste. This is what a cloud-based solution does for insurers for organizations that already have APIs. It not only delivers the cloud, but it easily guides IT teams through the process. We’ll discuss this more when we talk about developer and user roles in coming weeks.
In our next cloud blog, we’ll discuss documentation, administration and governance in the new API platform environment. (Spoiler alert: It’s much simpler, highly automated and built for security and consistency.)
