Introduction

Platform teams exist to turn messy, repeated infrastructure work into self-service capabilities that product engineers can adopt without filing a ticket. Webhook delivery is exactly that kind of work. Every service that sends or receives events needs retries, signing, and routing, and rebuilding that team by team is pure toil. A webhook gateway packages those concerns into one paved-road service your internal developer platform can offer. Puppet’s State of DevOps Report, which surveyed hundreds of developers both with and without platform teams, found 60% reporting improved system reliability, 59% greater productivity, and 57% better workflow standards. We think a webhook gateway belongs in that toolkit, and in this article we share why.

But, first some definitions. :)

What is Platform Engineering

Here’s a definition according to What is Platform Engineering?

Platform Engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform Engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.

Essentially, the platform team exists to enhance the productivity of the product-focused engineers, this is why Sam Newman in his recent article — Don’t Call It A Platform , advocates for a better name like “Delivery Support” or “Delivery Enablement Teams”. It is useful to highlight the dichotomy between Site Reliability Engineers and Platform Engineers. This article from Ambassador Labs shares an insightful image:

Put simply, the SRE runs the underlying infrastructure while the platform engineer provides the underlying infrastructure as a service (product) to product teams with baked in standards for the specific organisation. If you’re looking to learn more about the difference between a SRE and a platform engineer see here.

What is a Webhook Gateway?

In short, it's the dedicated service that manages event delivery between webhook providers and consumers. It owns retries, signing, and routing, acting as both a reverse and forward proxy for the API providers sending webhooks and the consumers receiving them. The full breakdown lives in the guide linked below.

Source: What are Webhook Gateways?

It exists to provide a consistent infrastructure for end-to-end webhooks management for engineers.

Why are Webhook Gateways important to Platform Teams?

Now, that we’ve set up the foundation of these terms, let’s talk about why they’re important to platform teams:

• Cross-Cutting Concern: Webhooks management are easily a cross-cutting concern. In a growing organisation, several backend services would more often than not, send or receive webhooks; how then do we apply retries, rate limiting, circuit breaking etc. to sending events to client endpoints consistently across the organisation? If unchecked this can rapidly deteriorate into massive code duplication, inconsistencies and a big ball of mess. This is where platform engineers step in, to bring sanity to cross-cutting concerns across an organisation and enable developers focus on core business problems.
• Developer Productivity: Developer time is a scarce resource. Product-focused technology companies more often than not are always hiring for brilliant engineers. The degree to which engineers are solving core business problems, I believe is directly correlated to the degree to which users would receive new features and bug fixes. Engineers can’t move fast and solve customer problems if they aren’t constantly battling with their tools. This is where platform engineers come in. It is said that the best SRE and platform engineers constantly find and eliminate toil.
• Standardisation: How long does it a new engineer to fully onboard and get productive? When switching teams in an organisation, how long does it take for an engineer to onboard the new engineer? What is the learning curve of these tools? Standardisation helps scale a growing organisation with best practices. This standardisation typically the responsibility of the platform engineers. Reduced learning curve etc.
• Improved Security: Security shouldn’t be an after-thought. The Entire DevSecOps movement was built around this idea. Webhooks carry sensitive data; providing a consistent secure platform where best practises are baked-in from the onset is an elite team practise. Platform engineers can work to ensure security across all webhooks sent and receive across the organisation.

Why Convoy? & How do I get started?

Convoy is an open-source high-performance webhooks gateway to manage millions of webhooks end-to-end. It is designed to be an highly scalable multi-tenant webhooks gateway to support multiple backend services sending and receiving webhooks. It comes baked in with several features like retries, rate limiting, circuit breaking, customer-facing webhooks dashboards, support for both sending & receiving webhooks and a lot more.

We recommend starting by installing Convoy in your own environment, or trying Convoy Cloud. If you have any questions or you’d like to nerd out about webhooks, shared services and platform engineering, feel free to join our growing community on Slack.

That’ll be all for now. Bye :)