Traefik Labs Extends Cloud-Native Reach of API Gateway
Traefik Labs today updated its application programming interface (API) gateway to add support for WebAssembly (Wasm), OpenTelemetry and the Kubernetes Gateway API.
Newly appointed Traefik Labs CEO Sudeep Goswami said the first release candidate for Traefik Proxy v3 extends the reach of the API gateway to emerging cloud-native applications that are gaining increased traction in enterprise IT environments.
Downloaded more than three billion times. Traefik Proxy is a reverse proxy and load balancer that leverages the HTTP protocol and provides a lighter-weight alternative for integrating microservices-based applications. The challenge IT teams encounter is that, as the number of microservices running in production environments expands, it becomes more challenging to manage application networking. An HTTP approach reduces the level of complexity IT teams would otherwise encounter when trying to deploy and update alternative proxy software, said Goswami.
The goal is to make it simpler for IT teams to know what services are running where and also monitor the quality of services (QoS) provided in the context of a service level agreement (SLA), he added.
At the same time, ongoing updates to the Kubernetes environment, such as the Kubernetes Gateway API, require application networks to continuously evolve as, for example, Wasm applications are deployed alongside containerized applications.
On the plus side, OpenTelemetry is emerging as a de facto open source format standard for collecting logs, traces and metrics that are needed to troubleshoot cloud-native application environments. In fact, OpenTelemetry support is now widely considered to be table stakes for instrumenting application environments, noted Goswami.
It’s not clear yet precisely which teams within an IT organization are assuming responsibility for application networking, but as layer 4 through layer 7 of the networking stack become more programmable, more responsibility for networking can be assumed by DevOps and platform engineering teams, noted Goswami. Application networking can now be managed as code in much the same way any other type of infrastructure is provisioned, said Goswami.
Meanwhile, existing networking teams generally continue to manage the physical networking underlays used to route network traffic. Regardless of how application networking evolves, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still all too common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more distributed, the need to programmatically provision networking services is only going to become that much more pronounced. The challenge is making it as simple as possible to achieve that goal, given the general lack of application networking expertise available.
Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications as distributed IT environments are becoming much more complex to manage. The goal, as always, is to eliminate as much friction as possible using automation at time when applications have never been more dependent on networking services.
