The Linux Foundation announced today that an open source application programming interface (API) gateway known as KrakenD has become the latest project it will oversee.

Rechristened the Lura Project, the lightweight stateless API gateway was originally developed by KrakenD, which plans to continue to offer an enterprise edition of the platform.

KrakenD CEO Albert Lombarte said the API gateway it developed provides a more streamlined approach to managing APIs that doesn’t require an organization to install a separate proxy or database. All the reverse proxy capabilities most organizations require is already embedded within the API gateway. That approach also makes it easier for IT teams to decouple back-end server applications from client applications because now an API can be more easily updated without impacting client applications, Lombarte added.

Organizations that already contribute to the ongoing development of the API gateway include 99P, Hepsiburada, Openroom, Postman and Stayforlong. The API gateway also is embedded in a variety of other platforms, said Lombarte; he noted that the number of servers running the gateway now exceeds more than one million per month.

API gateways have been available in various forms for years, but with the rise of microservices the number of APIs organizations need to deploy and manage continues to rise steadily. Each microservice added to an environment adds yet another API. At a time when microservices-based applications are at the core of many digital business transformation initiatives, IT teams must employ a more flexible approach to managing the interactions between APIs.

Thanks in part to the role they play in enabling digital business transformations, APIs are also being targeted more frequently by cybercriminals that have come to view them as an efficient way to exfiltrate data or inject malware into an application environment.

It’s not clear what impact the Linux Foundation’s support might have on organizations’ selection of one API gateway versus another. In fact, many organizations are still trying to navigate when to employ an API gateway versus relying on proxy software to manage a handful of APIs versus a service mesh to manage thousands. The issue comes down to not just how many APIs there are, but also the overall weight of the platform being employed, said Lombarte. A service mesh typically requires more time and effort to deploy and manage, he noted.

As the number of APIs in an IT environment continues to increase, there may come a day when organizations will have to revisit how APIs are created and maintained. All too often, APIs are still created as an afterthought once an application is created. They tend to be brittle and, as a consequence, still break often. A more holistic approach to managing APIs based on a set of DevOps best practices is required. The challenge is getting DevOps teams to prioritize APIs when there are so many other issues that require their attention. Nevertheless, it’s become apparent APIs are, in many cases, becoming too strategic to the business for their management to be left in the hands of a single development team.