API Management: It's a Twofer!
APIs need to be managed. So that’s the first problem API management solves. But the second is equally—if not more—important. Enterprise architectures are showing their age and cannot compete with the architectures of the digital natives, which focus on scale and lower costs through new paradigms such as eventual consistency.
A good API management solution is typically built to these new architectural principles and enables the API proxy layer to scale at cost. The beauty is that this architecture also serves as a Trojan Horse in the enterprise stack: new services can be written that leverage the API management layer to achieve scale at cost. In other words, it becomes a good Platform as a Service (PaaS) for a certain class of services.
Let’s take an example. Apigee’s API management platform not only proxies our customers’ APIs (i.e. built-out services), but also welcomes new APIs to be written entirely or partially in the API management layer. It does that by letting you “BYOC” (bring your own code) that implements the API.
The API then scales, as does the management of that API. Consider a shopping cart API. The shopping cart “service” could be delivered through an existing backend legacy system (one that dates from the e-commerce days), and its APIs could be managed in the API management layer. But the shopping cart service by itself can sit in the API management layer, implemented as Node.js code leveraging BaaS as the persistence layer.
The API to the shopping cart (/add, /remove) can further be managed (secured, analyzed, exposed, and documented) by the API management layer. If the API layer is implemented in the API management layer, the enterprise gets the scale at cost. And, as an added benefit, there is one less artifact that has to be deployed.
A predominant new pattern is “API-first.” This pattern dictates that all new services be designed from the API down. For this pattern, the API and API management become one and the same. Scaling the API is the same as scaling the API management, and is the same as scaling the service.
We provide architectural building blocks to scale API management: stateless scaling of routers and message processors; stateful scaling using Cassandra and BaaS; analytical scaling using Postgres and Spark; clean contracts for APIs; and the ability to add intelligence to API management. Enabling BYOC provides the same building blocks to scale the APIs (i.e., the services).
As Apigee moves toward a more containerized architecture, this distinction between running the API and running API management will quickly blur.
So API management like Apigee’s is a twofer. Buy it for API management, but use it as a PaaS for running more and more of your services!
What "services" naturally belong in the API management layer? Join the discussion in the Apigee Community.
Start a discussion with Anant by posting a question on the Community—remember to mention "@anant."