6 open source projects to boost your cloud-native API management game

We were very excited to be invited as speakers at the Cloud Native Computing Foundation’s KubeCon+CloudNativeCon in Amsterdam this year! 

Our KubeCon special edition stickers were extremely well received. But what made the experience even more awesome was connecting with many community members and learning about the latest trends in cloud-native environments.  

Being able to share ideas, talk about obstacles, and share tips with other experts in the field is priceless. The cloud-native world is perpetually evolving, and staying on top of the latest developments is essential to offer the best experience possible to our users.

We want to share the knowledge we gained at KubeCon with you so that you can stay ahead of the curve and optimise your API management practices for the cloud-native landscape. 

 

Check out our top six open source projects people couldn’t stop talking about at Kubecon and how we think they could help boost your API management game!

Argo CD

Argo CD is an open-source GitOps continuous delivery tool. It monitors your cluster and declaratively-defined infrastructure stored in a Git repository and resolves differences, effectively automating application deployment.

API platform teams are looking at replicating the solid and proven principles of DevOps and GitOps. Applied to the API Lifecycle, this concept is known as APIOps. 

APIOps help teams achieve faster, repeatable deployment into their API ecosystem, whether it is to onboard new teams or to deploy into existing environments. Ultimately it is always about being able to release faster with confidence.

Any API platform team looking to implement APIOps should check out ArgoCD. 

OpenTelemetry

OpenTelemetry is a collection of tools, APIs, and SDKs to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) that help you analyse your software’s performance and behaviour.

We believe that OpenTelemetry has an important role in the future of API observability. API platform teams often work with tens, if not hundreds, of development teams, often using different observability tools. OpenTelemetry with the OpenTelemetry collector will enable the API platform team to define observability pipelines and control the telemetry data they export to other platforms, allowing them to obfuscate any confidential information.

To enable this, API gateways need to provide good quality telemetry data out-of-the-box and include API-related metadata in the distributed traces like API name, API owner and even team or organisation.

Also, if you are curious about GraphQL’s current support in OpenTelemetry, Ahmet and I gave a talk about that topic – which you can watch here:

OpenPolicy Agent

We attended the OpenPolicy Agent meetup in the Miro office with a gorgeous view of Amsterdam:

Open Policy Agent (OPA) is a policy engine for cloud-native environments. It provides a unified framework for policy enforcement across the stack. OPA allows you to decouple policy decisions from your services, APIs, and microservices and manage policies separately from your application code. 

OPA can be used in API management to declaratively define and enforce policy at multiple layers. From the management level, am I even allowed to publish this type of API to that gateway? To the proxy layer – is the bearer of this token permitted to access this endpoint in my REST API?

At the OpenPolicy Agent meetup in Amsterdam held during KubeCon, we were fascinated to learn how Miro and Bankdata implemented OPA but we also learned that GraphQL field authorisation is in the works. 

Keycloak

Keycloak is an IAM solution that provides centralised authentication and authorization to applications and APIs. With a complete, ready-to-run IAM service in a single, lightweight container image, Keycloak is very easy to deploy and scale. 

Keycloak recently joined the CNCF as an incubating project, but it has already had significant adoption in the industry.

Anybody managing API security in a cloud-native environment needs to look at Keycloak, whether to configure Single Sign-on (SSO) access to your app or for onboarding clients via your developer portal using Dynamic Client Registration (DCR).

Backstage

Backstage is a platform for building developer portals. It unifies an organisation’s tooling, services, apps, data, and docs into a single UI that allows developers to easily create, manage, and explore software. An internal developer portal is also a key tool to support InnerSource. Innersource is a software development methodology that applies the principles of open source software development to an organisation’s internal software projects. It involves sharing code, best practices, and knowledge among development teams within an organisation, enabling them to collaborate more effectively and efficiently.

Backstage was created at Spotify in 2016 when the company grew incredibly quickly, and onboarding new engineers was becoming a challenge. The project became Spotify’s mission-critical tool for containing software chaos and empowering engineers to work faster and more efficiently. Spotify open-sourced Backstage in March 2020 to share its experience with the broader community, and Backstage joined the CNCF in 2022.

What does it mean for API platform teams? We see many teams integrating with Backstage to increase the discovery of their company internal APIs, along with any documentation, best practices and information about authentication. But also to share templates, guidelines and tools to on-board new APIs to the platform. 

Wasm

WebAssembly started in the browser. Some standards take a while to adopt, while others can be quick evolutionary events. Wasm gained significant community support, and application for this technology is becoming popular on servers and at the edge. 

In 2019, WebAssembly officially became the 4th language of the web. WebAssembly provides a compilation target that many different languages can support. WebAssembly can’t really do much without being provided with a function to do so by the host – This makes Wasm secure by default. In 2019 the WebAssembly systems interface (WASI) was also introduced to us so that we could take Wasm modules and embed them into use-cases outside of the browser.

Today, Wasm is well on the way to becoming the best and only plugin system you will ever need. If you wanted to extend Open Policy Agent, tweak your OTel collector, enable custom API monetisation models, or even write custom middleware for Tyk, you could use a Wasm plugin.

Check out Bailey Hayes’ excellent talk on the evolution of Wasm: past present and future where she provides an introduction to the WebAssembly component model. A promise of better language support and interoperability potentially offers major changes in how we write software.

What about Istio and Linkerd?

There’s one question that everybody has been asking themselves about service mesh: is sidecar-less service mesh the future? 

Istio introduced ambient mesh, a new sidecar-less data plane option for Istio service mesh based on eBPF to reduce infrastructure costs for Istio mesh users. Linkerd maintains the position that sidecar-less is a major step backwards in operability and security. 

Service meshes are often associated with API management but to us, it doesn’t really matter as API Management should be able to work seamlessly with any mesh – whether in a sidecar, or sidecar-less mesh, monolith, and also interoperate seamlessly outside of cloud native environments too.

One thing is sure, we are keeping an eye on eBPF and the future innovations in that area.

Thank you KubeCon Europe 2023 – it was a pleasure to be part of this event! See you next time in Shanghai, Chicago or Paris.

This blog also features contributions from Ahmet Soormally and Budha Bhattacharya.