Modern-day software development has made APIs more important than ever. Whether it is microservices, Agile or digital transformation, developers need APIs to connect data, apps and devices. In order to be able to deploy, manage, and run all the APIs necessary for their solutions, they implement API management strategies to make sure everything goes smoothly. 

RELATED CONTENT: 
A guide to API management solutions
What should you look for in an API management solution?

This has been the API status quo for the last couple of years, and API and API management have been steadily moving along. 

“API management is a pretty mature discipline now. When API management companies like 3scale were conceived 10-12 years ago, that was really a response to a real need from Agile developers who were saying our interoperability needs are not met by the ESB (Enterprise Service Bus) model that had dominated for 20 years up until that point,” said David Codelli, senior principal product marketing manager for the open-source software company Red Hat. “Today API management is doing an outstanding job of allowing microservices teams to get the interoperability and the self service they need. It is a well established business for mature companies.” 

But as time has proven again and again, most things in software development don’t stay the same for long. The advent of these modern software techniques has spurred new technologies to support the new techniques, and API management will have to evolve to continue to meet the needs and expectations of users. 

API management and the service mesh
The microservice architecture has introduced a new concept over the last couple of years to help deal with the overall visibility and insight into microservices. A service mesh is “a way to control how different parts of an application share data with one another,” according to Red Hat. While microservices enable developers to easily make changes to their services, a service mesh is used to handle the service-to-service communication.

According to Kevin Matheny, a senior director analyst for Gartner technical professionals, service meshes and API management are related, but also very different. Over time, developers are going to start, and some have already started, to combine service meshes into their API management initiatives. 

“Our customers are engaging with us to try to sort out the landscape and figure out what is complementary and what is overlapping. What are the ways they can build a plan to capitalize on both: advancements in service mesh and advancements in API management,” said Red Hat’s Codelli.

Matheny explained since this is a new emerging space, a lot of users are having trouble understanding how to bring those together. “API management is about gaining access to the APIs that are exposed to an application. Service mesh is about the peer-to-peer connectivity, the API connectivity inside of an application. Many organizations think because they have a service mesh, they don’t need API management, and that is not the case,” he explained. 

A service mesh is necessary to handle the service-to-service communication within independently deployable pieces of software that are loosely coupled. However, a service mesh does not provide the same set of functionality that an API gateway does. API management is necessary for any internally or externally exposed apps, and a service mesh is necessary to handle the side-to-side communications, Matheny explained. 

“The way to think about it is east-west versus north-south communication. Your north-south communications are API gateway-based. Someone from outside the organization wants to get something. In the case of a microservice-based application, it is that another application wants to get something from this application. Then that is mediated by an API gateway. But inside the boundary of your microservices cluster, the peer-to-peer connections — the east-west connections — are handled using the service mesh,” Matheny explained. 

The confusion comes from traditional architectures such as monolithic applications, where peer-to-peer communications are also handled by an API gateway or micro gateway. “You’re not taking advantage of the greater scope of functionality that API management platforms offer. Monolithic applications really narrow it down to just the gateway portion, so that tends to wind up with people saying this gateway portion can handle service-to-service communications between applications and a service mesh handles that. The implementations are different and the scope of use is different,” said Matheny. 

One way Red Hat tackled bringing the two together was by adding an adapter in the service mesh Istio to provide API management capabilities through Red Hat Integration. These capabilities include developer self-service and on-boarding, API documentation, monetization, and usage analytics. “We also want to make sure our customers understand that the higher level of API management like billing, rate limiting, analytics and developer portals are not addressed by Istio, so we encourage customers to look at the whole picture in planning out their API strategy,” said Red Hat’s Codelli. 

Codelli noted this space is still in its very early days and it will be at least a year until real product manifestations come to fruition. 

API management as code
The next big thing after service mesh for APIs will be APIs as products or API management as code, according to Red Hat’s Codelli.

“There has been a lot of buzz around infrastructure as a service, where you can program your information technology landscape, and we are starting to embrace that in API management efforts so that users have a development pipeline that orchestrates their hardware and software resources as well as API artifacts,” said Codelli.

Codelli went on to explain that things like opening an API contract, mock services, service metadata, configuration of policies, and configuration of other API management aspects such as security, will start to be managed units that undergo the same scrutiny and testing as the code for APIs. 

“This will save overhead, ensuring predictable and lower risk deployment, streamlining deployment cycles, being able to provide better resolution. Those are all the same things we got with infrastructure as a service and we will get even more as we do API management as code,” he said. “APIs are extremely important and the benefits of instrumenting it as code are going to be extremely important.” 

Treating your internal APIs as first class citizens 
While API management for public APIs is very well understood today, organizations are not providing the same treatment for their internal APIs, according to Gartner’s Matheny.

“Clients are aware they need things like endpoint protection, consistent security policy enforcement and traffic management for publicly exposed APIs, but tend to think internal APIs are lower risk because it only has internal connections,” he said. “But if your internal APIs are used by public facing systems, you should be treating them with the same level of rigor you do with your external facing APIs.” 

“You should be thinking about the fact that an internal API services a public facing system. The consequences of an outage could be severe, and organizations should ask themselves if this API is capable of producing an outage in a public system,” he added.