DEV Community

Cover image for Should I introduce an API Gateway in my workplace? A team oriented answer
Dan Lebrero
Dan Lebrero

Posted on • Originally published at danlebrero.com on

Should I introduce an API Gateway in my workplace? A team oriented answer

A while long ago, a friend asked for some advice regarding introducing an API gateway (API GW) into his company.

As I was a little bit surprised about my own answer, I want to share it here.

Context

Paraphrasing the question:

I am working in a company that has three different development teams. Each team is building their own services, which are exposed directly to our customers. There are lots of inconsistencies between the APIs exposed by the three services, which our customers have to deal with. Would you recommend us to introduce an API gateway?

As we both have worked together, we had a shared understanding about what we meant by an API gateway. Given the broad and generic term that it has become, the main functionalities of our API gateway were:

  1. One place to have all the common functionality required when exposing APIs externally: authentication, authorization, rate limiting, A/B testing and other routing requirements. Also it can take care of some caching, downstream service error handling and i18n.
  2. Make the heterogeneous internal services look homogeneous to external clients: naming conventions, concepts, url structure, versioning, timestamps, pagination, …
  3. Provide a more coarse-grained API.
  4. Keep backwards compatibility on external facing APIs, while internal services can evolve.

And from an architecture point of view, the change would be from this:

Before API GW

To this:

After API GW

Pure technical answer

Nobody would argue that having a homogeneous, coherent API that shields clients from possible internal API changes is very valuable.

Our clients will love it.

Our developer will love it.

But you need to think about the cost.

What the cost is

When we talk about cost, we usually put too much emphasis on the initial investment.

As I told my friend:

I think the initial cost of building the API GW is not huge. You can build it over a weekend, or a team of four can do it over a couple of months.

Jokes aside, that last sentence has a kernel of truth, which gives us a clue about the kind of cost we should be more wary of.

Keeping with the conversation:

The issue that I see is the maintenance: who is going to own the API gateway?

Because the most important thing on the architecture change is the change on team dynamics, from:

Before API GW team structure

To:

After API GW team structure

With this new team setup, you have to start thinking about how the different teams will interact between each other:

  • How internal service changes will need to be implemented and rolled out?
  • What information needs to be shared between the API team and the other teams?
  • What meetings will be required?
  • Who will decide on priorities?
  • Where will some of the functionality will be implemented: API GW or internal services?
  • Who can veto an API change?
  • Who can veto an internal service change?
  • How will support be handled?
  • ...

This is not to say that the new architecture is worse, but that all these questions should be taken into consideration when deciding if an API Gateway should be introduced or not.

Of course, this new team setup is just one of the possible ones. There are plenty of others (none of which is wrong) that will give different answers to the questions above, like:

Shared responsibility, no accountability

Where all teams own the API gateway, but nobody takes accountability.

Everybody responsible for API GW team structure

The API Council

Where all teams agree to meet monthly to agree on API rules, and that is the only agreement that is ever reached.

The API gateway council

The Architects Overlords

Where all powerful beings dictate the API rules for mortals to implement.

Architects overloads on their ivory tower

The Ignored Embedded Architects

Where architects work along side the development teams, and meet monthly to whine about how their wise advise is completely ignored.

Embedded Architects ignored by the team

The All Powerful API Framework

Where the Platforms team provides a mandatory API framework so that teams can run their own API-rules-compliant gateways, and where all teams do their best to avoid, circumvent and replace with battle tested Open Source alternatives.

Shared Platform API framework

A Team oriented answer

So to answer the question "Should I introduce an API Gateway in my workplace?" the main concern, and what you should focus on, is not the technical aspect of it.

The important question to answer is:

What are the team dynamics that you want for you company, given its current context?

Conway's law at its best.

Top comments (0)