The technical oversight committee for the Cloud Native Computing Foundation (CNCF) announced today that an emissary-ingress gateway for application programming interfaces (APIs) and an ingress controller designed to run natively on Kubernetes, formerly known as Ambassador, has become an incubation-level project.
The emissary-ingress gateway was originally developed in 2014 by Ambassador Labs when the company was known as Datawire. The gateway is built on top of open source Envy proxy software that is also a CNCF project.
Ambassador Labs CEO Richard Li says the emissary-ingress project provides a more efficient approach to managing APIs, because it relies on Kubernetes for persistence, which eliminates the need to deploy a separate database. Kubernetes can also automatically restart emissary-ingress if any problems are detected.
Contributing emissary-ingress to the CNCF will make it easier for contributors, that often participate in multiple projects spanning application connectivity tools, to collaborate with one another. The lines between where one application initiative project picks up and another one ends are increasingly becoming blurry, notes Li.
The road map for the emissary-ingress project calls for adding support for Web Assembly (Wasm), caching APIs and other emerging standards. Contributors have also committed to supporting Service APIs and Ingress v1 as the Kubernetes platform continues to evolve.
Ambassador Labs claims organizations that have deployed the API gateway are able to process as many as 500,000 requests per second across as many as 15 million users. Organizations that employ the API gateway today include AppDirect, Lifion by ADP, Ticketmaster, Chick-Fil-A and OneFootball. Ambassador Labs, in addition to continued contributions to the project, provides an enterprise edition of the platform.
In general, Li says more organizations continue to rely on API gateways and ingress controllers to manage north-south traffic, while a service mesh is increasingly employed to manage east-west traffic. There have been some efforts to extend service meshes to manage north-south traffic, as well; however, most organizations don’t typically have enough APIs running in a production environment to warrant deploying a service mesh just yet, Li notes. However, every organization still needs to manage north-south traffic between data center environments, Li adds.
With the rise of microservices, the number of APIs strewn across the extended enterprise is steadily increasing. Each microservice has its own API that needs to be managed, secured and updated. It’s not clear to what degree IT organizations are moving to unify the management of all their APIs, but at this point, it’s more a question of when, rather than if, a more centralized approach will be required. Each API needs to be managed as its own separate software artifact. However, while developers play a critical role in creating APIs, responsibility for managing those same APIs often falls to IT operations teams.
Regardless of who manages APIs, the days when organizations only had a few external APIs to manage are long over. Today, there are more internal-facing APIs than external ones that organizations rely on to share data between a multitude of classes of applications. The issue, now, is two-fold: first, finding the best way to make all those APIs accessible and second, finding ways to manage them at increasing levels of scale.